Content decay detection

What the weekly content decay report does

Every Monday at 8 AM, the workflow pulls the last 7 days of Google Search Console data and compares it to the previous 28 days. For every page, it asks: did clicks drop? did position drop? by how much? Then it classifies each page as critical decay (big drops on a high-value page), decaying (moderate drops), early decay (early warning signs), stable, or growing.

You get a Slack message + email every Monday morning with the breakdown: how many pages in each bucket, which pages are critical, what's growing. Critical pages also get auto-generated fix tasks (refresh content, audit backlinks, fix CTR) dropped into a separate Google Sheet tab.

About 5-10 minutes per Monday run. Your time: 15 minutes to read the report.

Why slow traffic loss goes unnoticed

Content rot is a slow burn. A post you wrote a year ago is at position 4. Six months later it's at 14. Six more months and it's at 32 and the page is barely getting impressions. You didn't notice because no single week's drop was big. The signs of content decay are exactly that: a slow, smooth slide in position and clicks across many months.

The fix is to refresh those pages. But before you can refresh them, you have to find them. And that's where most teams stall:

1. The manual version is opening GSC, picking a date range, picking another date range, exporting to CSV, manually diffing, eyeballing what dropped, deciding which drops are real signal vs noise. On a real content library that's several hours every week.
2. The "I'll check it next quarter" version is what actually happens. By the time someone looks, the drops are catastrophic – position 4 → 47, traffic down 90%, the page is essentially dead.
3. The cheap-tool version is a SaaS that emails you "your traffic is down 12% this month". Useless. You need to know which pages are decaying, not your portfolio average.

This content decay workflow does the boring part – the data pull, the per-page comparison, the classification, the report – automatically every week. Your editor sees the same Monday morning digest every week: here's what's critical, here's what's still growing, here's what to refresh first. No manual GSC drilling.

For a content library of 200+ pages this is the difference between catching decay in week 2 (fixable in an hour) vs week 12 (a real rewrite job).

A GSC property, a sheet and a Slack channel

Setup happens once and needs four things:

• A GSC property the workflow can read (service account access)
• A Google Sheet to log every weekly run (so you can see trends month-over-month)
• A Slack channel for the weekly digest (or skip Slack, just use email)
• A recipient email for the same digest

Per-run inputs: none. The workflow runs itself on the schedule.

The Monday digest and fix-task list

Every Monday morning:

• A Slack post with the headline numbers (critical: 4 pages, decaying: 11, growing: 8, stable: 192)
• An email with the full breakdown – each bucket's pages listed, biggest drops first
• A Google Sheet log that records the full classification for every page (so month-over-month comparisons are possible)
• A fix-tasks tab in the sheet, populated for critical pages – each critical page gets auto-generated tasks like "audit backlinks", "refresh content", "fix CTR with new meta description"

You read the digest, pick the 2-3 critical pages worth attacking that week, and either refresh them yourself or hand them to a writer with the auto-generated task list as a starting brief.

Under ten minutes of runtime, 45 minutes of your week

Workflow time: 5-10 minutes Monday morning. Most of it is parallel GSC calls.

Your time: 15 minutes to read the digest, 30 minutes if you want to deep-dive into one critical page.

End-to-end weekly: about 45 minutes of human time, down from several hours of manual GSC drilling.

The weekly digest is for the editor. Clients usually want the monthly view instead, which is what automated SEO reports are built to assemble.

Libraries where content decay monitoring pays off

Weekly decay checks are the always-on version of what a content marketing audit does once or twice a year, and they earn their place when these hold:

• Your blog has at least 100 posts older than 6 months. Below that, you don't have enough indexed content to make weekly monitoring valuable.
• You have GSC verified on the site and at least 90 days of GSC data. Without that the comparison windows are noisy.
• You're already committed to refreshing content. The analysis is wasted if no one acts on it.
• You want weekly cadence – not daily (too noisy), not monthly (you miss the early signal). Monday-morning weekly is the sweet spot for most content teams.

The third point matters most. A digest nobody acts on is 15 minutes a week spent reading bad news.

Sites where weekly decay checks add noise

It's the wrong tool in these four cases:

