Detecting SEO content decay automatically.

The slow loop most SEO teams live in

Tuesday morning. A top-10 page slips from position 4 to position 9 because Google adjusted its rank algorithm overnight. By Tuesday night, the page has lost ~600 clicks. By Friday, it's lost ~3,000 clicks. The SEO team's weekly health check runs on Monday morning; they catch the drop, file a refresh ticket, the content team picks it up the following Wednesday, the page republishes Thursday. By the time the position recovers, two weeks have passed and the cumulative click loss is ~9,000.

This is the median SEO operation. It's not because the team is bad; it's because the loop is structurally slow. Weekly dashboards. Manual triage. File-and-wait ticketing.

The actual decision window — the gap between a position drop being detectable and being actionable — should be hours, not weeks. The architecture to enable that is straightforward; it just isn't what most SEO platforms ship.

Where the latency comes from

SEO decay platforms typically run on a three-step pipeline that's slower than it needs to be at every step:

1. GSC ingest: nightly batch. Most platforms pull Search Console data once per 24 hours.
2. Decay computation: weekly. Trailing-7-day click compared to trailing-28-day baseline, computed Monday morning.
3. Surfacing: via dashboard. The operator has to log in and look. There's no proactive alert; if they don't check, nothing happens.

Each step compounds the lag. By the time the operator sees the dashboard, the data is 24-168 hours old. The dashboard shows the issue; it doesn't dispatch the fix.

What the better architecture looks like

Sumeru's SEO Intelligence engine runs the same conceptual pipeline — ingest → detect → queue — but on an event bus, with each stage publishing typed events:

1. GSC delta arrives via API   →  publish gsc.delta event
2. Detector subscribes        →  computes 9 decay signals in parallel
                              →  publish decay.detected event (if confidence > threshold)
3. Action handler subscribes  →  generates AI refresh draft
                              →  publish refresh.queued event
4. CMS adapter subscribes     →  inserts draft into editor approval queue
                              →  publish approval.pending event
5. Audit logger subscribes    →  writes plain-language audit row

Each stage runs as soon as the previous stage publishes its event. There is no batch step. P95 from GSC reflecting the change to the refresh draft landing in the editor queue: 60 minutes. P95 from queue to published page: depends on editor velocity, but most teams clear the queue daily.

The architectural insight: GSC's data freshness is the floor. We can't detect decay faster than Google publishes it. But everything after ingest can run in milliseconds.

The 9 decay signals

Decay isn't one thing; it's a family of related signals. Sumeru's detector runs nine in parallel and surfaces whichever fires:

1. Rank decay: sustained position drop over a configurable window.
2. CTR drop: impressions stable, clicks falling — usually means snippet ownership transferred or the SERP changed shape.
3. AI Overview gain: a query you rank for newly shows AI Overview above your result. Position 1 organic with AI Overview above is a 30-60% CTR loss.
4. AI Overview loss: the inverse — your page was cited in AI Overview, now isn't.
5. Schema-fit regression: structured data changed; rich result eligibility dropped.
6. Content gap: a competitor newly ranks for a query you don't.
7. Internal-link orphan: the page's internal-link inbound count dropped (e.g. someone deleted a section linking to it).
8. CWV regression: Core Web Vitals score dropped below the rank threshold.
9. Soft-404: the page now returns thin content (e.g. product unpublished, blog deleted upstream).

Each detector outputs a typed signal with a confidence score. The orchestrator routes high-confidence signals (above threshold) into the refresh queue automatically; medium-confidence signals surface in the dashboard with one-click approve; low-confidence signals roll up to a weekly digest for trend analysis.

The autoaction that ships the fix

Detection without action is a dashboard. The other half of the architecture is the refresh_blog_post autoaction handler.

When a decay signal fires with high confidence, the handler:

1. Loads context: the current page content, the GSC query data that triggered the signal, the brand-voice loaded from previous posts on the same site, top-3 competitor SERPs for the same query.
2. Routes to the AI Copilot with all four data sources grounded. The Copilot generates a refresh draft with the changes inline-cited (e.g. "Added section X because GSC shows query Q dropped from position 4 to 9 over the past 7 days").
3. Snapshots the original page so an undo is always possible.
4. Queues the draft into the CMS approval flow with the rationale visible to the editor.
5. Writes an audit row capturing the trace from GSC delta to refresh draft.

Total elapsed time from detection to draft in editor queue: typically 5-15 minutes, depending on AI Copilot latency. The editor then reviews — usually 1-3 minutes per draft — and approves or rejects. Most drafts are approved with minor edits.

What this actually changes operationally

An anonymised customer: $18M GMV brand in the home-goods space, ~2,400 indexed pages. Before Sumeru: weekly SEO health checks via Looker, ~3 decay events caught per week, average detection-to-action lag of 9 days, ~40% of caught events actually shipped a refresh.

After Sumeru deployment (90 days in):

• Average 47 decay events caught per week (vs 3 manual)
• Average detection-to-queue lag of 8 minutes (vs 9 days)
• 92% of queued drafts ship within 24 hours (editor backlog is much smaller because each refresh is pre-drafted)
• Recovered ~$340k/yr in lost organic traffic based on attribution-engine rollup against the affected pages

The biggest unlock isn't catching more decay events; it's shipping the response. The dashboard pattern catches plenty of issues; it's the editor backlog where most of them die.

Trade-offs to acknowledge

Two trade-offs an honest implementation has:

False positives. A drop from position 4 to 9 might be a permanent algorithmic shift, or it might be a 2-day anomaly that self-recovers. Sumeru's detector waits for sustained signal (default: 7-day rolling window) before firing high-confidence; this introduces a 7-day floor on detection-to-action. Some operators tune this down to 3 days for faster response; others up to 14 for fewer false positives.

Refresh quality. AI-generated refresh drafts are good, not great. Editors need to review and edit. The unlock isn't "AI replaces the editor"; it's "the editor reviews a pre-drafted refresh instead of starting from scratch." Time-per-refresh drops from 90 minutes to 12 minutes; the writing quality is approximately the same.

The architectural takeaway

Most SEO operations are slow because the pipeline is batch-shaped. Faster cadence requires an event bus, not a faster batch job. The runtime that delivers real-time attribution also delivers real-time decay detection — the same event-driven primitives generalise across surfaces.

The reason most SEO platforms don't ship real-time decay detection isn't that the math is hard. It's that the platform's architecture wasn't designed for it. Bolting real-time onto a batch pipeline produces something that looks real-time but isn't.

If you're evaluating SEO tooling, the diagnostic question is: can your platform detect a decay event and queue a refresh draft within an hour, or does it require a Monday-morning dashboard read?

---

If you want to see decay detection on your own catalog, request a demo — we connect to your GSC, run the detectors against your top 100 pages, and walk you through the live results in 10 minutes. /contact or read the SEO Intelligence Engine page.