What a core update actually changes
Google runs several broad core updates a year, announces each one on the Search Status Dashboard, and gives a start and end date. During the rollout, its ranking systems re-evaluate which pages best satisfy each query.
The framing that helps: think of a list of the 100 best restaurants in your city. When the 2026 list comes out, a restaurant that fell from 30 to 60 didn't get worse. Other restaurants got better, or the criteria shifted. Google uses almost exactly this analogy in its own guidance, and it's the most useful thing they've published on the subject.
One structural change is worth knowing: the separate helpful content system was folded into the core ranking systems in the March 2024 core update. There's no standalone content classifier to escape any more — content quality assessment is inside the core algorithm, which is why core updates now hit content-heavy sites harder than they used to.
Confirming it was the update and not you
Half the traffic drops blamed on core updates were caused by the site itself. Rule those out first, in this order, using dated data rather than memory.
- Check the dates line up. Open Search Console's Performance report, switch to a daily view, and mark the announced rollout start. A decline that began four days early is your deploy, not Google's.
- Check Manual Actions. A human penalty appears there and nowhere else. It's a different problem with a different fix — see Google Search Console for where to look.
- Check indexing. A drop in clicks with a matching drop in impressions and indexed pages is usually a
noindexshipped by accident or a robots.txt change, not an algorithm. - Check your own calendar. Migrations, template changes, plugin updates, expired SSL, a CDN change — anything shipped within a fortnight either side is a suspect.
- Check seasonality. Compare the same weeks last year. Indian B2B traffic collapses in late December every year and it has nothing to do with Google.
The two-week protocol
The instinct is to do something immediately. Resist it. Rankings genuinely fluctuate mid-rollout, and a page that recovers on day twelve will be deleted on day four by a panicking team.
Week one — do nothing but measure. Export daily Search Console data. Freeze a before-and-after snapshot of your top 200 URLs. Ship no content changes you can't undo.
Week two, once the rollout closes — segment the loss. This is the part most people skip, and it's where the answer lives. Split the drop by page type, by query intent and by whether the query now triggers an AI Overview. The pattern usually names the cause on its own.
Only then do you change anything, and only where the pattern points.
| What dropped | Likely cause |
|---|---|
| Only informational articles | Content quality, or answers absorbed by AI Overviews |
| Everything, roughly evenly | A site-level quality or authority re-assessment |
| One template or one folder | A technical or content issue local to that section |
| Pages that ranked above stronger sites | Google corrected an over-ranking; those were borrowed positions |
| Nothing dropped, but nothing grew | Competitors improved. Same result, different fix |
Core update, spam update, or manual action?
Three different events get called the same thing in client emails. They have different causes, different evidence and different recovery paths.
| Event | How you know | Typical recovery |
|---|---|---|
| Core update | Announced dates, broad movement, nothing in Manual Actions | Improve the content; recovery often lands with a later core update |
| Spam update | Announced separately, targets specific tactics like bought links or scaled content | Remove or disavow the tactic, then wait for re-processing |
| Manual action | A notice in Search Console. Unambiguous | Fix the violation, file a reconsideration request |
| Site issue | No announcement, drop starts on your deploy date | Fix the deploy. Usually the fastest recovery of the four |
Recovery timelines, without the comfort
Google has said that recovery from a core update can happen between updates, but in practice most substantial recoveries land when a later core update re-assesses the site. Since there are only a few a year, that puts realistic recovery at months, not weeks — and that's assuming you actually fixed the underlying problem rather than reshuffling headings.
Some sites never recover fully, and it's dishonest to pretend otherwise. Sites that ranked on thin content, aggregated affiliate pages or bought authority were often holding positions the algorithm never intended to give them. The update didn't take something away; it stopped an error.
The uncomfortable version: if your traffic came from publishing large volumes of adequate content around keywords you had no genuine claim to, recovery means building a real claim. That's a rebuild, not a fix, and it costs what a rebuild costs.