Content Decay Scorer Free Tool

Paste your pages one per line as page-url | clicks_90d_ago | clicks_now | word_count to score every post for content-decay risk at once. The tool compares organic clicks from 90 days ago to now, works out the percentage change, and ranks each page into a refresh priority tier. Posts that lost traffic and are thin (under 800 words) are flagged highest priority, so you know exactly which content to update first. This is a read-only report; nothing on your site is changed.

Enter one page per line as page-url then clicks 90 days ago then clicks now then word count

About Content Decay Scorer

What Content Decay Is

Content decay is when a page that once earned solid organic traffic quietly loses clicks and rankings over time, without anyone changing the page itself. Nothing broke. Nobody deleted a paragraph, deindexed the URL, or triggered a manual penalty. The page still loads, still ranks for roughly the same terms it always did, and still reads exactly as it did the day it was published. What changed is everything around it: the search results page, the competing content, and often the reader's expectations of what a good answer to that query now looks like.

This is different from a page that simply performs badly. A weak page might never have ranked well in the first place. A decaying page did rank well, sometimes for years, and is losing ground specifically because the world moved and the page didn't. That distinction matters because the fix is different too: a weak page usually needs a rewrite from scratch, while a decaying page often just needs its stale parts brought current.

It also helps to separate content decay from the more dramatic problems that get more attention in SEO discussions: a site-wide traffic drop after a core algorithm update, a page that got hit with a manual action, or a technical issue like a broken canonical tag or an accidental noindex. Those problems tend to affect many pages at once, often abruptly, and usually have a clear root cause once investigated. Content decay is the opposite shape. It's page-by-page, gradual, and has no single root cause to find and fix, which is exactly why it needs a different detection method (comparing click trends per page over a fixed window) rather than the kind of site-wide technical audit that catches the more dramatic problems.

Content decay is also gradual by nature. It rarely shows up as a single dramatic drop in an analytics dashboard. It looks more like a slow erosion: a page that pulled 400 clicks a month slides to 350, then 300, then 260, over a stretch of months, with no single week standing out as "the day it broke." That gradual shape is exactly why decay is one of the easiest problems on a website to overlook, and why a page-by-page traffic comparison is usually the only way anyone actually notices it.

Why Content Decay Is Easy to Miss

Most of the attention on any content-driven site goes toward publishing new material: new posts, new landing pages, new campaigns. That's a reasonable default: new content is where growth visibly comes from, and it's satisfying to watch a fresh page start ranking. Maintaining old content doesn't offer the same visible payoff. Nobody gets excited about updating a paragraph in a post from two years ago, even when that update is worth more traffic than the new post being planned for next week.

Because decay happens slowly, it also doesn't trip the alarms that other problems do. A 404 error, a broken redirect, a manual action: those show up as sharp, unmistakable signals. A page sliding from page 1 to page 2 of the search results over eight months does not look like an emergency in a traffic graph zoomed out to a year. It just looks like normal month-to-month noise, until someone stops and compares the same page's numbers across a longer window.

The practical result is that most sites with more than a handful of older posts are losing real, cumulative traffic to decay at any given moment: traffic they'd fight hard to win back if it disappeared all at once, but that nobody notices leaking away a little at a time. The pages responsible are usually not the newest ones and not the obviously broken ones. They're the quietly aging middle of the site: posts that were genuinely good when written, ranked well for a while, and have simply not been touched since.

There's also a workflow reason decay stays hidden even on sites that do pay attention to analytics. Most traffic dashboards default to showing the whole site's trend line, or a single page's absolute numbers over time. Neither view is built to answer "which specific pages, out of two hundred, are declining right now relative to where they were three months ago." Spotting that requires a page-by-page, before-and-after comparison across a consistent window, which is a different kind of check than glancing at a traffic graph, and one that's easy to keep postponing precisely because nothing about the dashboard is flagging it as urgent.

What Causes Content Decay

Content decay isn't one problem. It's a handful of distinct pressures that all produce the same symptom (declining organic traffic on an unchanged page). Knowing which one is actually happening on a given page changes what the fix should look like:

• Outdated facts, stats, or screenshots. A post citing a "2023 pricing" or "current version" freezes that framing permanently. Readers (and search engines evaluating freshness/accuracy signals) notice when a page's specifics stop matching reality, even if the surrounding advice is still sound.
• Competitors publishing fresher or deeper content on the same topic. Search results are relative, not absolute. A page doesn't have to get worse to lose rank; it just has to stand still while three competing pages get rewritten, expanded, or restructured around what's currently ranking well.
• Seasonal or topical relevance fading. Some pages were tied to a moment (a product cycle, a news event, a trend) and organically lose search demand as that moment passes, independent of anything the page does or doesn't do.
• Search algorithm updates rewarding a different depth or format than when the page was written. A page built around a format that used to satisfy a query (a short listicle, for example) can lose ground if the search engine starts favoring pages with more depth, more original detail, or a different structure for that same query, again with zero change on the page itself.

