A core update recalibrates how Google evaluates content quality across the whole index. It is not a penalty, which matters more than it sounds. Nothing was done to you. Other content was reassessed as better, and your relative position moved as a consequence.
The cadence has changed and most guidance has not caught up. Core updates now run roughly every three to four months rather than the historical twice yearly pattern. In 2025 there were three, in March, June, and December. In 2026 there have already been core updates in March, running March 27 to April 8, and May, running May 21 to June 2 and completing in just under twelve days.
Core Updates and Spam Updates Are Different Problems
Conflating them is the most expensive diagnostic mistake available, because the fixes have nothing in common.
A core update adjusts the ranking formula generally. There is no violation to correct. Recovery means genuinely improving content quality relative to what else is available.
A spam update enforces against specific policy violations. The March 2026 spam update expanded enforcement across scaled content abuse, expired domain manipulation, and site reputation abuse. Recovery means removing the violation.
Sites can be hit by both in quick succession, which happened in March 2026 when the spam update finished shortly before the core update began. A site that lost traffic in that window has to establish which one caused it before doing anything, because fixing thin content when the problem was a reputation abuse violation wastes months.
Establish Whether It Was an Update at All
Before any content work, confirm the timing lines up. Open Search Console, compare impressions, clicks, and average position for the fourteen days before and after a known update window, and check the drop against the Google Search Status Dashboard, which is the official record.
Where the fall began on a date with no update running, keep debugging elsewhere. Tracking changes, a migration, a robots.txt error, or a rendering regression all produce traffic drops that look algorithmic and are not, and the technical audit guide covers finding those.
Take a Search Console and analytics snapshot immediately when you notice a drop. That baseline becomes your only clean reference point, and it is unrecoverable once the sixteen month window rolls past it.
Diagnose at Segment Level, Not Site Level
A site wide traffic figure tells you almost nothing about what happened. The useful analysis is finding which parts of the site fell and which held.
Filter Search Console by page path and compare sections. A drop concentrated in one content type points at something specific about that content. A drop distributed evenly points at something site wide.
Then filter by query. Losing informational queries while commercial queries held is a different problem than the reverse. Losing queries where an AI Overview now appears is potentially not an update effect at all, which is the distinction covered in the measurement guide.
Segment by device too, since mobile and desktop can diverge, per the mobile SEO guide.
What Actually Recovers, According to People Tracking It
Lily Ray's 2026 commentary identified four recurring patterns among sites that gained ground after core updates: stronger E-E-A-T signals, cleaner entity clusters, better engagement metrics, and content answering the sub questions around a topic rather than only the head term.
That maps onto things covered elsewhere in this series. Named authors with verifiable credentials, per the author entity guide. Coherent topic clusters rather than scattered posts, per the content strategy guide. Content that resolves a situation rather than defining a term.
The common thread is that these are structural improvements rather than signals. Which brings up the thing Google says explicitly and most recovery advice ignores.
Do Not Make Changes to Signal Quality
Google's documentation is direct that surface changes intended to signal quality are not what its systems reward. Adding a byline to content with no actual named author. Inserting a publication date where none existed. Adding a word count badge.
These are attempts to look like the sites that recovered rather than to be one. They are also the most commonly recommended quick fixes after an update, because they are cheap and visible.
My position: if a change would not improve the page for a reader who knows the subject, it will not improve the page for the algorithm either. The changes that work are the ones that make the content genuinely better, which is expensive and slow and the reason recovery takes months.
The Timeline Is Longer Than Anyone Wants
Google's own documentation states that some changes can take effect in days and it could take several months for its systems to confirm a site is producing quality content overall.
Practitioner consensus puts full recovery at three to six months, frequently requiring the next core update to register. A realistic plan does rebuild work in the first ninety days and expects observed recovery during one of the following one or two rollouts.
Google has also stated plainly that not all sites recover. That is worth saying to a stakeholder before starting rather than after six months of work.
Do Not Make Major Changes During a Rollout
Core updates typically run twelve to twenty days. Rankings fluctuate throughout and settle afterward.
Making significant changes mid rollout adds noise to data you will need for diagnosis, and it means you cannot attribute any subsequent movement to either the update or your changes.
Wait for completion, then take a clean reading, then act. The instinct to do something immediately is strong and it costs you the ability to know what happened.
Content Pruning Is Frequently Part of Recovery
One documented commercial case involved a site losing 41 percent of organic traffic across four consecutive updates before recovering during a later rollout, after cutting 38 percent of its editorial content.
That pattern recurs. Sites carrying large volumes of thin, outdated, or overlapping content improve by removing it rather than by adding more, which is the logic covered in the pruning guide.
The judgement is which content to cut, and traffic alone is a poor guide. A page with low traffic that genuinely serves a narrow query is different from a page nobody reads because it says nothing.
Technical Fixes Rarely Resolve a Core Update Hit
This is where recovery budgets get wasted most predictably. A site drops, an agency runs a technical audit, and three months of work goes into crawl errors and page speed while the thin content that caused the drop sits untouched.
Google's guidance is explicit that core updates target content quality rather than crawl errors. Technical health is a prerequisite for ranking at all and it is not what a core update reassessed.
Fix technical problems because they are problems. Do not expect them to recover a core update loss.
Keep a Recovery Log
Record what changed, on which pages, and when. Set a reminder for the next expected update window, which on the current cadence is roughly quarterly.
When the next update runs, stop changing things and compare Search Console before and after. Without a log you will have made dozens of changes across several months and be unable to say which mattered.
Daily rank checking during this period produces anxiety rather than information. Weekly is enough, and monthly is sufficient for anything other than an active recovery.
What This Has to Do With AI Visibility
The quality signals core updates reward, genuine expertise, original material, and clear topical structure, are substantially the same signals that determine whether AI systems cite content. The non-commodity content guide covers that overlap.
The NotionCue Citation Tracker is useful during a recovery period as a second reading. Where classic rankings fell and citation presence held, the content is still being treated as a credible source, which suggests the problem is competitive rather than quality based. Where both fell together, that is a stronger signal the content itself is the issue.
Start your free NotionCue trial and take a citation baseline alongside your Search Console snapshot. Two independent readings diagnose better than one.
Before rewriting anything after an update, spend a day establishing which segment of the site fell and which queries were lost. Most recovery work fails because it started before that question was answered, and the wrong fix costs a full update cycle.
Common Questions
Can I recover before the next core update?
Partially. Some recovery happens through smaller unannounced adjustments between major rollouts. Full recovery frequently requires the next broad update to register the improvements.
Should I delete a site that has been hit repeatedly and start over?
Almost never. Existing authority is an asset even when rankings dropped, and a new domain starts from zero with no history at all. Rebuilding on the existing domain is slower to feel and faster to work.
How do I know whether a drop is an update or AI Overviews taking my clicks?
Check impressions against clicks. An update typically reduces impressions because you rank lower. AI Overview displacement typically holds impressions while clicks fall, since you still appear and fewer people click.