Working like a practitioner · module 10 of 13 · 7 min read
Algorithm updates, and how to respond
A core update is rolling out. What is the correct thing to do?
- core update
- rollout window
- confirmed vs unconfirmed
- recovery timeline
- documented vs actionable
Read first: Diagnosing a traffic drop
Google ships ranking changes constantly and names a few of them. Core updates are broad re-assessments of relevance and quality that roll out over one to several weeks. Around them the industry generates enormous noise, most of which is not actionable.
What a core update is not
It is not a penalty. Nothing was done to your site. A core update re-evaluates everything, and if others are judged to serve the query better, you move down without having got worse. Google is explicit that there may be nothing to fix.
Reading the rollout
Announced updates have a start and a completion date, both posted on Google's Search status dashboard and ranking updates page. Movement during the rollout is unstable — sites commonly drop, recover, drop again. Judging your position before the rollout completes is reading noise. Wait for completion, then compare a stable week against a stable week.
Confirmed versus unconfirmed
Practitioners detect volatility before Google confirms anything, and sometimes Google never confirms. Unconfirmed volatility is real but unattributable — which means it cannot be responded to specifically.
There is a useful triage rule from Google's own side. In August 2026 John Mueller made the distinction explicit: Google announces updates primarily to give site owners transparency, and when it publishes a blog post, policy change or documentation update alongside one, that is the signal there is something actionable. Volatility with no accompanying documentation is not something you can act on directly.
How to respond
- Wait for the rollout to complete. Then measure.
- Segment. Which sections and query types moved? A uniform drop and a section-specific drop have different explanations.
- Read what the winners have. Not to copy, but to understand what the systems now consider a better answer.
- Make substantial changes, not cosmetic ones. Core update recovery comes from being genuinely better, and typically shows up at the next update, not immediately.
- Change one thing at a time if you want to learn anything.
What trips people up
- Panic-rewriting everything mid-rollout. You destroy your ability to attribute anything and often make things worse.
- Expecting fast recovery. Recovery commonly waits for the next core update.
- Treating every tracker's volatility spike as an update. Those tools measure movement, not causes.
You have got this when
An update is announced and your plan is "wait, then segment, then read the winners" — and you can explain to a stakeholder why doing nothing for two weeks is the correct action.
Go to the source
What has changed since
Stories from the briefs that touch this module.