SEO Content Audit: The Framework We Run on 27 Sites
Summary
A working SEO content audit sorts every page into keep, refresh, merge, or retire, using a scored rubric instead of gut feel. This piece walks through the four-tier triage run across a 27-site portfolio, what changed in scoring after the March 2026 core update, and how to check whether a page is legible enough for AI systems to cite. The scoring criteria and the tools actually used are both included.
An SEO content audit works when it ends in a decision, not a spreadsheet. Every page gets sorted into one of four buckets: keep, refresh, merge, or retire. That sounds obvious until you run one on 400 URLs and realize most audits stop at diagnosis. We built the framework below after auditing 27 sites in our own portfolio, including this one. It is not a checklist. It is a scoring system that tells you what to do next, not just what is wrong with a page.
What most content audits get wrong at scale
Most audit guides assume you have 40 to 80 pages and an afternoon. Export the URLs, pull Google Search Console, flag anything down 20% year over year, done. That works fine for a small blog. It falls apart the moment you cross a few hundred URLs, because the real bottleneck stops being detection and becomes triage: which of the 60 flagged pages get fixed first, with what budget, by whom.
At that point a list of underperforming pages is not a plan. It is homework you have not done yet. We learned this the expensive way on our own sites: a 2025 audit produced a spreadsheet of 340 "needs attention" URLs and no way to sequence the work, so nothing got done for six weeks. The spreadsheet was accurate. It was also useless, because nobody could tell, from a row of numbers, whether a page needed ten minutes of editing or a full rewrite.
The fix is not a better checklist. It is a scoring rubric that outputs a verdict, and a rule for what happens once you have it. Diagnosis without a next action is the most common way a content audit turns into a document nobody opens again.
The four-tier triage we run instead of a spreadsheet review
Every URL gets scored across five dimensions, loosely adapted from a 100-point rubric Digital Applied published after the March 2026 core update: experience and authority signals, content depth relative to the query, freshness, engagement, and technical health. We weight authority signals heaviest, because that is the dimension that actually moved after March, and the one most programmatic operations get wrong by default.
The score sorts the page into one of four buckets:
Keep (score 80+): leave it alone, it is doing its job and touching it risks more than it gains
Refresh (55-79): update facts, add missing depth, fix the byline if it is anonymous, tighten the answer-first opening
Merge (30-54): the page overlaps with one or two others targeting the same intent, consolidate into a single stronger URL
Retire (below 30): redirect or prune, it is not worth the maintenance cost and it is diluting the site's overall quality signal
On a 214-URL portfolio blog we run internally, the first triage pass took about nine hours and split roughly 40% keep, 30% refresh, 20% merge, 10% retire. Nine hours for 214 pages is a real number worth planning around, not a rough estimate you adjust after the fact. Budget for a full day per 200 URLs and you will not be surprised.

