Hit by a Google core update? How to tell, and what to do next

A traffic drop that lands in the middle of a core update looks like an open-and-shut case. Sometimes it is, but a deploy, a seasonal dip or a technical problem can start in the same window. Here's how to check, and what to do once you're sure.

Quick answer: A core update is the likely cause if your drop started inside a rollout window listed on the Google Search Status Dashboard, shows up as lost rankings across many queries, and you've ruled out technical problems, manual actions and seasonality. Recovery means making your content more helpful and reliable, not applying a technical fix. It can take weeks to months, and Google doesn't guarantee it.

#What a core update is, and what it isn't

Core updates are broad changes to how Google ranks results. They aren't aimed at one site or one tactic. Google lists them on its Search Status Dashboard, and each one rolls out over days or weeks.

A core update is not a penalty. When a reviewer at Google takes action against a site, it shows up in the Manual actions report. A core update leaves no message anywhere in Search Console. You only see it in your traffic.

So a drop doesn't prove your pages are broken. Often Google now ranks other pages higher for queries you used to win. Your job is to work out why those pages look more useful, and whether you can honestly close the gap.

Spam updates are different. They target sites that break Google's spam policies, so if your drop lines up with a spam update rather than a core update, review your site against those policies first.

#Recent Google ranking updates

These are recent updates listed on the Google Search Status Dashboard, which is where to check start dates and rollout lengths:

The February 2026 Discover update affected Discover, not Search. If the traffic you lost came from Discover, check the Discover performance report instead of the Search results report.

Two things stand out. First, updates can overlap: the March 2026 spam update started three days before the March 2026 core update, so a drop that began in late March 2026 could belong to either. Second, the gaps between the core updates in this table range from just under two months to about five and a half. Keep that in mind when you plan your recovery.

#How to line up your drop with a rollout window

#Step 1: Find the day the drop started

In the Performance report, look at daily clicks with impressions and average position switched on. Find the first day that's clearly lower than the days before it and stays lower.

Two details matter here. Daily data is in Pacific Time, and performance data is usually available in 2-3 days, so wait a few days after a rollout ends before you judge its full effect.

#Step 2: Mark the rollout windows

A rollout window runs from the start date for the length shown on the dashboard. The March 2026 core update started March 27 and took about 12 days, so its window runs to roughly April 8.

Search Console's custom annotations make this easier. Right-click the Performance chart and choose "Add annotation" to mark the start and end of each update. Each note is limited to 120 characters, can't be edited, and is visible to everyone with access to the property. Annotations don't show in comparison mode, so check them in the normal view.

#Step 3: Check that the timing fits

A drop that started before a rollout began wasn't caused by it. A drop that starts during the rollout and settles at a lower level after it ends fits the pattern. Rankings can keep shifting until the rollout finishes, so don't treat mid-rollout numbers as final.

#Step 4: Rule out the other causes

Google's guide to debugging drops in Google Search traffic lists other causes that can strike the same week: technical issues, security issues, manual actions, seasonality, site moves and reporting glitches. The full walkthrough is in why did my Google traffic drop.

#Core update or something else? A checklist

The more of these hold true, the more likely a core update is your cause:

1. The drop began inside a core update's rollout window, not before it.
2. Average position got worse, not just click-through rate. If impressions held and only clicks fell, read clicks dropped but impressions didn't instead.
3. The Page indexing report shows no new spike in errors or excluded pages.
4. The Manual actions and Security issues reports are both clean.
5. The Data anomalies page shows no reporting issue for those dates.
6. Nothing changed on your site that week: no deploy, redesign, migration or robots.txt edit.
7. The same weeks last year don't show the same dip.

If the decline was a slow slide over months rather than a step down during a rollout, it's more likely content decay than an update.

#Measure the size and shape of the impact

Once you're fairly sure, measure what changed. In Compare mode, compare the weeks after the rollout ended with the same number of weeks before it started, and leave the rollout days out of both.