These causes aren't mutually exclusive, and a single decaying page is often affected by more than one at once: stale numbers plus a fresher competitor plus a slight shift in what the algorithm now rewards for that query. That's part of why guessing at the cause from memory is unreliable, and why comparing actual click numbers across a fixed time window is the more dependable starting point.

It's also worth separating the causes that are fixable from the ones that mostly aren't. Outdated facts and thin sections are entirely within a site owner's control — nobody else needs to do anything for those to be corrected. A competitor publishing a deeper piece is not directly controllable, but it is directly answerable: the response is to look at what that competing page now covers and close the specific gap, not to guess. Seasonal fading and algorithm-driven format shifts sit somewhere in between. A page tied to a passing trend may simply have a shorter useful life than a genuinely evergreen topic, and no amount of editing restores demand that's gone for good. It's worth diagnosing the cause before investing time in a rewrite: refreshing a page suffering from fading seasonal interest won't recover the traffic that updating a page with genuinely stale facts would.

Where the Input Data Actually Comes From: Google Search Console

The Content Decay Scorer needs two click numbers per page (clicks from roughly 90 days ago and clicks now) plus a word count. It does not fetch, crawl, or estimate any of these itself. Every number has to come from somewhere real, and in practice that somewhere is almost always Google Search Console's Performance report.

The relevant workflow inside Search Console: open the Performance report, filter to Pages if you want a page-level breakdown, then use the Compare date-range option (it sits next to the date picker) to compare two ranges, for example the last 90 days against the 90 days before that. Search Console will show clicks for both ranges side by side, per page, which is exactly the "90 days ago vs. now" pairing this tool expects. That data is exportable to CSV or Google Sheets directly from the report, which makes it straightforward to reshape into the pipe-separated lines the tool reads.

Word count doesn't come from Search Console — that's a property of the page itself, pulled from the CMS editor's word-count display, a browser reading-time extension, or a quick manual count for a handful of pages. It's a small extra step, but it's the piece that lets the tool distinguish a decaying page that's already substantial from a decaying page that's thin and has more obvious room to improve.

For sites without a formal export process already in place, it's worth budgeting time for this step honestly — pulling clicks for a couple hundred pages across two date ranges and pairing each one with a word count is manual work, even with Search Console's export doing the heavy lifting on the traffic side. Batching it (all pages in one Google Sheet, one export session, one sitting to add word counts) tends to be far less painful than trying to do it page-by-page as an afterthought each time a page is reviewed.

Without understanding this data source, the tool's input format looks arbitrary: three numbers separated by pipes next to a URL. Once it's clear that two of those three numbers come straight out of a two-click Search Console comparison and the third is a word count you likely already have or can get in seconds, the workflow makes sense: export, format, paste, get a prioritized list.

How the Content Decay Scorer Works

The tool takes one page per line in a fixed format:

page-url | clicks_90d_ago | clicks_now | word_count

