Back to blog

How to document a Minecraft plugin players will actually read

Maya Chen· Content Creator· June 5, 2026 · 3 min read

Open ten random plugin wikis and you'll find the same thing: a page titled "Config" with forty YAML keys and no explanation of what any of them do. That's not documentation, it's a dump. Players skim it for ten seconds, give up, and ask in your Discord instead.

Good plugin docs solve a much narrower problem than people think. Nobody wants to read your plugin's docs for fun. They want to install it, configure one specific thing, or figure out why a command isn't working. Structure around those three jobs and most of your repeat questions disappear.

Split "getting started" from "reference"

These are two different documents with two different readers. A server owner installing your plugin for the first time wants five steps, in order, with no branching. A server owner who already has it running and wants to change the PvP cooldown wants to jump straight to one config key.

Mixing these into one long page means both readers scroll past content they don't need. Put installation, requirements, and first-run setup on their own page. Put every config option, command, and permission node on separate reference pages you can link to directly.

Write the "why," not just the "what"

allow-crafting: false doesn't need an explanation. What happens when a player has an item crafted before you flipped that flag, or how it interacts with your economy plugin, that's the part worth writing down. Config keys are self-explanatory. Interactions and edge cases are not, and they're exactly what shows up in your DMs at 11pm.

A short table works better than paragraphs here:

| Config key | Default | What it actually affects | | --- | --- | --- | | pvp-grace-seconds | 10 | Delays PvP flag removal after combat. Does not apply inside claimed regions. | | economy-sync | true | Syncs balances with Vault. Disabling breaks shop plugins that read Vault directly. |

Give every command its own anchor

If your plugin has thirty commands, a single giant command list is useless for linking. When someone asks "how do I set a home," you want to paste one URL, not "scroll to the commands section, it's near the bottom." Structured pages with a real hierarchy (not one flat Markdown file) make this possible, which is one of the reasons plain GitHub Wiki starts to strain once a plugin has real adoption.

Flag breaking changes loudly

Version bumps that change default behavior are the single biggest source of angry reviews. A callout block at the top of your changelog ("Breaking: home-limit now defaults to 3, was unlimited") takes ten seconds to write and saves you a dozen confused bug reports.

Keep a real changelog page

Not a Discord announcement that scrolls away in a day, an actual page with dates and version numbers. Players troubleshooting an issue want to know if it's fixed in the version they're running, and that's impossible to check if your release notes only exist as chat history.

Make it searchable

However well you organize this, someone will land on the wrong page first. A search bar that actually indexes your reference pages (not just page titles) is the difference between them finding the right command and closing the tab.

This is the exact gap Nectory was built to close for plugin and mod docs specifically, structured pages, a block editor that doesn't require Markdown from your contributors, and full-text search across every space by default. You can see the full editor and wiki feature set on the features page.

Structure first, then write. Most plugin docs fail because of the first part, not the second.