The best way to audit old blog posts is to start with the one that still ranks. It has been live the longest, so the data inside it has had the most time to drift, and a page that keeps performing gives nobody a reason to open it. Search "content audit checklist" and the first column is always traffic: sessions, rankings, the date in the byline. Traffic tells you which posts readers reach. Whether those posts are still right is a different question, and the audit that answers it sorts by the age of the data inside each post, oldest first. Sort that way and the still-ranking post carrying a 2023 number into 2026 lands at the top, where it belongs.
This framework finds the posts most likely to be wrong before a reader does. It produces one thing: a sorted worklist, the specific posts to open first, so your time goes to the pages that matter instead of the ones that were already fine. Posts drift as the data inside them ages. That is content decay, and no traffic report shows it. The first move is to stop trusting the metric that hid it.
Claim: Roughly 24% of blog posts old enough to date carry data two or more years out of date, and a post's risk of holding stale data more than doubles after its first birthday. Source: LiquiChart staleness study, a scan of cited statistics across 45 domains (/blog/saas-blog-stale-data-study). Verified: 2026-06-04
Why Traffic Is the Wrong Sort Axis
Open the analytics for any blog and the audit sorts itself by sessions. The posts at the top are the ones readers reach; the bottom, the ones they do not. That sort answers a real question, just not the one an audit is for. Traffic measures demand.
Accuracy lives in the data inside a post and the sources it leans on, and those move on a schedule that has nothing to do with how many people visit. The two axes are independent. A traffic sort cannot see accuracy at all, so it leaves the real question untouched.
A post that still ranks is the most dangerous one in your catalog. It has been live the longest, it gets cited the most, and it is the least likely to be audited, because the instinct toward a page that works is to leave it alone. I feel that pull too: the post I am proudest of is the last one I want to reopen. That instinct is the bug. Those three properties compound into a number that has been wrong for a year, sitting in your best post, traveling into other people's work under your name.
The traffic sort also treats the whole post as the unit. Do that and you inherit content debt you cannot see: a single page can hold one solid first-party number and three borrowed stats that expired on someone else's schedule, and a post-level audit averages them into "still ranks, leave it." The claim is what actually ages. Sort by the post and the claim hides in the average. Sort by the claim and it has nowhere to hide.
Inventory the Claims, Not the Posts
When you audit old blog posts, the first pass is inventory, before you read a single one. Checklists have you list pages, then columns of metrics beside each. List the claims instead: every "according to" attribution, every percentage, every dated figure you published as fact. Lined up out of the prose, the claims are what age, each on its own schedule, no matter how the post around it performs.
This sounds like more work than the checklist. It is the opposite. 50 posts is a re-reading project. The claims inside them are a list. Lists, you can sort.
A page of prose forces you to judge the whole thing at once. A row that reads "2023 benchmark, borrowed, no link" tells you what to do without rereading the paragraph it came from.
The Content Health Scanner does this on a single URL, reading the page and handing back the testable claims inside it, so you work from the list instead of your memory of what you wrote. By hand or by paste, the principle holds: the audit only becomes tractable once the claim is the row. And an inventory surfaces what a metrics column never will. In a study of how SaaS blogs cite their sources, almost half of borrowed claims carried no external link at all, and nearly a quarter of the links that did exist were already dead. You cannot audit what you have not listed.
Sort by the Age of the Data Inside
With the claims in a list, the sort key is the age of the data each one carries. Claims do not all age at the same rate, and the difference tells you where to look first inside a post. A borrowed "according to" stat ages fastest: the source can publish a new edition or revise its methodology, and your post gets no signal that the number moved. A first-party figure you measured yourself describes a moment that already happened, on a date that does not change, so it ages slowest. The borrowed lines are where you look before your own.
How fast does this happen? A claim ages with the post around it. A scan of cited statistics across 45 domains shows the share two or more years out of date, by how old the post is.
The share more than doubles after the first birthday, from 2.3% in a post's first year to 13.1% by the 24 to 36 month band. The oldest posts have ranked the longest, and they carry the most data that has slipped out of date. That is why they belong at the top of the worklist. Across the whole scan, roughly 24% of posts old enough to date were carrying data two or more years out of date. Nobody schedules a birthday check for a page that is working.
One framing matters before you act on the sort. Old is not the same as wrong. A 2023 figure may still hold; sorting by age does not declare it false, it flags it for a look before a reader trusts it past its expiry. The audit surfaces the claim. You decide.
Fix the Oldest Data, Highest Reach First
Age sorts the list. Reach decides ties. The oldest claim in a post nobody reads ranks below a moderately aged claim in a post that ranks and gets cited, because the second one carries your name into rooms you cannot see. Age stays the primary key. Reach earns its place back as the tiebreaker, demoted from the thing you sorted by to the thing that settles a draw.
This pass produces the worklist the whole audit was for: a short, ordered set of posts to open, oldest data and highest reach at the top, everything else waiting its turn. You do not have to finish the catalog. You have to clear the top of the list, where being wrong costs the most.
This worklist is rare, and not because it is hard to build. It is rare because the sort almost never starts from accuracy. The default audit opens with traffic, and a list that begins on the wrong axis ends on the wrong posts.
Pull up your analytics and the audit sorts itself by sessions. So before you open a single post, answer a different question: when did you last check whether your best-performing posts are still right?
Whatever you answered, notice the question measured accuracy. Traffic measures something else, and only one of those two sort orders finds the post that still ranks while carrying a number that moved.
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 the Spreadsheet Caps Out
Auditing old blog posts by hand caps out around 40 posts. You can inventory the claims, sort them by data age, and have a worklist in a spreadsheet by this afternoon. What you cannot do is re-extract the claims from 300 posts every quarter, by hand, forever, while checking whether every source you cited still answers. The manual pass is a snapshot. The catalog keeps aging the moment you close the sheet.
That is the seam where the Content Health Scanner stops being a faster spreadsheet and starts doing what the spreadsheet cannot. On a single URL, with no account, it runs the same three passes you have been doing by hand 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 it checks the sources: an HTTP HEAD request to every cited URL, confirming the link still resolves instead of returning a 404 or a redirect.
The ones that resolve get read for their publish and modified dates, so a source that is alive but untouched in two years surfaces as its own kind of risk. Attribution and originality get scored across the page, sorting the numbers you measured yourself from the ones you borrowed and the ones with no source at all. The findings come back ranked, oldest data and dead sources first: the worklist the manual pass was trying to build.
What it does not do on that free pass is fix anything. It triages and flags. The repair is a separate move, once you know which posts to open. And there is a deeper reason a spreadsheet misses things, one that has nothing to do with effort: why manual audits miss source decay is its own subject.
Audit Cadence and the Layer Between Passes
How often should you audit old blog posts? Often enough to catch drift, not so often that you re-audit posts that have not changed. The genre consensus is to audit quarterly. If I had to pick a cadence, I would treat quarterly as the ceiling and annually as fine for a smaller catalog. Data moves slowly enough that a tighter calendar mostly re-reads posts that were already right.
The problem with any cadence is the gap between passes. A quarterly audit is a sampling pass: whatever drifts in the 11 weeks between runs, it catches late, if at all. Something has to watch the gap. That is the line between an audit and monitoring. The audit is the periodic pass you run; detecting when published data goes stale is the always-on layer that flags a claim the day its source moves, instead of the next time you open the spreadsheet.
The audit ends where the worklist begins. Once you know which posts to open and in what order, updating them without a full rewrite is the next move, and a smaller one than the blank page suggests. The sort already narrowed the work to the handful of claims at the top.
Somewhere in your catalog a post still ranks, still gets cited, and carries a number that stopped being true a year ago. It does not show up in your traffic, because traffic is not where the problem lives. It does not show up in your "last updated" date, because nobody updated it. The only reason you have not fixed it is that it never gave you a reason to look.
The sort order is the reason. The way to audit old blog posts is to open the oldest claim in the post that ranks the best, and you will usually find it on the first try.