If your clicks fell this year, the first job is not fixing anything. It is working out whether a Google core update in 2026 touched your site at all. Most sites that panic after a drop are reacting to something else: a Discover feed that cooled off, two of their own pages fighting each other, a consent banner change, or a seasonal dip that happens every year and gets blamed on Google.

This piece gives you the 2026 rollout timeline in one place, a diagnostic sequence to separate a real hit from noise, and a staged recovery plan. It also tells you where the evidence stops, because a lot of what is written about core updates is guesswork presented as fact.

What Google shipped in 2026, and what each update targeted

Google confirms rollouts on one page and one page only: the Search Status Dashboard. Everything else is commentary. Check the dashboard yourself before you quote a date to a client or a board, because the record there is authoritative and this article is not.

The 2026 timeline, with the December 2025 baseline

Most sites are still comparing against late 2025, so that update belongs in the list. As recorded on the Search Status Dashboard at the time of writing:

• December 2025 core update, beginning 11 December 2025. The baseline most 2026 comparisons are drawn against.

• February 2026 Discover core update, announced 5 February 2026. A separate system from web search.

• March 2026 core update, running 27 March to 8 April 2026.

• May 2026 core update, running 21 May to 2 June 2026.

• August 2026 spam update, running 18 to 21 August 2026, finishing in roughly two days and sixteen hours.

Dates move when Google amends the dashboard, so confirm them against the live record before you build a report on them.

A core update, a Discover core update and a spam update are three different things

A broad core update changes how Google's systems assess content across web search generally. A Discover core update affects the Discover feed, which is a separate surface with its own logic and its own referral pattern. A spam update targets content and links that breach Google's spam policies, and it behaves less like a reassessment and more like a filter.

The February 2026 Discover core update is the one people misread most. Publishers watch Discover referrals fall off a cliff, open Search Console, see the total clicks line drop, and start rewriting evergreen service pages that never appeared in Discover in the first place. Weeks of work, aimed at the wrong pages.

Before you conclude anything, split the data. In Search Console, Discover has its own report in the left-hand menu, separate from Search results. If the loss lives in Discover and your web search clicks are flat, your service pages are fine and your feed performance is the problem.

How to spot a blog inventing a ranking factor

Google does not publish factor lists for core updates. It never has. So when a secondary blog tells you the March 2026 update "introduced"a composite Core Web Vitals measure, or added a new authority signal, or started weighting some named metric, that is a guess dressed as reporting.

Two sources are worth citing: the Search Status Dashboard for dates, and Google's guidance on core updates for what to do about them. That guidance sets out self-assessment questions about content quality and states plainly that there is no specific fix guaranteeing recovery. Less satisfying than a five-step bounce-back post. Also true.

Rollouts run for weeks, and mid-rollout volatility is not a verdict

Core updates commonly take one to three weeks to finish, and the March and May 2026 rollouts each ran around a fortnight. During that window, rankings swing. Pages drop, come back, drop again. Reading day four of a rollout as your final position is how people end up deleting a page that was about to recover on its own.

Wait for the completion date on the dashboard. Then measure.

Were you actually hit, or does it just look that way?

The comparison that works

Month against month is useless here, because months contain different numbers of weekdays and rollouts do not respect calendar boundaries. Use equal windows instead.

In Search Console, compare the 28 days ending the day before the rollout started against the 28 days beginning the day after it finished. Same number of days, same weekday mix. Then filter the Pages report to URLs with at least 100 impressions in the earlier window, and flag anything that lost 30 per cent or more of its clicks. Set that threshold before you look at the data, not after, or you will find a story in the noise.

False positives that look exactly like a core update hit

Four causes account for a large share of drops blamed on Google:

• Seasonality. Check the same weeks last year. Accountancy, education, hospitality and home improvement all have predictable troughs.

• Tracking and consent changes. A new banner, a tag manager edit or a switch to a different analytics property can cut recorded sessions without touching rankings. Search Console data is independent of your consent banner, which makes it the better arbiter.

• Brand demand falling. If a radio campaign, sponsorship or trade show ended, brand searches fall and total clicks fall with them. Filter queries to exclude your brand name and see whether the non-brand line held.

• AI Overviews absorbing the click. Position holds, impressions hold, clicks fall. That is a SERP layout story, not a content quality story, and rewriting the page will not fix it.

Read impressions and average position alongside clicks

Clicks alone tell you nothing about cause. Pull all three metrics for the same window. Falling impressions with falling average position points at a ranking change. Steady impressions and steady position with falling clicks points at what is happening above your result: an AI Overview, more ads, a video carousel, a new People Also Ask block.

Rule out your own mistakes before blaming the update

We would guess that cannibalisation explains more "core update drops"than core updates do. Two of your pages target the same query, Google swaps which one it shows, the weaker one lands on page two, and the query looks lost. Before you rewrite a word, search the site for a near-twin of the losing URL. A blog post and a service page covering the same intent is the classic pairing.

Also check: a noindex tag left behind after a staging push, a migration with redirects pointing at the wrong URLs, a robots.txt edit, a burst of thin pages published in one week, or a plugin update that changed canonical tags across a template. Boring causes. Very common ones.

Read the damage at page and query level, not sitewide

Sitewide charts hide the pattern. Export the Pages and Queries reports for both windows, then segment by template or content type: service pages, location pages, blog guides, product pages, category pages. Sort by lost clicks within each group.

Say a 40-page site sees organic clicks fall by a third. Six bulk-written "best X in [town]"posts have lost almost all their impressions, while three genuinely researched guides held position or gained. That is not a domain problem. That is one cluster dragging, and the fix is aimed at six URLs, not forty.

