Was I Hit by a Google Core Update?

Check Search Console for a site-wide cliff on a single date, then compare that date against Google's confirmed core update rollouts. A core update moves many pages and queries at once, over a rollout window of one to two weeks. A drop confined to a few pages, or starting on a date with no announced update, is something else.

The three questions that settle it

Most of the diagnosis is three checks, in this order. Do them before you form a theory, because a theory formed first tends to survive evidence it should not.

Is the drop site-wide or page-specific? Core updates reassess broad swathes of a site. If two pages fell and 200 did not, an update is the least likely explanation.
Does the date line up with a confirmed rollout? Google publishes its ranking release history, which gives start and end dates for each core update. No matching date means no core update.
Is Security & Manual Actions clean? Ten seconds in Search Console, and it rules in or out the one cause that comes with an explicit notice.

If the answer is site-wide, date-matched and clean, you are almost certainly looking at a core update. If any of the three disagrees, keep reading — one of the impostors below fits better.

Get the date right first

The single most diagnostic thing you can do is establish precisely when the decline started, because every cause has a different date signature.

In Search Console, open Performance → Search results, turn compare mode off, and widen the range to 16 months. You are looking at the shape of the line, not the totals. Then narrow to a two-week window around the break so you can read the start date to the day.

Two cautions that produce false diagnoses:

The last two days of any range are incomplete. A dashboard ending yesterday always looks like a decline.
Check the time zone. Search Console reports in Pacific Time, so a drop that looks like the 14th to you may be the 13th in the rollout announcement.

If you need to find which specific URLs moved, that mechanical sweep is covered step by step in how to find which pages are losing traffic. This page is about what the pattern means once you have it.

The site-wide signature

This is the distinction people get wrong most often, and it is the one that saves the most wasted work.

A core update reassesses relevance and quality broadly. The fingerprint is many URLs moving together on the same date, in both directions — some pages usually rise even in a bad update. Average position shifts across queries that have nothing in common beyond being yours.

Compare that to what a page-level problem looks like: one URL falls to zero while everything around it is untouched. That is technical, near-certainly, and no amount of quality work will fix it.

A quick way to separate them: in the Pages tab, count how many URLs lost meaningful clicks on that date. A handful means investigate those URLs. Most of the site means investigate the site.

The impostors, and how each one gives itself away

What it looks like	Distinguishing signature	Where to go next
Manual action	Site-wide cliff, but a notice in Search Console	What is a manual action
Technical fault	Falls to zero, not to a lower level; URL Inspection fails	Getting indexed by Google
Your own deploy	Cliff matches a release date, not an update date	Check the deploy log first
Seasonality	Same dip at the same point last year	Compare year over year, not period over period
SERP feature change	Impressions and position flat, clicks falling	Showing up in AI Overviews
Competitive decay	A slope over months, not a cliff	What is content decay
Analytics fault	Search Console fine, analytics down — a broken tag	Search Console vs Analytics

Two of those are not problems at all. Seasonality needs a year-over-year comparison to see clearly, and a falling market means fewer people searching rather than a ranking loss. Both get misdiagnosed as updates every year.

The one to rule out fastest is your own deploy. Engineering ships a template change, a noindex escapes into production, and the cliff looks exactly like an algorithmic hit. Checking the release log costs a minute and closes a surprising share of cases.

What a core update actually is

Worth being precise here, because the language people use around updates causes bad decisions.

A core update is not a penalty. Nothing has been applied to your site. Google has changed how it assesses and orders results generally, and your pages are now judged against that revised standard alongside everyone else's. Google's own guidance on core updates makes the point that pages which drop are not necessarily in breach of anything.

Three consequences follow:

There is no reconsideration request. That route exists only for manual actions.
There is nothing to "undo." If you go looking for the change that caused it, you will find nothing, because the change was not on your side.
Recovery is not automatic and not quick. Meaningful movement generally waits for a subsequent core update, which can be months away.

That last point is the hard one. It is also why panicked rewriting during a rollout is the worst available response.

Do not judge a rollout while it is running

Core updates typically take one to two weeks to roll out fully, and rankings genuinely fluctuate during that window — including recovering partway before settling.

So the correct action in week one is to wait. Record the date, take a snapshot of positions and clicks so you have a real baseline, and do nothing structural until the rollout is confirmed complete. Sites that rewrite half their content mid-rollout end up unable to tell what the update did from what they did.

If it is a core update, what then

Google's stated remedy is to focus on overall content quality rather than hunt for a technical fix, and in practice the work looks like this:

Find what actually moved. Not every page fell. Compare the winners and losers on your own site — the differences between them are the most specific signal you will get about what the update rewarded.

Look at who replaced you. Search the queries you lost and read the pages now outranking you. This is more informative than any general advice about update recovery.

Check the quality signals you control. First-hand experience, genuine expertise, accurate and current information, clear authorship — the criteria in what is E-E-A-T in SEO. Core updates consistently reward these.

Be honest about thin content. Pages assembled to have a page rather than to answer something are the ones that go first. What is scaled content abuse covers where the line sits.

Check whether it was authority, not quality. If the pages that outranked you are comparable in quality but stronger in links, the gap is authority. That is a different problem with a different fix — how to audit your backlink profile is the place to confirm it, and Backlinkster is one way to close it, with one-for-one in-content swaps verified live by code. Five a month free, plans from $19.

Frequently asked questions

How do I know if a traffic drop is a core update or something else? Check three things: whether the drop is site-wide or limited to a few pages, whether the start date matches a confirmed Google core update rollout, and whether Search Console shows a manual action. Site-wide plus a matching date plus no manual action points to a core update. Anything else points elsewhere.

How long does a core update take to roll out? Usually one to two weeks, occasionally longer. Rankings fluctuate throughout, so a position on day three is not the outcome. Wait for Google to confirm the rollout is complete before judging the impact.

Is a core update a penalty? No. A penalty — a manual action — is applied to your site and comes with a notice in Search Console. A core update changes how Google assesses results generally; your pages are re-evaluated against a revised standard rather than punished.

How long does it take to recover from a core update? There is no fixed timeline, and significant recovery usually requires a later core update to reassess the site. That is often months rather than weeks, which is why quick fixes aimed at the previous update rarely pay off.

Can I recover from a core update by deleting content? Rarely, and it is frequently counterproductive. Deleting pages that have links or ranking history loses assets you would be better off improving or consolidating. Fix or merge before you delete, and redirect rather than remove.

What if the date doesn't match any known update? Then it is very probably not an update. Check your own deploy history first, then indexing status for the affected URLs, then seasonality against last year. Unannounced ranking adjustments do happen, but they are a last resort explanation, not a first one.

Should I make changes during a rollout? No structural changes. Record the start date and capture a baseline of positions and clicks, then wait. Editing mid-rollout makes it impossible to separate the update's effect from your own.

The bottom line

Three checks decide it: site-wide or page-specific, date-matched or not, manual action or clean. Most drops people attribute to core updates fail at least one of those tests, and the real cause is usually a deploy, an indexing fault or seasonality — all of which are fixable this week, unlike an update. Get the date right, count how many pages moved, and only then decide what you are dealing with.