Surviving Google Core Updates: Our Recovery Playbook

Every time Google ships a core update, the same pattern plays out. Timelines fill with screenshots of collapsing traffic graphs. Someone announces that SEO is dead. Panic drives a wave of changes that make things worse.

Recovery is possible, but it is slower and less dramatic than the drop, and almost everything people do in the first week is counterproductive. This is the sequence we work through.

First, understand what a core update is not

A core update is not a penalty. There is no manual action, no message in Search Console, nothing you can appeal.

What changes is how Google weighs the signals it was already reading. Pages do not get punished so much as re-sorted. If a competitor's page is now judged a better answer than yours for a query, you fall, and nothing on your page had to get worse for that to happen.

This distinction matters because it determines the fix. You cannot remove a violation, because there was no violation. You have to become the better answer, which takes longer and cannot be rushed.

Step one: change nothing for two weeks

This is the hardest instruction to follow and the most valuable.

Core updates roll out over days or weeks. Rankings move, settle, move again. If you start making changes on day two, you are editing a page while the measurement is still in motion, and when things stabilise you will have no idea which movement came from the update and which came from you.

Worse, panic edits tend to be large. Rewriting a page that was fine, consolidating pages that were working, disavowing links that were helping — these are the changes that turn a recoverable drop into a permanent one.

Use the waiting period to collect data instead.

Step two: find out what actually dropped

Open Search Console and compare the four weeks after the update against the four weeks before. Work at the page level, not the site level. A site-wide traffic figure hides the thing you need to see.

You are looking for the shape of the loss. If a handful of pages lost almost everything while the rest held, the problem is specific to those pages. If every page lost a similar proportion, the issue is site-wide and probably about trust rather than content.

Then look at where the traffic went. Search the queries you lost and study the pages that now outrank you. Not to copy them, but to understand what Google decided they do better. Frequently the answer is visible within a minute of reading: they cover the topic more completely, they are written by someone identifiable with relevant experience, or they are simply more current.

Step three: audit experience, expertise, authority and trust

Core updates consistently reward signals of credibility, and this is where most recoveries are actually won.

Start with authorship. Pages that give advice with no identifiable author, or a byline with no evidence the person has done the thing they are advising on, are increasingly difficult to rank in competitive areas. Add real bios with real credentials, and make them verifiable.

Look at sourcing. Claims that would make a reader ask "according to whom?" need an answer. Statistics without attribution are a liability, not a credibility signal.

Check currency. An article about a platform that has changed twice since publication is wrong, regardless of how well it is written. Dates matter in areas that move.

Then look for thin content honestly. Most sites carry a tail of pages published to target a keyword that never earned a visit. They dilute the site's overall quality signal. Removing them or merging them into something substantial is one of the few changes that can help across the whole domain.

Step four: review the link profile

Links that looked safe for years can become liabilities when the bar moves, particularly links from sites that were themselves hit by the update.

Export the full backlink profile and look for patterns rather than individual links. Clusters of links from the same network, sudden historical spikes from unrelated foreign-language sites, exact-match anchors in volumes that could not have happened naturally.

Be conservative with the disavow file. It is a blunt instrument and over-using it removes links that were helping you. Disavow what is clearly toxic and leave the ambiguous cases alone.

Step five: consolidate instead of multiplying

When a site has six thin articles circling the same topic, they compete with each other and none of them is authoritative.

Merging them into one comprehensive page, redirecting the old URLs, and letting the combined page inherit the accumulated signals is among the most reliable recovery tactics available. It is also counterintuitive, because the instinct after losing traffic is to publish more, and publishing more thin pages deepens exactly the problem that caused the drop.

What the timeline actually looks like

Recovery rarely arrives as a single moment. More often, partial improvement appears over several weeks, then a larger correction at the next core update, which may be three to six months away.

That delay is the hardest part to accept, and it causes the most damage. Teams make changes, see nothing within a month, conclude the changes failed, and reverse them — removing the improvements just before the update that would have recognised them.

Make the changes. Document what you changed and when. Then let them sit long enough to be evaluated by the system that will evaluate them.

What not to do

Do not rewrite the entire site at once. If everything changes, you learn nothing from the result.

Do not chase the update commentary published in the first week. The early theories are usually wrong, and acting on them means acting on a guess.

Do not buy links to recover. Adding an artificial signal to a site that was just judged on quality is the fastest way to turn a ranking drop into a manual action.

Do not delete pages reflexively. Check whether they have links or conversions first. Some of the quietest pages are load-bearing.

The underlying principle

Every core update moves in the same direction over time: toward content written by people who know the subject, for readers who have a real question, on sites that have earned the right to answer it.

Sites built that way move less during updates, and recover faster when they do move. That is not a recovery tactic so much as an argument for not needing one.