How to Run a Content Audit on a Service Website

Search a content-audit template and you get a 2,000-row spreadsheet, a Screaming Frog license, and eleven columns of crawl data. Then the guide stops at the words 'now analyze your data.' That is the exact step you cannot do alone, and it is the only step that matters.

This is the version for a service business with 40 to 100 pages. Four numbers per URL, five possible decisions, a stated threshold for each. You can finish it in an afternoon.

What is a content audit actually for?

A content audit exists to produce one thing: a decision column. Every URL on your site exits the audit tagged keep, refresh, merge, delete or noindex, with a date and an owner. Everything else — word counts, readability scores, crawl depth — is decoration.

The reason it works on service sites is that most of them are not suffering from missing content. They are suffering from ten mediocre blog posts fighting each other for the same query, three near-identical city pages a previous agency shipped, and one page that quietly ranks 11th for a query worth $4,000 a customer.

You do not fix that by writing more. You fix it by deciding what each existing page is for. That is also why a content audit is a different job from a technical SEO audit, which asks whether Google can crawl and render the page at all.

How do you build the inventory in one afternoon, not one week?

Three exports and about 40 minutes. You do not need a crawler license for a 60-page site — you need a list of URLs and the performance data Google already gives you for free.

• Export 1: Search Console → Performance → Pages, date range set to the last 12 months, exported to Sheets. This gives you clicks, impressions, CTR and average position per URL. It is the spine of the audit.
• Export 2: your XML sitemap (or a free crawl). This catches pages Google has never sent a single impression to — the ones missing from Export 1, which are often the most revealing rows in the sheet.
• Export 3: GA4 → Reports → Engagement → Landing pages, same 12 months, plus any key event (form submit, call click) you actually track.

Paste them into one sheet, one row per URL, and add a column called DECISION. Leave it blank for now. Do not add columns for word count or Flesch score — you will never use them, and every extra column is 20 more minutes you will not spend making decisions.

One caveat on Search Console: the Pages report is capped at 1,000 rows per export and its data is sampled at the long tail. On a 60-page site that ceiling is irrelevant. On a 5,000-page site it is not, and you should be looking at the technical and index-bloat side of the problem first.

Which four numbers decide a page's fate?

Four columns carry the entire decision: 12-month clicks, 12-month impressions, best average position, and whether the page has ever produced a lead. Everything else is a tiebreaker.

Impressions are doing more work in that list than they used to. Ahrefs compared 300,000 keywords using Google Search Console data and found that the presence of an AI Overview correlates with a 58% lower clickthrough rate for the #1 organic result — up from a 34.5% loss measured a year earlier (Ahrefs, December 2025 data).

Read that in audit terms. A page that earns impressions but few clicks in 2026 is not automatically a failed page. It may be a page whose clicks are being absorbed above the fold. Judging it on clicks alone will get it deleted for a crime it did not commit.

Keep, refresh, merge, delete or noindex — what is the rule for each?

Five decisions, five numeric triggers. These thresholds are tuned for a site with roughly 40 to 100 indexable pages — scale the impression floors up if your site is bigger, but keep the logic identical.

The honest verdict: on a small service site, REFRESH and MERGE will be 70-80% of your decision column, and that is correct. Deletion feels like progress because the sheet gets shorter. It is not progress. A merged page keeps its links and its impressions; a deleted page keeps nothing.

Refresh is not 'add 400 words and change the date.' Google explicitly warns against 'changing the date of pages to make them seem fresh when the content has not substantially changed.' If you cannot name what a reader gets from the new version that they did not get from the old one, you are not refreshing — you are reheating.

When is deleting a page the right call — and when is it a mistake?

Deletion is correct in exactly three cases, and on a typical service site they cover fewer than 10% of URLs.

• Expired, time-bound content: a 2023 promo page, a closed-registration webinar, a job posting for a filled role. Nothing to merge into and nothing to refresh.
• Duplicate city or service pages a previous agency mass-produced: 'Plumber in Naperville / Aurora / Wheaton' with the town name swapped and nothing else. Keep the one town you can actually staff and prove; delete or merge the rest.
• Pages targeting an intent you no longer serve: you stopped doing commercial roofing, or you dropped the product line. The traffic is real but it is the wrong traffic and it wastes your sales time.

Where deletion goes wrong is the redirect. A 301 tells Google the target should be canonical — Google's redirect documentation says 'the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.' That only holds if the target answers the same question. Redirecting 40 dead posts to your homepage does not transfer anything; Google is likely to treat those as soft 404s.

If nothing on your site answers the old page's question, do not invent a redirect target. Let it die. And skip the 410-versus-404 debate entirely: Google's HTTP status code documentation states that all 4xx errors except 429 are treated the same — 'Google crawlers inform the next processing system that the content doesn't exist.' Use whichever your CMS gives you for free.

One more trap: the Search Console Removals tool is not a deletion method. Google states plainly that 'requests made in the Removals tool last for about 6 months.' It hides a URL temporarily. It does not remove it.

Why is '0 sessions in 12 months' a dangerous rule?

Because a page with 0 GA4 sessions can be sitting at average position 12 with 3,000 annual impressions on a query that closes at $4,000. Sessions measure arrivals. Impressions measure whether Google has already decided you are relevant. Those are different questions, and the pruning rule that circulates on publisher blogs only asks the first one.

Publishers can afford that rule because their unit economics are pageviews. Yours are booked calls. Twelve visits a year to a page about emergency sewer line replacement can be worth more than 12,000 visits to a listicle, and a rule built for a media site will happily delete the sewer page.

The other reason to distrust it: cutting content in bulk to look 'fresh' is not a ranking strategy, and Google says so directly. Its self-assessment list asks whether you are '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?' The parenthetical answer in Google's own guidance is: 'No, it won't.'

So run the rule the other way. Before any page is tagged DELETE, check its impressions and its top query. If Google is showing it to anyone at all, the honest tag is usually REFRESH or MERGE. If two pages are splitting the same query, you have a keyword cannibalization problem, not a pruning problem.

What does a content audit NOT cover?

A content audit answers 'is this page worth having?' It does not answer 'can Google crawl it,' 'is it fast enough,' or 'does it convert.' Those are three separate jobs, and conflating them is how a one-afternoon audit turns into a six-week project that never ships a single change.

• Crawlability, indexation, redirect chains, Core Web Vitals → a technical SEO audit.
• Form friction, call-tracking, mobile CTA placement, trust signals → a CRO audit.
• Whether the page is long enough → mostly a fake question. Google states flatly that it has no preferred word count. A page is thin when it fails to answer the query, not when it is under 1,000 words. That is the subject of how long a service page should be.
• Why a page that used to rank has slid → that is content decay, and its fix is refresh, not deletion.

Run the content audit first anyway. There is no point in shaving 300ms off the load time of a page you are about to merge into another one. Decisions before optimizations, always.

Once the decision column is filled, work top-down by revenue potential: MERGE the cannibalized pairs first (fastest wins, no new writing), then REFRESH the pages sitting in positions 5-20, then handle the noindex and delete rows in a single 30-minute pass at the end.

If you would rather have someone else fill in the decision column and hand you the merge and refresh list, that is exactly what our SEO audit service produces — page by page, with the thresholds shown. Or start smaller: Get my free audit and we will tell you which pages are fighting each other before you touch anything. No lock-in, and you keep the file either way.