Site-level quality is why the good pages suffer too. Google's systems assess sites as well as pages, so a run of thin, machine-generated posts can weigh on articles that would stand up fine on their own. When that is the pattern, recovery is usually subtraction: merge, redirect or remove the weak cluster rather than adding more content on top of it. A free SEO content audit is a reasonable way to get an outside read on which pages fall into which pile before you start cutting.

The first fortnight: triage, not panic edits

What not to do in week one: mass deletions, rewriting everything at once, or publishing a surge of new posts to signal freshness. All three make the next diagnosis harder, because you will have changed so many variables that you cannot attribute any recovery to anything.

Do this instead.

1. Record the current state. For every flagged URL, save the clicks, impressions, average position and top three queries from your before window. You will want that record in eight weeks.

2. Sort into three piles: worth saving and rewriting, worth merging into a stronger page, worth removing and redirecting.

3. Fix the cheap structural problems. Duplicate title tags, two pages competing for one query, orphaned content with no internal links, missing or doubled-up schema where an SEO plugin is already outputting markup. A polite website SEO audit crawl tool that reads your site the way a new hire would will surface most of these in an hour.

4. Set a review date. Six to eight weeks out. Not Friday.

Rewriting the pages that lost, so they survive the next update

Rewriting fails when the writer adds length instead of substance. A 900-word page padded to 1,800 words is still the same page, only slower to read.

Thin and machine-written content has a tell, and it is recognisable once you know it: interchangeable openings that could sit on any competitor's site, even sentence rhythm with no short sentences anywhere, hedged claims with no source attached, stock phrasing that recurs every few paragraphs. Replace those with things only you could write. Real figures with the source named. Named tools, standards and regulations. Dated events. What went wrong on an actual project and what you did about it. That is what it takes to make AI content sound human, and it is the same work that makes human content worth reading.

Two more habits worth keeping:

• Consolidate rather than refresh three near-identical posts. Pick the strongest URL, fold the useful parts of the others into it, redirect the rest, update the internal links pointing at the old URLs.

• Look at the live top 10 before you rewrite. Search intent shifts. A query that returned buying guides in 2023 might now return comparison tables, supplier lists or a tool. Answer what is actually ranking, not what ranked two years ago.

Google does not penalise AI content. It penalises content that says nothing.

Publishing again afterwards without looking spammy

Going from one post a month to fifteen in a fortnight is a pattern worth avoiding. A spike of average content immediately after a drop compounds the original problem, because you are adding to the weak cluster you just spent a month pruning. Ramp gradually and hold the quality bar constant: two a month, then four, then whatever cadence you can genuinely sustain.

Check what already exists before commissioning anything new. Every brief should be written against a list of your current URLs and their target queries, so you do not publish a fourth article on a topic three of your pages already cover. Cannibalisation is far cheaper to prevent than to unpick.

Grade drafts on two axes: search fit, meaning how well the piece matches what is ranking, and content integrity, meaning whether a knowledgeable person would put their name to it. When those two conflict, integrity wins. Our own editorial checks before a draft reaches you work on exactly that split, and the second score is the one we refuse to compromise on.

For tracking, three things are worth watching weekly: rank movement on your priority queries, clicks at page level rather than sitewide, and whether AI assistants cite your pages when asked about your topic. Sitewide totals will tell you something went wrong. Only page-level data tells you what.

Frequently Asked Questions

Which Google core updates rolled out in 2026?

As recorded on Google's Search Status Dashboard at the time of writing, 2026 brought a Discover core update announced on 5 February, a broad core update from 27 March to 8 April, a broad core update from 21 May to 2 June, and a spam update from 18 to 21 August. The December 2025 core update, which began on 11 December 2025, is the baseline many sites are still comparing against. Confirm each date on the dashboard before citing it.

How long does a Google core update take to finish rolling out?

Broad core updates typically run for one to three weeks, and both the March and May 2026 rollouts took around a fortnight from start to completion. Spam updates are often faster: the August 2026 one finished in roughly two days and sixteen hours. Rankings move around during a rollout, so wait for the confirmed end date before drawing conclusions.

How do I know if a core update hit my site or something else did?

Compare 28 days before the rollout started against 28 days after it finished in Search Console, using the same weekday mix, and check clicks, impressions and average position together. If position held and only clicks fell, the change is likely in the SERP layout rather than in how Google rates your content. Rule out seasonality, brand search decline, tracking changes and cannibalisation before you accept a core update as the cause.

Can a site recover from a core update before the next one runs?

Sometimes, particularly where the loss came from something concrete like cannibalisation, a technical fault or a weak cluster you have since merged or removed. Google's own guidance states there is no specific fix that guarantees recovery, and that improvements may take time to be reassessed. Plan for weeks rather than days, and keep a record of what you changed and when.

Does deleting AI-written content help after a core update?

Deleting content because a machine wrote it is the wrong test. Deleting it because it is thin, duplicated, unsourced and says nothing a reader could not get elsewhere is the right one, and a run of pages like that can weigh on the rest of the site. Merge what has a genuine query behind it, remove what does not, redirect sensibly, and rewrite the survivors with detail only you could supply.

Whichever Google core update in 2026 you are still recovering from, the sequence is the same: confirm the dates on the dashboard, prove the drop is real, find the cluster, then fix the smallest number of pages that explains the loss. If you would rather have someone else read the site and tell you which pages are pulling their weight, get in touch with us and we will take a look.