Google Algorithm Updates: Every Confirmed Update Since 2021

Most coverage of a Google update is written within 48 hours of it starting, which is the one point at which nobody can know what it did. The useful artefact is duller and more durable: a dated list of what Google actually confirmed, and a repeatable way to check your own site against it.

Everything in the table below is transcribed from the Google Search Status Dashboard, which is Google's own record of confirmed ranking updates. Names, start dates and rollout durations are Google's, not our summary of press coverage. Last verified against the dashboard on 19 August 2026.

Every Google Algorithm Update Google Has Confirmed

Google began publishing this history in November 2021. Updates before that date were announced through blog posts and social accounts rather than a structured record, so they are not included here. Two entries are labelled “ranking issue” rather than an update, which is how Google logs a bug it later corrected.

What the Rollout Data Actually Shows

"The most-read coverage of a rollout is written in its first 48 hours, the one point at which nobody can know what it actually did.

The durations are the part of this record almost nobody reads, and they change how you should respond. Across the 16 core updates Google has dated, the median rollout is 14.5 days. The shortest was the December 2024 core update at 6 days, 4 hours. The longest was the March 2024 core update, which ran for 45 days.

No core update in the register has ever completed in under six days. That single fact invalidates most of what gets written in the first week of one. If you compare last week to this week while a core update is halfway through rolling out, you are measuring an unfinished change against a moving baseline, and the number you get will not survive the rollout completing.

• ✓
  Wait for Google to mark the rollout complete, then wait a further full week before comparing. On a median core update that is roughly three weeks from the announcement.
• ✓
  Spam updates move faster: the June 2026 spam update finished in 2 days, 1 hour, and the March 2026 spam update in 19 hours 30 minutes. A same-week diagnosis is more defensible there.
• ✓
  Two core updates have overlapped with other announced updates in the same window (March 2024, December 2024). When that happens, attributing a change to one of them is guesswork.
• ✓
  Google publishes a name, a start, and an end. It does not publish what the update weighted, which pages it favoured, or a recovery timeline.

What Google Confirms, and What It Leaves Unsaid

Google's core-update guidance explains that core updates are broad changes intended to improve how Search presents helpful and reliable results. They do not target one website, one page, or one content management system.

Google also explains that a page moving down is not automatically a penalty or proof that the page is bad. Search results change as systems, content, user expectations and the open web change. A competitor may now satisfy the query better. A page can also lose clicks with little position movement if demand or the appearance of the results page changes.

It is not enough to notice that traffic moved during a rollout window and declare a cause. A core update, a technical release, a crawl problem, changing search demand, a competitor's stronger page, a tracking fault, or normal volatility can overlap. Timing creates a hypothesis, not proof.

Do Google's Updates Set a Speed Threshold?

No update in the register has come with a new speed threshold. Google's current Core Web Vitals guidance defines a good user experience as LCP at 2.5 seconds or better, INP at 200 milliseconds or better, and CLS at 0.1 or better. Those numbers have not moved with any named core update.

These are field-performance thresholds, not a statement that every page beyond one number loses rankings. Search Console's Core Web Vitals report uses anonymized real-user data, evaluates the 75th percentile over the latest 28 days, and groups similar URLs. A one-time Lighthouse run and a Search Console URL group answer different questions. Our guide to Core Web Vitals explains which metric answers which question.

A PageSpeed score is useful for finding lab-test opportunities, but Google has never published a score of 70, 90, or 100 as a ranking cutoff. Google's page-experience documentation says good Core Web Vitals can contribute to Search success, while also stating that good report scores do not guarantee top rankings. Relevance and helpfulness still matter.

That distinction protects both SEO decisions and development budgets. Improve a slow or unstable experience because visitors benefit and because page experience is relevant. Do not promise that moving one metric across a line will reverse a core-update loss. The evidence and its limits are laid out in how website speed affects SEO, and the testing method in our repeatable PageSpeed process.

