How to Run a Content Audit to Find Decaying Pages Worth Refreshing

Your traffic chart is sloping down and you're not sure which page is causing it. That's the problem a content audit solves. By the end of this guide you'll have a ranked list of decaying pages, a diagnosis for each one, and a clear reason why the top few deserve your team's time this quarter. You'll need Google Search Console, GA4, a crawler, and a spreadsheet. That's it.

One thing before we start. This guide stops at finding and ranking the pages. Actually rewriting them is a separate job, and doing the finding well makes that job much smaller.

Step 1: Set your scope and your comparison windows

Decide what counts as a page before you open a single report.

Write down which page types are in scope: blog posts, resource pages, guides, docs, landing pages, product pages. Then write down what's out: login pages, search results, tag and archive pages, author pages, feeds, redirects, error pages, anything non-indexable. Those URLs aren't refresh candidates, and leaving them in will pollute every number you calculate later.

Next, classify what stays. Tag each page as evergreen, seasonal, news or trend, product or service, or campaign. A seasonal page and an evergreen guide decay in completely different ways, and you'll judge them against different baselines.

Now pick your windows. Use two layers:

• Detection: the last 28 days against the previous 28 days. Line up the same weekdays so weekends don't skew it.
• Validation: the last 90 days against the same period last year. Year over year is the honest test for anything seasonal.

Keep a 12-month baseline for evergreen pages and a 90-day baseline for news-style posts. If you want a faster read on a fast-moving topic, you can compare the last 7 days to the 7 before. Be careful with that one. Small numbers make wild percentages.

One small upgrade that pays off: use a rolling median instead of a plain average for your baseline. One freak traffic day won't drag the whole line.

You're done with this step when you have a written scope, page types tagged, date windows chosen, and agreement on whether you're measuring Google search only or search plus analytics plus AI visibility.

Common mistake: comparing a seasonal page month over month and calling the normal off-season dip decay. Use last year's same period, and look at demand before you blame the page.

Step 2: Build one clean list of every page

You need one row per canonical URL. Not one row per URL you happen to remember.

Pull from five places and reconcile them: your XML sitemap, a CMS export, GA4 landing pages, Search Console page data, and a fresh crawl. No single source is complete. A sitemap can miss pages that are live, include URLs that redirect, or list pages nobody visits.

A crawler like Screaming Frog gives you the structural fields that matter here:

• URL and HTTP status code, plus any redirect destination
• Indexability, and the reason if a page is non-indexable
• Canonical URL, and whether it points at itself or somewhere else
• Title, meta description, H1 and other headings
• Word count
• Inlinks, outlinks, and orphan status
• Content type and crawl depth

Then join everything on the canonical URL. Normalize first: trailing slashes, http versus https, host, URL parameters, redirect chains. Keep the original URL in its own column so you can debug the join later, but assign performance to the canonical destination.

This is the least glamorous step and the one that decides whether the rest of the site content audit means anything. Take the extra hour here.

Feeling buried already? Fair. If a crawl and five exports sounds like a week of work, this is one place a platform genuinely takes work off your plate. DeepSmith's Content Map crawls your site, enriches every page, and classifies it onto a topic and a funnel stage, and it rechecks your sitemaps every 24 hours so new pages fold in on their own. That gives you the inventory and the topic layer without the manual reconciliation. It doesn't replace Search Console, GA4, or a technical crawler, and you still need those for the performance and indexing evidence.

You're done with this step when every canonical page has a row, and every excluded URL has a written reason. You should be able to tell "this page gets no traffic because the content is weak" apart from "this page gets no traffic because it's redirected, blocked, duplicated, or not the canonical."

Where people go wrong: treating a word-count cutoff as a quality verdict. A short page can answer a question completely. A long page can waste everyone's time. Use word count to pull pages into review, never to decide their fate automatically.

Step 3: Pull your Search Console performance data

Search Console is your core dataset, because it's the only one that separates the four numbers that actually diagnose decay.

For every candidate page, collect:

• Clicks: visits from Google search results
• Impressions: how often the page appeared
• CTR: clicks divided by impressions
• Average position: the average rank of your topmost result for that row

Start in the Pages dimension to find the losers. Then drill into Queries for each candidate, because the page-level number hides the story. Check country, device, and search appearance too. A decline can be local, or it can be a result-type change rather than anything you wrote.

Weekly or monthly granularity works better for trends. Daily data is for spotting incidents.

If you're going to run this every quarter, consider exporting to BigQuery. A few things to know before you commit: it needs a Google Cloud project with billing enabled, the first export can take up to 48 hours, storage and query costs can apply above the free tier, and it only captures data from setup forward. Anything historical still comes from the reports or the API.

Here's how to read what you get:

Two caveats worth knowing so you don't chase ghosts. Search Console filters anonymized queries out of tables and exports, so query rows won't sum to your chart totals. And the interface export caps at 1,000 rows, while the Search Analytics API and the Looker Studio connector state an upper limit of 50,000 rows per day per site per search type. On a big site you'll be working with a sample, and that's fine as long as you know it.

