How to keep a knowledge base up to date

Help articles go stale quietly, and with an AI assistant answering from them, a stale article is now a wrong answer given to every customer who asks. Here’s a routine that keeps them right.

By Last updated:

To keep a knowledge base up to date, give every article an owner, update the articles as part of shipping each change, review the most-read ones on a fixed schedule, and use support replies and unanswered questions to find what’s wrong or missing. Treat a wrong article like a bug.

Why knowledge bases go out of date

Articles rarely go wrong all at once. They drift, for predictable reasons:

  • The product changes. A button moves, a setting is renamed, a limit goes up. Nobody remembers the three articles that mention it.
  • Plans and prices change, and the old numbers stay in articles written years ago.
  • Screenshots age faster than text, and one outdated picture makes a correct article look wrong.
  • Support fixes it in replies instead. The team learns the real answer and sends it by email fifty times, but the article never changes.
  • Nobody owns it. An article written by someone who has since left belongs to no one.
  • The same fact lives in several places, so an update to one leaves the others wrong.

The cost used to be a confused reader. If an AI assistant answers from your articles, the cost is a confident wrong answer, given to everyone who asks, with a link to the article as proof.

Give every article an owner

An owner is the person who gets asked when the article is wrong and who signs off when it changes. It should be a person, not a team, and usually whoever knows the subject best: billing articles to whoever runs billing, feature articles to the product team that built the feature.

Owners don’t have to write every change. They decide whether a change is right. That split matters: the support team often notices the problem, but the owner knows the truth.

One home for each fact

Decide where each fact lives, such as the refund window, the seat limit on each plan, or how to change an email address, and have other articles link to it rather than repeat it. Then a change is one edit, not a search through the whole help centre.

Update the docs when you ship

The best time to update an article is before the change goes live, when the person who built it still remembers every detail. Make it part of the definition of done.

  • Search the help centre for the feature’s name, the screen’s name, and the old wording of anything you renamed.
  • List the affected articles in the release ticket, and don’t close the ticket until they’re updated.
  • Check plan names, limits and prices in every article that mentions them.
  • Replace screenshots that show the changed screen.
  • Write a new article for a new feature, titled the way a customer would ask about it.
  • If you removed something, update or retire the articles that explain it, and redirect their addresses.

AI agents can do the searching. If your knowledge base has an API or an MCP server, an agent like Claude Code can read the change, find the articles it affects and draft updates for someone to review. Our guide to connecting AI agents to your help centre with MCP shows how.

Review on a schedule

Release-driven updates catch most changes. A scheduled review catches the rest: things that changed outside a release, and articles that were never quite right.

  • Monthly: your most-read twenty articles, and anything about billing, security or account access.
  • Quarterly: the next tier of articles by traffic.
  • Yearly: everything else. Delete or merge anything nobody reads and nobody needs.

Show a “last reviewed” or “last updated” date on each article. It tells readers how far to trust it, and tells you which articles have been forgotten.

Retire articles properly

When you remove or merge an article, redirect its address to the closest remaining one with a permanent redirect. Customers bookmark help articles, other sites link to them, and search engines rank them. A 404 throws all of that away. Our guide to migrating a help centre without breaking links covers redirects in more detail.

Let support tell you what’s wrong

Your support inbox is the best early warning you have. Every question a customer asks is either answered by the help centre, answered badly by it, or not answered at all. Watch for:

The same reply, written twice

If someone on the team writes the same explanation to two customers, it belongs in an article. If they write something that contradicts an article, one of them is wrong. Ask the team to flag these, or read a sample of closed conversations each week.

Unanswered questions

Searches that returned nothing, and questions an AI assistant declined to answer, are a list of what your help centre is missing, in your customers’ own words. Group them by meaning and count them. The most-asked one is your next article.

Unhelpful ratings and repeat contacts

An article people rate as unhelpful, or one they read just before emailing support, isn’t doing its job. It may be wrong, unclear, or answering a different question from the one in its title.

Saved replies

Canned replies drift too, and often hold the team’s most current answers. Compare them with the articles on the same subject now and then.

Screenshots

Screenshots help readers find their way, and they’re the first thing to go out of date. A few habits keep them manageable:

  • Use fewer. A screenshot earns its place when it shows something words can’t, such as where a control is.
  • Crop tightly to the part that matters, so unrelated changes elsewhere on the screen don’t date it.
  • Keep the instructions in the text. The words should work without the picture, which also helps search and AI assistants that can’t read images.
  • Give each image alt text that says what it shows.
  • Keep a list of which articles show which screens, so a redesign comes with a list of pictures to replace.

A monthly routine

An hour a month, done every month, beats a big clean-up once a year.

  1. 1

    Read the unanswered questions

    Group the questions the help centre couldn’t answer this month by meaning. Write or assign the top three.

  2. 2

    Check what shipped

    Go through last month’s releases and confirm each affected article was updated, screenshots included.

  3. 3

    Read twenty conversations

    A sample of closed support conversations, and of AI answers if you have them. Note any reply that should be an article, and any answer that contradicts one.

  4. 4

    Review the top articles

    Reread the most-read articles and the sensitive ones. Update the review date when you’re done.

  5. 5

    Retire one thing

    Delete or merge at least one article nobody needs, and redirect its address.

Doing this in AskBase

AskBase does the noticing for you, and a person decides. Every hour it reads email conversations your team has closed in the last week, with the customer’s name, email address, numbers and links taken out, and turns what the team taught the customer into a suggested change to an article. Once a month it reviews the help centre: it drafts articles for the most-asked content gaps and flags articles that contradict facts your team confirmed. On Growth and Business, AskBase also signs in to your product each week to capture its screens, so the review can draft updates for articles whose screens changed and suggest current screenshots. Nothing changes until someone approves it, edits it first or rejects it, and a rejected suggestion isn’t made again for 90 days. Learning from replies and the monthly review are on paid plans.

  1. 1

    Connect your inbox

    Answer support email in AskBase. Closed conversations become suggested article changes.

  2. 2

    Review suggestions

    Each one shows the change against the current article, why it was made and what to check.

  3. 3

    Ask for more

    Describe a change in words (“update the billing articles for the new plan”) and AskBase drafts up to six.

Questions people ask

How often should you review a knowledge base?
Review the most-read and most sensitive articles monthly, the next tier quarterly, and everything else at least once a year. Update articles whenever you ship a change that affects them, rather than waiting for the review.
Who should own the knowledge base?
One person should own the knowledge base as a whole, and each article should have its own owner: the person who knows that subject best. Support often notices problems first, but the owner decides what’s true.
How do I find outdated articles?
Search for the names of anything you changed recently, read a sample of support conversations for replies that contradict articles, and look at articles rated unhelpful or read just before someone contacted support.
Should I delete old help articles?
Yes, if nobody needs them. Merge or delete them, and add a permanent redirect from the old address to the closest remaining article so links and search rankings carry over.
Can AI keep a knowledge base up to date?
AI is good at noticing: finding articles affected by a change, spotting replies that should be articles and drafting updates. A person should still approve every change, because the AI can’t always know what’s true.

Related guides