Audit old blog posts by the age of the data inside them, oldest first. Every checklist you'll find opens the spreadsheet another way: sessions, rankings, the date in the byline. Those columns tell you which posts readers reach. Whether the posts are still right is the question an audit exists to settle, and traffic has no opinion on it. Sorted by data age, the page that has carried a 2023 figure into 2026 sits in row one, whatever its sessions say.
The whole exercise produces one artifact, a worklist: the ordered set of posts to open first, so an afternoon of fixes lands on the pages where a wrong number costs something. Posts drift on their own as the data inside them ages, a process called content decay, and it runs on the sources' schedule, off every dashboard you already watch.
In a LiquiChart scan of 5,034 claims across 46 domains, one in five of the posts that cite data were already carrying numbers two or more years out of date, and a post's risk of holding stale data more than doubled after its first birthday.
Why Traffic Misleads the Audit
Open analytics on any blog and the catalog arrives pre-sorted by sessions. That order answers a real question about demand, which pages pull readers and which sit idle, and demand is worth knowing. Accuracy lives somewhere else, in the figures a post cites and the sources those figures lean on, and both move on schedules that owe nothing to visit counts. The two axes never touch, so a list sorted by one says nothing about the other.
Look at what your top-ranking post has stacked against it. It has been live the longest. It gets cited the most. And it is the least likely page in the catalog to get a second read, because the instinct with a page that performs is to leave it alone. I feel that pull myself; the post I'm proudest of is the last one I want to reopen. Those three properties compound into a number that has been wrong for a year, sitting in your best page, traveling into other people's work with your name attached.
A traffic sort makes a second mistake: it takes the post as the unit of review. One page can hold a solid first-party figure next to three borrowed stats that expired on someone else's calendar, and a post-level judgment averages all four into "still ranks, leave it." That average is how you accumulate content debt without seeing it. The thing that actually ages is the claim, and the claim is the unit the rest of the audit works in.
Inventory Every Claim
The first pass, before you reread a single post, is an inventory. Go through the catalog and pull out every checkable statement you published as fact: each "according to" attribution, each percentage, each figure tied to a date. Leave the metrics columns off entirely. What you're building is a list of claims, each aging on its own schedule regardless of how the post around it performs.
A catalog of 50 posts is a rereading project; the claims inside those posts are a column, and a column can be sorted. A row that reads "2023 benchmark, borrowed, no link" tells you what to do without opening the paragraph it came from.
The Content Health Scanner extracts this list from a single URL. Whether a tool pulls the claims or you copy them out by hand, the audit turns tractable the moment the claim becomes the row. The inventory also surfaces problems no metrics column records: in a study of how SaaS blogs cite their sources, almost half of borrowed claims carried no external link at all, and about one in five of the links that did exist were already dead. A claim you never listed is a claim you never checked.
Sort by Data Age
The second pass sorts the list by the age of the data each claim carries, and the first thing the sort teaches you is that claims age at different speeds. A borrowed "according to" stat ages fastest, because the source can publish a new edition or rework its methodology and your post receives no signal that the ground moved. A first-party figure you measured yourself describes a moment with a fixed date, so it ages slowest and can wait. Inside any post, the borrowed lines come up for review before your own.
The drift also compounds with the age of the post itself. A scan of cited statistics across 46 domains measured the share of claims two or more years out of date, banded by post age.
The share more than doubles after the first birthday, from 2.0% in a post's first year to 10.3% in the 24 to 36 month band. Across the whole scan, roughly 20% of posts old enough to date were carrying data two or more years out of date. The oldest posts have ranked the longest and hold the most drifted data, which is why they lead the worklist, and they sit in exactly the band nobody schedules a check for.
One caution before you act on the sort: a 2023 figure can still be accurate in 2026. Age puts a claim in front of you for a look, and you decide whether it survives one.
Which Posts to Update First
Age orders the list. Reach settles the ties. Between two claims of similar vintage, the one in a post that ranks and collects citations comes first, because it repeats itself in rooms you can't see, under your name. Reach reenters the audit here, one pass later than the checklists use it, on tiebreak duty beneath the primary key of age.
The third pass yields the artifact the audit was for: a short ordered worklist, oldest data and widest reach at the top. You don't have to finish the catalog. Clearing the top of the list covers the posts where being wrong is expensive, and everything below it can wait its turn.
Worklists like this stay rare for one reason: almost every audit begins on the traffic axis, and a list that starts on the wrong axis ends on the wrong posts. So before you open anything, answer the question the whole sort turns on: when did you last check whether your best-performing posts are still right?
Whatever you answered, the date you reached for was the date of an accuracy check, and no analytics dashboard records those. The still-ranking post with a moved number lives in exactly that gap.
The interval you choose is the difference between an audit you run once and a worklist you regenerate. Set no interval and the sort order you just built decays the moment a source moves; set one and the same three passes hand you a fresh worklist each time. The catalog keeps aging on its own schedule either way, and the interval is the only thing that decides whether the worklist stays current or goes stale with it.
Where Manual Audits Cap Out
Done by hand, this works to roughly 40 posts. You can inventory the claims, sort them by data age, and land a worklist in a spreadsheet by this afternoon. Re-extracting claims from 300 posts every quarter, while confirming that every source you cited still answers, is a different scale of job, and the catalog resumes aging the moment you close the sheet. A manual pass is a snapshot of a moving thing.
Past that seam, the Content Health Scanner runs the same three passes on a URL, no account needed, and returns a ranked list of findings in under a minute. It extracts the claims and scores each for staleness against the age of its time reference, then sends an HTTP HEAD request to every cited URL to confirm the link still resolves, flagging the 404s and the redirects. Sources that do resolve get read for their publish and modified dates, so a page that's alive but untouched for two years surfaces as its own kind of risk, and every claim is scored for attribution and originality, separating the figures you measured from the ones you borrowed and the ones citing nothing at all. The findings come back ordered the way the worklist would be: oldest data and dead sources first.
The free pass ends at triage; the repair is a separate move, made once the ranking tells you which posts to open. Spreadsheets also miss a whole category of drift for a structural reason, separate from effort, and why manual audits miss source decay takes that up on its own.
How Often to Audit Old Blog Posts
Often enough to catch the drift, and no oftener. The genre consensus is to audit quarterly. If I had to commit to a cadence, quarterly is the ceiling and annual is fine for a small catalog, since data moves slowly enough that a tighter calendar mostly rereads posts that were already right.
Any cadence leaves a gap between passes. A quarterly audit samples the catalog four times a year, and whatever drifts in the 11 weeks between runs gets caught late or missed. Watching the gap is a different job from running the audit, and detecting when published data goes stale describes that job: an always-on layer that flags a claim the day its source moves.
The audit itself hands off at the worklist. With the order set, updating the posts without a full rewrite turns out smaller than the blank page suggests, because the sort already shrank the work to a handful of claims per post.
Somewhere in your catalog right now, a post ranks, collects citations, and repeats a number that stopped being true a year ago. Your traffic report shows it healthy. Its last-updated date shows nothing, since nobody has touched it. That page will never give you a reason to look; the sort order is the reason. Open your best-ranking post and check the oldest borrowed claim inside it. You'll usually find the problem on the first try.