How do you tell content decay from a site-wide dip?

Content decay is a fall in one page's search traffic that the rest of your site does not share, while a site-wide dip moves most pages together. To tell them apart, subtract the site-wide change over the same dates from each page's change; what is left is the page's own decline, which is the part to investigate.

• Penlid's decay check compares a page's last 28 days with the 84 days before them and subtracts the site-wide move over the same dates (Penlid, methodology page, read 30 October 2026).
• Penlid gives no verdict to a page under 3,000 impressions in the trailing 90 days, and its tool page asks for at least 112 days of data (Penlid, content decay check, read 30 October 2026).
• Google's guide to debugging traffic drops tells you to look for patterns in the pages affected, from the whole site down to a group of pages or even one very important page (Google, Search Central documentation, read 30 October 2026).
• After a core update, Google suggests waiting at least a full week after it completes, then comparing that week with the week before the update started rolling out (Google, Search Central documentation, read 30 October 2026).

What separates content decay from a site-wide dip?

Content decay is one page losing search traffic while the rest of the site holds or loses less; a site-wide dip is a loss that most pages share. None of the Google pages we read for this guide uses the term or describes a decay flag in Search Console, so the definition here is ours.

Google's guide to debugging traffic drops tells you to look for patterns in the pages affected, from the whole site down to a group of pages, or even just one very important page. That gives three shapes, and the table pairs each with a first check.

Subtracting the site's move separates the first shape from the third. In the middle case, every page in the affected section reads as falling against the rest of the site, so look at those pages together before calling each one decay (our reasoning, not a documented rule).

What should you rule out before you blame a page's content?

Rule out the data, the calendar, an update and the days you compare, because each can move many pages at once without any change to your content.

• The data. In its section on the main causes of a drop, Google's debugging guide adds that the drop might be related to a change in the data processing or a logging error. The guide to telling a real drop from a Search Console data anomaly covers that check, and the newest days in an export can still change.
• The calendar. The same guide has you select the last 16 months and compare the drop with a similar period, such as the last 3 months year over year, and has you check your top queries on Google Trends to understand if the drop was only for your website or throughout the web. See also separating seasonality from a real SEO change.
• An update. If you suspect an algorithmic update, Google says there might not be anything fundamentally wrong with your content, and for a core update it suggests waiting at least a full week after a core update completes. The Search Status Dashboard lists each update's start and length in US/Pacific time; for the March 2026 core update it shows 27 Mar 2026 and 12 days, 4 hours. A drop that starts inside such a window is timing evidence, not proof of cause (measuring what a Google update did to your site).
• The days compared. Google's page on comparisons says weekly or monthly granularity neutralizes the day-of-the-week effect. Penlid's two windows are whole weeks, 28 = 4 × 7 and 84 = 12 × 7 (our observation, not a stated reason).

How does Penlid's decay check separate the two?

Penlid's content decay check compares each page's last 28 days with the 84 days before them and subtracts the rest of the site's move over the same dates. The methodology page calls this the critical adjustment: we subtract the site-wide move over the same window. Without it, the page says, on a seasonal site every page can look like it is decaying every January, and a refresh budget goes to pages that are fine.

You can reproduce the idea by hand from a day-by-day export with a Date and a Page column; the tool page says Search Console's own Export button does not produce that shape. These steps are our reading of Penlid's description, not its published formula:

1. Sum clicks per page over identical calendar days, counting a missing day as zero, because, with date as a dimension, Google's API reference says any days without data are omitted from the result list. A page with clicks on 7 days in every 28 would have its last 28 rows reach back 28 ÷ 7 × 28 = 112 days (our arithmetic).
2. Divide the last 28 days' total by 28 and the total for the 84 days before by 84, so the two windows are comparable.
3. Do the same for the rest of the site, with the page left out of its own baseline, so a big page's crash cannot soften the number it is judged against.
4. Subtract the site's change from the page's change; the gap is what to investigate.

What should you do with a page that reads as decaying?

Treat it as a lead to investigate, not a diagnosis, because a page picked for having fallen may partly recover with no change from you (why pages that dropped often recover on their own). Wikipedia defines regression toward the mean as the pattern where, after an extreme sample, the next one is likely to be closer to its mean. Penlid measured the effect on simulated sites, using pages whose last 28 days sat at least one standard deviation below their own average and which were then left completely untouched.

So measuring a refresh of the pages the check flags can report false "improved" results. The methodology page's remedy is to choose which pages to change without looking at how they were trending, such as alternate pages (choosing pages to change without bias). How to tell if a content update worked covers the measurement, and which pages to prune covers pruning, the alternative to a refresh.