Google core update 2026: is there one in August?

No. As of 10 August 2026, Google has not confirmed an algorithm update this month. What exists is heavy ranking volatility around 1–3 August, a run of unconfirmed movement through July, and a lot of people connecting those dots into an “update” that nobody at Google has named. That distinction is the whole point of this post, because the advice you should follow is completely different depending on which one you are looking at.

I am writing this while sitting on a traffic chart of my own that fell off a cliff on 28 July. It turned out to mean something — just not what everyone was saying, and not what I concluded the first time I looked. That is at the end, with the numbers and the correction.

Checked against Google’s incident feed on 10 August 2026 · status: no confirmed August update

Every confirmed Google core update in 2026

Five named events so far this year, all well documented, all over. Everything else people are calling an “update” sits in the unconfirmed column. I built this list from Google’s own incident feed rather than from write-ups, and it is worth saying why: two of these five are routinely left out of the “2026 updates” round-ups, including the one I nearly left out myself.

What Google announced, and where it announced it

Part of the reason people miss these is that Google barely announces them any more. There is no Search Central blog post for either the March or the May 2026 core update. The March one was described in a post on LinkedIn, of all places, where Google Search Central called it “a regular update designed to better surface relevant, satisfying content for searchers from all types of sites” and noted the rollout may take up to two weeks. The Search Status Dashboard carries only the bare line and the dates.

That is the whole official guidance. Everything else you have read about what the March update “targeted” is someone’s interpretation. Google’s standing line on core updates has not changed in years: there is nothing new or special that creators need to do.

Why one date is worth two minutes of your time

Worth a small demonstration on the spam update, since this post is about checking rather than repeating. The trade press does not agree on when it began: Search Engine Roundtable dates the start to 14 June, Search Engine Watch says 24 June. Rather than hedge, go to the source. Google’s Search Status Dashboard records the spam update beginning 24 June 2026 at 16:00 UTC and ending 26 June at 17:00 UTC. Search Engine Watch is right. The “14 June” is a typo in Search Engine Roundtable’s boilerplate, contradicted by its own announcement post, which is dated 24 June. Checking that took two minutes, and it is exactly the move this whole post is arguing for: the primary record exists, and it is public.

Since 26 June, Google’s Search Status Dashboard shows no ranking, indexing, crawling or serving incident. Not for July. Not for 1–6 August.

What actually happened around 1 August

What the trackers showed

Barry Schwartz at Search Engine Roundtable flagged heavy volatility starting Saturday 1 August and heating up through 3 August, with spikes across the third-party tracking tools and the usual forum chatter. That volatility is genuine. It shows up in Sistrix, Mozcast, Semrush Sensor, AccuRanker, Algoroo and others. The aggregate of a dozen-odd trackers spiked, and many of the individual tools did too. Something moved.

It was not the first bout, either. By Schwartz’s own timeline there was unconfirmed movement on 11 July, again on 18–19 July running through that week, and again on 24 July. Four separate stretches of unconfirmed volatility in roughly four weeks.

What publishers reported, and why it does not add up

Here is where it gets murkier. Search Engine Watch read 88 posts and comments across Reddit, Search Engine Roundtable and WebmasterWorld, and the reports contradict each other:

• One publisher’s keyword positions improved while traffic fell 14%.
• Another lost roughly 50% of traffic with no meaningful ranking change at all.
• The clearest Reddit case showed organic decline starting around 22–24 July, more than a week before the supposed August event.
• A Brazilian publisher said Discover traffic had been sliding since mid-July.
• A WebmasterWorld user reported a 70% drop across several sites on 5 August — then reported hours later that traffic had surged back and sales had jumped.
• A UK operator said results on 6 August appeared to be returning to their pre-July state.
• One person traced their “Google problem” to their own server.

That is not what a broad core update looks like. A core update produces a consistent, directional, reproducible pattern across a recognisable class of sites. This produced a mess.

In fairness to Schwartz, he reads it the other way. His 6 August write-up says the chatter “seems consistent with a big Google Search algorithm update that is underway”, and he closes by saying something big appears to be happening. He has watched far more of these than I have. My disagreement is narrow: something is clearly going on, but the reports are too contradictory to tell you what — and “an update is happening” is not actionable for someone staring at a chart.

Three different things wearing the same costume

The most useful thing in the whole August story is a boring one: several unrelated disruptions landed in the same week, and people merged them into a single villain.

Search volatility. Real, tracked, unconfirmed. Affects rankings.

