DeepSmith

Aug 26 · Content Operations

19 min read

How Agencies Run Content Decay Audits Across Multiple Client Sites

Avinash Saurabh
Avinash Saurabh · CO-Founder & CEO
A monochrome cover with the line One Audit, Every Client Site set over four identical outlined cards whose connector lines converge on a single shared node, beside a declining chart fragment.

You have eight clients, three strategists, and a quarter that started yesterday. Somewhere in those eight sites, pages are quietly losing traffic. You know it. You just don't have a way to find them without burning a week per account.

That's the problem this guide solves. By the end, you'll have one repeatable decay audit you can run across every client site, with a client-ready deliverable at the end. Not a fresh spreadsheet each time. One system, applied eight times.

Here's the good news: you probably already do most of these steps. They just live in different heads and different files. Let's pull them into one shape.

What content decay actually is, in one paragraph

Content decay is a page's slow slide in organic traffic and rankings over time. Slow is the key word. A cliff on a Tuesday is usually a migration, a tracking break, a manual action, or an algorithm update, which needs a different fix.

There's a second layer now. A page can hold its Google position and still vanish from AI answers, so treat organic visibility and AI visibility as two separate reports rather than one blended number.

Causes stack up in familiar ways: a stale page, a better competitor page, shifted query intent, two of the client's own pages splitting one term, a SERP feature or AI Overview eating the click, a template edit, or demand simply dropping.

Notice how many of those aren't content problems? That's why an agency content audit needs a process, not a percentage rule.

Step 1: Lock one audit standard before you open a client report

Start here, not in a client's Search Console. The one thing that makes a repeatable decay audit actually repeatable is that the specification exists before anyone starts interpreting pages.

Write one audit charter. It defines scope, cadence, comparison windows, page types, metrics, thresholds, action labels, evidence requirements, who reviews, and what the client receives. Version it. Every account runs the same one.

Set the scope once. A sensible default is all indexable editorial, resource, documentation, comparison, and commercial pages. Exclude utility pages, tag archives, internal search, login paths, parameter duplicates, and anything the client asks you to leave alone. Store exclusions in the client registry rather than deleting them, so next quarter you can see why a page is missing.

Set the cadence once. Quarterly for the full portfolio is a good default. A small site that publishes rarely can drop to twice a year. Add a review after a core algorithm update, a migration, a redesign, or a big content release. And look at the highest-value pages annually even when they haven't tripped a threshold.

Use two comparison windows, never one. A 90-day or quarter-over-quarter view for operational triage, and a same-period year-over-year view so seasonality doesn't fool you.

You also need a client registry: one row per account with the domain, key subfolders, CMS, analytics and Search Console properties, crawl scope, timezone, seasonality, business priorities, conversions, competitors, and the assigned strategist. This is the file that keeps client A's context out of client B's audit.

Common mistake: making a percentage-drop rule the whole audit. A drop is a reason to investigate. It is not proof that a refresh is the right answer.

Done when: you have a versioned specification, a client registry, a fixed column schema, an audit calendar, and a written difference between a candidate and a confirmed cause.

What the client sees: a one-page audit charter, plus an account matrix showing which sites are ready, blocked, or missing data.

If per-client context lives in briefs and Slack threads, it is costing you. DeepSmith handles that layer with separate workspaces: each client gets its own isolated account with its own content, context, and plan. Deep IQ stores that client's positioning, products, personas, brand voice, visual rules, and content types as structured records, so one client's voice never leaks into another's work. Isolation is the point here, not automation.

Step 2: Build the same content inventory for every client

Now open the client. Crawl the agreed scope and produce one row per canonical page. Same columns, every account, every quarter.

Your minimum fields:

  • Client and workspace ID.
  • Canonical URL, discovered URL, title, H1, word count, template, content type, publication date, last meaningful update, status code, canonical target, indexability, robots state, and sitemap presence.
  • Topic, funnel stage, primary intent, primary query cluster, business importance, conversion goal, and owner.
  • Search Console clicks, impressions, CTR, average position, top queries, and period deltas.
  • GA4 organic landing sessions, engagement rate, key events, revenue where configured, and period deltas.
  • Backlinks and referring domains, plus link change where you have it.
  • AI mention rate, citation rate, cited page, share of voice, and competitor citations where the client tracks them.
  • Crawl date, analyst notes, action, priority, owner, due date, status, and post-change measurement date.

That's a long list. You build it once. After that it's a template, and the same template turns a one-off job into a client site content audit anyone can run.

Pick one crawler and use it the same way everywhere. Screaming Frog's free version crawls up to 500 URLs at a time, fine for a small client, not for a portfolio. A paid license removes that limit and runs $279 per license per year for one to four licenses, dropping to $265, $249, or $235 as you buy five, ten, or twenty. It can restrict a crawl to a subfolder, include or exclude URL patterns, render JavaScript, connect to GA4, Search Console and PageSpeed Insights, run from the command line, and schedule crawls. Its Presets feature saves your standard export group, so every scheduled crawl returns the same files.

