An internal wiki decays for a structural reason rather than a cultural one. Adding a page is always defensible, removing one requires somebody to decide it is wrong, and no process assigns that second job to anybody. Over three years the result is predictable.
TL;DR
- Wikis do not rot from neglect. They rot because creation is rewarded and removal is nobody’s responsibility.
- A small number of people write almost everything, so the wiki reflects their areas and ignores the rest.
- Pages with no owner should be deleted rather than inherited. The threat produces owners quickly.
- Undated pages are unusable to anyone who was not there when they were written.
- A retrieval layer over a decayed wiki delivers wrong answers more efficiently.
- Measure the share of pages touched in the last year. Under a third means the search results are mostly archaeology.
The asymmetry that causes decay
Writing a page has a clear trigger. Somebody asks a question twice, the second time is annoying, and a page gets written. The benefit is immediate and the author gets credit.
Deleting a page has no trigger at all. Nobody is annoyed by a stale page, because the people harmed by it are the ones who did not know it was stale, and they do not report it. They act on it instead. So pages accumulate, and a search that returned two results in year one returns eleven in year three, with no indication of which of the eleven is still true.
This is not a discipline problem. It is a missing role.
A few people write nearly all of it
Look at page authorship in any wiki over a year old and the distribution is heavily skewed. A handful of contributors account for the large majority of pages, a slightly larger group has edited something once, and most of the company has never written anything.
Two consequences follow. The wiki covers what those few people care about, which is usually infrastructure and tooling, and barely covers the things they consider obvious, which is usually everything a new starter needs. And when one of them leaves, a whole subject area becomes unmaintained at once, with nobody noticing until something is wrong.
The repair is not a campaign to get everybody writing, which does not work. It is to name owners for subject areas so that departure is visible.
Three repairs that hold
What to do:
- Put a review date and a named owner on every page, set at creation with a default.
- Delete pages with no owner rather than reassigning them in bulk.
- Show the last reviewed date to readers, not just to editors.
- Archive superseded pages instead of deleting, so links fail visibly rather than silently.
- Keep a log of what was removed and when.
The second one causes the most argument and does the most work. Reassigning orphaned pages to a team produces nominal owners who never review anything. Announcing that unowned pages will be deleted produces real owners within a fortnight, for the pages that matter, and quietly disposes of the rest.
A cleanup that halved the wiki
A company of about a hundred and twenty people had a wiki of roughly nine hundred pages and a standing complaint that nothing could be found.
Before restructuring, somebody counted. Under a third of pages had been edited in the previous twelve months. Forty per cent had a last editor who had left the company. Searching the five most common support topics returned between four and nine pages each, none marked current.
They announced a deletion date for unowned pages and gave four weeks. About two hundred pages gained owners. The rest were archived. Search results became usable without anybody changing the search tool, the navigation or the platform, and the complaint stopped.
Do not put retrieval in front of a decayed wiki
The tempting shortcut is to leave the wiki alone and add something that answers questions from it. This makes things worse in a specific way.
A person searching a decayed wiki sees eleven results and some signal that the situation is murky. They hedge, they check with somebody, they treat the answer as provisional. An answering layer collapses that into one confident paragraph with no indication that ten other versions existed. The ambiguity was doing useful work and you have removed it.
Matram is our own product and the same caution applies to it. It reads the documents you point it at and answers from them, so pointing it at four versions of a process means it answers from whichever it was given. It has no free tier, it is not an HRIS, and its actions reach HubSpot, Zendesk and webhooks only. WhatsApp is coming soon rather than available. Pricing is flat at $29, $69 and $199 a month with unlimited seats. Consolidate first, connect second. In that order it is a genuine improvement, and in the other order it is an efficient way to distribute a stale answer.
Numbers worth knowing about your own wiki
| Measure | How to get it | Concerning when |
|---|---|---|
| Pages edited in last 12 months | Sort by last modified | Under a third |
| Pages whose last editor has left | Cross reference with the directory | Over a quarter |
| Results per common topic | Search your top five | More than three |
| Pages with a named owner | Check page properties | Under half |
| Contributors in the last year | Authorship report | Fewer than ten |
The checklist worth keeping
Checklist:
- Every page has a named owner and a review date set at creation.
- Unowned pages are archived on a published date, not reassigned in bulk.
- The last reviewed date is visible to readers.
- One authoritative page per topic, with the rest archived.
- A removal log exists so deletions can be answered rather than argued about.
- Subject area ownership is reviewed when somebody leaves.
Final Thoughts
Wiki decay looks like a content problem and is a process one. Nobody is assigned to remove things, the harm from a stale page falls on people who cannot detect it, and a handful of authors carry subject areas that become unmaintained the moment they move on.
Owners, review dates and a willingness to archive will fix more than a migration or a better search box. Do that work before putting anything in front of it, because retrieval makes a good wiki findable and a decayed one dangerous.
Frequently asked questions
Why does our internal wiki go out of date?
Because adding a page has an obvious trigger and removing one has none. Nobody is annoyed by a stale page, since the people it misleads usually cannot tell it is stale and act on it instead of reporting it. Without an assigned owner for removal, accumulation is the only possible outcome over time.
Should we delete pages or archive them?
Archive rather than delete, so existing links fail visibly instead of silently returning nothing. Keep a short log of what was archived and when, because the standard objection to removal is that somebody might need it, and a log converts that from an argument into a lookup that takes seconds.
How do we get more people contributing?
Campaigns to encourage broad contribution reliably fail, because writing documentation is not most people’s job and never becomes urgent. Naming owners for subject areas works better, since it makes a gap visible when somebody leaves rather than discovering it months later when a page turns out to have been wrong.
Is a last reviewed date worth adding?
It is one of the highest return changes available, because it converts an unanswerable question into a glance. A reader cannot otherwise distinguish a maintained page from an abandoned one, so they either trust everything equally or check everything with a person, and both outcomes defeat the point of having a wiki.
Will an answering layer fix a messy wiki?
No, and it removes a safety signal. Someone looking at eleven search results knows the situation is ambiguous and hedges accordingly, while a single confident paragraph hides that entirely. Consolidate to one authoritative page per topic first, then add retrieval, because the reverse order distributes stale answers more efficiently.
How do we know whether ours is decayed?
Sort by last modified and work out what share of pages have been touched in twelve months. Under a third means search results are largely historical. Then search your five most common topics and count the results, since more than about three per topic with none marked current is the condition that makes a wiki unusable for anyone new.