A Google Ad Manager disruption on 4 August, 09:26 to 19:00 UTC. Google confirmed this one and classed it as a minor incident: Ad Manager stayed reachable, but threw errors and high latency. It affects what publishers see in Ad Manager, and potentially ad delivery. It has nothing to do with your organic rankings — but if you watch revenue as a proxy for traffic, a bad day in Ad Manager looks a lot like a traffic collapse.

GA4 real-time reporting complaints, also 4 August. Google recorded no Analytics incident. Whatever this was, it affects what you see, not what happened.

Prove it is a ranking problem before you change anything

The single most expensive mistake in an unconfirmed-update week is rewriting a site that was never penalised. Work through this in order, and stop as soon as you find your answer.

The chart that scared me, and what I got wrong about it

Some context: I run Crit Pick as an SEO case study in the open, alongside SeeIndie. It is a young site — the Search Console window opens on 2 June 2026.

Across the last two and a half weeks of July I published 284 new pages: one per creature for the Palworld Paldex, on the theory that people search for one creature at a time. That total is not the interesting number, though. A hundred of them went out inside three days. Then I opened Search Console and found a chart that fell off a cliff on 28 July and stayed there.

That is the date range everybody was calling an unconfirmed Google update. So I did what this post tells you to do, worked through the checklist, and concluded it was nothing. Then I exported the full data and found out I had been wrong. Both passes are below, because the gap between them is the most useful thing I can hand you.

Pass one: what I concluded from the overview

My first read came off the broad view in Search Console — the performance overview and the top-pages panel, the screens you actually land on. From that vantage point everything looked benign, and I had three reasons ready.

Indexing was fine and rising. That part holds up. 158 pages indexed on a curve that climbs through the whole window without dipping. Of the 54 pages explicitly not indexed, most were things I had asked for: 17 redirects, 9 noindex, 6 alternate-canonical. Only 13 genuine 404s and 5 robots.txt blocks — and, as I later had to correct myself on, those belong to older parts of the site and have nothing to do with the batch.

Dilution was real. Also true, as far as it goes. 284 brand-new pages on a two-month-old domain enter the index around position 30 to 80. Average them in and the site’s mean position falls while every existing page stays where it was.

And the numbers were tiny. True as well: 44 clicks across three months is under one a day, and at that volume individual days of zero mean nothing on their own.

Three defensible observations. From them I concluded there was no signal in the chart at all. That conclusion was wrong, and the reason is instructive: every one of those checks was about the pages I had added. None of them asked what happened to the pages I already had.

Pass two: what the full export shows

Then I exported the raw daily data and plotted it in a spreadsheet myself, instead of reading Google’s rendering of it. Same property, same window, and a completely different story sitting in it. It took about five minutes and one chart.

Longer bars on position mean worse. Google Search Console, daily export.

Impressions fell 75% and did not recover. Average position went from 12.5 to 27.6 — the site fell fifteen places and stayed fallen. And the clicks went to zero for twelve consecutive days.

That last figure is the one that breaks my original argument, so it deserves the arithmetic. Before 28 July the site converted impressions to clicks at 0.88%. The 537 impressions it collected afterwards should therefore have produced roughly 4.7 clicks. It produced none. Treating clicks as a Poisson process, the chance of getting zero when you expect 4.7 is about 0.87% — call it one in a hundred and fifteen.

Put differently: before 28 July, 21 of 47 days had no clicks, which is exactly the noisiness I described. After 28 July it was 12 days out of 12. “Too small to mean anything” was a fair description of the site in June. It stopped being fair the moment the zeroes stopped being intermittent.

What the 284 pages actually did

Here is the part that points at a cause. Of the 284 creature pages, 43 have registered a single impression between them since launch. Together those 43 account for 555 impressions and one click. The rest are invisible.

Meanwhile the site’s clicks still come almost entirely from the handful of pages that existed before the batch.

So the accusation writes itself, and it is mine to answer. The pages are one per creature off a single template — same structure, same headings, same stat block, creature swapped. I built them that way deliberately, because that is how the search splits. But “one page per entity” and “a hundred near-identical pages shipped in three days by a two-month-old domain” describe the same object, and Google is entitled to read the second description.

Three candidates, and none of them proven

The timing is not subtle: the break lands as the batch finishes going out, with a hundred pages inside three days. What I cannot tell you is the mechanism.

