Building a wiki for a game that updates every few weeks

A wiki for a live game has one problem a normal wiki does not: the ground moves. Every patch invalidates pages you spent a weekend on, and the pages that go stale are usually the popular ones.

Here is the structure that survived contact with a game that updates constantly.

Separate what changes from what does not

The single most useful decision was splitting pages into two kinds:

• Volatile pages: stats, recipes, drop tables, tier lists. These carry a version stamp in the URL or the header, and they are expected to be rewritten.
• Stable pages: how a mechanic works, why a strategy is sound, what to do first as a new player. These survive patches because they describe reasoning, not numbers.

A guide that explains why a build works outlives a guide that lists its numbers, every time.

Version the numbers, not the prose

Where a number must appear, put it in one place and reference it. When the patch lands you edit one table instead of forty paragraphs. This is dull engineering and it is the difference between updating a wiki in an hour and abandoning it.

Write for the person arriving from search

Most visitors land on one page and never see your home page. So every page has to answer a whole question on its own: what changed, what to do, and what to read next. Navigation is a bonus, not a safety net.

Mark outdated pages honestly

A banner saying "this was written before patch X" costs nothing and buys trust. Quietly leaving stale numbers up costs you the visitor permanently.

If you are starting one, begin with three game wiki guides pages that will still be true next month, then add the volatile ones.

Notes from maintaining a wiki through four major patches.