How to Keep Documentation Up to Date

A review process attached to your release cycle instead of a calendar reminder, and a written record of which articles have been verified and when. The aim is not a help centre that is always perfect. It is one where you know which parts are trustworthy and which are not.

Before you start

You need a list of every published article, some way of seeing what shipped recently - release notes, merged pull requests, or a changelog - and a decision about who owns each article by name. Team ownership is the same as no ownership, because a review task assigned to a team is a task assigned to whoever feels worst about it. If you do not yet have a list of suspects to start from, how to tell which articles are out of date produces one without reading anything.

Attach the work to something that already happens. Calendars lose to feature work.

Steps

1. Inventory every published article in one place.
   A spreadsheet is fine. One row per article, with columns for URL, owner, the date it was last verified, and the part of the product it describes. The last-verified column is the one that does the work, and it is almost never the same as the last-edited date your tool shows you.

2. Tag each article by how fast it decays.
   Three tags are enough: interface-bound (screenshots, button names, step order), conceptual (what a feature is for, how pricing works), and policy (retention, security, terms). Interface-bound articles go wrong within weeks of a release. Conceptual articles last years. Treating them the same is why annual audits feel endless and still miss things.

3. Attach the review to the change that causes it.
   Add one line to your pull request template or definition of done: "Does this change anything a published article says?" A developer who has the change in front of them answers that in ten seconds. A technical writer reading a diff three weeks later cannot answer it at all.

4. Give each tag a review interval, and make them different.
   Interface-bound articles every quarter, conceptual once a year, policy only on change. A single interval applied to everything guarantees you spend the same effort on your refund policy as on the setup flow that changed twice since you last looked.

5. Record "checked, still correct" as an event.
   Verification with no output is verification you will repeat. Stamp the last-verified date even when nothing changed. Without it, every audit starts from scratch and the second one costs as much as the first.

6. Show a last-updated date on the article itself.
   Readers use it to decide whether to trust the page, and so do you. Make it reflect real review rather than the last typo fix, otherwise the date becomes a lie that everyone learns to ignore.

7. Delete rather than defer.
   An article describing a feature that no longer exists is worse than no article. If it covers something removed, take it down and redirect the URL somewhere useful rather than leaving it on a list to rewrite one day.

8. Keep a short, visible list of known-stale articles.
   Three or four you have consciously decided not to fix yet. Written down, that list is a backlog. Undocumented, it is indistinguishable from having forgotten.

Common mistakes

Running one large annual audit. It arrives when nobody has capacity, takes a fortnight, and is out of date before it finishes. Smaller reviews tied to releases cost less in total and never produce a fortnight-shaped hole in anyone's quarter.

Treating every article as equally perishable. A page about your data retention policy and a page with eleven screenshots of the onboarding flow are not the same maintenance problem, and reviewing them on the same schedule wastes effort on one while starving the other.

Writing from the specification rather than the shipped build. Specifications drift during implementation. An article written from the design document is wrong on the day it publishes, and it is wrong in ways nobody catches, because the person who wrote it believes they checked.

Letting a typo fix reset the last-updated date. That single behaviour destroys the only cheap signal you have for finding stale content. Keep verification separate from editing, even if it means an extra column in a spreadsheet.

Assigning ownership to a team. "Support owns the help centre" reliably produces articles nobody has read since the person who wrote them left. One name per article, reviewed when people change roles.

When this stops scaling

This process works while one person can hold the shape of the product in their head and recognise, on reading a release note, which articles it touches. That recognition is the load-bearing part, and it fails on two axes.

The first is article count. Past roughly fifty published articles the mapping from "what shipped" to "what is now wrong" stops being something anyone can do from memory, and the review starts missing the articles that most needed it - the ones nobody thought of.

The second is release cadence. If you ship weekly, a quarterly sweep of interface-bound articles is reviewing content that has changed twelve times since you last looked. The sweep never catches up; it converges on being a sampling exercise with a review process attached.

At that point the bottleneck is not writing or reviewing. It is knowing which articles a given change invalidated, which is a question about diffs rather than about prose. SupportPages answers it per change, so each review starts from the handful of articles that change touched rather than from the whole help centre, and the last-verified column stays honest without a quarterly sweep. If your last audit found problems you knew about six months earlier, that is the gap worth closing.