Core Updates Are Not Updates: Google’s Shift to Continuous Systems

Every core update produces the same cycle. A rollout is announced, forums fill with people comparing losses, theories circulate about what the update targeted, and a month later somebody publishes a recovery checklist. The cycle repeats because the underlying model is wrong.

The model most people hold is legislative: rules existed, rules changed, comply with the new rules. That is not what happens, and the difference is not semantic — it changes what you should do afterwards.

Systems versus updates, which Google separates and the industry does not

Google publishes a guide to its ranking systems that draws a distinction almost nobody carries into practice.

	System	Update
What it is	A component that runs continuously	A discrete change or refresh event
Duration	Always on	Rolls out over days or weeks, then completes
Examples	Spam detection, helpful content assessment, passage ranking, neural matching	A named core update, a spam update
How you experience it	Invisible. It is the baseline	Visible movement in your data

That retirement is the tell. When a function moves from “update” to “system,” it stops being an event you can respond to and becomes a condition you exist within. There is no next Penguin to recover from because Penguin is not a thing that happens any more — it is part of how ranking works all the time.

The same absorption happened with the helpful content system, which was folded into core ranking rather than continuing as a separate periodic update. People still talk about “the helpful content update” as an event to recover from. It is not an event.

What a core update actually does

Think of it as re-scoring rather than rule-changing. The evaluation criteria are broadly the same; the evaluation itself is redone across an enormous corpus, and relative positions shift.

This produces three outcomes that look identical in your analytics and have completely different causes.

What happened	Cause	What you should do
Your assessment worsened	Something about your content is judged less well than before	Genuine content work. The only case where a checklist applies
Someone else’s improved	A competitor got better, or a new entrant appeared	Nothing about your site is wrong. You were outcompeted
The query interpretation shifted	Google reassessed what users want from that query	Your page may no longer match the intent. Different problem entirely

Penalty and reassessment are different things

The word “penalty” gets applied to algorithmic movement constantly and it is wrong in a way that misdirects the response.

• A manual action is a penalty. A human reviewer determined a violation. It appears in Search Console. There is a reconsideration process. It is adversarial and it is documented.
• Algorithmic reassessment is not a penalty. Nobody looked at your site. No notification exists because there is nothing to notify — a score changed. There is no reconsideration process because there is no decision to reconsider.

This matters practically. People spend weeks looking for the violation they must have committed, because “penalty” implies transgression. Frequently there is none. Being ranked lower than you were is not evidence of wrongdoing; it is evidence of a comparison that came out differently.

Why “recovery” takes so long, and often does not happen

Three structural reasons recovery is slow when it happens at all:

1. Assessments are refreshed on their own cadence. Changes you make must be crawled, evaluated, and then reflected — which for broad quality assessment may only fully register at a subsequent reassessment.
2. Relative position requires relative improvement. If you improve by ten and the competitive set improves by twelve, you continue to fall while genuinely getting better. Absolute improvement is not the unit.
3. Some assessments appear to operate site-wide. Which means a large body of weak pages can weigh on strong ones, and improving one page does not lift the aggregate. This is the argument for pruning, and it is frequently applied too aggressively by people deleting pages that were quietly earning citations.

A sane post-update process

What I would actually do, in order, and the first two steps are the ones people skip.

1. Wait for the rollout to complete. Rollouts run over weeks and rankings fluctuate throughout. Acting on day three means responding to an intermediate state. This is the single most common error and it produces changes that then have to be undone.
2. Look at the results pages, not your site. For your most affected queries: who is there now, who left, and has the result type changed? If the page composition shifted from guides to product pages, you have an intent reclassification and no content edit fixes it.
3. Segment the loss. Site-wide, or specific sections? By query type? By intent? A uniform drop suggests a site-level assessment; a concentrated one suggests query interpretation or a specific competitor.
4. Read the pages that replaced you, honestly. Not to find their tricks. To determine whether they are actually better for that query. Frequently they are, and that is the finding.
5. Only then consider content work, and target the specific gap you identified rather than a generic quality checklist.
6. Expect months, and expect it to require the next reassessment. Set that expectation before you start, not when someone asks in week four.

The continuous-systems reality

The deeper shift is that discrete, nameable updates are becoming a smaller part of the picture. Ranking is increasingly the output of many continuously-operating systems — neural matching, passage-level assessment, spam detection, query understanding — each evolving on its own schedule, most of it unannounced.

Which means the mental model of “stability punctuated by updates” is obsolete. The accurate model is continuous drift, occasionally punctuated by a reassessment large enough to be worth naming.

Two consequences I would act on:

• Stop treating announced updates as the unit of analysis. Movement between updates is not noise, it is the system working. Measure trends over quarters, not deltas around events.
• Stop optimising for the last update. By the time consensus forms about what an update rewarded, the systems have moved. Chasing the previous reassessment is how sites end up permanently one cycle behind.

Why the industry resists this framing

I want to be direct about the incentive, because it explains why the wrong model persists despite Google explaining the right one repeatedly.

“Google changed the rules and we know the new rules” is sellable. “You were reassessed against unchanged criteria and came out lower, possibly because a competitor improved” is not. The first is a service. The second is a diagnosis with no product attached.

So every update generates a wave of analysis identifying what it targeted, usually within days, usually from correlational data across a sample of sites with no controls. Those analyses are read as findings. They are hypotheses generated from noise, and the honest version — that broad reassessment does not have a single target — cannot be packaged.

What survives

If updates are reassessments rather than rule changes, the strategy that follows is unglamorous and I think correct: build the thing that scores well under any reasonable assessment, and stop trying to identify the current one.

That is not a platitude about quality content. It is a specific claim about volatility. Sites that move violently with every update are usually sites optimised to a particular configuration of signals. Sites that drift gently are usually sites where the signals are incidental to something genuinely useful. The second group is not immune, and it is legible across reassessments in a way the first is not.

The same logic now applies to retrieval systems, which change more often and announce even less. The habits transfer, and I have set out the retrieval version in how retrieval actually selects your page and why AI visibility tools disagree. The longer pattern this sits inside — which techniques survive a reassessment and which never do — is in what twenty years of algorithm change taught me about what survives.

Frequently asked questions