Content Decay Detector

Summary#

Content Decay Detector groups your real ranked keywords by the page that holds them, compares each keyword against its previous position, and scores every page on how much traffic it is losing. The output is a refresh queue ordered by traffic at risk. Its internal tool id is content_decay.

Purpose#

Published content does not hold its position. Competitors publish, results get re-ranked, and a page that brought in traffic for two years quietly stops. The loss is invisible in a total-traffic chart because a dozen small declines look like noise.

This tool exists to make the decline page-level and specific. The decision it supports is a maintenance decision: given limited editing time, which page do you refresh first?

Overview#

You enter a domain. Metric Vault pulls that domain's ranked keywords from live search data, highest traffic first, including each keyword's current position, its previous position, whether it was lost outright, its estimated traffic and its search volume.

How much of your site a run covers#

A standard run reads 700 keywords. For a large site that is a sample, and the result says so in a line under the numbers: Sample size 700 of 209,454 ranked keywords, highest traffic first, grouped into 160 pages. Both figures are measured on the run, so the line moves with the domain. When 700 covers everything the domain ranks for, it says that instead, because a site with nine ranked keywords is not a sample of itself.

Reading highest-traffic-first matters: a sample takes the keywords carrying the most traffic, so the pages most worth knowing about are the ones it reaches.

On a paid plan the result offers Run the deeper scan, which re-runs at your plan's depth. On one large site that took the run from 160 pages to 889. The deeper scan costs a credit like any other run, and the disclosure line updates to the depth it actually reached.

Even the deepest run is a depth rather than a census, and the line never claims otherwise. Covering every keyword on a site with a couple of hundred thousand of them would mean hundreds of provider calls for a single run.

Every keyword is attributed to the page that ranks for it, and the pages are scored. A keyword counts as slipping when it fell two or more places — a one-place move is treated as noise — or when it disappeared from the results entirely. The traffic tied to those slipping keywords becomes the page's traffic at risk.

The decay score combines three things: how large that page's traffic at risk is relative to the worst page on the site, what share of the page's keywords are slipping, and how severe the average slip is. A page that is gaining on balance is pulled down so it does not surface as a refresh target.

The queue is then ordered by traffic at risk, with the decay score as the tiebreak. That ordering is the point: it puts the page where a refresh recovers the most traffic at the top.

Benefits#

• Page-level, not site-level, so the output is an editing list rather than a chart.
• Ordered by traffic at risk, so the first row is the highest-value refresh.
• Shows the individual slipping keywords behind each page, so you know what to fix.
• Distinguishes a page that is genuinely decaying from one that is simply small.
• Costs 1 credit, which keeps it under the monthly premium threshold.

Use Cases#

Planning a quarterly refresh cycle. You have time to update five pages; the top five rows tell you which five.

Explaining a traffic dip. The traffic-at-risk figure and the slipping keyword list turn "traffic is down" into a specific, fixable list.

Protecting a flagship page. A high-traffic page appearing in the Refresh now band is the most urgent maintenance signal the platform produces.

Auditing an inherited site. One run tells you which of someone else's pages are still working and which are fading.

Deciding refresh versus rewrite. A page with many keywords slipping slightly needs a refresh; a page that lost most of its keywords usually needs rebuilding.

Requirements#

• A signed-in account.
• A paid plan — 1 credit per run, and any cost above zero is blocked on Free.
• A domain that already ranks for something. A brand-new site has no ranked keywords and therefore nothing to score.
• Available credits and hourly headroom.
• No integration and no verified domain.

Permissions#

Any workspace member on a paid plan can run it. Free accounts are refused with This tool needs a paid plan. Free includes the 10 technical SEO tools; upgrade to Pro to unlock the rest. The recommendations panel under the result requires Pro or above — see Get Recommendations.

Cost#

1 credit per run. The run button reads Detect Decay · 1 report, matching the 1-credit charge.

Below the premium threshold of 3, so the monthly quota never blocks it — only the hourly fair-use cap of 100 light-tool calls per hour. A shared-cache hit still charges the credit; the cached window for this tool is three days. See How credits work and Result caching and freshness.

Navigation Path#

Dashboard → Keyword & Content Research → Content Decay Detector

The sidebar entry carries a pink NEW badge.

Inputs#

Pressing Enter in the field runs the tool. Try sample and the run button both fire the run immediately — they do not open a preview.

Step-by-Step Guide#

1. Open Keyword & Content Research and choose Content Decay Detector.
2. Enter your domain in the field marked e.g. nike.com.
3. Click Detect Decay, or press Enter.
4. Wait for Analyzing… this can take a few seconds for live data. to clear.
5. Read the four KPI tiles, then What this means.
6. Work down Refresh Priority Queue from row 1.
7. Open Why these pages are decaying for the keyword-level evidence on the worst pages.
8. Export or share the report from the buttons at the top of the view.

Two sources, and the tool says which#

If the domain you run this on is a Search Console property you have connected and selected, the tool uses measured clicks: what Google recorded for each page over the last 28 days, against the 28 before it. The queue is labelled Measured and names the property.

For any other domain, including every competitor, it uses estimated traffic modelled from ranking data, and the queue is labelled Estimated.

The two disagree, and only one of them is checkable against Search Console, so the tool never mixes them in one queue.