Why Slow Sites May Still Lose Visibility

Rejecting a false speed threshold does not mean performance is unimportant. Google recommends good Core Web Vitals, and slow pages can create real operational disadvantages. Visitors may abandon a page before its content becomes useful, interaction delays can obstruct navigation or forms, and layout shifts can cause mistakes. Those problems can reduce the value of traffic even when rankings remain unchanged.

Performance can also interact with other technical conditions. Unavailable servers, blocked resources, unstable rendering, excessive client-side work, or a broken mobile experience may affect crawling, rendering, accessibility and conversion. Those are specific defects to test. Our walkthrough of why a website loads slowly covers how to isolate each one. They are not evidence that Google applied a universal slow-site penalty.

Think in layers. Search visibility depends on whether Google can discover, crawl, render, index, understand and select the page for a query. The visitor then has to load, understand, trust and act on it. Speed influences parts of that journey, but it cannot compensate for the wrong search intent, duplicate pages, an accidental noindex, weak information, or an offer that does not match the user.

• ✓
  A slow page with uniquely helpful information may still rank because relevance remains important.
• ✓
  A fast page can still lose visibility when it does not satisfy the query or cannot be indexed correctly.
• ✓
  A ranking change and a conversion change can happen together, but each needs its own measurement.
• ✓
  Improving real-user performance is valuable even when no ranking recovery can be promised.

How to Separate an Algorithm Update From a Problem You Caused

Start with a controlled comparison, not a site-wide rewrite. Google's traffic-drop guidance recommends confirming that the rollout has finished, waiting at least a full week, and comparing a post-rollout week with a week before the rollout. Keep seasonality in mind, and use a year-over-year comparison when the business has enough history.

In Search Console's Performance report, compare clicks, impressions, click-through rate and average position. Then segment the change by page, query, device, country and search type. A site-wide position loss across many established queries looks different from a mobile-only click decline on a few templates. If impressions are steady while clicks fall, inspect titles, snippets, result features and demand before blaming performance.

Next, check whether Google could access and index the affected pages. Review the Page indexing report, Crawl stats, Manual Actions and Security Issues. Use URL Inspection on representative winners and losers to compare crawl status, the indexed version, canonicals, rendered output and live availability.

Only then overlay performance. Compare the mobile and desktop Core Web Vitals URL groups, CrUX field data, and representative PageSpeed or Lighthouse tests. Check whether the affected pages actually became slower before the visibility change. If poor LCP existed for months while rankings fell only on one content cluster, speed alone is a weak explanation. If a release caused field metrics, errors and conversions to worsen on the same template, performance becomes a stronger lead.

Finally, compare Search Console with analytics and business outcomes. Google notes that Search Console clicks and Analytics sessions are calculated differently, so they will not match exactly. Use them together to understand discovery before the visit and behavior after the visit. Separate a visibility loss from a tracking break, landing-page engagement problem, or conversion issue. Where a rival page moved up instead, our competitor ranking gap analysis sets out the seven evidence groups to compare.

How to Track Google Updates Without Chasing Rumours

A business does not need to follow every SEO rumour, but it should maintain awareness of official Google changes. Google continually updates its systems, including smaller changes that are never individually announced and will never appear in the table above. Monitoring does not prevent every traffic loss. It gives you context, protects the baseline, and reduces the chance that your own release is confused with an external update.

Keep the Search Status Dashboard and Search documentation updates in a simple monitoring routine. Review Search Console messages, Page indexing, performance, security and Core Web Vitals on an agreed cadence. Record major site releases, migrations, template changes, content updates, consent changes, analytics changes and outages.

Search Console supports custom annotations in Performance charts. Add concise notes for important releases and fixes without including personal information. Keep a longer internal change log with the deployment ID, affected templates, owner, expected effect, rollback path and validation result.

• ✓
  Weekly: review official ranking updates, Search Console messages, and unusual click or indexing changes.