You're done with this step when every candidate has clicks, impressions, CTR, position, and top queries for both windows, and you've recorded the search type, country, device scope, and whether any of the data is still preliminary.

Step 4: Add analytics and business value

Search Console tells you what happened before the click. GA4 tells you what happened after.

Use the Landing page report, which ties metrics to the page a session started on. Pull the same comparison windows you used in Search Console, joined on the same normalized canonical URL:

• Organic landing-page sessions
• Active users and new users
• Average engagement time per session
• Key events, leads, signups, or purchases
• Revenue, where it applies
• Conversion rate, calculated the same way for every row

Now the part people skip. Business value is a reason to prioritize a page, not proof that it's decaying. A page with 200 visits a month and five qualified leads beats a page with 5,000 visits and nothing. Give every candidate a value label: high, medium, low, or unknown, backed by a real observation.

Pro tip: keep loss and value in separate columns. Call one decay severity and one recoverable value. A 60% drop on a page with ten impressions is not more urgent than a 15% drop on the page that fed your pipeline last year. When those two numbers live in one blended score, the small page always wins the argument and it shouldn't.

You're done with this step when every candidate carries a business-value label with evidence behind it, or a written reason you're keeping it anyway.

Step 5: Flag pages with screening triggers, not verdicts

Now you get to filter. These thresholds are screening defaults, not laws. Nobody official defines decay by a percentage, so treat every one of these as "look at this page," never as "this page is broken."

Practical triggers for a quarterly pass:

• Organic traffic down more than 20% over 90 days
• Target keyword rankings down more than five positions
• CTR falling while impressions hold steady
• AI citation rate falling
• Engagement worse than the page's own history
• No new referring domains in six months or more
• Traffic down more than 20% year over year

Tighter operational alerts, if you're monitoring monthly:

• Clicks down 30% or more from a 28-day baseline, two weeks running
• CTR down 25% or more while position moves less than 0.5, which points at the snippet rather than the content
• Average position down two or more on queries with at least 100 impressions in the last 28 days
• Average engagement time down 20% or more while traffic holds
• Conversion rate down 25% or more while sessions hold
• On product or service pages, conversion down 25% or more with sessions within plus or minus 10%
• On news or trend posts, impressions down 40% plus CTR down 20%
• On genuinely low-volume pages, use absolute numbers instead of percentages

Calibrate all of these against your own site's volatility. A site that publishes twice a week behaves nothing like one publishing daily.

Two triggers firing together is a much stronger signal than one. That's the fastest way to sort a long flag list.

You're done with this step when every flagged page names its trigger, its baseline, its comparison window, and the volume behind the percentage.

Common mistake: flagging a page because the percentage looks scary when the denominator is tiny. Set a minimum: a floor on impressions, clicks, sessions, or conversions before any percentage threshold is allowed to fire.

Step 6: Diagnose why each flagged page slipped

A flag is a question. This step is the answer. Work through these in order, and stop at the first one that explains the drop.

Is demand down? Compare impressions and topic trends against the same period last year. If clicks and impressions are falling across a whole section, don't rewrite one page. Look at seasonality, algorithm updates, security or spam issues, reporting problems, and site-wide technical failures first.

Did rankings fall? Go to the query rows. Find the specific queries that lost impressions, clicks, and position. Check whether a different URL of yours now shows up for them.

Did CTR fall without a real position change? Then this is probably a presentation problem, not a content problem. Look at your title, your description, rich-result eligibility, what SERP features appeared, and what competitor snippets now say.

Did intent change? Search the query yourself and look at what Google is serving now. A query can quietly shift from informational to comparison or transactional while the words stay identical. Your page can be excellent and still be answering the wrong question.

Did competitors improve? Compare the current top pages for your important queries. Look for newer evidence, better coverage, real first-hand experience, clearer structure. You're identifying what's missing from yours, not copying theirs.

Did you cannibalize yourself? Group your own pages by overlapping query. If several target the same intent, note which one historically performed best and whether authority is now split. Cannibalization is something to investigate, not proof that a page must go.

Did the page change right before the drop? Check your update history. A decline with no edit before it looks like ordinary decay. A decline right after a big edit needs a before-and-after read of what changed.

Is it technical? Check index coverage, URL Inspection, status code, robots directives, an accidental noindex, canonical consistency, redirects, sitemap inclusion, rendering, and internal links. A technical fault has to be ruled out before you call a page a refresh candidate, or you'll rewrite a page that Google simply can't reach.

You're done with this step when every flagged row names one primary diagnosis with evidence. "Traffic down" is not a diagnosis. "Impressions down year over year across the topic," "CTR down with stable position," "two of our URLs overlap on the same intent," and "canonical points at the wrong page" all are.

Step 7: Check your AI visibility as its own channel

Here's a decline that won't show up anywhere in steps 3 through 6. Your Google traffic can hold perfectly steady while AI engines quietly stop citing you.

