Why your Confluence wiki is going to seed
Open any Confluence space your team has used for more than two years. You’ll find pages last edited by people who don’t work there anymore. Process docs that reference tools you stopped using. Onboarding pages that contradict each other. Meeting notes from sprints whose product is now sunset.
Your wiki has gone to seed.
We don’t mean it’s broken. The site is up. Search returns results. New pages get added. By every functional metric, the wiki is fine.
But ask anyone on the team: “Where do I find the canonical answer to X?” — and watch them hesitate. They’ll search Confluence, find three pages, look at the dates, ask in Slack anyway. The wiki has become a low-trust source.
This is what going to seed means in this context. The system isn’t dead. It’s just not where the truth lives anymore.
Why this happens
Three pressures drive wiki decay, and none of them are anyone’s fault.
Sprint pressure beats documentation hygiene. A team mid-sprint won’t pause to update an old runbook unless it’s blocking them. The page rots in the background.
Authorship is unowned. Pages are added by whoever needs them at the time. Six months later, when context shifts, no one is on the hook to revisit. The author has moved teams or left.
Search ranks recency-blind. Confluence will happily serve a four-year-old page above a six-month-old one if the keyword density wins. The user has to inspect the date themselves.
Add up these three forces over eighteen months and you don’t have a wiki. You have an archaeology dig.
The signs
You can usually feel it before you can name it. Specific signals to watch:
- Pages where the last meaningful edit is more than a year old.
- Pages tagged “draft” that have been draft for nine months.
- Multiple pages with similar titles (“Onboarding 2024”, “Onboarding — new”, “Team onboarding v2”) and no shared parent.
- Frequent Slack messages of the form “is the Confluence page on X still accurate?”
- New hires asking the same setup question every quarter despite a documented answer existing somewhere.
If two or more of these are familiar, your wiki is somewhere on the seed-going spectrum.
What doesn’t work
Three approaches we’ve watched fail repeatedly.
Bulk delete. Scariest option, also the worst. Delete pages, the institutional memory goes with them, and the team revolts after the first time someone needs an old page that turned out to be load-bearing.
Archive everything older than N months. Slightly safer but still blunt. A two-year-old security policy can be perfectly current. A two-week-old standup note is already irrelevant. Age is a weak signal on its own.
Manual audit days. “Let’s all sit down on Friday and clean up the wiki.” Generates a one-time burst of activity that decays back to baseline within two weeks. Doesn’t scale, doesn’t compound.
The pattern in all three is the same: they treat wiki cleanup as a project rather than a process.
What works
Lower stakes. Ownership-aware. Signal-based.
Surface staleness, don’t enforce it. Show owners which of their pages haven’t been touched in a long time and why it might matter. Let them decide. People are good at judging their own pages once you remove the friction.
Triangulate signals. Time-since-last-edit, time-since-last-view, presence of a known author, sprint or release context. Any one signal is noisy. Three together are usually right.
Default to soft archive, never bulk delete. Move stale content out of search by default. Keep the page reachable by direct link. Reversible decisions stay cheap.
Repeat quietly, on a schedule. Once a week is enough. Once a quarter is too rare. People stop trusting the wiki between audits.
What we built
PageKeeper is one execution of the pattern above. It scans configured Confluence spaces, scores pages on staleness signals (time, traffic, author presence, custom labels), digests the result to page owners, and lets them approve archival in one click. No bulk delete. No workflow modification. Calm and reversible by design.
It’s the first product from Klem HQ. If your wiki is going to seed and the failure modes above feel familiar, we’d like to hear from you — early customers shape what we build next. hello@klemhq.com.