How I Use the GSC searchAnalytics API, Screaming Frog, and Claude to Catch 90-Day Content Decay Before Rankings Fall Out of the Top 10

Content decay detectors have a trust problem. Most flag anything with a downward line on a graph, then hand an SEO a spreadsheet of 200 “declining” URLs where 150 are normal seasonal noise.

I run a weekly pull against the Google Search Console API for this site, cross-check the real drops in Screaming Frog, and use Claude to triage what’s left into a short list worth an editor’s time. This is the actual workflow, including the parts that produce false positives.

What Counts as Content Decay Versus Normal Ranking Noise?

Content decay is a page that ranked, earned impressions, and is now losing both — not for one week, but across a sustained stretch of the comparison window. A single bad week after a Google core update is noise until it repeats for several weeks running.

The tell that separates decay from noise is the query-level view, not the page-level total. If a page’s impressions dropped because Google Search Console started attributing traffic to a new AI Overviews-triggered query variant, that’s a SERP feature shift, not decay of the underlying content.

Real decay usually shows the same target query losing average position steadily, month over month, with no algorithm update to point to. That’s the pattern this workflow is built to isolate.

How Do You Pull 90-Day vs Prior-90-Day Deltas From the Google Search Console API?

The Search Console API exposes search performance through the searchAnalytics.query method, part of the Search Console API (the successor to the older Webmasters API). You send a POST request with a startDate, endDate, and a dimensions array — typically ["page", "query"] for this workflow.

Run the same request twice: once for the trailing 90-day window, once for the 90 days immediately before it. Google Search Console data has a reporting lag of a few days, so anchor both windows a few days before today, not on today’s date.

POST https://www.googleapis.com/webmasters/v3/sites/{siteUrl}/searchAnalytics/query
{
  "startDate": "2026-05-01",
  "endDate": "2026-07-30",
"dimensions": ["page", "query"],
  "rowLimit": 25000
}

Authenticate with a Google Cloud OAuth2 client or a service account that has been added as a user in Search Console property settings. Python’s google-api-python-client library handles both, and the response comes back as JSON you can load straight into a pandas DataFrame or dump to CSV for a spreadsheet review.

Join the two windows on page and query, then compute the delta for impressions, clicks, and average position. That joined table is the raw material for every step that follows.

What Does a Genuine Decay Signal Actually Look Like in the Data?

A genuine signal has three characteristics together, not just one. Average position has moved meaningfully worse — SEOs commonly use a rule of thumb of at least a few positions, not a fractional 0.3 shift that’s within normal SERP volatility.

Second, the position slide is consistent across the window, not a single-week spike caused by a temporary SERP feature test. Third, impressions dropped in proportion to the position change — if impressions held steady while position worsened slightly, Google may simply be testing rank variance, which resolves on its own.

Pages that keep impressions but lose clicks are a different problem entirely. That pattern usually means a title or meta description issue, or a new AI Overview sitting above the organic results and absorbing the click — not page-content decay.

How Does Screaming Frog’s Crawl Comparison Rule Out the Boring Causes First?

Before assuming a decaying page needs a content rewrite, rule out the mechanical causes. Screaming Frog’s crawl comparison feature stores a crawl as a baseline, then diffs a later crawl against it — flagging changed titles, changed canonicals, new noindex tags, and broken internal links.

Run this against every URL that cleared the Google Search Console decay filter, comparing today’s crawl to a saved crawl from before the decline started. Three fixes show up disproportionately often: a canonical tag pointing to the wrong URL after a template change, an internal link that used to point to the page and now points to a related one instead, and a title tag overwritten by a bulk SEO plugin update.

Any of those three explains a ranking drop without the page’s actual content being the problem. Fixing the technical issue is a five-minute task; rewriting the article is not — so this step exists specifically to avoid rewriting pages that don’t need it.

What Is the “Human-Review Tax,” and Why Do Decay Detectors Trigger It So Often?

The human-review tax is the hours an editor spends opening pages a detector flagged that turn out to be fine. It’s the real cost of a noisy detector, and it’s usually higher than the cost of missing a genuine decay signal a week later.

Three patterns generate most of the false positives. Seasonal topics look like decay every year during their off-season, then recover on their own — a workflow that doesn’t compare year-over-year, not just 90-day-over-90-day, will re-flag the same seasonal pages annually.

SERP feature churn is the second pattern: Google adding a People Also Ask block, a video carousel, or an AI Overview above a result reduces impressions and clicks for reasons that have nothing to do with the page’s quality. The third is measurement noise on genuinely low-volume queries, where a swing from 40 impressions to 25 impressions looks dramatic as a percentage but is statistically meaningless.

The fix for all three is the same: require the sustained, cross-week pattern from the section above before a page ever reaches an editor’s queue, and tag seasonal pages so the detector compares them against the same period last year, not the prior 90 days.

How Do You Triage What’s Left: Lost Impressions Times Remaining Demand?

Once the mechanical fixes and the false positives are filtered out, what remains needs a priority order, because no team rewrites everything in one week. Rank by lost impressions multiplied by whether the query still has demand — not by position drop percentage alone.

This is also where a competitive check earns its place. If Ahrefs or Semrush shows a competitor publishing a materially deeper or more current version of the same topic around the same time the decay started, that’s usually the actual cause — not something intrinsic to the page.

Where Does Claude Fit Into the Triage and Rewrite-Prioritization Step?

Claude doesn’t decide which pages decayed — the Google Search Console API data does that. Claude’s job starts after the joined, filtered, ranked table exists: reading the current page content against the decay reason and drafting a rewrite brief.

I feed Claude the page’s current HTML, its target query, the delta table row for that page, and a short prompt asking it to identify what’s missing relative to what currently ranks above it — outdated version numbers, a missing angle, thin sections that used to be competitive and no longer are.

The output is a rewrite brief, not a finished article: which H2s to add, which claims need a current source, where the page reads stale. An editor still writes or approves the final copy. This keeps the model in a research-and-triage role instead of an unsupervised publishing role.

What Does the Full Weekly Workflow Look Like Start to Finish?

Monday morning, a scheduled Python script calls searchAnalytics.query twice — trailing 90 days and prior 90 days — and writes the joined delta to a CSV. That script lives in a small GitHub repo alongside the rest of the site’s SEO tooling.

The script filters for the sustained, cross-week decline pattern and drops anything below a meaningful impression floor. What’s left — usually a short list, not hundreds of rows — gets a Screaming Frog crawl comparison pass to rule out canonical, noindex, and internal-link breaks.

Surviving URLs are ranked by lost impressions times remaining demand, and the top few go to Claude for a rewrite brief each. A short Slack message summarizes the week’s list with links to each brief, and an editor picks up the work from there.

Per Google’s own Search Console API documentation for searchAnalytics.query, results can be filtered and grouped by page, query, country, and device dimensions, and the API is the same data source that powers the Search Console Performance report in the UI — meaning a workflow built on it stays consistent with what’s visible in the dashboard.

How Do You Avoid False Positives From Seasonal or Low-Volume Pages?

Tag seasonal pages at publish time — a holiday buying guide, a tax-season explainer — and compare them against the same calendar window a year prior instead of the trailing 90 days. Otherwise a seasonal page gets flagged as “decaying” every single year during its off-season.

For low-volume queries, set an impressions floor before a page enters the decay list at all. A page swinging between 20 and 35 monthly impressions will show large percentage swings that mean nothing at that volume; a floor filters this out before it ever reaches triage.

Finally, exclude pages that changed URL, merged into another page, or were intentionally deprioritized. Those show up as “decay” in raw API data but are decisions someone already made on purpose.

Last updated: 2026-08-07