Organic search and AI answers are separate channels. Diagnose them separately. A page can lose citations and keep clicks, or gain citations while clicks fall. Neither one explains the other, and treating an AI drop as proof of Google decay will send you rewriting the wrong pages.

If you have AI visibility tracking, add these to your audit sheet: mention rate, citation rate, share of voice, and which of your pages are being cited for which prompts. If you don't have tracking yet, note the gap in your sheet and move on. Guessing here is worse than an honest blank.

This is the second place DeepSmith does real work. AI Visibility tracks mention rate, citation rate, share of voice, sentiment, and visibility trend, and its Pages view attributes citations to the specific pages on your site, with the prompts driving each one. Which engines you see depends on your plan: Pro covers ChatGPT, Grow adds Perplexity, Scale adds Gemini, and Enterprise or Custom covers all ten, including Claude, Google AI Overviews, Google AI Mode, Grok, Meta AI, Microsoft Copilot, and DeepSeek. It's a separate signal for your audit, not a substitute for Search Console.

You're done with this step when every candidate has either an AI visibility reading or an explicit "not tracked" note, kept in its own column rather than blended into the organic diagnosis.

Step 8: Score and rank the pages worth refreshing

You now have flags and diagnoses. Time to turn them into an order.

Score each page on a small scale, 0 to 3, across six dimensions, and write down what each score means:

• Decay severity: how big, how long, how many signals agree
• Historical value: what this page used to earn in clicks, rankings, links, and key events
• Recoverable opportunity: valuable queries still getting impressions, positions near page one, backlinks still pointing at it, a clear gap you can close
• Business value: leads, revenue, product relevance, funnel role
• Confidence: how good the data is and how clear the diagnosis is
• Effort: scored in reverse, so an easy fix rises

Then sort. A workable priority order looks like this:

1. High-value page, several decay signals, real remaining demand, clear fix hypothesis
2. High-value page, one strong signal, needs a bit more diagnosis
3. Strong links or historical rankings, business value unclear
4. Low volume, big percentage drop, little absolute value
5. Decline fully explained by seasonality, a technical exclusion, or a deliberate sunset

Resist the urge to publish a universal "refresh anything above 12" rule. The right weights depend on your goals and your conversion model. Keep the raw measurements next to the score so someone else can audit your call six months from now.

This is where an evidence trail turns into a defensible backlog. DeepSmith's Opportunity Agents read your own AI Visibility and Content Map data and return ideas with the justifying data point attached, which is the difference between a backlog you brainstormed and one you can defend in a planning meeting. It won't decide whether a page is worth refreshing. That call stays yours.

You're done with this step when the queue is ranked and every row explains, in a sentence, why that page is worth the time.

Step 9: Give every row a decision

Every page in your audit ends in one of five branches. Assign one to each. No blanks.

Refresh candidate. The URL still has backlink equity, valuable rankings or impressions, or real business value, and the problem looks fixable with better, more current, more complete, or better-aligned content.

Technical repair. The content is probably fine. Indexability, canonicalization, redirects, rendering, sitemap inclusion, internal links, or structured data explain the loss.

Consolidation candidate. Several thin or overlapping URLs chase the same intent. Name the strongest destination and record the supporting URLs, the overlap evidence, the links, and the historical performance.

Monitor. The signal is weak, the page is low volume, the window is too short, or the topic is seasonal. Set a next review date and a baseline. This is a real decision, not a dodge.

Archive or removal review. The page is expired, duplicated, empty, or impossible to make accurate, and there's no audience, link, ranking, conversion, or navigation value left. A useful review trigger is persistent zero impressions and zero clicks over 12 months with no internal-link justification. That's a trigger for a review, never an automatic delete. Check backlinks, referring traffic, internal links, rankings, and any legal or compliance need first. Low traffic on its own is not a reason to remove anything.

You're done with this step when every in-scope canonical page has a decision with evidence, or a written reason it was excluded. A vague "needs updating" with nothing behind it is how audits die in a shared drive.

What to do next

Start with the top three rows. Not the top thirty.

Take the highest-value pages that showed multiple corroborating signals and have a clear diagnosis, and work those first. You'll learn more from three fixes you can measure than from a queue of forty you never start.

Then make it a rhythm. A light monthly scan for threshold breaches, a fuller quarterly site content audit, and a deeper annual look at your evergreen pages. Keep the baseline and the decision log every time. After two or three cycles you'll see the patterns: which topics keep sliding, which technical faults keep coming back, and whether your prioritization is actually picking winners.

Track the process itself too. How many pages you inventoried, how many you excluded, how many each trigger flagged, how many turned out to be real content decay versus demand or technical or SERP issues, and how long a flag takes to become a decision. That's how you find out whether the audit is working.

If the collection and prioritization work is what's stopping you from running this regularly, that's exactly the manual load DeepSmith is built to reduce, with Content Map for the inventory and topic layer, AI Visibility for the citation channel, and Opportunity Agents for turning findings into an evidence-backed backlog. You can start a free trial and see your own data before you decide.

You're closer to this than you think. One clean inventory and one honest scoring pass, and you'll never guess at your refresh list again.