Google Updates

Google ships thousands of ranking changes a year; the named core updates are the tectonic ones. The pattern across a decade is consistent: each update pays down a shortcut the industry had industrialised, and sites built on that shortcut hand back their rankings with interest.

How to read any update

Ask one question: what shortcut did this deprecate?

Panda taxed thin content. Penguin taxed link schemes. The helpful-content systems taxed pages written for search engines rather than readers. The recurring spam updates keep taxing purchased authority, and the local equivalents keep taxing fake reviews and doorway city pages — the local article covers that version.

The through-line is a business model rather than an algorithmic quirk. Google sells answer quality; anyone borrowing rankings against that quality is holding a position the lender periodically forecloses on. Sasta shortcut, mehenga update — same story every cycle, new acronym.

Which means the useful response to an update announcement is not “what changed in the algorithm” but “which of my rankings were borrowed?”

Before: structural immunity

Earn rankings with content that survives being read by a human and quoted by a machine. Those two bars are converging, which is genuinely useful news: the specificity, sources and mechanisms that make a page citable by an answer engine are the same properties that make it survive a helpful-content evaluation. One standard, two payoffs.

Diversify demand. Organic plus direct plus referral plus the channels an update cannot touch. A business whose entire pipeline depends on one channel’s ranking has accepted a single point of failure that it does not control and cannot appeal to. This is the argument for treating marketing as a system rather than as a collection of channel tactics.

Keep the technical layer clean. Updates reprice content, but technical decay makes you fragile — and it means that when volatility hits, you cannot tell the difference between an algorithmic reassessment and your own broken rendering.

After: incident discipline

Confirm it was the update. Compare the drop against your own deployment log before anything else. Self-inflicted drops attributed to updates are extremely common, because the timing is coincidental and the update is a more comfortable explanation than a release. If a deploy landed in the same window, investigate that first.

Measure per page type, not per site. Updates reprice categories of page. Knowing whether your service pages fell while your articles held, or the reverse, tells you which shortcut got deprecated. A site-wide average tells you only that you feel bad.

Wait for the rollout to settle. Core updates take days or weeks to fully deploy, and rankings move in both directions during that period. Conclusions drawn on day three are frequently wrong, and changes made on day three make later attribution impossible.

Then fix the named thing. Not everything. Thrashing — rewriting, restructuring and re-linking simultaneously — destroys your ability to learn what worked. Identify the specific pattern that was repriced, fix that, and accept that recovery typically arrives with the next core update rather than next Tuesday.

The pattern to notice about recoveries

Recoveries are slow and they are not negotiable. The systems that repriced your pages re-evaluate on their own cadence, which means the gap between doing the right work and seeing it reflected can be months.

This has a practical consequence for how you should plan: the work has to be justifiable on its own terms rather than as a recovery bet. Improving a thin page because it should be better is defensible whatever happens next; improving it as a wager on the next update is a position you will abandon in six weeks when nothing has moved.

The uncomfortable summary

If an algorithm update could kill your business, the update was never the risk. The shortcut was.

That reframing is the entire value of this article, and it applies beyond search: any growth channel where you are borrowing legitimacy — bought reviews, bought links, thin content at scale, engagement farming — is a position with a lender who can call it at any time and gives no notice. The businesses that ride out updates calmly are not lucky or better informed. They are the ones who never took the loan.

The incident checklist

When traffic falls, work this order rather than improvising.

Establish the shape. Site-wide or page-type specific? Sudden or gradual? Search-only or across all channels — because a fall in direct traffic too means something non-algorithmic happened.

Rule yourself out. Deployment log against the drop date. Robots.txt, noindex tags, canonical changes, and any rendering change shipped that week. Most falls that get attributed to updates are self-inflicted and fixable in an hour.

Confirm the update. Search Console’s date annotations and the timing of announcements. If there was no update, the previous step is where your answer is.

Segment before concluding. Which page types, which queries, which intents. Two page types moving in opposite directions is common and highly informative — it usually names the deprecated pattern precisely.

Wait for the rollout to settle, then fix the specific pattern rather than everything, and document what you changed and when so that the next core update produces evidence rather than another mystery.

The discipline is deliberately boring, and its main function is preventing the panic response that turns a recoverable dip into an unexplainable one.

What a decade of updates has actually rewarded

Strip out the names and the pattern is short enough to act on.

Specificity over coverage. Pages that answer one question completely have outperformed pages that mention many things, consistently, across every update generation.

Demonstrated experience over described expertise. Content that could only have been written by someone who did the thing has been repriced upward every time thin aggregation was repriced downward.

Earned attention over acquired attention. Links, mentions and citations that someone chose to give have held value while every purchased equivalent has been devalued, repeatedly, with increasing efficiency.

Consistency over campaigns. Sites that published steadily for years hold rankings that campaign-driven sites acquire and lose.

None of that is a tactic, which is precisely why it survives — there is nothing in it for an update to deprecate. The strategy it implies is unfashionable and cheap to state: know something, write it down carefully, and keep doing that.

/blog/technical-seo — keeping the foundation clean · /blog/local-seo — the review and city-page version of the same lesson · /blog/generative-engine-opt — the converging quality bar · /services/marketing — diversified demand as a system

Questions I actually get

How do I know whether an update hit us or we broke something ourselves?

Compare your deployment log against the update dates in Search Console. Self-inflicted drops are extremely common and get blamed on updates because the timing is coincidental — a release that changed routing or rendering will look exactly like an algorithmic hit until someone checks.

How long does recovery take?

Typically until the next core update, because the systems that repriced your pages re-evaluate on their own cadence rather than continuously. That means recovery is measured in months, and thrashing in the interim usually makes diagnosis harder rather than faster.

Should we do anything during the volatility window?

Measure, do not thrash. Wait for the update to settle — usually a couple of weeks — before drawing conclusions, because rankings move in both directions during a rollout. Panic changes made mid-rollout make it impossible to attribute anything afterwards.

Is there any update-proof strategy?

Content that answers a real question specifically, with sources, from someone who has done the thing — plus demand that is not entirely dependent on one channel. That is not a trick; it is the absence of one, which is why it survives.

Do the named updates matter more than the unnamed ones?

The named core updates are the tectonic ones and the easiest to reason about. Thousands of unnamed changes ship yearly and mostly produce noise you should not react to individually.

What is the first thing to check when traffic falls?

Whether it fell for a page type or across the board. Type-specific falls tell you which shortcut got repriced; site-wide falls point at something technical, and technical causes are usually your own doing and quickly fixable.