How to Confirm an Update Actually Hit Your Site

Four tests confirm an algorithm impact, and you need all four: Google confirmed an update on those exact dates, your drop began inside the rollout window rather than before it, the damage is uneven across your site, and nothing else explains it. Miss any one and you do not have a confirmed impact — you have a coincidence with a plausible story attached. This matters because “an update hit us” is the most comfortable explanation available, it places the cause outside anyone’s control, and it is wrong more often than the industry admits.

The cost of getting it wrong is not just an inaccurate report. It is three weeks of content rewrites aimed at a problem that was actually a caching misconfiguration.

Test 1: Did Google confirm an update on those dates?

Go to Google’s Search Status Dashboard. Not a volatility tracker, not a forum thread, not an SEO newsletter — the dashboard. It logs each ranking update with start and completion timestamps, and it is the only authoritative confirmation that exists.

If nothing is listed for your window, write “unconfirmed volatility” in your reporting. That is not hedging; it is accuracy. Rankings fluctuate daily for reasons that have nothing to do with announced updates: ordinary index churn, SERP feature changes, seasonality, competitor movement, and occasionally Google’s own bugs.

The August 2026 case is the clearest demonstration. Around fourteen tracking tools registered spikes across 1–6 August 2026. The industry named an update. Google’s dashboard showed no ranking, indexing, crawling or serving incident in that entire window. Everyone who wrote “the August core update” in a client report was reporting something that did not happen.

Test 2: Do the dates genuinely align?

This is where most confirmations quietly fail, because people check whether an update existed that month rather than whether it explains their specific drop.

Two things to verify. Your drop must begin at or after the rollout start — a decline that began on 18 May was not caused by an update that started on 21 May, no matter how convenient that would be. And the shape should match a progressive rollout: core updates propagate over 12 to 18 days, so a genuine impact typically appears as movement spread across days, often in waves. The May 2026 update moved in three distinct waves over twelve days.

A vertical cliff on a single date is a much stronger signal of something structural on your side than of a core update.

Also check you are attributing to the right update. In 2026, three confirmed rollouts landed inside five weeks: the February Discover update ran 5–27 February, the March spam update ran 24–25 March, and the March core update began on 27 March. A late-March drop could plausibly belong to any of the last two, and they require opposite responses.

Test 3: Is the damage uneven?

Core updates reassess relevance and quality, which is inherently uneven — different pages compete against different fields, so they cannot all move identically.

Export Search Console by page and by query, then group by template, content type, publication era, funnel stage and author. You are looking for a pattern: blog posts fell while service pages held, or 2022 content fell while 2025 content held, or informational queries fell while commercial queries held.

That pattern is the fingerprint. It is also the diagnosis, because whatever the losing pages share is what was reassessed downward.

If everything fell by roughly the same proportion, you almost certainly have a technical or measurement cause rather than an algorithmic one. Uniformity points at robots.txt, a stray noindex, a broken template, a firewall rule, or a tracking failure — see was it an update or was it you.

Test 4: Have you ruled everything else out?

An update is a diagnosis of exclusion. Before accepting it, eliminate:

• Your own deployments. Check the release log against the drop date — code, themes, plugins, caching, CDN, DNS, SSL, CMS upgrades.
• Indexation changes. Search Console → Pages. A fall in indexed pages is close to conclusive evidence against an update, because updates re-rank sites rather than de-indexing them.
• Crawl access. Server logs. If Googlebot’s crawl volume dropped on the same date, that is your cause.
• Measurement. Does the drop appear in Search Console and analytics, or only one? A GA4-only decline points at tracking. Google’s own GA4 reporting bug in early August 2026 sent people diagnosing ranking problems that did not exist.
• The wrong surface. Search, Discover and News move independently and are separated in Search Console’s search type filter.
• SERP composition. If positions and impressions held but clicks fell, an AI Overview or a new feature above you is the likelier cause than a ranking change.
• A manual action. Security & Manual Actions. Thirty seconds, and it is a completely different problem — see how to tell if you have a penalty.

The full ordered sequence, by frequency, is in the twelve diagnoses.

Setting up the comparison correctly

Even with all four tests passed, a bad comparison window will misstate the size of the impact.

1. Use equal-length periods. Comparing 30 days to 14 days produces a number that means nothing.
2. Both windows must sit entirely outside the rollout. A window straddling the rollout blends the before and after states into one average describing neither. Choosing the right comparison window covers the mechanics.
3. Avoid crossing other events — a seasonal peak, a promotion, a site migration.
4. Compare year on year as a cross-check. If the same dip appears in the same week last year, seasonality is doing more work than any update.

What a confirmed impact actually licenses you to say

Even after four clean tests, be careful about the claim you are making. You can say an update coincided with a change in your rankings and that no other cause was identified. You cannot say what the update did mechanically, or which signal moved.

Google published no new guidance with either 2026 core update, so anyone stating what those updates “targeted” is inferring. The direction across 2026 is supportable — evidence over volume — but the mechanism is not, and stating inference as fact is how reports age badly.

A defensible summary reads something like: positions on our commercial cluster fell an average of 4.2 places between the two comparison windows, coinciding with the May 2026 core update confirmed by Google as running 21 May to 2 June; no deployments, indexation changes or tracking issues were identified in that window; the pages that gained on our lost queries consistently carry original data and named authorship, which ours do not.

That last clause is the valuable part. It turns a confirmation into a brief, and it is what the 30-day recovery plan is built to act on.

Frequently asked questions

How do I know if a Google update hit my site?

Four tests, and you need all of them: Google confirmed an update on those exact dates via its Search Status Dashboard, your drop began inside the rollout window rather than before it, the damage is uneven across page types or query clusters, and you have ruled out deployments, indexation changes, crawl problems, tracking bugs and SERP composition changes. Missing any one means you have a coincidence, not a confirmed impact.

Where does Google confirm algorithm updates?

The Google Search Status Dashboard at status.search.google.com. It lists each ranking update with start and completion timestamps and is the only authoritative source. Third-party volatility trackers show that results moved but cannot distinguish an algorithm update from an infrastructure bug, a SERP feature change, seasonality or your own site changes.

My rankings dropped but Google confirmed no update. What happened?

Search results fluctuate daily without any announced update, through ordinary index churn, SERP feature changes, seasonality and competitor movement. Check your own deployment log first, then indexation in Search Console’s Pages report, then whether the decline appears in both Search Console and analytics. In August 2026, fourteen trackers spiked while Google’s dashboard recorded no incident at all.

What does uneven damage mean when diagnosing an update?

It means some page types, templates, content eras or query clusters lost ground while others held. Core updates reassess relevance and quality, so they cannot affect everything identically — different pages compete against different fields. Whatever the losing pages share is both the fingerprint of an algorithmic cause and the diagnosis of what was reassessed downward.

Can I say what a Google core update targeted?

Rarely, and not for the 2026 core updates. Google issued no new guidance with either the March or May 2026 rollouts, so any statement about what they targeted is inference rather than fact. You can accurately report that a change coincided with a confirmed update and that no other cause was found. Stating a mechanism Google never described is how reports age badly.

Sources

• Google Search Status Dashboard
• Search Console Performance report — Google Search Central
• Google core updates and your website