The URL has to be absolute (http:// or https://), and the three numbers have to be plain non-negative whole numbers: no decimals, no commas, no minus signs. A line that doesn't match this shape exactly is skipped as invalid rather than guessed at, and duplicate URLs are automatically de-duplicated (the first occurrence of a given page wins). This keeps the tool honest: it never silently reinterprets malformed input, it just leaves it out and tells you how many lines were skipped.

For every valid page, the tool computes a decay percentage: the signed percentage change in clicks between the two time points:

decay_pct = (clicks_now − clicks_90d_ago) / clicks_90d_ago × 100

A page that went from 200 clicks to 100 clicks gets a decay_pct of −50 (lost half its traffic). A page that went from 100 clicks to 150 gets +50 (gained traffic, not decaying at all). This is the whole engine of the tool — a straightforward before/after percentage change, nothing more exotic than that.

The one place that formula breaks on its own is when clicks_90d_ago is zero. Dividing by zero isn't computable, and the tool handles that honestly instead of crashing or inventing a number:

Once decay_pct is known (or marked n/a), every page is placed into one of four refresh-priority tiers:

Results are sorted with critical pages first, then high, then medium, then low, and within each tier the most-negative decay_pct sorts first (n/a rows sink to the bottom of whichever tier they land in). The intent is that the top of the results list is always the single most urgent page to look at.

The One Detail Worth Getting Precisely Right: What Word Count Actually Does

It's tempting to assume word count factors into the decay percentage itself. It doesn't, at all. The decay_pct number is pure click-trend math: clicks now versus clicks 90 days ago, nothing else enters that formula. Word count only comes into play after a page has already qualified as severely decayed (decay_pct ≤ −50). At that point, and only at that point, word count acts as a tie-breaker between two levels of urgency: a severely-decayed page under 800 words is ranked critical, because it's both declining and thin, the combination most likely to keep sliding and the one where a content expansion has the clearest, most direct payoff. The identical decline on a page that's already 800+ words is ranked high instead of critical. It's still genuinely urgent, but "add real depth to a thin page" is a smaller job than "figure out what's missing from a page that's already substantial." Word count plays no role whatsoever in the medium or low tiers: a page losing traffic gradually, or gaining traffic, is sorted purely on its click trend regardless of length.

Worked Example: A Small Batch Run Through the Tool

Take five hypothetical pages pasted into the tool in this format, to see exactly how the tiers get assigned in practice:

/guide-a/ lost 70% of its clicks and sits at 620 words, under the 800-word line, so it's ranked critical: the single page to fix first. /guide-b/ lost slightly less (60%) but is already 1,450 words, so despite the steeper-looking click loss it's ranked high rather than critical. The decline is just as real, but the page already has substance, which is the whole point of the word-count tie-breaker. /guide-c/ lost about a quarter of its clicks, real but not severe, landing in medium. /guide-d/ actually gained clicks, so it's low regardless of its length. /guide-e/ had zero clicks 90 days ago and picked up 12 clicks since, a genuinely positive development, but the percentage change from zero can't be computed, so it's reported n/a and sorted into low rather than being assigned a misleading number.

How Often to Re-Run This Check

Because the tool compares two 90-day windows, running it more often than roughly every 90 days mostly re-measures the same period and doesn't add new information. A page's traffic trend doesn't move fast enough for a weekly re-check to be meaningful. A quarterly cadence (every 90 days, matching the window the tool itself uses) is a reasonable default for most sites: pull a fresh Search Console export, re-run the same batch of pages, and compare the new tier assignments against the last run. Pages that were critical or high and have since dropped off that list are a useful signal that a fix worked. Pages that stay in the same tier run after run are the ones that got flagged but never actually addressed, worth prioritizing on the next pass rather than letting the same page linger on every quarterly list indefinitely.

How to Use This Tool

1. Export click data from Google Search Console. Open the Performance report, use the Compare date-range option to compare the last 90 days against the prior 90 days, and export the page-level results (CSV or Google Sheets).
2. Add a word count for each page. Pull it from your CMS editor, a reading-time extension, or a manual count for a small batch.
3. Format each page as one line in the exact order page-url | clicks_90d_ago | clicks_now | word_count — absolute URL, then the three whole numbers, separated by pipe characters.
4. Paste the full list into the tool's input box, one page per line (up to 20,000 lines, capped at 5,000 distinct pages per run).
5. Submit and read the results top to bottom. The results are already sorted (critical first, then high, medium, low), so the top rows are the pages worth opening first.

Reading Your Results

Working through the worked example above as if it were a real results table: /guide-a/ at the top of a critical list means "open this page today." A steep decline on a page that hasn't built up much depth yet is the fastest-payoff fix available, because expanding a 620-word page is usually quicker than reworking a page that's already long. A high-tier page like /guide-b/ is just as urgent in terms of lost clicks, but the fix looks different: the page already has real length, so the problem is more likely stale specifics, a competitor that's gone deeper on the same topic, or a format shift, rather than simple thinness.

Medium-tier pages are worth a scan but not a fire drill. A moderate decline over 90 days can be normal fluctuation, a slightly fading seasonal topic, or the early edge of a decay pattern that hasn't become severe yet. It's reasonable to batch these into a monthly review rather than reacting immediately.

An "n/a" row, like /guide-e/ above, is not a bug and not something to chase. It simply means the tool has no baseline to measure a percentage change against (dividing by zero clicks is undefined, not zero and not infinite). If anything, a page that had no clicks 90 days ago and has some now is a mild positive signal worth a glance, just not one this tool is built to quantify.

An empty critical and high list across an entire batch is a genuinely good result. It means nothing in that batch has lost half or more of its clicks over the comparison window, and whatever medium-tier pages exist are candidates for routine maintenance rather than urgent fixes.

One more thing worth reading correctly: the tool scores exactly the pages submitted, and only those pages. It doesn't crawl a sitemap or discover pages on its own, so a results list that looks "clean" only reflects the batch that was pasted in. If an entire section of a site (an old category, a set of older posts) was never included in the export, its decay is invisible to this run, not necessarily absent in reality. Building the input list from a broad enough Search Console export, not just the pages already suspected of declining, is what makes the results trustworthy rather than a confirmation of an existing hunch.

Fixing Decayed Pages Once You Find Them

Finding the decaying pages is only half the job. What actually recovers traffic is what happens next on the page itself:

• Update outdated facts, statistics, screenshots, and version numbers. If a page references a "current" price, tool version, or dataset that's now stale, that's usually the fastest, lowest-effort fix with the clearest payoff.
• Expand thin sections that competitors now cover more thoroughly. If a section of the page reads as shallow next to what's currently ranking around it, that section — not the whole page — is where the rewrite effort should go.
• Check whether internal links pointing to the page (or from it) still make sense. A decaying page is sometimes still linked from newer content in a way that no longer reflects the site's current structure or priorities; a stale internal link pattern can compound a page's decline.
• Only bump the visible publish or "updated" date when the substance genuinely changed. Changing a date without changing the underlying content is a credibility problem, not a fix. Readers and search engines both notice a "recently updated" label on a page that reads exactly as it did years ago. Update the date because the content changed, not to make the page look fresher than it is.

None of these fixes require touching the page's URL, its overall structure, or its core argument if that argument still holds — content decay recovery is usually additive and corrective, not a ground-up rewrite. The pages that recover fastest tend to be the ones where the original framing was sound and only the specifics went stale, which is also why catching decay early (before a page has drifted for years) tends to be a smaller job than catching it late.

After making changes to a batch of decaying pages, the practical next step is simply to re-run this same comparison again in another 90 days — pull a fresh Search Console export, re-run the tool, and see whether the pages that were critical or high have actually moved down in decay or off the list entirely. That follow-up loop is what turns a one-time cleanup into an ongoing maintenance habit (see "How Often to Re-Run This Check" above).

Working the List in Order, Not All at Once

A results list with a dozen critical and high pages can look overwhelming, but the sort order the tool already applies is doing the prioritization work — there's rarely a good reason to skip around it. Start at the top row and work down, because the tool has already put the most-negative decay first within each tier. Trying to fix every flagged page in one sitting usually means every page gets a shallow touch-up instead of a handful of pages getting the depth they actually need; a smaller number of properly reworked pages tends to move the needle more than a long list of pages that each got five minutes of attention.

It's also reasonable to treat critical and high differently in terms of effort budget. A critical page (severely decayed and thin) is often a genuinely fast fix — expanding a 600-word page to actually cover the topic properly is a bounded task. A high-tier page (severely decayed but already substantial) is more likely to need real diagnostic work first: reading the current top-ranking competitors for that query, figuring out what they now do that the existing page doesn't, and deciding whether that's a content gap, a stale angle, or a format the query has moved on from. Budgeting more time for high-tier pages rather than assuming "high" means "less work than critical" avoids a common trap — the tier label reflects word count, not the size of the fix.

Related Tools

A few other free tools on this site pair naturally with a content-decay workflow:

• Orphan Page Finder — decaying pages sometimes overlap with orphaned ones (pages with no internal links pointing to them); worth checking whether a page losing traffic has also quietly lost its internal link support.
• Duplicate Meta Finder — when refreshing a decaying page's content, it's a good moment to also confirm its title and meta description are still unique and not duplicated by another page on the site.
• Redirect Chain Checker — if a decaying page's URL has been through a restructure or redirect at some point, confirm the redirect path is clean before investing time refreshing the content itself.

Frequently Asked Questions

Does content decay mean my page did something wrong?

No — decay happens to pages that were performing well and are simply losing ground as the world around them changes (see "What Content Decay Is" above). It's not a penalty or an error on the page.

Why does the tool report "n/a" instead of a percentage for some pages?

A percentage change from zero clicks is mathematically undefined, not zero and not infinite — the tool reports it honestly as not computable rather than guessing. See the zero-clicks table above.

Does a higher word count always mean a lower priority tier?

No — word count is not part of the decay percentage at all. It only breaks a tie between critical and high once a page already qualifies as severely decayed. See "The One Detail Worth Getting Precisely Right" above for the exact rule.

Where do I actually get the clicks_90d_ago and clicks_now numbers?

Google Search Console's Performance report, using the Compare date-range option to compare two 90-day windows — the full export workflow is covered above under "Where the Input Data Actually Comes From."

Should I update the page's visible date every time I make a change?

Only when the substance actually changed — see "Fixing Decayed Pages" above. Bumping a date without a real content change undermines the credibility the date is supposed to signal.

How many pages can I check at once?

Up to 5,000 distinct pages in a single run, from up to 20,000 input lines; duplicate URLs are automatically de-duplicated and lines that don't match the exact four-field format are skipped rather than guessed at.