Guide · Updated
How to find outdated help articles
Outdated help articles rarely announce themselves. They sit quietly with good traffic while customers follow steps that no longer work. These six checks find them, starting with the cheapest. Run the first three this week; they catch most of the damage.
What makes a help article outdated?
An article is outdated when any statement in it no longer matches the product: a step, a setting name, a number, a screenshot, or a claim about what's possible. One wrong detail is enough, because customers can't tell which parts are still true.
The usual suspects are steps that reference moved or renamed UI, plan limits and prices, screenshots, field names in API examples, and statements like “this isn't supported yet” about features you've since shipped.
Check 1: Compare recent releases with your articles
Take every customer facing change from the last 90 days of releases and search your help center for the feature, setting, or screen it touched. Any article that mentions it is a candidate. This is the single most productive check, because it starts from what actually changed.
- Open your changelog, release notes, or merged pull requests for the last 90 days.
- Write down each change a customer would notice.
- Search the help center for each one, including old names.
- Read every matching article against the current product.
For Ledgerloop, the invoicing SaaS in our examples, a release that moved reminders from Settings to the Invoices page means searching for “reminder”, “Settings”, and “overdue”, then reading every hit.
Check 2: Read tickets that mention your docs
Search your support inbox for phrases like “the article says”, “your guide”, “the docs”, “doesn't match”, and “I followed”. Customers who quote your docs back at you are pointing straight at the outdated part.
Also look at tickets that arrived right after a customer viewed an article, if your tools show that. A customer who reads an article and then writes in anyway either found it wrong or found it unclear. Both need fixing.
Check 3: Look at feedback votes and searches
Sort articles by “not helpful” votes and look for any that spiked after a release. Then read your help center's search terms: searches for a new feature name that return nothing, or that land on an old article, tell you the docs haven't caught up with the product's vocabulary.
| Signal | What it usually means |
|---|---|
| “Not helpful” votes jump after a release | The release made the article wrong |
| Searches for a new name return nothing | The docs still use the old name, or the article doesn't exist |
| Search lands on an article, then a ticket follows | The article is wrong or incomplete |
| Assistant cites an article for a changed detail | The article needs an edit before the next answer |
Check 4: Sort articles by age and traffic
List your articles with their last updated date and views. Old and heavily read is where outdated content hurts most. Old and rarely read can wait, or can be archived.
| Last updated | Traffic | What to do |
|---|---|---|
| Over 6 months | High | Review now |
| Over 6 months | Low | Review this quarter, or archive |
| Recent | High | Spot check after each release |
| Recent | Low | Leave it |
Age alone isn't proof: a concept article from last year can be perfectly accurate. Use age to choose what to read, not to decide what's wrong.
Check 5: Walk through setup articles in a fresh account
Create a new account and follow your getting started and setup articles exactly as written, step by step. Every place you have to improvise is a place a new customer gets stuck. Do it on a phone too if customers sign up on mobile.
This catches what the other checks miss: missing steps, screens that changed slightly, and instructions that assume settings a new account doesn't have yet. It takes an hour and it's the closest you can get to seeing the docs through a customer's eyes.
Check 6: Check articles against the code
The most thorough check compares what each article says with what the code does: setting names, limits, defaults, flows, and field names. By hand, that means an engineer reading articles next to the codebase, which rarely happens. With tooling, it can run on every article on a schedule and on every merged pull request.
This is the only check that finds drift before customers or analytics show it, because it doesn't wait for symptoms.
How do you decide what to fix first?
Fix by impact: how many people read the article, and how bad it is to follow the wrong version. Billing, setup, and anything customers act on with money or data come first. Cosmetic issues in rarely read articles come last.
- Wrong numbers in billing and plan articles.
- Broken steps in setup and getting started.
- Wrong details in the articles your assistant cites most.
- Outdated screenshots in high traffic articles.
- Everything else, by views.
When you fix an article, update its date and check the articles that link to it; outdated statements often appear in more than one place.
How does usedocs find outdated articles?
usedocs runs checks 1 and 6 for you. It reads every merged pull request and release, finds the articles that describe what changed, and proposes an edit with the change attached. A scheduled check reads every live article against the code and your website and flags statements that no longer match, with a suggested fix. Doc health lists which articles match the code and which need review.
It covers checks 2 and 3 through the customer side: “not helpful” votes, questions the assistant couldn't answer, and imported tickets become ranked gaps with drafts. Every change waits in one review queue for your approval.
FAQ
How often should I check for outdated help articles?
Check the articles each release touches as it ships, review feedback and searches weekly, and walk through setup articles every month or two.
Should I delete outdated articles?
Fix them if the topic still matters; otherwise redirect them to the closest current article. Deleting without a redirect breaks links from emails, search results, and other articles.
Is a last updated date useful to readers?
Yes. It tells readers how much to trust an article, and it reminds you which ones haven't been looked at in a while.
Can I find outdated articles automatically?
Yes, with tools that compare articles against releases or the code. Analytics like votes and searches also help, but they only show problems after customers hit them.
Use usedocs for this
usedocs checks every live article against your code on a schedule and proposes edits when merged pull requests change what an article describes.