• Your site is brand new. Decay analysis assumes a meaningful baseline.
• You don't have GSC. The whole thing runs on GSC's API. Without it there's nothing to compare.
• You write seasonal content (e.g. holiday gift guides). The comparison logic will flag everything as decaying every February. The workflow can be tuned to ignore seasonality but it adds complexity – flag this on the call.
• You want a fully automated "detect AND refresh" pipeline with no human review. That's a different workflow and it's a bad idea even when it works – content decay decisions need editorial judgement.

Detection and repair stay separate on purpose, because deciding how to fix content decay on a given page is an editorial call. Once a page is flagged, the content refresh workflow drafts the rewrite for an editor to approve.

How to identify content decay: nodes and thresholds

It takes about 14 functional nodes in n8n, in roughly this order:

1. Schedule trigger – Monday 8 AM
2. Calculate date ranges – recent 7 days, baseline 28-day window
3. Fetch GSC for the recent window
4. Fetch GSC for the baseline window (parallel)
5. JavaScript code node: compare clicks + position per page, classify as CRITICAL_DECAY / DECAYING / EARLY_DECAY / STABLE / GROWING
6. Log every result to the master sheet
7. Filter to decaying-or-worse pages
8. Build the weekly report (formatted text, includes top decliners per bucket)
9. Send to Slack
10. Send to email
11. Check if any pages are in CRITICAL_DECAY
12. For each critical page: generate fix tasks (backlink audit, content refresh, CTR optimization)
13. Log fix tasks to the dedicated sheet tab

The classification logic is the part that earns its keep. The thresholds for "critical" vs "decaying" vs "early decay" aren't arbitrary: they're tuned to filter out small week-over-week GSC fluctuations while catching real declines.

The defaults: critical = ≥30% click drop on a page with ≥100 baseline clicks; decaying = ≥20% click drop OR position drop of ≥5 spots on a top-20 page; early = position drop ≥3 spots OR click drop ≥10%.

Those numbers get tuned to your site during setup – sites with low baseline traffic need different thresholds than sites with high baseline traffic.

Handover: the sheet, workflow and tuning doc

At handover the whole setup is yours to run and retune:

• The full n8n workflow file
• The Google Sheet template (master log tab + fix-tasks tab)
• A setup doc covering: service account creation, GSC permission, Slack webhook setup
• A runbook for the common errors (GSC quota exceeded, sheet-too-large after a year of logging, false-positive seasonality flags)
• A tuning doc – the threshold numbers that work for your site, plus how to retune them as the library grows
• A Loom of one full Monday run
• Optional add-on: auto-create a Linear / Asana / Notion ticket for each critical page (instead of just logging to the sheet)
• Optional add-on: GA4 conversion data overlaid on the decay classification (so you can prioritize critical pages by revenue impact, not just traffic)

The tuning doc is the piece to guard. Thresholds go stale as the library grows, and it records why each one sits where it does.

Three fixes that make the report actionable

The data pull is straightforward. The hard part is making the report actually actionable instead of a wall of numbers.

Three things that took iteration to get right:

• The classification thresholds. Most "content decay tools" use one global threshold across all pages, which means high-traffic pages get flagged every week (normal week-over-week noise) and low-traffic pages never get flagged (no signal). The workflow's thresholds adjust based on baseline traffic.
• The fix-task generator. A "critical page" without context is just bad news. The auto-generated tasks turn the alert into a starting brief: which signals match a backlink problem vs a content-freshness problem vs a CTR problem. That cuts the time from alert to action.
• The signal-vs-noise filtering. Pages can drop 30% in clicks because Google rolled out a core update over the weekend. The workflow has a "global drop" detector that, when most pages drop in tandem, suppresses individual page alerts and instead sends a single "looks like an algorithm update, here's the portfolio impact" message.

Those three are what separate a decay report from the generic traffic alerts most SEO monitoring setups send. The defaults are tuned for B2B content sites, and we re-tune them during setup against your own baseline.

What a weekly run costs

Per Monday run: free. GSC API is free. n8n hosting: about $5/month if self-hosted.

Pricing is monthly rather than per build: the report runs inside execution capacity ($2,000 a month, flat, for the agents and automations route) on top of a fractional Head of Content retainer. Most of the setup goes into tuning the thresholds to your traffic profile and building the fix-task prompts.

Calibrating the thresholds to your site

Bring GSC access and a rough sense of your portfolio (how many pages, average traffic per page) to a call. We'll calibrate the thresholds together, and the first Monday digest can be in your inbox within 10 days.