The columns differ, on purpose. Search Console stores clicks per page and queries per property, not queries per page, so on the measured path there are no per-page keyword counts to show. Those three columns are removed rather than filled with zeros, and the space goes to what was measured: clicks now, clicks before, average position, clicks lost, and why.

The "why" is one of three, split from the stored numbers rather than guessed:

This is the same split the Search Console page uses, off the same stored columns, so the two screens cannot disagree about a page.

Reading the Results#

The four KPI tiles.

What this means. Two to four plain-language findings, each with a badge: Act for a bad-tone finding, Watch for a warning, OK for a good one. The first one usually names your single worst page and the visits at risk on it. When nothing is decaying, this block says so directly rather than manufacturing concern.

Refresh Priority Queue — Highest traffic at risk first. The core deliverable. One row per page, ten columns:

The four statuses.

Read a row like this: high traffic and high traffic-at-risk is your first refresh; high traffic with low risk is a page to leave alone; low traffic with high risk proportionally is worth a quick edit but not a rewrite; Growing pages should be studied, not touched — whatever is working there is worth copying onto the decaying pages.

Why these pages are decaying. Expanded detail for up to five pages in the Refresh now or Watch bands. Each block shows the URL, the status, a Decay N/100 chip, and a one-line reason in the form "7 of 24 keywords slipping (2 lost), avg -6 positions; ~1,400 monthly visits at risk". Beneath it, a keyword table:

This table is where the edit brief comes from. A page losing its head term needs a different fix from a page losing a dozen long-tail terms: the first is a competitive problem on one query, the second is usually a freshness or depth problem across the whole piece.

Get recommendations. A panel under the result turns the findings into a step-by-step plan, grouped as Fix first, Do next and Quick wins. It is a Pro-and-above feature with its own monthly allowance — see Get Recommendations.

What to do with it. Take the top three rows. For each, open the keyword table, note the terms that slipped, and rewrite those sections with current facts and numbers. Refresh the publish date, then re-promote the page. Re-run in six weeks and check whether those rows moved down the queue.

Examples#

Screenshots#

Tips#

• Enter the root domain, not a single page. The tool builds a site-wide queue.
• Read Traffic at risk as a percentage of tracked visits, not as an absolute — the percentage is what tells you how serious this is for your site.
• Study the Growing rows before you edit the decaying ones. They show what is currently working on your site.
• Re-run quarterly. Ranking movement below one position is deliberately ignored, so weekly runs mostly show the same queue.
• Feed the top row straight into Content Optimizer to get the specific edits for that page.

Best Practices#

• Refresh by traffic at risk, not by decay score. The score ranks severity; the traffic figure ranks value.
• Fix the content, not just the date. Changing a publish date without updating the page rarely recovers a position.
• Handle lost keywords separately from slipped ones. A lost keyword usually means the page no longer matches the query at all.
• Pair a decaying cluster with Internal Linking Engine — a page starved of internal links decays faster and recovers slower.
• Keep a record of each run before you edit, so the next run measures the effect of your work.

Common Mistakes#

• Entering a single URL. The queue is built from every ranked keyword on the domain; a URL narrows nothing and can return nothing.
• Treating a low Pages Analyzed count as good news. It means the domain ranks for little, which is a different problem.
• Refreshing the highest decay score first when a lower-scoring page has far more traffic at risk.
• Reading Avg drop alone. A large average drop across two keywords matters less than a small drop across sixty.
• Re-running weekly and expecting movement. Sub-two-place changes are filtered out on purpose.

Limitations#

• Ranked-keyword data comes from Google's United States, English-language index. The country picker does not change the underlying market.
• Up to 700 keywords are analyzed per run, ordered by estimated traffic. A very large site is sampled at its most valuable end, not read whole.
• Comparison is against each keyword's own previous position as reported by the data provider — it is not a diff against your last Metric Vault run.
• Keywords that moved fewer than two places are ignored.
• Traffic figures are estimates, not analytics. They are useful for ranking pages against each other, not for reporting exact visits.
• Pages that rank for nothing never appear, however badly they are performing.
• The date range picker does not change the comparison window.
• Saved results are kept for 90 days.

Troubleshooting#

FAQs#

How does it know a page is decaying? It compares every ranked keyword's current position against the previous position reported by the data provider, counts the ones that fell two or more places or were lost, and totals the estimated traffic behind them. That total is the page's traffic at risk.

What exactly is the decay score? A 0-100 composite: half of it is the page's traffic at risk relative to the worst page found, roughly a third is the share of the page's keywords that are slipping, and the rest reflects how severe the average slip is. Pages improving on balance are scored down so they do not appear as refresh targets.

Why is a page with a big drop lower in the queue than one with a small drop? Because the queue is ordered by traffic at risk. A four-place drop on a term worth 5,000 visits outranks a twenty-place drop on a term worth 40.

Is this comparing against my last run? No. It compares each keyword against its own previous position in the search data, so a first run is immediately useful — there is no baseline to build.

Why does it cost 1 credit when it looks so detailed? It makes a single, cached provider call and does the analysis in-house. Credits track backend cost — see How credits work.

Can I export the queue? Yes. Export PDF, Export Excel, Export CSV, Export JSON and Share public link are at the top of the view.

Does refreshing a page guarantee recovery? No. A refresh restores relevance and freshness; if a competitor now covers the topic far better, the fix is a rebuild rather than an update.