• ✓
  Monthly: compare important page groups, queries, devices, conversions, Core Web Vitals, and crawl health.
• ✓
  At every release: annotate the date, affected routes, measurement plan, and rollback decision.
• ✓
  After an announced update: preserve the baseline, wait for the rollout to finish, and analyze the right comparison window.
• ✓
  Before a large response: require page-level evidence and test the smallest reversible change first.

This is how you avoid getting hurt by an update in two different ways. The first risk is losing visibility because a genuine content, technical, or experience weakness was ignored. The second is damaging a healthy site by reacting to an unverified theory. A monitoring and change-control habit helps with both.

Do Not Blame WordPress, Shopify, or Another Platform Without Testing

Google has never stated that an update targeted WordPress, Shopify, Webflow, Wix, or any framework. Platform names are not a diagnosis. Hosting, themes, apps, plugins, media, fonts, consent tools, analytics, third-party scripts, caching, rendering strategy and editorial decisions can produce very different results on the same platform.

Test representative templates and actual user journeys. A WordPress site with disciplined engineering can provide good Core Web Vitals. A custom Next.js site can be slow when it ships oversized media, excessive JavaScript, or uncontrolled third-party tags. Modern architecture creates options, not automatic rankings.

Start from the diagnostic for the stack in front of you: fixing a slow WordPress site, testing a slow Wix site, auditing Squarespace for SEO, or diagnosing a Shopify Dawn theme.

Fixing the site you have is usually the first move, when it can do the job without becoming a maintenance burden. Moving becomes reasonable when the problems you have written down repeatedly block performance, security, content operations, integration, ownership or growth goals. The migration still needs a complete URL inventory, redirect decisions, metadata parity, analytics validation, staged crawl, cutover plan and rollback path. The search side of that is covered in what a migration does to search visibility, and delivery under our migration service and custom engineering.

What to Change After a Confirmed Traffic Drop

Match the remedy to the evidence. Fix technical access when pages cannot be crawled or indexed. Improve the affected content when the query intent, accuracy, usefulness or trust context is weak. Improve performance when field and lab data identify a real user-experience problem. Address snippets when impressions hold but CTR declines. Repair analytics when Search Console and session data diverge after a measurement release. For a WordPress property where the drop followed a speed regression, our WordPress traffic drop walkthrough follows the same order.

Google advises against radical quick fixes when a page is already performing well. Make sustainable improvements for users, release them in controlled groups, and record what changed. Do not change content, templates, internal links, navigation, schema and hosting at the same time if you expect to learn which change helped.

There is no universal core update recovery time. Google's core-update guidance says some effects can appear within days, while broader reassessment can take several months. It also states that no improvement guarantees a visible ranking effect. Use a review schedule and decision gates, not a promised recovery date.

A 30-Day Monitoring Plan, Counted From Your Own Release

In the first week after your own release, preserve exports from Search Console and analytics, record the official rollout dates, and list every relevant internal change. Build a page-by-query comparison for the pages with the largest click or position differences. Inspect representative URLs and rule out manual actions, security issues, indexation problems, server errors, robots directives and canonical mistakes.

In the second week, compare mobile and desktop field performance by template. Reproduce problems with lab tools, then trace them to images, fonts, JavaScript, rendering, server response, layouts or third-party code. Separately review search intent, competing results, content accuracy, authorship and the usefulness of each affected page.

In weeks three and four, prioritize changes by confidence, user impact and reversibility. Release small groups when possible. Validate indexing and rendering, monitor errors and conversions, and document the outcome. Continue watching Search Console, but avoid interpreting daily noise as a verdict.

The result should be a decision log, not a dramatic headline: confirmed observations, rejected explanations, open questions, chosen changes, owners, validation dates and rollback conditions. That record becomes the baseline for the next Google algorithm update and the next website release.

If the log points at a rebuild rather than a repair, scope tiers are on the pricing page and finished projects on the work page.