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.

El archivo de la habilidad

---
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.

## Qué necesitas antes

- 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

## Método

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.

## Qué produce esto

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.

## Dónde falla esto

- 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

---

De la biblioteca de habilidades de QuQi - https://www.quqi.io/es/skills/content-decay-cohort-tracking

Qué necesitas antes

• 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

Método

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.

Qué produce esto

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.

Dónde falla esto

• 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

Usa esta skill en tu propia IA

El archivo es markdown simple, con el nombre y el disparador en su frontmatter. Cuando un asistente sabe cargar skills por su cuenta, es ese frontmatter lo que lee para decidir que esta le aplica.

Más en Analítica e informes