One detail saves real pain later: normalize URLs before you join anything. Lowercase the hostname, settle your trailing-slash rule, strip tracking parameters, keep only query strings that identify a genuinely distinct page, and record redirects separately. That's an operating recommendation, not a Google rule, but the join breaks without it.

Where agencies go wrong: mixing crawl URLs, canonical URLs, and analytics landing-page URLs in one column. Keep raw URL, normalized URL, canonical URL, and final URL as four separate fields.

Done when: every in-scope page has one normalized row, every exclusion has a reason, duplicates and redirects are classified, and the sheet accepts the same performance fields for any account.

What the client sees: not this. The inventory is an appendix or shared action sheet. The client-facing report shows only pages that need a decision.

Step 3: Pull performance data in a way that survives portfolio scale

One client is a manual export. Eight clients is a pipeline. This is the step where a multi-client content audit either scales or quietly eats your margin.

Use Search Console for search demand, GA4 for landing behavior and business outcomes, your crawler for technical state, and backlink, rank, or AI-visibility data when the account has it. Pull the same fields everywhere, then join on the normalized URL.

Search Console, without hitting a wall

The Search Console API gives you clicks, impressions, CTR, and position across dimensions like page, query, country, device, and search type. For clean page-level counts, query with page aggregation and avoid grouping page and query together. Combined requests can lose data and cost far more quota.

A few limits worth writing into your job before you write the job:

  • Query one day at a time and aggregate locally. Google's own guidance says this avoids quota trouble, and data usually lands after two to three days.
  • Maximum response size is 25,000 rows, so page through by raising startRow in 25,000 steps until you get zero rows back.
  • Search Analytics exposes at most 50,000 rows per day per search type, sorted by clicks.
  • Quotas run 1,200 queries per minute per site and per user, plus 40,000 per minute and 30,000,000 per day per project. URL Inspection has its own separate quotas.
  • Don't re-request the same long date range repeatedly. Long ranges and page-plus-query filters are the expensive calls.

For a durable history, Search Console's bulk export to BigQuery schedules a daily export of the property's performance data, minus anonymized queries. Validate the setup per property rather than assuming they're identical.

For client dashboards, the Search Console connector for Data Studio, now Looker Studio, needs an account with at least view permission. Pick either Site Impression or URL Impression. One data source uses one method, so build two if you want both views.

GA4, and the three-day catch

GA4 separates "we lost search visibility" from "the page still gets found and nobody engages." A practical recurring extract: organic landing sessions, engagement rate, key events, revenue where configured, landing page, date, channel, source and medium, plus deltas. In the interface that's Reports, Acquisition, Traffic acquisition, a last-90-days range, Organic Search as the primary channel group, and a landing-page filter for the subfolder. Pull LLM referral sources separately.

For a warehouse pipeline, the GA4 BigQuery export creates one dataset per linked property, with daily events tables and optional intraday tables. Event data is nested and repeated, so plan for that. Here's the catch worth a calendar note: daily tables can still update for up to three days after the event date, and anything later isn't recorded. Build that buffer into your monthly close, or your numbers will move after the report goes out.

Pro tip: snapshot raw daily or monthly data into your own storage. A live dashboard is a view, not a historical record, and a client will eventually ask what a page looked like eleven months ago.

Done when: every client has the same metric set, extraction dates and comparison windows are logged, API failures are visible, and any row traces back to a source export.

What the client sees: a data-quality box. Coverage dates, missing sources, known sampling or anonymization, and whether a number is clicks, sessions, impressions, or conversions. Never blend unlike metrics into one trend line.

Step 4: Flag candidates, then score them the same way everywhere

Rules find candidates. A transparent score ranks them. Keep those two jobs separate, and don't hide either one inside an opaque formula.

Useful starting triggers from published audit guidance:

Treat every one as a starting point. Calibrate to the client's baseline, traffic volume, seasonality, page type, and business cycle. Five positions lost on a low-volume term is not the same event as five lost on the query that drives demos.

Then score with separate fields you can defend:

  • Decline severity: traffic, impression, click, ranking, CTR, engagement, and AI-visibility deltas.
  • Business relevance: conversion role, commercial intent, strategic topic, client priority.
  • Recoverable authority: historical peak, backlinks, internal links, how close the page still ranks.
  • Change risk: seasonality, migration, algorithm update, technical incident, recent rewrite.
  • Effort: content-only, technical fix, consolidation, new research, approval, or a dev dependency.

