How to Find Stale Content in Your Knowledge Base

Summary: Most knowledge base articles go stale not because nobody cares, but because the product shipped faster than the docs could follow. This guide covers the specific signals that tell you content has drifted, the manual and automated methods for catching outdated articles and what to fix first once you find it.

Stale content or outdated content refers to any knowledge base article that no longer matches the current state of the product it describes.

We build a product that catches this stuff for a living, and just a few days back, we couldn't find a feature in a new tool we have started to use. We asked the chatbot and it directed us to a settings page that had been moved after a product update. The docs hadn't caught up yet, and I spent fifteen minutes trying to find an answer. Our CEO hunted around the knowledge base and found it manually. She's patient like that. Most of your customers are not patient like that.

If you run a help center for a product that ships regularly, some of your articles are wrong right now. You probably suspect this already. This guide is about finding which ones.

What stale knowledge base content actually looks like

The tricky thing about stale articles is that they look exactly like accurate ones. Nobody stamps them with an expiry date. They sit in your help center looking perfectly fine until someone raises a ticket or your chatbot gives an answer that doesn't match the product.

Here's what to look for.

Screenshots that don't match the current UI.
Perhaps a button has moved to a new spot, or a settings page was restructured. The text might still be roughly correct, but the screenshot is showing the customer a screen that doesn't exist anymore. This is the most common form of drift, and it's hard to catch at scale because you'd have to open every article and compare it to the live product. Nobody has that kind of afternoon.

Feature descriptions referencing old behavior. The article describes a setting as a toggle when it's now a dropdown, or an integration flow that requires an API key when the product moved to OAuth a couple of releases ago. The workflow technically still exists but behaves differently enough to confuse someone following it step by step.

Articles describing a longer path than necessary. Your article says to export data by going to Settings > Reports > Export. Your product now has an Export button on the dashboard. The old route might still work, but you're sending customers on a scenic tour when there's a motorway, and your chatbot will happily describe every turn.

Contradictions between articles. Two articles describe the same feature but disagree because one was updated after a release and the other wasn't. For a human reader, that's confusing. For a retrieval-based chatbot, it's worse: it picks whichever article scores higher on the query, and if that's the outdated one, the customer gets an incorrect answer delivered.

Where to start looking

A full audit of a 500-article help center takes weeks. We covered a broader audit framework in How to Audit Your Help Center for AI Chatbot Readiness. What follows here is specifically about finding stale content, and the fastest way in is to start where the most people are looking.

Your most-viewed articles

Pull your help center analytics and sort by page views over the last 90 days. Your top 20 articles by traffic are the ones customers hit most often, so any staleness there affects the most people. Open each one, read it against the current product, check the screenshots, and follow the steps to see if they still work. This takes a few hours for 20 articles and tends to surface problems quickly.

Your chatbot's low-resolution articles

If you're running an AI agent like Fin, Zendesk's AI, or any retrieval-based chatbot, look at the articles it references most often but resolves least often. In Intercom, you can find this under Fin AI Agent > Analyze > Performance. Sort by involved conversations and look for articles where the resolved count is much lower than the involved count. Those articles are being pulled into conversations but aren't getting the job done.

We wrote a separate post on this specific workflow: How to Improve Intercom Fin Resolution Rate.

Tickets that reference documentation

Search your recent support tickets for phrases like "the article says" or "I followed the instructions but" or "the help center told me to." These are customers who took the time to tell you exactly where the documentation let them down. That's useful data, and it's free. Some of those will be stale content, some will be gaps, but either way someone has done half the audit for you by filing the ticket.

Release notes from the last two quarters

Go through your product's release notes or changelog for the past six months. For each change that affected the UI, a workflow, or a policy, check whether a corresponding article was updated. This is tedious. It is also the only method that catches drift your analytics can't see: articles that aren't getting traffic precisely because they describe something that's changed. Nobody's finding them through search anymore because the terms have shifted, but the chatbot still retrieves them when a customer asks the right question the wrong way.

Article feedback ratings

If your help center has "Was this helpful?" ratings on articles, sort by lowest-rated articles over the last 90 days. Articles with declining ratings over time are often ones where the content has drifted since the last product update. The rating drop won't tell you what's wrong, but it narrows your list.

