QuQi

Content Decay Cohort Tracking

Site totals hide decay because new publishing masks it, so by the time the total falls the back catalogue has been sliding for a year. Sorting by clicks lost year on year does not fix this: it promotes pages that had a one-off spike and buries steady pages that quietly lost a third of their value. Grouping by publish cohort separates normal ageing, which needs no action, from pages that actually broke.

Get the skill file Let the agents run it
CATEGORY
Analytics & reporting
FORMAT
content-decay-cohort-tracking.md
STEPS
7
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when an older content library is losing traffic quietly and you need to decide what to refresh, what to leave and what to retire.

The skill file

content-decay-cohort-tracking.md
---
name: content-decay-cohort-tracking
description: Use when an older content library is losing traffic quietly and you need to decide what to refresh, what to leave and what to retire.
---

# Content Decay Cohort Tracking

Site totals hide decay because new publishing masks it, so by the time the total falls the back catalogue has been sliding for a year. Sorting by clicks lost year on year does not fix this: it promotes pages that had a one-off spike and buries steady pages that quietly lost a third of their value. Grouping by publish cohort separates normal ageing, which needs no action, from pages that actually broke.

## What you need first

- Search Console clicks by URL, monthly, 24 months minimum
- publish date and last substantive update date for every URL
- the query each URL earns most of its impressions from
- a rough refresh cost in hours, so the triage produces a decision rather than a list

## Method

1. Group URLs by publish quarter and plot median clicks per URL against months since publish. Use the median, because a few outsized hits will otherwise describe a curve no other page follows.
2. Read the normal shape off your own data: where clicks peak, where they plateau, where they fall away. Published decay benchmarks average across industries with very different refresh rates and will not match your site.
3. Flag pages that fall away from their own cohort curve rather than pages that simply fell. A page down 20 percent while its cohort is down 40 percent is outperforming and needs nothing.
4. Split the flagged set by cause before costing any work, using query-level data: lost position, stable position with lost CTR, or a query that lost demand. Only the first is a content problem.
5. Check the live SERP for the main query on the worst cases. Where the result page has filled with a different content type, a refresh cannot recover the page and a different asset is the honest recommendation.
6. Cost each refresh against the recoverable clicks, using the cohort plateau as the ceiling rather than the historic peak. The peak often included launch promotion that will not repeat.
7. Record the pages you decided not to touch and why, with a review date, or the same URLs will be re-audited from scratch every quarter.

## What this produces

A cohort decay curve for your own site plus a triaged URL list marked refresh, leave or retire with a one-line reason and a cost estimate for each refresh.

## Where this goes wrong

- Treating every decline as decay when part of the catalogue is seasonal and simply out of season on the day you ran the audit
- Refreshing by changing the visible date and little else, which mostly changes nothing and removes your ability to tell whether real edits would have worked
- Measuring refresh success against the week before the refresh rather than against the cohort curve, so an ordinary seasonal rise gets recorded as a win
- Retiring pages on traffic alone, when a page with no traffic may hold external links or carry internal linking to pages that do

---

From the QuQi skill library - https://www.quqi.io/skills/content-decay-cohort-tracking
Free to download · no account, no email

What you need first

  • Search Console clicks by URL, monthly, 24 months minimum
  • publish date and last substantive update date for every URL
  • the query each URL earns most of its impressions from
  • a rough refresh cost in hours, so the triage produces a decision rather than a list

Method

  1. 01 Group URLs by publish quarter and plot median clicks per URL against months since publish. Use the median, because a few outsized hits will otherwise describe a curve no other page follows.
  2. 02 Read the normal shape off your own data: where clicks peak, where they plateau, where they fall away. Published decay benchmarks average across industries with very different refresh rates and will not match your site.
  3. 03 Flag pages that fall away from their own cohort curve rather than pages that simply fell. A page down 20 percent while its cohort is down 40 percent is outperforming and needs nothing.
  4. 04 Split the flagged set by cause before costing any work, using query-level data: lost position, stable position with lost CTR, or a query that lost demand. Only the first is a content problem.
  5. 05 Check the live SERP for the main query on the worst cases. Where the result page has filled with a different content type, a refresh cannot recover the page and a different asset is the honest recommendation.
  6. 06 Cost each refresh against the recoverable clicks, using the cohort plateau as the ceiling rather than the historic peak. The peak often included launch promotion that will not repeat.
  7. 07 Record the pages you decided not to touch and why, with a review date, or the same URLs will be re-audited from scratch every quarter.

What this produces

A cohort decay curve for your own site plus a triaged URL list marked refresh, leave or retire with a one-line reason and a cost estimate for each refresh.

Where this goes wrong

  • Treating every decline as decay when part of the catalogue is seasonal and simply out of season on the day you ran the audit
  • Refreshing by changing the visible date and little else, which mostly changes nothing and removes your ability to tell whether real edits would have worked
  • Measuring refresh success against the week before the refresh rather than against the cohort curve, so an ordinary seasonal rise gets recorded as a win
  • Retiring pages on traffic alone, when a page with no traffic may hold external links or carry internal linking to pages that do

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/content-decay-cohort-tracking/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When is cohort tracking the right method rather than sorting by clicks lost year on year?

When an older library is sliding quietly and the site total still looks healthy because new publishing masks it. Sorting by clicks lost promotes pages that had a one-off spike and buries steady pages that gave up a third of their value. Grouping by publish cohort separates normal ageing, which needs nothing, from pages that actually broke.

What do I need in hand before starting, and what happens if I start without it?

Twenty-four months of monthly clicks by URL, publish and last substantive update dates, the query each URL earns most of its impressions from, and a rough refresh cost in hours. Without publish dates there are no cohorts and you are back to ranking pages by how far they fell. Without the cost figure the output is a list rather than a decision.

What do I end up with, and which part of it actually gets used?

A decay curve built from your own publishing history plus a triaged list marked refresh, leave or retire with a one-line reason and a cost. The leave column saves the most money: a page down twenty per cent while its cohort is down forty is outperforming. Use the cohort plateau as the recovery ceiling, not the historic peak, which often included launch promotion.

What is the mistake that most often ruins this, and what does it cost?

Refreshing by changing the visible date and little else. It mostly changes nothing and removes your ability to tell whether real edits would have worked, so the page returns to the audit next quarter. Measuring the refresh against the week before it shipped compounds that, because an ordinary seasonal rise gets recorded as a win and the tactic gets trusted.

More in Analytics & reporting