Internal Wiki Best Practices
Why most internal wikis rot, and the small number of rules that keep one usable.
Every internal wiki starts well. Most are abandoned within a year, and almost nobody deletes them — they just stop being trusted.
The failure is predictable and so is the prevention. It isn't about which tool you chose.
Read the documentation philosophy · Request Your Free Systems Audit
How wikis die
Search stops working. Not technically — it returns results, but three of them are outdated versions of the same page and nobody can tell which is current. Once people stop trusting search, they start asking a person, and the wiki is finished.
Nobody owns anything. A page without an owner is correct on the day it's written and degrades from there.
It becomes a dumping ground. Meeting notes, drafts, half-ideas and actual procedures in the same space. The signal disappears into the noise.
Structure is invented page by page. Everyone makes a sensible decision about where to put their page. Fifty sensible individual decisions produce an incoherent whole.
Updating is harder than asking. If fixing an error takes more effort than messaging a colleague, errors stay.
The rules that prevent it
One home per fact
Every piece of information lives in exactly one place. Everywhere else links to it.
The moment the same rule is written on two pages, they begin to diverge. Within months you have two answers and no way to tell which is right.
This is the single most important rule, and the hardest to maintain, because copying is always easier in the moment.
Every page has an owner and a date
Shown at the top, not buried in metadata. A reader seeing a name and a date can judge how much to trust the page. A reader seeing neither will either trust it blindly or ignore it — both bad.
Separate the stable from the temporary
Procedures, rules and reference material are one thing. Meeting notes, project updates and drafts are another.
Keep them in separate spaces with different expectations. Reference material gets reviewed; notes don't need to be and shouldn't clutter the search results of someone looking for a procedure.
Decide the structure once
Agree the top-level categories before people start creating pages, and don't let the tree grow more than three levels deep.
Three levels is a practical limit: beyond it, nobody can predict where something lives, and unpredictable location means search is the only route — which brings you back to the first failure mode.
Make deletion normal
Most wikis only grow. Build the habit of removing pages that are no longer true.
A quarterly pass asking "is this still accurate, and does anyone use it?" takes an hour and is the difference between a wiki and an archive.
Naming
Name pages for what someone would search for, not for how you'd categorise them.
| Instead of | Write |
|---|---|
| Process Documentation v2 FINAL | How to process a refund |
| Marketing Guidelines | Brand voice and tone rules |
| Onboarding | New starter: first week checklist |
Nobody searches for "guidelines." They search for the thing they're trying to do.
Pick one convention — sentence case, no version numbers in titles, verbs for procedures — and apply it. Consistency matters more than which convention.
The front page
Most wiki front pages are a welcome message. That's a wasted position.
The front page should answer: where do I find the thing I need right now?
A workable structure: the five most-used pages, a short list of spaces with one line each on what belongs in them, and how to request something that doesn't exist yet.
Who maintains it
One person owns the structure. Not the content — the structure. They decide where new spaces go, approve new top-level categories, and run the quarterly cleanup.
Without this role, structure decisions get made by whoever is creating a page, which is how incoherence arrives.
It's a small job. An hour a month, plus the quarterly pass.
Make contribution easy
Every barrier between noticing an error and fixing it reduces the chance of a fix.
- Anyone who can read should be able to edit, or at minimum comment
- No approval workflow for correcting a typo or a wrong step
- A visible way to flag "this looks out of date" that takes one action
The risk of someone making a bad edit is far smaller than the certainty of errors staying put.
What doesn't belong
Credentials and secrets. Ever. Reference where they live, never what they are.
Anything with legal or compliance weight unless there's a version-controlled approval process.
Personal notes. If one person uses it, it belongs in their own notes.
Content that lives elsewhere. If the real source is a design tool, a code repository or a CRM, link to it. A copy will go stale.
A realistic review cycle
| Frequency | Action |
|---|---|
| On change | Update the page, bump the date |
| Quarterly | Owner reviews their pages: still accurate, still used |
| Quarterly | Structure owner removes dead pages, merges duplicates |
| Annually | Is the structure still right, or has the business moved? |
Choosing a tool
Less important than the rules above, but a few things matter:
Search that works. Version history. Permissions granular enough to separate spaces. Easy enough that people will actually edit it.
Almost every modern tool clears that bar. The tool is rarely the reason a wiki fails.
A wiki is only as good as the last person who corrected it. Make correcting easier than asking.
Want your knowledge properly structured?
A free systems audit covers how your business stores and finds what it knows.