How to set up a wiki for your Minecraft or FiveM server

Every game server collects knowledge fast: rules, commands, ranks, how to join, how the economy works, and how staff handle reports. When all of that lives in Discord channels and pinned messages, players miss it and staff answer the same questions all day. A wiki fixes that by giving everything one organised home. This guide covers how to set one up for a Minecraft, FiveM or Rust server, though the same approach works for most game communities.

Decide what goes in the wiki

Think about two groups of readers.

Players need to know:

• How to join, including the server address, version, mods or resources needed, and whitelisting
• The rules, and what happens if they break them
• Commands, ranks and perks
• How the economy, jobs or progression work
• Events, wipe schedules or season information
• How to report a player, appeal a ban or apply for staff

Staff need to know:

• How to handle reports, warnings, kicks and bans
• What evidence is needed before taking action
• How appeals work and who decides them
• When to escalate to a senior admin
• How to onboard a new moderator

Player pages should be public. Staff pages should be private, so players can't see your internal processes and staff aren't distracted by player guides.

Start with a simple structure

You don't need dozens of pages on day one. A structure like this covers most servers:

1. Start here, covering how to join, the rules and an FAQ
2. Server guides, covering commands, ranks and perks, the economy and jobs, and events
3. Updates, covering changelogs, wipe schedules and rule changes
4. Staff handbook (private), covering moderation procedures, ban and appeal process, and onboarding

For a FiveM roleplay server, add a section for laws and departments, with a page for each department's procedures. For Minecraft, a page per gamemode or world keeps things tidy. Nest pages inside each section so the top level stays short and easy to scan.

Write rules people can actually follow

Rules are the most-read page on most server wikis, and the one most likely to cause arguments. Make them clear:

• Number every rule, so staff and players can refer to "rule 4" without ambiguity.
• Give an example for any rule that could be read more than one way.
• Say what happens when a rule is broken, whether that's a warning, a temporary ban or a permanent ban.
• Show when the rules last changed, so returning players know to check again.
• Link to the appeals process, so players know there's a fair way to challenge a decision.

For more on writing pages players can follow, see how to write documentation people actually use.

Build a staff handbook

A written handbook is what makes moderation consistent. Without one, every moderator handles things slightly differently, and players notice.

Write a page for each common situation, using the same layout each time:

• When this applies: the type of report or situation
• Evidence needed: screenshots, clips or logs
• What to do: the steps, in order
• Escalate if: when to involve a senior admin

Add an onboarding page for new staff that links to everything they need to read in their first week. It saves your senior staff from explaining the same things to every new moderator.

Connect it to Discord

Your players already live in Discord, so that's where they need to find the wiki:

• Pin a link to the rules page in your rules channel, and keep the full text in the wiki so there's one version.
• Link the "Start here" page in your welcome message for new members.
• Use your bot's custom commands to reply with links to the right page, like a !rules or !join command.
• Add wiki links to your ticket tool's canned replies, so staff point players to the answer instead of retyping it.

The aim is for "it's in the wiki" to become the normal answer. Players learn to check there first, and your staff get time back.

Keep it up to date after every update

Server wikis go out of date quickly because servers change quickly. After every update, wipe or rule change:

• Update the affected pages before or alongside the announcement.
• Add a changelog entry so players can see what's new.
• Keep a version history, so you can see exactly what changed in the rules and roll back a mistake.

Give one staff member responsibility for each section. A wiki that everyone owns tends to be a wiki nobody updates.

A starting checklist

• Write the "Start here" page: how to join, the rules and an FAQ
• Number your rules and add examples and consequences
• Create a private staff handbook with your 5 most common situations
• Add a page for commands and ranks
• Pin the wiki in Discord and link it in your welcome message
• Add wiki links to your bot commands and ticket replies
• Assign an owner to each section

See how Docvora works for game server communities, including private staff pages and your own wiki domain.