Band the result simply. P1 is high business relevance plus a real decline and a plausible recovery path, and it goes in the next sprint. P2 is a moderate decline or moderate value, and it goes in the scheduled backlog. P3 is low value or low confidence: monitor, consolidate, or prune after checks. Blocked is anything waiting on data, tracking, legal, a migration, or a client decision.

One diagnostic pattern does most of the work:

  • Impressions down and CTR down: classic decay candidate, pending technical and demand checks.
  • Impressions down, CTR up: visibility fell, but the people who still see it click. Often the most recoverable page on the list.
  • Impressions flat, CTR down: look at SERP features, AI answers, snippets, and richer competitor results before rewriting a word.
  • Traffic down right after a content edit: compare versions. Sometimes the fix is restoring what worked.
  • Traffic down with no preceding change: gradual decay is more plausible, but still check seasonality, demand, and technical state.

The AI layer belongs in this step, not bolted on later. DeepSmith's AI Search Visibility area reports mention rate, citation rate, and share of voice with trends, a per-platform breakdown, a competitor leaderboard, and the sources engines cite most. Its Pages view shows which of the client's pages AI actually cites and the prompts driving them, and Competitor citations shows who wins those prompts and on which pages. Content Map classifies the client's site and competitor sites onto one topic and funnel-stage taxonomy, so coverage gaps and untapped topics are measured instead of guessed. Opportunity Agents read that data and return ideas with the justifying data point attached, and every run is logged.

The AI Visibility Pages view lists a demo brand's own pages with the citation count, citation rate and number of tracked prompts each page wins, and opening one page shows the exact prompts driving those citations.

That last part matters at portfolio scale. An idea that arrives with its evidence is one a strategist can defend in a client call.

Done when: every candidate has a reason code, score components, a confidence level, an owner, and a next action. A reviewer can rebuild your priority order from the raw fields alone.

What the client sees: an executive shortlist. Top opportunities, effort band, business reason, evidence, recommended action, review date. No traffic promises.

Step 5: Diagnose the cause and assign one action label

Here's where most audits leak value. A page declines, someone writes "refresh," and a writer spends four hours on a page whose real problem was a canonical tag.

Look at the page, the SERP, the query set, competitors, links, technical state, and business context. Then pick exactly one label from a fixed vocabulary:

ActionUse whenCheck first
Keep As IsPerformance is stable and nothing material is wrongThat it isn't losing AI visibility or conversions while traffic looks flat
UpdateTopic and intent still hold, but facts, structure, freshness, links, or answer clarity are weakCompeting results, claims and evidence, sections worth preserving, headings and direct answers
Consolidate and RedirectTwo or more pages overlap, or cannibalization is clearPick the canonical destination, map unique content, preserve links, redirect after QA
Delete or noindexIrrelevant, duplicative, and carrying no organic, referral, conversion, backlink, or citation roleSocial and referral traffic, backlinks, internal links, legal needs, replacement destination
Rewrite from scratchThe topic still matters but the page never matched the intentPreserve useful evidence and links, re-research intent, define the new page first
Fix technical issueIndexability, canonical, status, rendering, template, speed, migration, or tracking explains itAssign to the technical owner. Don't file it as a content refresh
MonitorEvidence is thin, demand is seasonal, or the page is too new to judgeSet a review date and name what evidence would change the call

Deletion deserves an extra beat. Before removing anything, check whether it still pulls social or referral traffic, holds backlinks, anchors internal links, or exists for a legal reason. Low search volume is a reason to investigate, never permission to delete.

Common mistake: treating "declining" as a synonym for "rewrite." A page might need its old version back, a redirect, a technical fix, or genuinely nothing.

Done when: every P1 and P2 page has one action, one rationale, one owner, one acceptance criterion, and a documented exception where the normal rule didn't apply.

What the client sees: an approval-ready action register. Before state, diagnosis, proposed change, risk, owner, target date, acceptance metric.

Step 6: Run the refresh through a QA gate, not a bulk rewrite

Approved actions become a sprint, not a batch job. For every page, save a before snapshot and record the date you published the change.

Your refresh brief should carry:

  • The target query cluster and the current intent.
  • The exact evidence that triggered the action.
  • Sections to keep, rewrite, add, or remove.
  • Missing facts, examples, first-hand experience, sources, media, product details.
  • Internal-link targets and why each one.
  • Metadata, heading, schema, canonical, indexability, and redirect requirements.
  • Reviewer, approval status, publish date, and a rollback plan.

After publishing, check the status code, canonical, indexability, render, title, H1, structured data, internal links, redirects, analytics collection, and the actual page content. Add internal links from relevant strong pages, and fix broken external links while you're in there.

And please don't touch the date without touching the content. A refreshed timestamp on an unchanged page makes decay worse, not better.