I had a draft of this section that was more confident than it deserved to be. It pointed at two numbers in my index report — thirteen 404s and six pages filed as duplicates of others on the site — and read them as fingerprints of the batch. They are not. Both predate this and belong to unrelated parts of the site. I had inferred a connection from proximity in a report, which is the same move I spend the rest of this post objecting to, so it is worth saying plainly: I have no evidence that distinguishes these three, only a coincidence in timing and three mechanisms that would each explain it.

Those call for opposite responses — rewrite the template, fix a bug, or do nothing and wait. Which is exactly why guessing would be expensive, and why “it was the August update” would have been the most expensive guess available: it points at no action at all, and it lets me off the hook.

The one thing that needs doing regardless: 284 pages published, 212 known to Search Console, so about 72 URLs Google has never seen. That is a sitemap and internal-linking gap, it is unambiguous, and it is true under all three explanations.

I will report which one it was in the next Crit Pick checkpoint. If it turns out to be the first, I will have shipped a demonstration of scaled content abuse into a post that explains scaled content abuse, which would at least be tidy.

Two bigger properties, the same window

Sixteen clicks is not evidence. So I went and looked at two properties with real volume that I have Search Console access to. I am not naming either of them, but the numbers below are exactly as exported.

Property one is a site I have worked on full-time for the past four months. Over the last three months it did 880,000 impressions and 5,952 clicks, at an average position of about 7.

Property two is an established site I do not touch at all — I only watch it. Over the same stretch: 113,000 impressions and 5,123 clicks, at a 4.5% click-through rate, which tells you it serves a much narrower and more intent-heavy set of searches.

Two properties, one window. Because the first week of August contains a different mix of weekdays and weekend days than the fortnight before it, I compared weekdays with weekdays — otherwise the calendar does the talking.

Weekday clicks per day, Monday to Friday only. Google Search Console.

Property two did not move. Weekday clicks went from 73.3 a day in the back half of July to 81.2 in the first week of August. Average position improved slightly, 9.03 to 8.82. This is a property with more than enough volume to register a broad ranking change. It registers nothing.

Property one softened. Weekday clicks fell from 108.5 to 89.8, weekend clicks from 74.8 to 55.0, and average position slipped from 6.93 to 7.56. That is a real move of roughly 17% on weekdays, and I matched weekdays to weekdays precisely so that nobody can wave it away as a calendar artefact.

So: two sites I have direct access to, the same six days, one down 17% and the other flat to slightly up. This is not me proving that nothing happened. It is me reproducing, on a sample of two, exactly the contradiction Search Engine Watch found across 88 publisher reports. If this were a broad core update, the direction would be consistent across sites. It is not.

And then, while writing this, I remembered what I had actually been doing.

In that same fortnight, property one had 27 pages rewritten inside a single week, because the figures underneath them changed and the old ones were now wrong. Then another 12 pages were reworked into a new design. Thirty-nine pages altered, in precisely the window I had been busy attributing to Google.

That is not proof either. But sending 39 changed pages back to be re-crawled and re-assessed is a thoroughly ordinary way to produce a short dip, and it is a far more economical explanation than an update nobody has confirmed. The suspect with motive, means and opportunity was me.

Which leaves the cleanest fact in this whole post. Property two, the one I never touch, did not move at all. The sites where something visibly changed are the sites where I changed something. The control group sat there and did nothing.

I want to be careful not to over-claim in the other direction now. I cannot prove the reworks caused the dip any more than I could have proved an update did. The difference is that one hypothesis has a documented event attached to it in the right week, and the other has a forum thread.

The Saturday that looked like a cliff

One more thing from property one, because it is the most common way there is to misread a chart.

The last day in the export, 8 August, shows 38 clicks. The seven days before it averaged 82.3. That is a 54% drop on the final data point — the exact shape that makes somebody screenshot a chart and post it to a forum.

8 August was a Saturday. On this property, Saturdays run 38% below the overall daily average. Every week. All year.

Property two has the opposite rhythm: Sundays run 25% above its average and Fridays 16% below. Two sites, two inverted weekly cycles, both entirely ordinary. Before you read a shape into the right-hand edge of a Search Console chart, check what day of the week it is.

What a real change actually looks like

Worth one contrast, since this whole post is about telling signal from noise.

I picked property one up four months ago, when it was doing roughly ten clicks a month.

Clicks per month, property one. Google Search Console.

The interesting part is not the total, it is which number moved. Average position sat around 7 the whole time and barely budged. Click-through went from 0.49% in May to 0.80% in July. The site did not climb. The same rankings started earning more clicks — which is the signature of back-end work: titles, snippets, structured data. That happens to be the only kind of work I have done there.