Signals your platform already surfaces

Most help center platforms have built-in tools for this, though they all approach it the same way: they track how long it's been since someone edited the article, not whether anything has happened in the product that makes it wrong.

Zendesk has Article Verification, which lets you flag articles for review on a schedule. You set the interval, say every 90 days, and Zendesk nudges the article owner to re-verify. Useful for creating a review habit. Less useful for catching the article that went stale last Tuesday because your engineering team renamed a feature.

Intercom (now Fin) approaches it from the other direction through Fin's Content Gap Suggestions, which look at conversations where Fin couldn't resolve the issue and flag where articles are missing or contradictory. The suggestions come in weekly, ranked by impact. This means someone has already had a bad experience before the system catches it, but at least it catches it.

Confluence offers time-based automation for archiving untouched pages and reminding owners to review. Atlassian's AI layer, Rovo, can create maintenance rules from natural language descriptions. Same limitation as Zendesk though: a page can pass its scheduled review and go stale two days later when a feature ships.

Freshdesk, Document360, and several others offer similar content health features. We compared these in The 8 Best Tools to Keep Your Knowledge Base Up to Date. The specifics differ but the pattern is the same: they track time since last edit, not relevance to what has actually changed in the product.

What's missing across all of them is the connection between your product's release cycle and your article accuracy. Scheduled reviews catch content that's been sitting untouched for months and is obviously outdated. What they don't catch the article that was verified last Friday and became wrong on Monday because a feature was renamed.

How to automate stale content detection

For teams shipping frequently, manual audits don't stay finished. You complete the review, feel good about yourself for half a day, and then the next release introduces new drift.

Connect your release pipeline to your content. If your team uses Jira, Linear, or GitHub, the tickets that close after a release contain information about what changed in the product. Comparing those changes against your published articles tells you which ones are likely affected. This is what Pageloop does: it watches for status changes in your project management tools and surfaces which published articles those changes touch, so you can review the right 5 articles after a release instead of scanning all 500.

Use AI to cross-reference your articles. Paste five articles about the same feature area into Claude, ChatGPT, or any LLM with a long enough context window and ask: "Do any of these contradict each other?" It won't catch everything, but it's much faster than one person reading through hundreds of pages, and the contradictions it does catch tend to be the ones your chatbot is actively confused by.

Track chatbot failure patterns. If your chatbot logs which articles it retrieves per conversation, you can watch for articles that used to resolve issues and have stopped doing so. A rising retrieval-without-resolution rate on a previously healthy article often means the content has drifted since the last update.

What to fix first

Prioritize by exposure. An article with 2,000 views per month and one incorrect screenshot is a higher priority than an article with 50 views describing a deprecated feature. The first one is misleading more people even though the second one is technically more wrong.

Within each article, fix factual errors first, then procedural errors, then screenshots, then phrasing. An article that tells a customer to click a button that no longer exists is a bigger problem than an article with a slightly outdated screenshot of a button that's in a slightly different place. Fix what stops people from completing their task before you fix what confuses them visually.

After updating, check the articles your chatbot retrieves alongside the one you fixed. Fixing one article without checking its neighbours can move the problem rather than solve it, because the chatbot may still be pulling a contradictory article for related queries.

Keeping it from coming back

The teams we've spoken to who keep their help centers current don't treat documentation as something you get to after the release. It's on the release checklist alongside QA and deployment. The article update happens before the feature goes live, or at least in the same sprint.

The Consortium for Service Innovation's KCS methodology formalizes this idea. KCS treats knowledge creation as a byproduct of resolving customer issues rather than a separate documentation project. When an agent solves a problem, they update the article as part of that interaction. The knowledge base improves continuously rather than in quarterly audit sprints that everyone dreads and nobody finishes.

For help centers powering AI chatbots, the margin for stale content has narrowed considerably. A human reader might notice a slightly off screenshot and work out the correct path. A chatbot will serve 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.


Image Courtesy: Yale Center for British Art and Art UK
Man of War Rocks, Coast of Dorset, John Brett (1831–1902)