SEO Content Audit: What to Update, Merge, or Delete

A content audit that ends in a spreadsheet is not an audit. It is an inventory.

The guide ranking second in the US for "seo content audit" runs roughly 5,200 words and was updated in May 2026. Screaming Frog's, at position nine, runs longer and was last touched in March 2025. Both are competent. Both hand you a column called "action" and leave you to fill it in from feel, which is precisely the part that is hard.

This article is about the four values that column can take, the numbers that decide between them, and one Search Console report that did not exist when either of those guides was written. Google finished rolling it out to every site in the world on 31 August 2026, seven days before this was published.

An audit produces four verdicts and nothing else

Every URL you look at ends in one of four buckets: keep, update, merge, delete. Anything else you write in that column is a note to yourself, not a decision.

The buckets are not equally expensive, and that asymmetry should drive the order you work in.

Keep is the default. That sounds obvious until you notice that most audit templates open with a "content decay" tab, which frames the exercise as finding pages to change. An audit that changes nothing on eighty percent of a site is a normal outcome, not a failed morning.

Delete is the verdict to be most suspicious of. A URL that has been indexed for two years carries internal links, whatever external links it picked up, and a history in Google's index. You are throwing all of that away in exchange for a tidier sitemap, and a tidier sitemap is worth nothing on its own. The same restraint applies to an archive of hundreds of near-identical posts, which is the case we work through for wedding photographers.

Pull the data, then learn what it leaves out

Start from Search Console, page dimension, sixteen months if you have it. The API returns the same rows as the interface without the export dance:

curl -s -X POST \
  "https://www.googleapis.com/webmasters/v3/sites/https%3A%2F%2Fexample.com%2F/searchAnalytics/query" \
  -H "Authorization: Bearer $GSC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "startDate": "2026-06-09",
    "endDate": "2026-09-07",
    "dimensions": ["page"],
    "rowLimit": 25000,
    "dataState": "final"
  }'

Two properties of that data change how you read it, and neither is mentioned in the guides currently ranking.

The first is anonymization. Search Console's documentation on performance report dimensions is explicit: "Some queries are omitted from the report to protect user privacy. These are called anonymized queries. They're included in chart totals, unless a query filter is applied." Page-level impressions will therefore be higher than the sum of the query rows under that page. If your audit sheet computes "queries per page" or tries to attribute every impression to a keyword, it is computing on a filtered set and will systematically under-count the long tail. On a young blog the long tail is most of what you have.

The second is the window. The same documentation, describing the branded query filter, states that it "provides a 16-month history of data, starting from when it was first introduced in March 2025". In practice the whole performance report runs on that rolling window. Anything older is gone unless you exported it, so an audit is also the moment to start a monthly export you will be glad of next year.

On the crawl side you need the list of URLs that exist, which is not the same as the list Search Console knows about. Screaming Frog's free tier caps at 500 URLs and the licence is £199 per year as of publication, which is enough for most blogs and cheaper than the alternative of guessing. If your blog is file-based, the crawl is a ls:

