When was the last time you looked at a post you published three years ago? For most people the answer is never, which is exactly the problem. Content accumulates. You publish, you move on, and the old pieces sit there aging, some still useful, many quietly rotting, and you have no idea which is which because you have never looked. A content audit is the act of finally looking, on purpose, at everything you have made and deciding what each piece deserves.
A content audit is a systematic review of your entire published library, page by page, to judge what to keep as is, what to improve, what to combine, and what to remove. It rests on an idea that runs against most content instinct: more is not always better. A page that adds nothing does not sit there harmlessly. It dilutes the average quality of your site, competes with your own better pages, and signals to a search engine that your standards are loose. The audit finds those pages and deals with them.
Why old content turns into a liability
The instinct that every page is an asset is where this goes wrong. Pages have carrying costs. An outdated post gives readers wrong information and erodes their trust in everything else you say. A thin post that ranks for nothing still counts toward how a search engine judges your site overall, and a pile of them drags the judgment down. Two posts covering nearly the same topic split their own authority and compete with each other, so neither ranks as well as a single combined page would.
None of this is visible from the outside, which is why it goes unaddressed. Traffic slides gently, rankings soften, and there is no single dramatic failure to point at, just a slow erosion nobody traces back to the forgotten library. By the time it registers, you have hundreds of pages and no idea where the rot is. The audit exists to make the invisible visible, to turn a vague sense that something is off into a page-by-page verdict you can act on.
The four-bucket method
Here is the framework that turns an overwhelming pile into a series of small decisions. Call it the four-bucket audit. Every page you own goes into exactly one of four buckets, and the bucket determines what happens to it. The power is in the constraint: forcing a single verdict per page stops you from staring at your library in paralysis and starts you moving through it.
The four buckets are keep, refresh, merge, and cut. Keep is for pages that still perform and still hold up, which need nothing. Refresh is for pages with a good core that have gone stale, wrong on a few facts, missing recent developments, thin in a section, and are worth updating rather than rewriting. Merge is for pages that overlap another page enough that combining them into one stronger piece beats keeping both. Cut is for pages that are outdated beyond saving, rank for nothing, and serve no one, which get removed and redirected. Every page lands in one bucket. No page gets to stay in limbo, because limbo is how the rot survived in the first place.
How to actually run the audit
Start by listing every page you have, pulled from a crawl of your site, into a spreadsheet. Next to each, add three numbers: how much traffic it gets, how it ranks and whether anyone clicks, and when it was last updated. Those three data points, traffic, search visibility, and age, give you most of what you need to assign a bucket. A page with steady traffic and recent updates is a keep. A page with a good position but no clicks might be a refresh. A page with zero traffic, no rankings, and a three-year-old timestamp is a cut, unless it overlaps a stronger page, which makes it a merge.
Then go page by page and commit a verdict. This is slower than it sounds and worth every minute, because the whole value of the audit is the honest judgment on each individual page. Resist the urge to keep something out of sentiment. A post you were proud of that now ranks for nothing and helps no reader is still dead weight, and keeping it because you liked writing it is exactly the bias the audit exists to override.
What to do with each bucket
The keep pile is done, left alone until the next audit. The refresh pile becomes a work queue, prioritized by which updates will return the most for the least effort, usually pages that already rank decently and just need to be brought current. The merge pile is more delicate: pick the stronger of the overlapping pages as the survivor, fold the best of the others into it, and redirect the ones you retire so their accumulated authority flows to the survivor instead of vanishing.
The cut pile is the one people flinch at, and it is often where the biggest gains hide. Removing genuinely dead pages, thin, outdated, unvisited, and redirecting them to a relevant living page, lifts the site’s overall quality signal and stops those pages from competing with your good ones. Deletion done carelessly, without redirects, throws away authority and breaks links. Deletion done properly, with every removed URL pointed at a sensible replacement, is a net gain. The fear of cutting is usually worse than any consequence of doing it right.
Auditing in the age of AI answers
There is a newer reason the audit matters. AI answer engines pull from sources they judge to be authoritative and current, and a library full of stale, thin pages reads as neither. When a model assembles an answer about your topic, it is more likely to draw from a site that shows tight, current, well-organized depth than one bloated with dead pages. The audit that cleans up your library for search also makes you a cleaner, more trustworthy source for the systems increasingly deciding who gets cited.
This tightens the case for cutting. In a search world, a dead page was mostly neutral, a little dead weight. In an answer-engine world, the overall impression of quality and currency directly affects whether you get pulled into answers at all. The audit is no longer just housekeeping. It is part of staying visible as discovery shifts from ranked links to synthesized answers, and the site that keeps its library honest has an edge over the one that never looks.
Making the audit a habit
Run once, a content audit is a heavy project. Run on a schedule, it is light maintenance. The reason the first audit feels brutal is that you are clearing years of accumulated neglect at once. Do it annually and each subsequent pass handles only a year of drift, which is manageable. Put a recurring date on the calendar, treat it like any other maintenance, and the library never gets the chance to rot the way it did before you started looking. The four buckets stay the same. The pile you sort through just gets smaller every time.