Did the Google core update hit your site? How to measure it in Search Console and GA4

Every core update produces the same week of screenshots: a line that bends on the day Google announced something, and a caption that says the update did it. Sometimes it did. Often the line would have bent anyway, because a holiday started, a single odd query came and went, or the site itself changed the same week.

This guide measures the last three core updates on one real site, with its own Search Console and GA4 data, and shows what the headline number said each time and what was actually behind it. The site is a multilingual booking site for workshops in one city; we leave its name out. Then it applies the same method to the November 2026 core update, which started on November 10 and is still rolling out as this is written.

The short version: compare the right windows, split the change by section before you read it, and check every movement against the four things that look exactly like an update.

How do I know if a Google core update affected my site?

Compare two windows of equal length: one that ends the day before the rollout started, and one that starts the day after it finished. Google lists the start and end of every confirmed update on its Search Status Dashboard, so the dates are not a guess. Then read clicks, impressions and average position together, for the whole site and for each section of it.

An update's effect looks like a step: many pages move within the rollout and stay moved. If the change is in one query, one page or one folder, or if it started before the rollout did, it is probably something else. Google says core updates do not target specific pages or sites, so a change that hits exactly the pages you edited last week deserves a second look.

Search Console's own date picker can compare two windows, but only one dimension at a time and with no section filter carried across both. GSC PAP's compare_periods takes any two windows and a page filter, so a folder's before and after is one question to your assistant.

Google core updates in 2026 and their dates

From the Search Status Dashboard, Ranking section. Core updates have taken between 12 and 18 days to roll out.

Which dates to compare before and after an update

Leave the rollout out of both windows. During a rollout rankings move back and forth, and a window that includes part of it measures the update half done.

• ·Before: the 14 days ending the day before the rollout started.
• ·After: the 14 days starting the day after Google marks it complete.
• ·Same length and whole weeks, so both windows hold the same weekdays. 14 days is short enough to keep seasons out and long enough to smooth a single odd day.
• ·Wait three days after the after window ends. Search Console data takes about that long to settle, and a window that ends today always reads low.
• ·Add a control. The same two windows a year earlier tell you what those weeks normally do. If you have no year-earlier data, a second site or section the update should not have touched does the same job less well.

What three core updates looked like on a real site

Here is what a first reading of each update said, using the windows above, and what was behind it once we split the change.

• ·None of the three first readings survived the split. The December result might be the update, but these windows cannot show it.
• ·The rest of this guide takes each one apart, because each fails in a way that is common.

One query can fake an update's effect

After the March 2026 update the site's impressions fell 35% while clicks rose 11%. Split by query, the whole fall was one query: "art classes", searched in Türkiye, for which Google began showing the site's listings page in volume on February 22. Its average position climbed to about 4 in March and it earned 8,193 impressions in the before window, and no clicks. It dropped out during the rollout, on April 5, and never returned to the first pages.

Take that query out and the site's impressions went from 12,220 to 13,166, up 8%. The update did not cost the site any traffic. It removed a generic query the site was never going to win, for a page that did not answer it. That is plausibly the update at work, and it is the opposite of a penalty.

• ·Check the before window as hard as the after window. Here the baseline was the unusual part: the query had arrived a month earlier and inflated it.
• ·Rank the queries by the change in impressions and read the top five before you report a site-wide percentage. A drop that sits in one or two queries is a story about those queries.
• ·A query with many impressions, a good position and no clicks is a mismatch: the page is shown, and it is not what the searcher wanted. Losing it can be the update getting the match right.

Your own changes land in the same windows

The May 2026 update started on May 21. The site had relaunched on a new platform on May 19, two days earlier, with a Turkish section that had not been public before. Any before and after for the May update is also a before and after for the relaunch.

Split by folder, the two effects come apart. The Turkish section went from 1 click to 23. Everything else went from 457 clicks to 485, up 6%. Roughly half of the site's gain was its own launch.

