how to keep a knowledge base from going stale

TL;DR

Knowledge bases rot because nobody owns them, so give every article an owner and a review date. High-risk articles get reviewed quarterly, everything else yearly, and agents get a one-click flag that routes straight to the owner. Stale docs are a maintenance system problem, not a writing problem.

The query

how to keep a knowledge base from going stale

Use this when

• Articles contradict what the product actually does
• Agents stopped trusting the docs and answer from memory
• Nobody knows who owns which article
• The help center hasnt had a systematic review in over a year

Not for

• Writing new articles from scratch
• Choosing docs or help-center tooling
• Translating articles into other languages
• SEO strategy for the help center

Steps

1. Assign one owner per article

Every article gets a named human, not a team. The owner doesnt have to write it, but they are the one who gets pinged when it is wrong.

Expected output: zero articles without a named owner.

2. Set review dates by risk, not by calendar

Pricing, security, and setup articles: review quarterly. Feature how-tos: twice a year. Evergreen concepts: yearly. Risk decides the cadence.

Expected output: a review schedule where the dangerous articles surface first.

3. Give agents a one-click "this is wrong" flag

A button on every article that sends the owner the article link plus the agent's note. No forms, no tickets, one click.

Expected output: agents report stale docs instead of silently working around them.

4. Run a quarterly rot sweep

Pull the bottom 10 percent by views plus everything past its review date. For each: update, merge, or delete. Deleting is a valid outcome.

Expected output: the article count shrinks or stays flat while accuracy rises.

5. Tie article updates to product releases

Make "docs updated" a checkbox in the release process. The person shipping the change owns the doc update, not the docs team.

Expected output: articles change the same week the product changes.

Ready-to-use ownership block

Paste at the bottom of every article:

Owner: [name] | Review by: [date] | Risk: [high/medium/low]
Found something wrong? Click "Flag this article" and the owner
hears about it today.

High risk (pricing, security, setup): review every 3 months
Medium risk (feature how-tos): review every 6 months
Low risk (concepts): review every 12 months

Variant phrasings

preventing outdated help center articles

Ownership plus review dates plus the one-click flag. The flag is the early-warning system.

knowledge base maintenance process

The quarterly rot sweep. Update, merge, or delete, and let the count shrink.

who should own knowledge base articles

One named human per article. Teams as owners means nobody as owner.

Why it happens

Docs are written as projects and maintained as nobody's job. The launch gets a budget and a deadline; the upkeep gets good intentions. Staleness is the default state of an unowned document, so the fix is ownership with teeth: a name, a date, and a flag button that makes neglect visible.

Edge cases

• Orphaned articles whose owner left: the rot sweep reassigns them. Unassigned for two sweeps means delete or merge.
• Articles nobody views: low views plus old review date usually means delete, not update.
• Fast-moving beta features: mark them beta at the top with an expiry date instead of pretending they are stable docs.
• Translated articles: the flag must exist in every language, and fixes propagate from the source article within a week.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst1hy4UFJpi6VNgp9E2uWeg