Google Core Update: how to tell if it hit you with your own rank data

Latest Google core update: dates, duration, and where to confirm it

This section gets updated every time Google ships a new core update — we change the post's dateModified, not the URL, so you can come back to this same page instead of hunting for a newer article. With data verified on the Google Search Status Dashboard on September 10, 2026, the most recent rollout started on May 21, 2026 and ran for 11 days and 21 hours, finishing around June 1-2 (check the dashboard for the exact hour if you need minute-level precision).

A few other rollouts landed close to those core updates and are worth not confusing with the main one: a spam update on March 24, 2026 (three days before that month's core update started), another spam update on June 24, 2026, and another on August 18, 2026, plus a Discover update in February 2026. Each of those moves traffic on its own, so if your measurement window overlaps any of these dates, your reading gets contaminated and you need to shift the window.

To confirm any of these dates yourself, open the Google Search Status Dashboard (status.search.google.com) and look under ranking incidents: that is where Google lists the start date, status (in progress or finished), and duration of every core update, spam update, and Discover update it chooses to announce. What the dashboard does not show are the smaller, continuous core updates Google ships without announcing each one individually — they exist, but they do not get a date you can write down.

What a core update is — and what it is not

Per Google's own documentation, a core update is a broad change to how the search engine evaluates and ranks content overall, made several times a year. It does not target a specific site or fix a specific problem — it adjusts ranking systems at scale, and as a side effect entire sites can move up or down without having changed anything. On top of that, Google also ships smaller, continuous core updates without announcing each one, which is why your position is never fully still, core update or not.

What a core update is not: it is not a manual action (a penalty aimed specifically at your site for breaking a policy, with its own reason and date) and it is not the same as a spam update (a different kind of rollout, focused on detecting specific spam content and practices). The three can land close together on the calendar — the March 2026 spam update did hit three days before that month's core update — but they are different mechanisms and are not fixed the same way.

Before running any measurement protocol, rule this out in one step: open Search Console's Manual Actions report. If something is listed there, a core update is not what hit you — that is a different problem with its own fix, and the rest of this guide will not help with that case.

Why Search Console alone is not enough to measure a core update

Search Console is where your clicks and impressions live, and it is free, but it has four limits that make it insufficient as the only proof that a core update hit you. The first is that the average position it reports blends every country, device, and query variant together: you could have dropped hard on mobile in Colombia and gone up on desktop in Spain, and the average shows you one lukewarm number that describes neither case. If you want the full breakdown of why that arithmetic fails as a baseline, we cover it separately in why Search Console's average position does not work as a baseline.

The second limit is a 2-3 day delay in the data: if you compare the exact day of the rollout, you do not yet have complete data for that day. The third is that impressions blend two different causes — you changed rank, or Google changed the blocks it shows for that query (added an AI summary, removed a featured snippet) — and Search Console does not tell you which one happened.

The fourth is two data windows with known anomalies that are worth adjusting for rather than using as a raw baseline: a logging bug inflated impressions, CTR, and average position from May 13, 2025 through April 27, 2026 (clicks were not affected), and starting May 7, 2026 Google stopped showing the FAQ result in most searches — right at the base date of the May core update. Neither one invalidates Search Console, but if your comparison window lands there, the reading gets skewed. We will cover each of these breaks in its own dedicated post; for now, knowing the date is enough to know when to be skeptical.

That is why measuring a core update needs a second source: a rank tracker with daily checks and competitor history gives you your own position series, without blending countries together and without depending on whether Google decides to show an extra SERP feature that day.

How to tell if a core update hit you: the 14-versus-14-day protocol

Before running any of these steps, a filter worth applying first: if you are not yet sure you actually dropped and this is not just normal day-to-day noise, start by telling apart noise from a real drop before spending time comparing windows around a core update that might not have touched you at all.

With that ruled out, here is the full protocol, built to run with your own rank history and then cross-check against Search Console.

1. Step 1 · Confirm the rollout's start and end

   On the Google Search Status Dashboard, write down the exact start and end dates (e.g., May 2026: May 21 to ~June 2, 11 days 21 hours). Without those two dates you cannot set any window.

2. Step 2 · Check what else lands nearby

   Spam updates, Discover updates, known Search Console anomalies, commercial seasons, and your own rollouts (redesign, migration, template change). If anything overlaps your window, shift it to the clear side.

3. Step 3 · Set the before window

   The 14 days ending the day before the rollout starts. This is your clean comparison point, before Google's adjustment kicked in.

4. Step 4 · Set the after window

   The 14 days starting the day after it ends. Never measure or compare while the rollout is still in progress — rankings oscillate while Google is still testing.

5. Step 5 · Compare the median, not the average

   Per keyword, calculate the median position for each window and the percentage of keywords in the top 3 and top 10. The median does not get dragged around by a single odd-position day.

6. Step 6 · Segment

   By page type, intent, device, and city or country. A single overall average hides an update that only hit one specific segment.

7. Step 7 · Compare against your own background noise

   Only mark a segment as affected if the change holds through the entire after-window and exceeds the variation that segment already showed between two normal fortnights before the update. Without that comparison point, any oscillation looks like a core update effect.

8. Step 8 · Cross-reference the historical top 10

   For each keyword that dropped, check who entered or climbed in your top 10, and what kind of page it is. That tells you what Google rewarded this time, not just that things got worse for you.

9. Step 9 · Cross-check with Search Console

   Using the same windows, same country filter, and same search type, review actual clicks and note any anomaly. This is where you want to cross-reference Search Console with your daily positions instead of looking at each source in isolation.

10. Step 10 · Decide, and write down the date

    Wait, fix something technical, or rewrite. Whatever you decide, write down the date you made the call — you will need it to measure its effect later.

Why 14 days instead of the full week Google's documentation suggests? Because a single week carries the day-of-week effect (your transactional keywords move differently on a Monday than a Sunday), and the normal noise across just seven data points is too high to separate from a real change. Fourteen days cover two full weekly cycles in each window, which dilutes that bias without stretching the wait into something impractical.

March and May 2026 core updates: the windows, already calculated

To save you steps 2 and 3 of the protocol for the two most recent 2026 updates, here are the windows already adjusted for the nearby events we found while checking the calendar.

For March, the before window runs from the 10th to the 23rd, cutting off right before the March 24 spam update so those three days do not blend with the core update that started on the 27th. For May, the before window (May 7-20) coincides in Search Console with the May 7 end of the FAQ result: if you are cross-checking impressions from that period in GSC, remember part of the drop in impressions there can come from that SERP change rather than the core update itself — with your own position history, that particular noise does not apply, because it measures rank, not impressions.

Source for the start and end dates: Google Search Status Dashboard, checked on September 10, 2026.

Reading by segment: page type, intent, and device

A core update almost never hits a whole site evenly. It is common for one page category to go up while another goes down, for mobile to move differently than desktop, or for one country to react differently than another to the exact same keyword. If you only look at the overall number, those movements cancel each other out and you end up reading "nothing happened" when actually two opposite things happened at once.

The breakdown that gives the clearest signal, in this order: first by page type (home, category, product, blog guide — each one competes against a different SERP); then by intent (informational versus transactional, since Google often adjusts these two groups with different weights in a core update); and last by device (mobile versus desktop). If you sell in more than one country, add country or city too: with coverage across 19 countries and 52 cities, it is common to see a core update hit one city's SERP and leave another one untouched with the exact same keyword.

For each segment, compare the median position of the before window against the after window, same as step 5 of the protocol, but calculated only with that group's keywords. And apply the same filter from step 7: a segment only counts as affected if the change holds through the full 14 days and exceeds the variation that same group already had between two normal fortnights before the update — that variation is your background noise, and every site has its own.

This segmentation approach is our own criterion, not an official Google recommendation: we share it because it has given us the clearest readings, but there is no published Google formula that says "this is how you measure a core update by segment." Adjust the groups to fit the size and structure of your own site.

Who gained what you lost: cross-referencing the historical top 10

Knowing you dropped is half the picture. The other half is reading competitor history for each affected keyword: which domain entered the top 10 that was not there before the rollout, or which domain that was already there moved up several spots in the same window. That is the piece of data that turns "I dropped" into something you can act on.

What matters is not just the name of the winning domain, but what kind of page it is: a forum, a news outlet, a marketplace, an official brand site, an independent guide. If across five of your dropped keywords the same type of page keeps climbing — say, forums and communities — that tells you something concrete about what format Google is favoring in this update for that search intent, beyond anything you adjust in your own content.

This cross-reference also helps you rule out a wrong reading: if the domain that displaced you is the same one across all your keywords and it is a large competitor that was already climbing before the core update, what you are seeing is probably not the update's effect but a trend it already had, which the update simply sped up. Looking at the full history, not just the two 14-day windows, keeps you from crediting the core update with something that was already happening.

The baseline trap (and positive impacts)

This whole protocol assumes you had a before window with data: 14 days of your own history before the rollout started. If you only started tracking a keyword after the core update, that window simply does not exist, and there is no comparison possible with your own data, no matter how much you try to force it. It is the most common trap and the quietest one — you notice it weeks later, too late for the update that just passed but still in time for the next one.

Another contamination source worth ruling out before crediting everything to the core update: in several LATAM countries, May and June bring strong commercial seasons (Hot Sale, CyberDay, among others depending on the country) that shift search volume and intent independently of the algorithm — confirm the exact 2026 dates for your market before ruling them out as a variable. The same goes for your own changes: if you launched a migration, a redesign, or changed titles close to the rollout, that variable blends with the core update's effect and the protocol alone does not separate them.

And if the result was positive, apply the same rigor before celebrating: confirm the gain with the same 14-versus-14 protocol, check that it holds across the full window and not just a couple of stray days, and verify it does not coincide with one of the commercial seasons or a change of your own that could also explain it. A real gain you confirmed with data is worth more than one you just assumed.

On the check you rely on for all of this: Pro's daily check is what gives you the resolution to date the change precisely; Free's weekly check is enough to see that there was a trend, but not to say which day it started. And even with a daily check, each keyword's Evolution chart in the app shows up to your last 180 measurements — for a multi-year lookback, that window has its own limit too.

If it hit you: when to wait for the next core update, and when to touch the site

This section answers just one question — wait or act — and deliberately does not get into tactics for recovering rankings: that deserves its own guide, and we cover it separately in our piece on moving from positions 11-20 up to page one. The goal here is smaller: decide what to do with the information you already gathered through the protocol.

Wait if, after segmenting and cross-referencing the historical top 10, the drop is mild or spread across several competitors, with no technical fault you can find on your end. Google's own documentation says as much: you do not need to wait for a specific next core update, because there are smaller, continuous core updates too, which can also move something in your favor without announcing any date.

Act if cross-referencing through the protocol reveals a concrete technical error (an entire template that lost indexing, a block that stopped rendering, an accidental canonical change) or if a whole category of your site dropped evenly while the rest held — that points to a problem of your own, not just the algorithm's general adjustment.

Either way, keep in mind what Google does not promise: there is no guarantee of recovery, no fixed timeline, and no specific action that reverses the effect. The only thing you control is measuring rigorously enough to make the right call with the information you actually have.

What to have ready today for the next core update

The next core update arrives without advance notice — Google does not publish a calendar. What controls how fast and how clearly you can read it is what you set up today, not what you scramble to build once it is already in progress.

Four concrete things: a representative sample of keywords per segment (page type, intent, device, and country or city if you sell in more than one), tagged now so you do not have to rebuild those groups by hand three months from now; an active daily check, because day-level resolution is what tells "it settled" apart from "it got lucky on measurement day"; active alerts so you do not have to log in every day to check; and Search Console connected, so you have the click and impression cross-check ready when step 9 of the protocol comes around.

None of these four things tell you what to do if the next core update hits you. What they do is make sure that, on that day, you have exactly what most sites were missing in the May rollout: a clean baseline of your own. That is how Rankiamos keeps your baseline and each keyword's top 10, ready before Google announces anything.