Content decay vs a Google algorithm update

Content decay and a Google algorithm update both show up as a falling line in Search Console, but the shapes differ. Decay is a slow slide on a single page over weeks. An update hit is a sudden step on a date Google published, usually across many pages at once. Read three things off the curve, the slope, the timing, and the breadth, and the shape tells you which one you have.

This is the companion to detecting content decay: that guide finds the sliding pages and separates real decay from a page merely losing the click to an AI Overview. This one answers the question that comes first, is it even decay, or did a Google update move the whole site on one date? Get that wrong and you will refresh a page that a site-wide re-scoring will undo, or wait out an update when the truth was one page quietly rotting.

TL;DR:

• Decay is a slow slide on one page over weeks. An update hit is a sharp step on a date Google published, usually across many pages at once.
• Three reads separate them: the slope (gradual slide vs cliff), the timing (does the drop line up with a confirmed update), and the breadth (one page vs the whole site).
• Google lists every core and spam update with its start date and rollout length on the Search Status Dashboard. Check your cliff against that list before blaming your content, and treat a date match as a hint, not proof.
• The fix differs. An update wants better relative quality and patience for the next refresh, not a quick fix. Decay wants the refresh, merge, or retire call.

Is it content decay or a Google update?

Read three things off the curve: slope, timing, and breadth. Content decay slides down gradually on a single page, tied to no particular date. An algorithm-update hit drops sharply, lines up with a confirmed update rollout, and usually moves many pages together. Gradual and lonely means decay. Sudden, dated, and site-wide means an update.

The three reads, in the order worth checking:

• Slope: a gradual slide or a sharp step? Decay is a long, quiet decline across weeks or months. An update hit is a step change, a visible before-and-after that lands over a few days.
• Timing: does the drop have a date? Decay has no anchor date, it just drifts. An update hit starts on or near a rollout Google announced, so the fall has a timestamp you can look up.
• Breadth: one page or the whole site? Decay is page-specific, one URL bleeding while its neighbors hold. An update usually moves a whole group of pages, or the entire site, at once.

No single read is decisive on its own. Together they converge fast: a lonely, undated, gradual decline is decay, and a shared, dated, sharp one is an update.

What does content decay look like in your data?

Content decay is a slow, steady fall in one page's clicks after it matured, with no date attached. Impressions usually soften before clicks do, and the page's average position drifts from the top of page one toward page two. The defining feature is that the decline is lonely: other pages on the site hold steady while this one slips.

It happens because the world moved while the page stood still. A competitor went deeper, the search intent shifted, freshness faded on a query where recency matters. Because the fall is gradual, you cannot see it in a snapshot, you need two comparable windows or a rolling one, read at the page level, the honest source for volume and change. One limit rides on the timeline. Search Console keeps only 16 months, so a slide that began three years ago can look like it started at the edge of your window, and an old, forgotten cliff can pass for decay simply because the drop happened before your data begins.

What does an algorithm-update hit look like?

An algorithm-update hit is a sharp drop that begins on or near a date Google published, and it typically moves many pages at once rather than one. Rankings step down across the rollout window, not in a single instant, and the pages that fell were not breaking any rule. They were re-scored against everyone else competing for the same searches.

Google is explicit that core updates are broad and don't target individual pages. A page that dropped was not penalized, it was re-ranked relative to the pages around it, the way a top-20 list reshuffles when strong new entries appear, not because yours got worse. Two practical consequences follow. First, the drop is rarely one clean vertical line: core updates roll out over days, sometimes two to three weeks (the December 2025 core update ran eighteen days, the May 2026 core update about twelve), and Google lists each one with its dates, so you see a staircase down over the rollout, not a single cliff. Second, because it hits broadly, the quickest confirmation is whether several of your pages moved on the same dates.

How do you line the drop up against a confirmed update?

Google lists every confirmed ranking update, core and spam, with its start date and rollout length on the Search Status Dashboard. Put your page's drop next to that list. If the cliff starts inside a published rollout window and several pages moved together, an update is the likely cause. If the date matches nothing on the list, decay is the better bet.

The check is quick. Note the date your clicks or impressions stepped down, then open the Search Status Dashboard and see whether a core or spam update was rolling out in that window. Google gives you both the start date and the duration, so you match against a range, not a single day. A match is a strong hint, and it is only a hint. A drop can land on an update date by coincidence, a tracking change or a site migration can mimic the same sharp shape, and correlation is not proof of cause. Treat the date as evidence that narrows the diagnosis, not a verdict that closes it.

One page or the whole site: what does breadth tell you?

Breadth decides your next move. If one page is sliding while the rest hold steady, treat it as decay and act on that page now. If many pages stepped down together on an update date, treat it as site-wide and reassess broadly before touching anything, because a single-page fix cannot answer a site-wide re-scoring.

This is the read that changes what you do with your afternoon. A lonely decline is a page-level problem with a page-level answer: refresh it, merge it, or let it go. A synchronized, dated drop across many pages is a site-level signal, and the honest response is to step back and ask what Google re-scored, not to rewrite one title and hope. Sorting your pages by clicks lost, then checking whether the losers share a date, is the fastest way to tell a handful of independent decays apart from one update that moved everything at once.

What should you do differently for each?

For decay, work the page: decide between a refresh, a merge, and retiring it, off the signals in your own data. For an update, resist the quick fix. Google says there is no single element to change, and a fuller recovery often arrives with a later core update or refresh rather than between them. Improve the page's real quality against what now outranks it, then give it time.

The decay path is a concrete decision, and how to revive a decaying page walks it: refresh when the page still ranks but has aged, consolidate when your own URLs compete, retire when the demand left. The update path is more patient. Google's own advice is to avoid quick-fix changes and it warns there is no guarantee a given edit moves anything, so the durable move is to make the content genuinely better against what beat it, then wait. You do not have to wait for a major update to see improvement, but a full recovery often lands with the next core update. And one limit holds across both cases: Search Console stops at the click. It shows a page lost traffic and which shape the loss took. Whether the visitors you kept convert is a separate measurement on a different machine.

Telling decay from an update without watching every date

Done by hand, this is bookkeeping: note each page's drop date, cross-check it against the update calendar, and decide whether the fall is lonely or shared, for every page that slips. It is exactly the weekly discipline that gets skipped until a quiet slide has already cost you months, or until you have spent an afternoon refreshing a page that an update, not the content, moved.

That is the work QueryScope is built to hold. It reads your real Search Console data in the terminal, keeps a daily history so the 16-month wall never closes on your baseline, and surfaces the pages actually sliding so a page-level decay does not hide inside a site-wide total, or the reverse. If you want the one-line definition behind any term first, the Search Console glossary covers clicks, impressions, and position, each with the caveat that comes with it.

Sources

• Google Search Central, Google Search's core updates and your website (core updates are "broad in nature, and don't target specific sites or individual web pages"; avoid "quick fix" changes; you don't have to wait for a major core update to see improvement, but a fuller recovery often aligns with one).
• Google Search Status Dashboard, ranking updates history (confirmed core and spam updates with rollout start dates and durations: the December 2025 core update ran 18 days, the May 2026 core update about 12, so an update is a staircase over its rollout, not a single-day cliff).
• Google Search Central, A deep dive into Search Console performance data filtering and limits (page-level data is the honest source for volume and change, because rare queries are dropped from the query table while their clicks stay counted in the totals).
• Google Search Console Help, Performance report data retention (Search Console retains performance data for 16 months with no historical backfill, so the start of an old, slow slide can fall outside the window).