Recovery · Jan 15, 2026 · 6 min read · by the Ridgeway Digital team

After a core update hit: how to diagnose before you react

A core update lands, traffic falls, and every instinct screams to do something — rewrite the pages, disavow some links, change everything at once and change it today. That instinct is precisely how a recoverable dip hardens into a permanent loss. The first move after a core update is not action; it's diagnosis. You cannot fix what you haven't correctly identified, and the cost of treating the wrong cause is rarely just wasted effort — it's often making the real problem worse.

Confirm it's actually the update

Before assuming the algorithm is the culprit, line the traffic drop up against the confirmed rollout dates of the update. A decline that visibly started a week before the update began isn't the update's doing at all — it's a separate problem you'd waste a month treating as algorithmic while it quietly continues. Seasonality, a broken analytics tag, a botched migration, a server issue or a sudden SERP-layout change can all masquerade convincingly as core-update damage. We rule each of them out before we accept the headline explanation, because the obvious story is wrong often enough to be worth ten minutes of doubt.

Find the pattern in what dropped

Core updates almost never hit a site evenly, and the real signal lives in which pages lost ground while others held steady:

• By content type. If thin, templated or affiliate-heavy pages fell while genuinely in-depth pages held their positions, the update is rewarding depth and helpfulness — a content-quality signal, not a links problem to be solved with outreach.
• By topic. If one section of the site cratered while the rest was untouched, you may have an expertise, freshness or relevance gap in that specific area that the update has started to penalise.
• By search intent. Sometimes Google simply re-decides what a query deserves — favouring informational results where it used to reward commercial ones, or vice versa. When the intent itself has shifted, no amount of on-page tweaking on your existing page helps; you needed a different kind of page.

The pattern is what points at the cause. Reacting before you've found it means confidently treating a symptom you never actually diagnosed.

What recovery actually looks like

Core-update recovery is slow, and it usually arrives with the next broad update rather than in the weeks between. That timeline is the whole reason patience is a strategy and not just a virtue. Panic-rewriting every affected page in week two, then rewriting them again in week four because nothing has visibly changed, simply churns the site and denies any single fix the time it needs to be read and re-evaluated. We make considered, evidence-led improvements to the pages the diagnosis actually implicated, document exactly what we changed and why, then hold the line and let the next assessment read the improved version.

The uncomfortable honest answer

Sometimes a core update is simply the algorithm correctly deciding that a competitor now deserves the spot more than you do. In those cases the path back isn't a clever trick or a technical fix — it's the unglamorous work of becoming genuinely more useful than the page that replaced you. We'd far rather tell a client that plainly on day one, and plan the real work it implies, than sell them three comfortable months of fixes that were never going to move the needle.