How to Find Stale Content in Your Knowledge Base
The articles that look fine are usually the ones that aren't.
Summary: Most knowledge base articles go stale because the product shipped faster than the docs could follow. This guide covers the signals that tell you content has drifted, the manual and automated ways to catch it, and what to fix first.
Stale content or outdated content refers to any knowledge base article that no longer matches the current state of the product it describes. To find it, sort your articles by last updated or review date and read anything untouched for six to twelve months. Then check that list against your zero-result searches, your lowest-rated articles, and whatever shipped in the last two releases. Age narrows the list; the other signals tell you which of those articles is actually wrong.
We build a product that catches this for a living, and a few days ago we couldn't find a feature in a new tool we'd started using. We asked the chatbot and it sent us to a settings page that had been moved in an update. The docs hadn't caught up, and I spent fifteen minutes looking. Our CEO hunted around the knowledge base and found it manually. She's patient like that. Most of your customers are not.
If you run a help center for a product that ships regularly, some of your articles are wrong right now. This guide is about finding which ones.
What stale content actually looks like
Stale articles look exactly like accurate ones. Nobody stamps them with an expiry date. Here's what to look for.
Screenshots that don't match the current UI. A button moved, or a settings page was restructured. The text still reads correctly, but the image shows a screen that no longer exists. This is the most common form of documentation drift and the hardest to catch at scale, because you'd have to open every article and compare it to the live product.
Feature descriptions referencing old behavior. The article calls a setting a toggle when it's now a dropdown, or describes an API key flow after the product moved to OAuth. The workflow still exists but behaves differently enough to confuse someone following it step by step.
Paths longer than they need to be. Your article says to export by going to Settings > Reports > Export. Your product now has an Export button on the dashboard. The old route works, but you're sending customers on a scenic tour when there's a motorway.
Contradictions between articles. Two articles describe the same feature and disagree, because one was updated after a release and the other wasn't. For a reader that's confusing. For a retrieval-based chatbot it's worse: it picks whichever article scores higher, and if that's the outdated one, the customer gets a wrong answer delivered with confidence.
Where to start looking
A full content audit of a 500-article help center takes weeks, and we covered the broader version in How to Audit Your Help Center for AI Chatbot Readiness. For staleness specifically, here are the eight signals.
The last-updated column. Sort your article list by last modified, oldest first. Six months is a sensible cut for anything describing a screen, a workflow or a limit; twelve for policy and billing pages that move more slowly. This one needs no analytics and no setup, which makes it the first thing to run on a help center you have just inherited and know nothing about.
Your most-viewed articles. Sort by page views over the last 90 days and work through the top 20 against the live product. Staleness there reaches the most people, and 20 articles is an afternoon.
Failed searches. Your internal search log holds the zero-result queries, plus the ones where results appeared and nobody clicked. Both usually mean the article exists under a name the product stopped using. Cheapest signal on this list, and the one most teams never open.
Your chatbot's low-resolution articles. If you run Fin, Zendesk AI, or any retrieval-based agent, find the articles it cites often and resolves rarely. In Intercom that's under Fin AI Agent > Analyze > Performance: sort by involved conversations and look for a resolved count well below it. More on this in How to Improve Intercom Fin Resolution Rate.
Tickets that quote your docs. Search recent tickets for "the article says" or "I followed the instructions but." Those customers have already done half your audit and told you exactly where the documentation failed them.
Release notes from the last two quarters. For each change that touched the UI, a workflow, or a policy, check whether an article was updated. Tedious, and the only method that catches drift analytics can't see: articles nobody finds through search anymore because the terms moved, which the chatbot still retrieves. This is the signal Pageloop automates, by matching closed tickets and release notes against your published articles.
Article feedback ratings. Sort by lowest-rated over 90 days. A declining rating won't tell you what's wrong, but it narrows the list.
Articles nobody reads. Now sort the other way. Your top articles show the staleness that costs most; the bottom shows the staleness nobody has reported, because nobody got that far.
Two signals that need no dashboard
Most of those need analytics. These two are visible in the content itself, and Pageloop's Help Center Audit checks both for you.
Links that no longer resolve. A broken internal link usually means the article on the other end changed shape without anyone checking who pointed at it. Three cases behave differently: links properly broken because the URL moved or the content was archived, links nothing can verify either way, and links to domains that block automated checks and come back looking broken when they're fine.
Articles that disagree with each other. Two articles can both be popular and still contradict each other, so no traffic report will hand you this one. Pick a feature area, open everything that touches it, and read them against each other rather than against the product. Pricing and numeric limits are where disagreements cluster, because those change without any part of the interface changing.
What your platform already surfaces
Most help center platforms measure time, whether that's time since an article was edited or time since anyone read it, rather than whether something happened in the product that made it wrong.
Platform | What it tracks | Where it stops |
|---|---|---|
Zendesk Article Verification (Enterprise plans) | Rules that unverify articles on an interval you choose, from two weeks to a year, then email the owner twice a week until they verify | The article that broke last Tuesday when engineering renamed a feature |
Intercom Fin content gap recommendations (Pro add-on) | Failed Fin answers compared against successful human replies, each recommendation carrying an impact score, plus a weekly check for duplicates and contradictions | Someone has a bad experience before the system catches it |
Confluence automation with Rovo | Pages inactive for a set period, by last edit or last view, archived or flagged by rules you can write in plain language | A page can pass its check and go stale two days later |
Freshdesk approval workflow (Enterprise) | Who reviews and approves an article before it publishes, with statuses through the process | Governs the review, not whether the published article is still accurate |
Document360 and several others | Review reminders against a due date | The due date is a calendar guess, not a signal from your product |
Product changes themselves: closed Jira, Linear and GitHub tickets, release notes in Slack, and support conversations, matched to the articles they affect, plus audits for broken links and conflicting articles | Nothing publishes without someone approving it |
We compared these in The 8 Best Tools to Keep Your Knowledge Base Up to Date. Check whether your platform stores a review date or an expiration date separately from the last-modified date. Cascade CMS documents that scheduling a review date leaves the last modified date alone, which is the behaviour to look for. If fixing a typo resets the review clock, every small edit pushes the real audit further out.
How to automate detection
Manual audits don't stay finished. You complete the review, feel good about yourself for half a day, and the next release introduces new drift. Four things to automate.
Connect your release pipeline to your content. The Jira, Linear, or GitHub tickets that close after a release describe what changed. Compared against your published articles, they tell you which ones are affected. This is what Pageloop does: it watches for status changes in your project tools and surfaces the articles those changes touch, so you review the right 5 articles after a release instead of scanning all 500.
Hand off the links and the contradictions. Both signals above are mechanical enough that nobody should do them twice by hand. Pageloop's Help Center Audit checks internal and external links, sorts them into broken, unverifiable, and blocked-by-the-far-end, and flags conflicts where two articles state the same thing differently, naming the affected articles and showing its reasoning. Each finding opens into an update you review first.
Use AI to cross-reference. Paste five articles about one feature area into Claude, ChatGPT, or any model with a long enough context window, and ask whether they contradict each other. It won't catch everything, and the contradictions it does catch tend to be the ones your chatbot is already confused by.
Track chatbot failure patterns. If your chatbot logs which articles it retrieves, watch for ones that used to resolve issues and stopped. Rising retrieval without resolution usually means the content drifted.
What to fix first
Prioritize by exposure. An article with 2,000 views a month and one wrong screenshot beats an article with 50 views describing a deprecated feature. The first misleads more people even though the second is more wrong.
Within an article, fix factual errors, then procedural ones, then screenshots, then phrasing. Telling a customer to click a button that doesn't exist is worse than showing a button that moved slightly. Fix what stops people finishing the task before you fix what confuses them visually.
Then check the articles your chatbot retrieves alongside the one you fixed, because it may still be pulling a contradictory neighbour for related queries.
Some of the list needs removing rather than fixing. An article describing a feature that no longer exists should be retired, and one that duplicates a better article should be merged into it. Archive rather than delete where your platform allows it, so the URL keeps resolving for anyone who bookmarked it and your team can still read what it used to say.
Keeping it from coming back
The teams who stay current put documentation on the release checklist next to QA and deployment. The article update happens before the feature goes live, or at least in the same sprint.
For help centers powering AI chatbots, the margin has narrowed. A human reader might notice an off screenshot and work out the right path anyway. A chatbot serves outdated instructions with exactly the same confidence it serves accurate ones. It doesn't know the difference. That's your job, and it's easier when you know where to look.
Frequently asked questions
How do I know if my knowledge base has stale content?
Your support queue is the fastest way to tell that a knowledge base has stale content: agents correcting information from your own articles, or customers reporting that the instructions don't match what they see. The other giveaways are screenshots of a UI that no longer exists, articles naming removed features, and chatbot answers that contradict your product.
How old does an article have to be before it counts as stale?
A common threshold is six months for articles describing a screen, a workflow or a limit, and twelve months for policy and pricing pages. Age works as a filter rather than a verdict, so treat what the threshold surfaces as a reading list. If your platform stores an expiration or valid-to date, set that per article instead.
Can I find stale content without help center analytics?
You can find stale content without any help center analytics using three methods:
Release notes, two quarters at a time, read against the articles each change touched.
Broken links, which point at pages that changed shape without anyone telling the articles pointing at them.
Contradictions between articles covering the same feature.
The last two find problems traffic reports miss, because a popular article and a contradictory one both look fine on views.
What is the difference between stale content and outdated content?
Stale content and outdated content describe the same problem: an article that no longer reflects reality. Some teams reserve stale for content nobody has reviewed in a set period, and outdated for content that is factually wrong. An article published yesterday can be outdated if a release shipped this morning. More on this in 10 Help Center Problems That Get Worse Before Anyone Notices.
Can I automate finding stale content?
Finding stale content automates in part: Pageloop connects to Slack, Linear, Jira and GitHub and suggests updates when a product change affects an article. The detection runs on its own; review and publishing stay with you. A manual audit cycle also works, but articles sit stale between reviews, and the faster you ship the wider that gap gets.
Image Courtesy: Yale Center for British Art and Art UK Man of War Rocks, Coast of Dorset, John Brett (1831–1902)
Author
Fatema works across marketing and content at Pageloop. She has an academic background in Ecology, a side-life in fashion, and an irrational loyalty to milk coffee.
Other related content you might be interested in