Then sort the Pages table by "Clicks Difference" and look for what the biggest losers have in common: a page type, a topic, a template, an author, the age of the content. Say a recipe site lost most of its clicks on listicle roundups but held steady on single, tested recipes. That points to the roundups, not the whole site.

Size matters too. Google's debugging guide treats small position drops, such as moving from 2 to 4, as normal fluctuation that often recovers without action, and advises against radical changes to pages that perform well. Large drops, such as falling from the top 10 to around position 29 across many terms, call for a site-wide self-assessment of helpfulness and reliability.

If your property has it, the branded queries filter helps separate demand from rankings. It splits Performance data into branded and non-branded queries using AI-assisted classification, which can occasionally get a query wrong. If non-branded clicks fell while branded clicks held, that fits a ranking change rather than less interest in your brand.

#Run an honest self-assessment

Google's guide to creating helpful, reliable, people-first content is the best checklist for this step. Its self-assessment questions include whether your content offers "original information, reporting, research, or analysis" and whether it's "produced well, or does it appear sloppy or hastily produced".

The guide also frames trust as who, how and why. Make it clear who created the content (bylines help), how it was made (for example, how you tested a product), and why it exists: to help people, not just to rank.

It lists warning signs of search-engine-first content too, including mostly summarizing what others say without adding value, heavy automation across many topics, and "changing the date of pages to make them seem fresh".

To make this practical:

1. Take the 10 to 20 pages that lost the most clicks.
2. Search the main query each one lost, and open the pages that now rank above you.
3. Answer the self-assessment questions for your page and theirs, side by side.
4. Write down what they offer that you don't: original data, first-hand testing, a clearer answer, a more credible author.
5. Ask someone outside the team to read both. They'll be harsher than you.

#What to change, and what to leave alone

Change what your self-assessment turned up:

• Add what only you can add. Original data, first-hand experience, real examples, your own analysis.
• Fix or merge weak pages. Thin, outdated or hastily produced pages are the first candidates. If two pages answer the same question, merge them and redirect the weaker URL.
• Show who's behind the content. Bylines, author bios with relevant experience, and notes on how you researched or tested.
• Update honestly. When you substantially improve a page, an "Updated" date is fine and useful to readers.

Leave these alone:

• Pages that still perform well. Google advises against radical changes to them.
• Publish dates. Changing dates to look fresh is on Google's list of warning signs.
• Shortcuts at scale. Mass-rewriting hundreds of pages with automation repeats a warning sign instead of fixing anything.

Make changes deliberately and log them with dates. If you change everything at once, you'll never know what helped.

#Realistic recovery timelines

Google's debugging guide says some changes show results within days, while others can take months, and it recommends waiting a few weeks before analyzing again. It's also explicit that improvements don't guarantee recovery.

In practice, many site owners see their biggest movement, up or down, when a later core update rolls out rather than gradually in between. With the core updates in the table above landing roughly two to five and a half months apart, plan your recovery in months, not weeks.

While you wait, track a few things on a schedule: weekly clicks and position for the pages you changed versus pages you didn't touch, non-branded clicks if you have the branded filter, and an annotation for each change you ship. For a quick first look at which pages moved, try the free traffic drop checker.

Core updates don't tell you which of your pages they touched. If you'd rather not dig for that by hand, RankSlide checks every page and query in your Search Console daily and emails you when a page with 20 or more weekly clicks falls 15% or more below its average week over the previous 28 days, with a plain-English explanation of the likely cause. Try the demo to see it with sample data.

#FAQ

#Is a Google core update a penalty?

No. A core update changes how Google ranks results across the web and doesn't single out your site. Manual actions are the closest thing to a penalty, and they appear in the Manual actions report with a reason.

#How long does core update recovery take?

There's no fixed timeline. Google says some changes show within days and others take months, and that improvements don't guarantee recovery. Make your changes, wait a few weeks, measure, and don't be surprised if bigger shifts arrive with a later update.

#Should I make changes while the update is still rolling out?

It's better to wait. Rankings can keep moving until the rollout ends, so you could end up "fixing" a page that would have settled on its own. Use the rollout period to collect data and plan.