analyze_content_decay

Cost: 10 credits.

analyze_content_decay compares the two windows in your latest pull_gsc_data and flags decaying pages: pages whose clicks fell by a meaningful amount and a meaningful proportion between the previous window and the current one. These are the pages most worth a refresh, re-optimization, or internal-link boost before the slide continues. Run pull_gsc_data first.

What it does

It sums each page's clicks across both windows (a page can rank for many queries) and flags a page when it lost at least 5 clicks AND at least 30% of its previous clicks. Both thresholds must be met, so a tiny wobble or a large-but-proportionally-small dip is left out. Results are ordered by clicks lost, biggest bleed first.

Two rules sit alongside those thresholds. A page with no clicks at all in the previous window is skipped outright — with no baseline there is nothing that could have decayed, whatever the arithmetic says. And a "page" is a document: rows differing only by a #fragment are summed together in both windows first, because Google routinely moves an article's clicks between its bare URL and its anchors, and reading those as two pages manufactures a decay on one and a rise on the other.

Example

Ask your MCP client in plain language:

Which pages on example.com are losing traffic?

Input

Returns

A list of decaying pages — each with its previous and current clicks, the clicks lost, the drop as a percentage, and the page's impressions and average position in both windows — biggest loss first, and not capped. If nothing is decaying, it says so (and you are still charged for the delivered analysis).

Those last two numbers are what separate the two ways a page loses clicks. Impressions down as well means the page lost ranking, and the instruction below is the right one. Impressions held while clicks fell means the page is still being shown and something on the results page took the click — an AI Overview, a featured snippet, an ad — and rewriting the page is not the answer to that. A page that stopped appearing has no position at all in the current window, and the reply says not ranking rather than printing a number.

The list ends with one line saying what position is: Google reports it as an average over the whole window, not a rank on any single day, so a page that sat 5th for half the window and 16th for the other half reports the same figure as one that never moved.

Each page carries what to do about it, and which of three instructions you get depends on how the page fell. A page down to no clicks at all is told to verify it is still indexed, reachable and not redirected before rewriting anything — that is also the shape a truncated pull manufactures. A page that lost most of its clicks but not all is told to re-target rather than tweak. A page in the middle still ranks and still earns, so that one gets the refresh-and-internal-links advice.

When a published Google update rolled out inside the period being compared, the reply says so above the list and names the update and its date. A core or spam update can move a whole site at once, and ten pages that all fell in the same week may be one event rather than ten content problems — so the note asks you to check whether many pages moved together before rewriting any of them. It says may, deliberately: Google publishes when an update rolled out, never what it did to your site. The dates come from Google's own status history and the reply tells you when that list was last checked, once it is old enough to be missing newer ones.

Every reply ends with the same footer: the window that was analyzed against the one before it, a caveat when either window hit the row cap, when the pull was taken plus a sentence once that is old, and — when your Search Console credential has stopped working — a warning to reconnect.

Inherited limits

This analysis sees only what pull_gsc_data brought back. A pull pages through a window and stops at 100,000 (query, page) rows at the very most — usually sooner, at a storage budget measured on the rows themselves, and the reply names the row count each window was cut at — and a page that fell out of a truncated window's top rows is read as having lost those clicks, so a large property can show a decay that never happened — the analysis prints a caveat when either window hit the cap.

Both windows also end 3 days before today rather than running up to it, so the newest days are not analyzed yet. See pull_gsc_data for both limits in full.