Core Update Recovery: The Exact Process, Step by Step (2026)

A core update has hit your site and the traffic is down. The worst response is also the most common one: change everything at once, quickly, and hope something sticks. That approach fails for a simple reason — when ten things change in the same week, you never learn which one mattered, and you cannot tell whether the site is recovering or still falling.

Recovery is a process with an order. Each step answers a question the next step depends on. Worked in sequence, it turns a frightening drop into a diagnosable problem with a measurable fix. Worked out of order, it is guesswork with a deadline.

Google ran core updates in March and May 2026, and the pattern after each one is the same: the sites that recover are the ones that diagnose before they change anything, fix in order of impact, and then wait long enough to measure properly. The 2026 recovery playbooks agree on that sequence, and on one uncomfortable fact — recovery is measured in months, and it often only becomes visible when a later core update rolls out. That is the timeline to plan around, not a promise anyone can make about your site.

Before step one: let the rollout finish

Do not start recovery work while the update is still rolling out. Rankings move daily during a rollout, and a page that looks lost on Tuesday can look different by Friday for reasons that have nothing to do with your site.

Wait until the rollout is confirmed complete, then compare two full weeks before the drop against two full weeks after it. That comparison — not a single day’s numbers — is the baseline every later step is judged against. If you change things mid-rollout, you will spend the next month arguing about whether the update or your changes caused what you see.

Step 1: Confirm the update caused it

A traffic drop that coincides with a core update is not proof the update caused it. Confirm it before spending anything on recovery.

• Match the dates. The drop should start when the rollout started, not a week earlier. An earlier start points at something else — a technical change, a lost link, a page that went down.
• Segment before you conclude. Split the loss by page type and query group. A core update usually hits some sections hard and leaves others untouched. If every page fell by the same amount on the same day, suspect a technical cause first.
• Rule out the mechanical causes. Check indexation, crawl errors, accidental noindex tags, and pages that stopped rendering. These are quick checks, and they are the cheapest fixes in recovery — if one of them is the cause, you do not have a core update problem at all.
• Check for the AI Overview pattern. If impressions held steady while clicks fell, the ranking may be intact and the click may have been taken on the results page instead. That is a different problem with a different fix, and it has its own test.

If the diagnosis points elsewhere, stop here. Recovery work applied to the wrong problem is how sites get worse while trying to get better.

Step 2: Audit technical health and revenue, in that order

With the cause confirmed, audit the site the way a search engine actually experiences it — not the way it looks in a dashboard.

Start with the technical foundation: can the pages be crawled, rendered, and indexed without friction? Look for pages that return errors, pages blocked or orphaned from internal linking, duplicate or near-duplicate pages competing with each other, and slow or broken experiences on the pages that lost the most traffic. Fix what blocks visibility before touching a single sentence of content — a page that cannot be reached properly cannot recover, however good its writing becomes.

Then check revenue, not just traffic. While traffic is down, the traffic that remains has to work harder. Which pages still convert, and what do visitors do on the pages that lost clicks? If a page lost traffic but still brings enquiries, protect it first. Recovery is not only about getting visits back; it is about making sure the visits you still have are worth more. That is the same order used in a full growth engagement — technical health first, then conversion — because it protects the business while the longer recovery work runs.

Step 3: Judge the content honestly

Core updates reward pages that genuinely serve the searcher. That is a hard standard to apply to your own work, so apply it page by page, not site-wide.

For each page that lost traffic, ask three questions:

• Does this page answer its query better than the pages now ranking above it? Not longer — better. Clearer, more complete, more current, easier to act on.
• Is it thin, outdated, or overlapping with another page on the same site? Thin pages, stale advice, and two pages chasing the same query are the usual suspects. The fix is rarely to delete in bulk: merge overlapping pages into the stronger one, refresh outdated pages with current information, and only remove a page when it serves no query and no visitor.
• Would a visitor trust this page enough to act on it? Specific evidence, named sources, dates, and real examples build that trust. Vague claims and generic advice do not.

Do this for the pages that lost the most traffic first. A site-wide rewrite is the most expensive way to fix a problem that lives on twenty pages.

Step 4: Rebuild topical authority around what remains

Once the weak pages are repaired or merged, rebuild the structure around them. A single strong page rarely recovers alone; it recovers as part of a cluster that shows the site covers the topic properly.

That means filling the gaps the audit exposed — the related questions the site never answered, the sub-topics its competitors cover and it does not — and linking the cluster together so both visitors and search engines can follow the thread from the main page to the supporting ones. Internal links should reflect how the topic actually works, not how the menu is organised.

This is also where the AI search picture matters. The same clear, citable, answer-first passages that help a page rank also make it usable as a source when an AI Overview draws on it. Write for the searcher first, but write in a way that can be quoted: direct answers, attributed figures, and definitions that stand on their own.

Step 5: Measure, then wait — properly

This is the step most recoveries fail, because it feels like doing nothing. It is not. It is the only way to know whether steps one to four worked.

Measure the same way you measured at the start: two-week periods, query by query, page by page. Compare the pages you fixed against the pages you did not touch. If the fixed pages are stabilising while the untouched ones keep falling, the work is having an effect even if the headline number has not moved yet.

Do not judge the result after a week. Core update recovery is measured over weeks and months, and the clearest signal often arrives only when the next core update rolls out and the site is reassessed against the new baseline. That waiting period is not wasted time — it is the measurement period. Changing the pages again halfway through it restarts the clock and destroys the evidence.

Keep one log through all of it: what changed, on which pages, on which date. Without that log, you cannot connect a recovery — or a further drop — to anything you did.

What not to do

• Do not rewrite pages that still rank. A rewrite can break the ranking that remains.
• Do not delete pages in bulk because they lost traffic. Deleting a source removes any chance it recovers, and it can break the internal links that hold a cluster together.
• Do not buy links or add content for volume while recovering. Both add noise to the measurement and risk a second problem on top of the first.
• Do not chase the update by copying whatever the new top-ranking pages do. Imitating a competitor’s format is not the same as serving your searcher better.
• Do not declare recovery — or failure — on a single good or bad week. Recovery is a trend across weeks, confirmed at the next update, not a daily number.

The answer in one paragraph

Let the rollout finish, confirm the update actually caused the drop, fix technical health first, then judge the content page by page, rebuild the topic around what remains, and measure for weeks before touching anything again. Each step depends on the one before it, which is why the order matters more than the speed. If the diagnosis is unclear — the loss spread unevenly, some sections recovering while others keep falling, or the pattern pointing in two directions at once — that is the right moment for a second pair of eyes on the actual data: Search Console, analytics, and the affected pages together, not a generic checklist.

Next step: Request a free written SEO audit of your site — a concise written report on what the data actually shows, which step of this process your site needs first, and what to fix before the next core update: Free SEO Audit. You can also see how this recovery process fits into a full growth engagement on the Services & Pricing page.