Production is where an agency content audit turns from analysis into billable hours. Once you've diagnosed the need, DeepSmith's Content Studio moves an idea from New Ideas to Planned Content to Produced Content, with the Writer turning a planned item into a researched, brand-grounded article that already carries internal and external links, a cover image, and publish-ready metadata. Autowrite runs that on a schedule with nobody in the app, and Produced Content publishes straight to WordPress, Webflow, Strapi, Sanity, or Contentful.

The strategist still owns the diagnosis, the fact check, the client approval, and the publication QA. Automating production doesn't remove review. It stops senior people from doing mechanics by hand.

Done when: the change clears technical and editorial QA, the baseline snapshot is stored, the publish date is logged, and the page enters the measurement queue.

What the client sees: a change log. Old state, new state, reason, approver, publish date, QA result.

Step 7: Measure, package, and sell it as a service

You've done the work. Now make it a product.

Keep the same report structure across accounts, with room for each client's business context. Measure the same fields before and after, over matched periods, and annotate seasonality and algorithm events.

Two overlapping circles labelled Client A and Client B each hold their own business priorities, seasonality and competitors, while the shared centre they both contain holds the schema, thresholds, action labels, report sections and cadence that stay the same on every account.

Give it time. Wait at least two months before judging SEO and AI-visibility results from a content action, then rerun the analysis after two or three months. That's a measurement interval, not a promised recovery. Report what changed, what didn't, and what you still don't know.

Your standing report, same seven sections every time:

  1. Executive summary: pages at risk, pages recovered, decisions needed, blockers.
  2. Visibility trend: clicks, impressions, CTR, rankings, organic landing sessions, engagement, conversions, and AI mention, citation, and share-of-voice metrics where tracked.
  3. Prioritized action register: P1, P2, P3, action, owner, status, due date, evidence, next review.
  4. Completed work: pages changed, technical fixes, consolidations, redirects, QA outcomes.
  5. Opportunity backlog: new candidates, competitor changes, intent shifts, AI-citation gaps, coverage gaps.
  6. Data-quality statement: collection dates, missing sources, anonymized queries, late GA4 data, exclusions.
  7. Next-cycle plan: recurring tasks and the approvals you need.

Then price it in tiers based on scope, not on outcomes you can't guarantee. A baseline portfolio scan. A recurring multi-client content audit with a fixed page allowance. A top tier adding refresh briefs, production, distribution, and AI-visibility reporting. What you charge and how many pages you include are your decisions, and neither belongs in a client deck as a benchmark.

Done when: every client gets the same sections, every metric has a definition, every recommendation carries evidence, and next quarter starts from the current register instead of a blank sheet.

What the client sees: a branded report, an action register, a before-and-after view, a completed-work log, and the next backlog.

What to do next

Don't launch this across eight accounts on Monday. Pick one client. Run the full cycle end to end, from charter to report. Fix what breaks, then clone it.

Your very next step is smaller than that: write the audit charter. One page. Scope, cadence, windows, thresholds, action labels, report sections. Everything else in this agency SEO audit process hangs off that document, and it takes an afternoon.

Then lock the action register and put the next review on the calendar before you call the cycle done. An audit with no scheduled follow-up is a snapshot, and snapshots don't compound.

If the AI-visibility layer is the part you can't deliver yet, that's the most common gap in an agency SEO audit process right now, and it's fixable. DeepSmith tracks mention rate, citation rate, and share of voice per client workspace, then produces the on-brand content to close the gaps it finds, from the same data. See real numbers and real drafts on a 7-day free trial before you pay, with no long-term contract.

You've got this. One client, one cycle, then repeat.

Frequently asked questions

How often should an agency run a content decay audit across client sites?

Quarterly for the full portfolio is a solid default. A small site that publishes rarely can move to twice a year. Add a review after a core algorithm update, a migration, a redesign, a tracking change, or a large publishing push, and check each client's most valuable pages once a year even when nothing has crossed a threshold.

What is the first metric to use for finding decaying pages?

Start with page-level organic clicks or traffic decline, because that's the signal a client will care about. Then validate with impressions, CTR, rankings, engagement, conversions, backlinks, technical state, and AI visibility. No single metric proves decay on its own.

Should every declining page be refreshed?

No, and this is the biggest money-saver in the process. Keep stable pages. Update relevant stale ones. Consolidate overlapping pages. Redirect pages whose topic no longer fits but whose links still matter. Delete or noindex genuinely low-value pages only after referral, link, and conversion checks. Fix technical and tracking causes as technical work, not content work.

How does a repeatable decay audit avoid making every client identical?

Standardize the mechanics and isolate the judgment. The schema, thresholds, action labels, report sections, QA gates, owners, and cadence stay the same everywhere. Business priorities, seasonality, conversion definitions, page scope, competitors, brand context, and approval rules live in each client's own record or workspace, where they can't bleed into anyone else's client site content audit.