The scoring itself stays manual on purpose. Content scoring tools like Surfer will happily hand you a number, but the number does not know why your byline is anonymous or whether the page still matches search intent after a competitor rewrote the category page last month. Use the tool for the content-depth dimension, not for the whole verdict. Automating the score defeats the point of scoring at all.
Where the data actually comes from, and where it lies
Pull twelve months of Google Search Console (clicks, impressions, position) and GA4 (sessions, engagement rate, conversions) for every URL. That part is standard, and King Content Agency's seven-step framework covers it well for a single-site audit at a manageable scale.
Where it gets misleading at portfolio scale: a raw traffic drop on a page that lost 40 internal links after a navigation redesign looks identical, in Search Console, to a page that genuinely decayed on quality. Both show the same downward line for the same twelve months. Only one of them needs a rewrite; the other needs a link back.
We run the technical layer separately, through a site-wide crawl, before touching the content scores at all. If a page's traffic dropped because it stopped being linked from anywhere useful on the site, that is an internal linking fix, not a content problem, and no amount of rewriting the copy will move the number. Conflating the two is the single most common mistake we see in audits that "didn't work" after months of effort.
For sites under 100 pages, review every flagged URL individually. Past that, we sort by traffic tier first (top 20%, middle 60%, bottom 20% by sessions) and only hand-review the top two tiers; the bottom tier gets the scoring rubric applied in batch, no individual reads. It is a coarser pass, and it is the only way nine hours stays nine hours instead of forty.
How the March 2026 core update changed what we look for
The March 2026 core update affected an estimated 55% of monitored sites, with sites lacking first-hand experience signals dropping an average of 8 positions. That is not a small correction, and it is not evenly distributed: sites with named, credentialed authors were far less exposed than sites publishing under a generic "Team" byline.
The update did not punish AI-assisted content as a category. It punished unowned content: no named author with a real track record, no evidence anyone with domain knowledge reviewed the draft before it published, generic claims with nothing behind them. Every audit we run now includes a byline check as a first-class signal, not a footnote buried under technical checks.
Three cases where this holds, two where it does not. It holds for programmatic content published at volume with rotating or missing authors, for pages making claims with zero sourcing, and for anything that reads like it was templated 400 times with a keyword swapped in. It does not hold for niche technical documentation with a small page count, where thin can just mean precise, and it does not hold for evergreen reference pages where freshness matters less than accuracy in the first place.
Can AI systems actually read this page in three sentences?
This is the dimension most 2025-era audit templates skip entirely, and it matters more every quarter. Take the page's H1 and first two paragraphs, and try to summarize the answer in three sentences without lifting a full paragraph verbatim. If you cannot do that cleanly, an AI system probably cannot either, and it will summarize a competitor's page instead of yours.
We check this with a citation tracker rather than guessing from a hunch. If a page ranks on page one but never shows up in AI-generated answers for the same query, that is a legibility problem, not a rankings problem, and the fix is usually structural: a direct answer in the first 80 words, a clear TL;DR block near the top, and headings phrased as the questions people actually type.
What we do with the pages that fail
Retire means a 301 redirect to the closest live equivalent, or a prune with a custom 404 if nothing fits well enough to redirect to. Merge means picking the stronger of two overlapping URLs, folding the weaker one's unique value into it, and redirecting the loser. Refresh is where most of the budget goes, and where teams tend to underestimate the time.

For refresh, we draft the update with an assisted writing tool, then edit it against the source material ourselves before it republishes. That editing pass is not optional; skipping it is how a refresh becomes just as unowned as the original page it was meant to fix. Skip the temptation to let the tool touch anything already scoring above 55, too. Refresh what is broken, not what is merely quiet this quarter.
The tools in the stack, and the ones we skip
Screaming Frog's free tier handles the technical crawl up to 500 URLs, which covers most of our individual sites. Past that threshold, we pay for the crawl rather than split it into batches, because split crawls miss cross-page duplication. For content scoring, we use one tool as a single input among five, never as the verdict on its own.
This article, and every other one on this site, was produced with EsyBlog itself: the system audits and writes its own back catalog, which is either a useful case study or an obvious conflict of interest, depending on how skeptical you want to be about the source. We would rather state that plainly than pretend it is not true.
We are honest about where it is weak. It is slower than a human on breaking news, and it needs a real editor to catch tone drift on anything that runs past 2,000 words. We keep using it anyway, because the alternative, at 27 sites and a two-person editorial team, was not "hire ten writers." It was publishing nothing, or publishing worse.

What changes after the first audit
The second audit is faster, because you already know where the anonymous bylines live and which templates keep triggering the retire bucket. The scoring rubric does not change much between rounds; what changes is how quickly you trust your own verdicts instead of re-checking each one.
Score, sort, act, and schedule the next pass before you close the spreadsheet. A framework nobody revisits is the same failure mode as the checklist we started with, just with better organized columns. EsyBlog runs this exact framework on demand for teams who want the scoring sheet without building it themselves.