ls content/blog/*.md | sed 's#content/blog/#/blog/#; s#\.md$##' | sort > /tmp/urls-that-exist.txt

The join of those two lists is where the interesting rows are. A URL in the crawl and not in Search Console has never been served. A URL in Search Console and not in the crawl is a 404 that still has demand, and that one is usually worth a redirect.

Search Console has a column that did not exist in June

Google's generative AI performance report is the genuinely new input for a 2026 audit. The Search Console documentation states: "As of August 31, 2026, we've rolled out these insights to all websites worldwide." It covers AI Overviews and AI Mode, and it reports impressions and clicks per page for those surfaces separately from ordinary organic results.

One counting rule in that documentation matters for the arithmetic: "if two results from the same site appeared in a generative AI search results feature, they count as a single impression." Two of your pages cited in the same answer is one impression, not two. Any per-page attribution you build on this number is approximate by design, and treating it as exact will make a merge look better than it was.

The consequence for the audit is direct. A page with zero organic clicks and steady impressions in generative AI features is not dead weight. It is being read by a system that decides what to say about your topic, and deleting it removes a source that has already been trusted at least once. That page belongs in "keep" or "update", never in "delete", and the answer engine optimization side of your reporting is where you check it.

Resist the temptation to invent a new optimization for this surface. Google's own guidance on AI features, last updated 10 December 2025, says plainly: "There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary." There is no file to add. What you audit is the same content, with one more column showing where it is already being used, which is also the honest way to read a brand visibility report across assistants.

Read impressions before clicks

Clicks are the metric everyone sorts by, and they are the wrong first sort. Impressions tell you whether demand reached the page at all. Clicks tell you whether the page won the click once it got there. Those are different failures with different fixes.

Four states, four different verdicts:

The second row is the one worth money and the one most audits mishandle, because a sheet sorted by clicks puts it at the bottom next to the genuinely dead pages.

We run this on our own blog and it is currently the most interesting row we have. As of 7 September 2026, /blog/diy-seo-for-small-business shows 451 impressions and zero clicks over the previous 28 days, growing by roughly fifty impressions a day.

Nothing is wrong with the article. Google is showing it, repeatedly, and nobody clicks. That is a title and description problem, and rewriting the 3,000 words underneath would be work aimed at the wrong defect. We say this publicly because it is the exact pattern we tell customers to look for, and doing your own SEO means being willing to read your own bad numbers.

Here is the bucketing, small enough to paste and adjust:

// node bucket.js rows.json
import { readFileSync } from 'node:fs'

const rows = JSON.parse(readFileSync(process.argv[2], 'utf8')).rows ?? []

const verdict = (r) => {
  const [impressions, clicks, position] = [r.impressions, r.clicks, r.position]
  if (impressions < 20) return 'candidate-delete'      // no demand reached it
  if (clicks === 0 && impressions >= 100) return 'update-snippet'
  if (clicks === 0 && position > 20) return 'update-content'
  if (clicks > 0) return 'keep'
  return 'review'
}

for (const r of rows) {
  console.log([verdict(r), r.keys[0], r.impressions, r.clicks, r.position.toFixed(1)].join('\t'))
}

Those thresholds are starting points, not law. On a site with a hundred thousand sessions a month, twenty impressions is noise and the floor should be much higher. The shape of the rule is what transfers: demand first, then conversion of that demand, then position as the tiebreak.

Keep: the pages that need nothing

The hardest verdict to defend in a meeting is "leave it alone", so it helps to have Google's own words for it. From the guidance on creating helpful content, last updated 10 December 2025, in the list of questions you should be able to answer no to:

Are you adding a lot of new content or removing a lot of older content primarily because you believe it will help your search rankings overall by somehow making your site seem "fresh"? (No, it won't)

That sentence kills two rituals at once. Refreshing every article on an annual rota is not a strategy, and pruning to a smaller, "healthier" site is not one either. Both are changes made for the algorithm rather than the reader, which is the thing the guidance is describing.

It also helps to know there is no switch to flip. Google's ranking systems guide, also updated 10 December 2025, records that the helpful content system "evolved and became part of our core ranking systems" in March 2024. There is no separate classifier to escape and no site-wide flag to clear by deleting pages. That framing still circulates in audit advice written before 2024, and it is worth checking the date on anything that repeats it.

Update: change the entry point before the body

When a page surfaces and does not earn the click, the title and the meta description are the whole of what the searcher read. Rewrite those first, publish, and wait for a fortnight of data before touching anything else.

The order matters more than it sounds. Rewriting the body of a page that already holds a position puts the only thing working at risk, in exchange for a change nobody in the results page can see. If position is stable and impressions are rising while clicks stay at zero, the body is not the defect.

When the body is the defect, the symptom is different: the page surfaces for a query it half-answers, sits beyond position twenty, and the top results cover something it does not. That is a coverage gap, and the fix is to add the section rather than to reword the intro. Our own product page SEO piece exists because the pages ranking for that query answered what to put on a page and never what a page can earn, which is a coverage gap of exactly this kind, and the same reasoning drives which pieces a store keeps when it audits its ecommerce content marketing archive.

Two things not to do while updating. Do not change the URL for cosmetic reasons, because you then owe yourself a redirect forever. Do not bump the date without changing the content, which is the same freshness theatre Google names above.

Merge: canonical and redirect are not interchangeable

Two of your pages answering one query is the most common real finding of a content audit, and the fix depends on whether both pages should keep existing.

Google's documentation on consolidating duplicate URLs, last updated 10 July 2026, draws the line. Use rel="canonical" to "consolidate the signals they have for the individual URLs (such as links to them) into a single, preferred URL" when you want both pages to stay. Use a redirect "when you want to get rid of existing duplicate pages". The same page is careful about what a canonical is: "A strong signal that the specified URL should become canonical", not an instruction Google is obliged to follow.

If you are removing the loser, the redirect page (updated 14 April 2026) is unambiguous about which kind. Permanent redirects "show the new redirect target in search results". Temporary ones "show the source page in search results", which is the opposite of the point. In a Next.js project that is config, not middleware:

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  async redirects() {
    return [
      {
        source: '/blog/old-thin-post',
        destination: '/blog/the-page-that-survived',
        permanent: true, // 308, the modern permanent redirect
      },
    ]
  },
}

export default nextConfig

Redirect to the page that actually answers the same question. A merge that points twenty retired posts at the blog index is not a merge, it is a bulk deletion with extra steps, and Google is likely to treat those targets as soft 404s. The rest of the Next.js SEO surface is worth a pass at the same time, since you are already in the config.

Before you merge, confirm the two pages really do compete. Filter Search Console by the shared query and look at which pages appear, the same collision test we run on a keyword map. If only one of them ever surfaces, you have two articles on related topics, not a duplication, and merging them will cost you the queries the second one owns alone.

Delete: 410, noindex, and what the removals tool does not do

Deletion is the verdict that cannot be undone, so it is worth knowing exactly what each mechanism does.

Google's guidance on removing information, updated 10 December 2025, lists three ways to make a removal permanent: remove or update the content, password-protect the page, or add a noindex tag. It is equally clear about the tool people reach for first: "Requests made in the Removals tool last for about 6 months." That tool suppresses a URL while you fix something. It is not a delete.

The same page warns: "Don't use robots.txt as a way to block your page." The reason is in the indexing documentation, updated the same day: "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler." Disallowing a URL you have just marked noindex guarantees the rule is never read, which is the trap behind the status "Indexed, though blocked by robots.txt" and one of the four branches in why your website is not showing up on Google.

For a page that should stop existing and has no replacement, return 410 rather than 404. Both remove the page; 410 says the removal is intentional. For a page that should stay reachable but leave the index, the App Router metadata export is the whole of it:

// app/legacy/page.tsx
export const metadata = {
  robots: { index: false, follow: true },
}

Keep follow: true unless you also want the links on that page to stop passing signals internally.

One rule that survives every audit: never delete a page that has external links pointing at it. Redirect it to the closest live equivalent instead. The links are the scarce asset, and they took longer to earn than the article did to write.

What an audit cannot fix

An audit reorganizes what you have. It does not turn thin pages into good ones, and it does not launder content that was produced at volume for search engines rather than readers.

Google's spam policies, last updated 28 August 2026, are worth reading in full before an audit of a large, machine-generated archive. The opening definition now covers a surface it did not use to: spam is "techniques used to deceive users or manipulate our Search systems into featuring content prominently, such as attempting to manipulate Search systems into ranking content highly or attempting to manipulate generative AI responses in Google Search."

The scaled content abuse definition in that document has two conditions, and it is worth being precise about them: "many pages are generated for the primary purpose of manipulating search rankings and not helping users". Both halves have to hold. How the pages were written is not one of the conditions, and the examples make that explicit by naming generative AI tools used "without adding value for users". Volume alone is not the offence, and neither is authorship. This is the same distinction that decides whether an AI SEO agent is a production tool or a liability.

The honest limit of the whole exercise: no one can guarantee a position, and results vary by site, by competition and by how much demand actually exists. An audit improves the odds by removing self-inflicted problems. It does not create demand where there is none, which is the arithmetic behind whether SEO is worth it at all and behind what SEO should cost you before you commit to it.

Cadence, and writing the verdict down

Quarterly is the right rhythm for most sites, and monthly is almost always too often: the metric you are reading moves on a scale of weeks, and re-deciding a page every four weeks means deciding on noise.

The part people skip is recording the decision. For every URL you touch, write down the verdict, the number that produced it, and the date. Six months later, when a page you merged is still not recovering, the only useful question is what you believed at the time and whether it was true. A sheet of actions without reasons cannot answer that.

The same record is what lets you tell a slow win from a mistake. A page updated in March that has climbed from position 34 to 19 with no clicks yet is working. Without the March number it looks identical to a page that has done nothing, and the temptation is to change it again, which resets the clock. This is the discipline that separates content operations for a SaaS blog from a series of unrelated Saturday afternoons.

If your audit produces more work than you can do, do the "update the snippet" rows first. They are the cheapest change on the list, they touch the two lines a searcher actually reads, and they are the only ones where the page has already proved there is demand.

FAQ

What is an SEO content audit?

It is a review of every indexed page on a site that ends with each URL assigned one of four verdicts: keep, update, merge, or delete. The inventory step (crawling the site, exporting Search Console, joining the two) is preparation. The audit is the decision, and a review that stops at the spreadsheet has done the easy half.

Can I do my own SEO audit?

Yes, and for a blog under a few hundred pages it is a day of work with free tools. You need Search Console access, a crawl of your own URLs, and the willingness to leave most pages alone. What you are buying when you pay someone else is usually the time and the judgement on borderline rows, not access to data you cannot get. The same is true of SEO you run yourself more broadly.

Can ChatGPT do an SEO audit?

It can do parts of it well and one part badly. Assistants are good at summarizing a page against a query, drafting a replacement title, and spotting that two of your articles cover the same ground. They cannot see your Search Console data unless you paste it, and they will confidently invent thresholds if you ask for a rule rather than a judgement on rows you supply. Give them the numbers and ask for the reasoning, not the other way around. Which pages assistants cite is itself a metric worth tracking, and getting cited by ChatGPT is a different problem from ranking.

How much does an SEO audit cost?

Agency content audits are typically quoted as a one-off project, and the range is wide enough that a single number would be misleading. The variables that move the price are the number of URLs, whether the deliverable includes implementation, and whether it is a technical crawl or a content review. The fuller breakdown is in our piece on what SEO costs. Done in-house, the cost is a day of your time plus a crawler licence if you exceed the free tier.

How often should you run a content audit?

Quarterly for an active blog, twice a year for a site publishing occasionally. The constraint is the data: Search Console position and impression trends need several weeks to mean anything, so auditing monthly means acting on noise. Run one immediately after a migration or a large publishing push, regardless of the calendar.

Does deleting old blog posts improve SEO?

Not on its own, and Google says so directly. The helpful content guidance asks whether you are "removing a lot of older content primarily because you believe it will help your search rankings overall by somehow making your site seem 'fresh'", and answers its own question: "No, it won't."

Deleting is correct when a page has no demand, no links, and no role. It is the wrong reflex when applied as a site-wide cleanup. Pages that earn impressions in AI features but no clicks are the clearest example of something that looks deletable and is not, which is one reason LLM visibility belongs in the same report as organic traffic.