---
title: "How to Tell Which Articles Are Out of Date"
canonical: https://supportpages.io/guides/tell-which-articles-are-out-of-date
updated: 2026-08-13
---

A ranked list of articles that are probably wrong, built from signals you can gather without reading anything. Reading is the expensive step, so the point of the exercise is to read as few articles as possible and still find the damage.

## Before you start

You need your article list with last-edited dates, access to whatever records what shipped - release notes, a changelog, merged pull requests - and, if you have them, site search logs and recent support tickets. The tickets are the strongest signal available and the one most teams never connect to their documentation.

## Steps

1. **Pull the article list with last-edited dates and traffic.**
   Export it rather than browsing it. Anything you have to click through you will abandon at article thirty.

2. **Mark every article whose subject area shipped a change since it was last edited.**
   Take the last two or three months of release notes, list the parts of the product each one touched, and flag the articles covering those areas. This produces the highest-value suspects and it takes about an hour.

3. **Search your support tickets for article URLs.**
   A customer who was sent an article and replied is a documented failure of that article. Support macros linking to a page that generates follow-up questions are pointing at something wrong, not something missing.

4. **Look at your site search for queries that end in nothing.**
   A zero-result search for a term your product uses in the interface means the interface renamed something and the article did not. These are cheap to fix and disproportionately visible.

5. **Check for interface language that no longer exists.**
   Take the literal button labels from your current product and search your article text for the previous names. A text search across your export finds renamed features in minutes, and renames are the single most common source of quiet inaccuracy.

6. **Flag anything with images older than your last design change.**
   You do not need to open the article. If the image predates the redesign, treat it as suspect and let the priority order decide whether it is worth confirming.

7. **Score each article: evidence, traffic, and cost of being wrong.**
   A low-traffic page that is wrong about billing outranks a high-traffic page with a dated screenshot. Cost of being wrong is the column people forget, and it is the reason a purely traffic-ordered list misleads.

8. **Only now, open the top ten and confirm.**
   Confirmation is fast when you already know what you expect to find. Record the outcome against each one, including the false positives, because false positives tell you which signals to weight down next time.

![Four staleness signals ranked by how reliable each is: screenshots, renamed features, edit date and traffic.](/images/guides/figures/tell-which-articles-are-out-of-date.webp)

*Screenshots date an article faster than reading it does.*

## Common mistakes

**Trusting the last-edited date.** It records the last time anyone typed in the article, not the last time anyone verified it. A tag change or a typo fix resets it, so a freshly-dated article can be years stale and a two-year-old article can be perfectly accurate.

**Treating low traffic as evidence of health.** Nobody reads it is not the same as nothing is wrong. Some low-traffic articles are low-traffic because they are wrong and people bounce off them, and search data will not distinguish the two.

**Auditing in alphabetical or category order.** Both orders are uncorrelated with where the errors are, so you spend your first and most attentive hours on whatever happens to start with A.

**Assuming conceptual pages are safe.** They decay more slowly, not never. Pricing model changes, plan renames and policy updates all invalidate pages that contain no screenshots at all, and those pages are the ones nobody thinks to check.

**Confirming everything before fixing anything.** A full confirmation pass across the whole help centre is a second audit bolted onto the first. Confirm the top ten, fix them, then re-rank with what you learned.

## When this stops scaling

Every signal here is a proxy, and proxies work while the volume is small enough that a person can adjudicate them. Below about forty articles you can hold the whole map in your head and the signals mostly confirm what you suspected.

The threshold is the point where the release stream stops being readable. If more than a handful of meaningful changes ship each week, step two stops being an hour of work and becomes a standing job - and it is the step that produces most of the value, so degrading it degrades the whole method.

There is a second, quieter limit. This process finds articles that are wrong. It does not find the articles that should exist and do not, and that gap grows with every feature that shipped without documentation. No amount of auditing existing pages surfaces a missing one.

Past that point the useful question changes from "which articles look old" to "which articles does this specific merged change affect", which is answerable from the diff rather than from a spreadsheet. [SupportPages](https://supportpages.io) watches merged pull requests and puts the affected articles in front of you when the change lands, so the list is short and arrives while the change is still fresh. If your audits keep rediscovering the same articles a quarter late, that is the loop worth shortening.