But the shape is worth internalising. A real change shows up as a sustained move in one specific metric over months. What everybody called an update in August shows up as a wiggle that points in two different directions on two different sites.

What “Google says” usually does not say

Here is the part I did not plan to write. While researching this post I ran the top-ranking pages for “google core update 2026” through a content tool, which extracts the claims those pages present as fact. Three of them are not merely shaky. Google has publicly said the opposite.

That is worth dwelling on, because in a volatile week these are exactly the claims that get repeated at you as the reason your traffic moved. In June 2026 Google published a document specifically warning that third-party SEO advice “may misinterpret or make claims about what ‘Google says’”. What follows is that document, illustrated.

Domain authority is not a Google concept

The claim: domain-level authority matters more than page-level optimisation. Google does not use a domain authority score. “Domain Authority” is a metric invented by Moz; “Authority Score” belongs to Semrush. John Mueller has put it about as plainly as Google puts anything: Google does not use scores from third-party SEO tools or services, whether about a site’s authority or its spamminess. Google’s own documentation adds that third-party tools have no access to its internal ranking data. Optimising for a number that Google cannot see is not a strategy.

E-E-A-T is not a ranking factor

The expansion is right — Experience, Expertise, Authoritativeness, Trustworthiness — and the concept is genuinely useful. But Google’s own wording is explicit: “While E-E-A-T itself isn’t a specific ranking factor…” It is a framework for the human quality raters who evaluate search results, and Google says rater data is not used directly in its ranking algorithms. Related claim, same problem: that verifiable author credentials make pages rank better after an update. Google recommends bylines where readers would expect them, as a trust practice. It has never tied them to ranking gains.

AI content is not penalised — scaled content abuse is

The direction here is right but the mechanism gets mangled. Google’s position is that using AI “doesn’t give content any special gains. It’s just content.” What it acts on is scaled content abuse: generating many pages primarily to manipulate rankings rather than help users, and the policy explicitly says this applies no matter how the pages were created. Its first listed example is using generative AI to produce many pages without adding value.

I have a personal stake in that last distinction, since I just published 284 pages in two and a half weeks, a hundred of them inside three days. The policy does not care that they exist. It cares whether each one helps somebody. That is a harder standard than a word count, and a fairer one.

Three more that did not survive checking

The same extract threw up three claims that are not so much wrong as unsourceable — presented as established fact, traceable to nobody.

What to do before the next core update

If your traffic genuinely fell, and you have worked through the checklist, and it really is a ranking drop — the honest answer is still: not much, yet. Unconfirmed volatility frequently reverses. The UK operator who reported results appearing to return to their pre-July state by 6 August is a normal outcome, not a lucky one. Rewriting content in the middle of a volatile stretch means you will never know whether the recovery was your fix or the algorithm settling.

Wait a week after the rollout completes

This one is not my opinion, it is Google’s documented guidance: “We recommend waiting at least a full week after a core update completes before analyzing your site in Search Console.” Note the wording — a week after it completes, not a week after it starts. On a rollout that runs twelve days — and February’s ran twenty-two — those are three to four weeks apart. Most of the panic posts I read during a core update are written on day three.

Document what moved. Fix the things that are broken regardless of any update — the 404s, the missing pages, the titles with a 0.3% click-through. Then wait for either a confirmed announcement or two weeks of stable data before you conclude anything.

When the next core update comes

On 2026’s cadence — March, May, and a spam update in June — another core update in the second half of the year is a reasonable expectation, though Google publishes no schedule. The useful preparation is not a checklist of things to change. It is knowing where the primary record lives (the Search Status Dashboard), knowing that a rollout takes one to two weeks, and having enough of your own baseline data that you can tell a real move from arithmetic.

And be suspicious of anyone who has already published a definitive guide to recovering from the August 2026 core update. There is not one to recover from.

Common questions

Sources: Search Engine Roundtable (Barry Schwartz), “Google Search Ranking Volatility Hits August 1st & Heats Up Into August 3rd”, 3 August 2026, and “Google Search Ranking Volatility Heats Up Into August 5th & 6th”, 6 August 2026 · Search Engine Watch (Radu Tyrsina), “Google Algorithm update in August 2026? What we know”, 6 August 2026 · Google Search Status Dashboard (March, May and June 2026 incident records) · Google Search Central on LinkedIn, March 2026 core update · Google Search Central documentation: core updates, creating helpful people-first content, third-party SEO services, spam policies, AI-generated content · Google Search Console — three properties, exports of 10 August 2026: the case-study site plus two larger properties reported here anonymously.