Google changes its ranking systems several times a year, and the week an update rolls out is the worst possible time to start preparing. By then your rankings are already moving, the trackers are red, and whatever you ship in a panic is being judged against numbers that haven't finished settling. Real preparation is a sequence you run partly before any update and partly during the rollout — and most of it is about not making things worse while you figure out what actually happened.
This is the practical checklist. You will confirm whether an update is even the cause, freeze non-essential changes while it rolls out, capture a clean baseline, run Google's own people-first self-assessment on your weakest pages, diagnose whether you're looking at a quality demotion or an AI answer eating your clicks, harden the technical base, improve rather than delete, and keep publishing on a steady cadence while the system re-evaluates. One thing to hold onto up front: a core update is not a penalty, so there is usually nothing to 'fix' in the punitive sense — the work is to be genuinely more useful than the pages Google is now ranking above you, and that work has to already be aging when the next reassessment comes. For the strategy behind these steps, see the guide on [Google search ranking update preparation](/guides/google-ranking-update-preparation).
The steps
Confirm an update is actually running before you assume anything. Open Google's Search Status Dashboard and check whether a ranking update is live, and note its start and end dates. A traffic swing that doesn't line up with a confirmed update is probably something else — a technical fault, a seasonal shift, or an AI Overview change — and chasing it as if it were an algorithm update wastes the effort. Knowing which event you're in is the first and cheapest preparation step.
Identify whether it's a core update or a spam update. The two demand opposite responses. A core update recalibrates Google's overall assessment of quality and is explicitly not a penalty — pages that drop haven't violated any guideline. A spam update enforces specific policies, and a drop tied to one can mean a real violation. If it's a core update, the response is broad quality improvement; if it's a spam update, audit against the spam policies and remove the violating pattern. Don't apply the core-update playbook to a policy problem.
Freeze non-essential changes until the rollout completes. Positions genuinely fluctuate while an update is live, so editing against them means reacting to noise. Google recommends waiting at least a full week after a core update finishes rolling out before analyzing your site in Search Console. Hold your planned content and structural changes until the Status Dashboard shows the update complete — the discipline to not thrash mid-rollout prevents most self-inflicted damage.
Capture a clean before-and-after baseline. To read what actually moved, compare a full week after the update settled against a full week before it started, per page and per query. Pull impressions, average position, and click-through from Search Console so you can see not just that traffic changed but how. This baseline is what turns the diagnosis in the next step from a guess into a reading.
Diagnose the real cause before touching a single page. Three different events all look like "traffic dropped." A ranking demotion shows the positions themselves falling. An AI Overview or AI Mode absorbing the click shows impressions and position holding while click-through collapses on informational queries. A technical fault or manual action is a separate class again — check the Manual Actions report and your indexing. Refactoring a page for quality won't recover a click that leaked into an AI answer, so name the event before you act.
Run the people-first self-assessment on your weakest pages. Take the pages that dropped most and run Google's self-assessment against them honestly: do they show real experience and expertise, do they satisfy the person who searched, would they survive a trust comparison against the best competing results? Assess the site as a whole, not just individual pages — core updates judge overall quality. This is where you find the genuine gaps between 'covers the topic' and 'is the page a reasonable person would want returned.'
Harden the technical base while it is calm. Resolve crawl errors and indexing problems, keep Core Web Vitals and mobile usability healthy, and confirm your most valuable pages are accessible and correctly structured. None of this is a lever that engineers a mid-rollout recovery — it's hygiene that stops technical debt from being mistaken for a quality problem when the update reassesses what Google can crawl and render.
Improve the content — treat deletion as a last resort. For pages hit by a core update, the fix is to make them genuinely more useful: deepen thin sections, add real experience and evidence, remove filler written only to rank, and update anything stale. Deleting pages wholesale is a blunt instrument that loses equity and rarely addresses the underlying quality signal — reserve it for pages that are truly beyond saving, and improve the rest.
Keep publishing on a steady cadence while you wait. Recovery from a core update often isn't recognized until a later reassessment — a reference range of roughly three to six months, per Google's Gary Illyes in October 2026. You can't rush that with a burst of edits, so the right move is to keep shipping genuinely helpful content on a consistent schedule so the improvements are live and aging when the next update runs. A standing cadence beats a post-update scramble every time.
Reduce how much of your reach depends on Google search. The preparation that outlasts every ranking update is diversification: build and maintain an audience across social platforms, email, and other channels that a search update cannot reshuffle. When a rollout does cost you search traffic, a diversified base means it dents one channel instead of cutting your lifeline. The companion tutorial on [diversifying away from Google search traffic](/how-to/diversify-away-from-google-search-traffic) walks the channel-by-channel build.
Common gotchas
Reacting while the update is still rolling out. Positions move for days to weeks during a rollout; edits made against mid-rollout numbers 'fix' things that were never broken. Wait for the Status Dashboard to show it complete, then wait a full week more.
Treating a core update as a penalty. Pages that drop in a core update haven't violated anything — there's no violation to remove, so a frantic 'cleanup' does nothing. The only response that works is being genuinely more useful than the pages now ranking above you.
Confusing a core update with a spam update. They need opposite responses: broad quality work for one, policy-violation removal for the other. Applying the wrong playbook burns months.
Mistaking AI-driven click loss for a ranking drop. If positions and impressions held but clicks fell on informational queries, an AI answer took the click — refactoring the page for quality won't bring it back. Diagnose the event first.
Deleting pages to 'recover' faster. Wholesale deletion loses equity and rarely fixes the quality signal; improve pages instead and reserve deletion for genuinely unsalvageable ones.
Expecting overnight recovery. Core-update recovery frequently lands only at a later reassessment, often months out. A burst of edits the week after a drop won't accelerate it.
Having no measurement baseline. Without a clean before-and-after in Search Console you can't tell a demotion from a click leak from a technical fault, and every decision after that is a guess.
Where Kompozy fits
The steps above split cleanly into two kinds of work: diagnosis you do once per update, and output you have to sustain for months while the system re-evaluates. The second kind is where ranking-update preparation quietly fails. You can't rush a core update's recovery, so the correct move — keep shipping genuinely helpful content on a steady cadence, and keep a multi-platform audience alive so a search dip doesn't zero your reach — is really a production problem: can you actually publish, every week, through an uncertain three-to-six-month window, without the wait becoming a slow fade in output? That is the problem [Kompozy](/) is built to carry.
Kompozy is an AI content generation and multi-platform publishing engine, not a scheduler bolted onto manual work, which is what makes it useful precisely during the recovery window steps eight and nine describe. From a single source it generates up to 18 channel-native formats — [Persona Shorts](/glossary/persona-shorts) and clipped video, brand-exact carousels, photo and quote posts, text and threads, a blog article, and an email newsletter — so the depth improvements you're making for search double as content for every other channel. One [Persona Brief](/glossary/persona-brief) keeps all of it in the same voice, and [Autopilot](/glossary/autopilot) publishes and schedules across the eight social platforms plus blog and email from one queue, on durable workers that keep running on the weeks you step away. The result is that a steady cadence survives the wait instead of collapsing into it.
The boundary is honest: Kompozy does not rank your pages, undo a demotion, or shorten a core update's recovery — nothing can, and any tool claiming otherwise is selling the panic this page tells you to avoid. What it changes is your ability to keep producing through the volatility, so that when the next reassessment runs, your improvements are live and aging and your audience never depended on a single Google surface in the first place. Starter is $199/mo (5,500 credits) for a solo operator hardening one site; Pro is $499/mo (18,000 credits) for a team running a daily, multi-channel cadence; Enterprise is custom. Preparation for a ranking update is mostly having built the thing in advance — Kompozy is what keeps the building cheap enough to never stop.
Frequently asked questions
Can you prevent a Google core update from hurting your rankings?
Not directly — a core update reassesses the whole web's quality and you can't opt out. What you can do is reduce your exposure: build genuine depth so your pages hold up against the competing results Google is weighing, keep a clean technical base, and diversify your distribution so a search dip doesn't zero your reach. There's no switch to flip the week an update lands; the protection is structural and built in advance.
What should you do the moment you notice a ranking drop during an update?
Confirm on Google's Search Status Dashboard that an update is actually live, then freeze non-essential changes and wait for it to finish rolling out. Positions fluctuate mid-rollout, so reacting immediately means acting on noise. Once it's complete and a week has passed, compare a clean week after against a week before to see what truly moved, and diagnose the cause before editing anything.
How long should you wait before making changes after a core update?
Google recommends waiting at least a full week after the update finishes rolling out before you analyze your site in Search Console. Combined with the rollout itself, which can run one to three weeks, that often means two to four weeks before you have numbers worth acting on. Any edits made earlier are responding to positions that hadn't finished settling.
Is it worth rewriting content immediately after a core update?
Only after you've diagnosed that a genuine quality demotion is the cause, not an AI Overview absorbing clicks or a technical fault. If it is a quality issue, improving the content is the right response — but recovery is typically recognized at a later reassessment, so there's no speed bonus for rushing. Make real improvements, keep them live, and let the next update re-evaluate.
Does diversifying distribution actually help with ranking-update volatility?
It's the one preparation that works regardless of what Google does. On-page quality work makes a single update less likely to hurt and easier to recover from, but if search is most of how people find you, Google's volatility is your volatility. An audience spread across social platforms and email keeps producing reach when rankings move, which turns a core update from an existential event into a bad week on one channel.