• ·Write down your own deploys, migrations, template changes and launches with their dates. Against an update's dates, that list settles more questions than any ranking tracker.
• ·GA4 broke on the same day. Before the relaunch, GA4 counted about twice as many Organic Search sessions as Search Console counted clicks; after it, fewer: 904 sessions in the before window, 359 after, while Search Console clicks rose. The site was rebuilt on a new platform, so GA4's before and after are not the same measurement, whatever the update did.
• ·When Search Console and GA4 disagree on direction, suspect the measurement first. Search Console counts on Google's side and is not affected by your tag, your consent banner or your redesign.

A growing site grows through every update

A second, younger site in the same business, with Search Console data from October 2025, rose in every window we measured: impressions went from 1,522 to 8,179 around the March update and from 12,770 to 27,575 around the May one. Read naively, both updates were a gift.

They were mostly the trend. A site that is still being indexed and still adding pages climbs week after week, update or no update. For a site like that, compare the after window with where the trend before the rollout was heading, not with the level it had reached. A growth rate that holds through the rollout means the update did little. One that bends during it is the signal.

Split the change before you read it

A site total hides the shape of a change. These splits each answer a different question, and the first two do most of the work.

compare_periods(
  site_url="sc-domain:example.com",
  previous_start="2026-10-27", previous_end="2026-11-09",
  current_start="2026-11-25", current_end="2026-12-08",
  dimensions=[],
  dimension_filter_groups=[{"groupType": "and", "filters": [
    {"dimension": "page", "operator": "contains", "expression": "/blog/"}]}])

^https://example\.com/(de|fr|es)/

• ·In the March example, queries ranked 4 to 10 in the before window lost 8,322 impressions and gained 28 clicks. A position band that loses impressions and gains clicks is not a ranking loss.
• ·Any query filter drops anonymized queries, so a query-level split always adds up to less than the property total. Compare query splits with each other, not with the total.

Ranking, demand or the results page: reading the three numbers together

Average position is an average over everything you were shown for, so it moves when the mix of queries changes even if no ranking did. Losing a query you ranked 4 for, as in March, makes the average worse. Read position per query or per band, not for the site.

Did the update reach the business? Checking GA4

Search Console stops at the click. To know whether an update changed bookings or sign-ups, compare the same two windows in GA4, Organic Search sessions and key events, for the same sections.

GSC PAP's ga4_compare_periods takes both windows explicitly and a filter, so the before and after need not be adjacent and can be limited to one section's landing pages. Use landingPage with BEGINS_WITH and the folder path.

• ·Expect GA4 Organic Search sessions to differ from Search Console clicks. They count different things: GA4 includes other search engines and loses visits blocked by consent or ad blockers. Compare the direction and the size of the change, not the two numbers.
• ·If the update moved clicks and conversions did not move, the queries that changed probably were not the ones that convert. That changes how urgent a fix is.
• ·If GA4 moves and Search Console does not, look at the site and its tagging before you look at Google.

Measuring the November 2026 core update

The November 2026 core update started on November 10 at 18:06 UTC. Google said the rollout could take up to two weeks. The before window is ready today; the after window is not.

• ·Before window: October 27 to November 9, 2026. Its data has settled, so record the totals and the section splits now, while the date is fresh.
• ·After window: the 14 days starting the day after Google marks the rollout complete. If it completes on November 24, that is November 25 to December 8, readable from about December 11.
• ·Watch the calendar in the after window. It holds Thanksgiving (November 26), Black Friday (November 27) and Cyber Monday (November 30). For retail and travel sites those days move demand on their own, which is the December 2025 problem again. Compare with the same weeks of 2025 if you have them.
• ·List your own changes from late October onwards. Anything you shipped in either window belongs in the reading.
• ·Daily movement during the rollout is not the result. Look at it to see when things moved, and measure only once the rollout is over.

Limits of this method

A before and after shows what changed in those weeks. It does not prove why.

• ·Two windows can't separate an update from anything else that happened in them. The splits and the control window narrow it; they don't close it.
• ·Google ships smaller ranking changes all the time, many unannounced. A change outside a listed rollout may still be Google, and a change inside one may not be the listed update.
• ·Small sites move a lot by chance. A section with 20 clicks a fortnight can swing 30% on nothing. Treat changes in small sections as unknown.
• ·Search Console keeps 16 months. A year-over-year control for an update needs data from the year before, which you only have if you kept it.
• ·One site is an example, not a benchmark. The numbers here show the method; the effects on your site will differ.