Category: Industry

On August 26, a Google spokesperson confirmed what SEOs had already been spotting in the wild since late June. Search result links are being rewritten to route through google.com/goto before landing on the actual destination page. Google’s stated reason was procedural: it said it regularly deploys technical measures to protect its services and users from evolving abuse. This sits alongside a separate legal fight, Google’s suit against SerpAPI, first filed in July and amended in August, over how that company accesses Google’s search results.

That much is confirmed. What happens after that point, in coverage of this story, splits into two very different camps, and it is worth being precise about which claims are actually settled and which ones are not before you act on either.

What actually changed, mechanically

Instead of a result linking straight to a destination page, the link now points to google.com/goto, with the destination URL encoded using Protocol Buffers, Google’s own binary data format. A server-side redirect on Google’s end then forwards the visitor to the real page. For a person clicking a result, nothing looks different. They click, they land where they expected. What changed sits entirely underneath that click, in a URL structure that any tool reading destination links now has to parse differently than before.

Third-party tools that read destination URLs directly took the first hit, and here the evidence is solid because the vendors themselves reported it. SerpAPI confirmed impact across several of its products. Ahrefs confirmed what it called a temporary inconsistency in its data. One rank-tracking vendor documented a real six-day window, August 26 through September 2, where its Share of Voice reporting misattributed clicks because its parser was not reading the new format correctly. That has since been fixed, with the affected data being backfilled for customers.

Not every tool broke the same way, and this is worth sitting with for a moment. SE Ranking and Semrush both confirmed no impact on their own position tracking data at all. So the blanket claim that the /goto redirect broke SEO tools is not quite accurate. Some tools broke. Others, reading the exact same search results pages, did not, which suggests the difference has more to do with how each vendor’s parser was originally built than with the redirect itself being universally disruptive.

Where the coverage actually splits

Here is where a real divide appears. Several sources treat GA4 organic-to-direct misattribution as an established, active problem, describing what one piece called “massive organic attribution data loss” and sudden, unexplained spikes in Direct traffic. That framing has spread fast, because it is the scariest possible read of a genuinely technical, genuinely unresolved situation, and alarming framing tends to travel faster online than careful, hedged framing ever does.

Now look at what the more carefully sourced coverage actually says. As of late August, one detailed technical write-up stated plainly that nobody had reported confirmed organic undercounting inside GA4. A separate analysis went further and ran an actual test across ten device and browser combinations, checking whether referrer data survived the redirect chain. It found the referrer stayed intact in every case, and GA4 correctly classified those sessions as Organic Search each time. Multiple outlets, working independently of each other, land on the same conclusion. Google has not confirmed a GA4 attribution impact, and the direct evidence gathered so far does not show one either.

None of that means the concern is baseless. The mechanism Google’s own documentation describes makes an attribution gap plausible in principle. If a redirect chain ever strips referrer data before it reaches your site, GA4’s fallback logic would file that session as Direct rather than Organic Search, silently, with no alert generated anywhere in your dashboard. That is a real risk worth watching closely. It is not the same thing as a confirmed, ongoing problem, and treating it as something that has already happened is exactly the kind of overstatement that risks needing a correction once more data actually comes in, one way or the other.

Why the distinction actually matters

It would be easy to read the last two sections and conclude the difference between disputed and confirmed is mostly semantic. It is not, and the practical stakes are worth spelling out.

If a team reacts to this as a confirmed GA4 problem, the natural response is to start second-guessing every organic traffic number reported for the past month, which burns real time reconciling data against a theory that current testing does not support. Budget conversations get harder to have with confidence when the underlying numbers are being treated as suspect without evidence. Reporting to a client or a leadership team gets shakier too, since telling a room that your organic numbers might be wrong because of a redirect Google has not confirmed affects attribution is not a comfortable thing to say out loud in a review meeting.

If a team instead treats this as a plausible, unconfirmed risk worth monitoring, the response looks completely different. You set a baseline, you watch two specific ratios over the following weeks, and you keep operating normally in the meantime rather than freezing decisions around a risk that has not actually materialized in the testing done so far. That is the more defensible position given what is currently known, and it is also simply less exhausting to maintain.

A second, less-discussed layer

There is a second angle here that is easy to miss if you are only thinking about traditional search engine optimization reporting. Reports say /goto-wrapped URLs are starting to show up as cited sources inside ChatGPT, Perplexity, and Claude, wherever those systems pull from Google’s search results as part of answering a query. If a citation-tracking tool has the same blind spot rank trackers had in late August, before their parsers caught up, the same kind of silent misattribution could in theory apply to AI citation counts, not only to GA4 sessions.

Nobody has published confirmed data on this specifically yet either. It follows the same underlying mechanism, and the same caution about calling something confirmed before the evidence is actually in applies here just as much. This is precisely the kind of gap that generative engine optimization and answer engine optimization work now has to account for. Visibility inside an AI answer is only useful if you can actually measure it, and a measurement tool with an unpatched blind spot will quietly undercount exposure it should be reporting, in exactly the way several rank trackers briefly did in late August.

Setting a baseline instead of guessing

The sensible response to a disputed, plausible-but-unconfirmed risk is not to panic and it is not to ignore it. It is to set a baseline now, so that if this ever does show up in your own data, you catch it immediately instead of noticing it months later as an unexplained trend with no starting point to compare against.

Record this week’s ratio of Search Console clicks to GA4 organic sessions for your key properties, and write the number down somewhere you will actually revisit. Do the same for your current organic-to-direct traffic split. These two figures are your tripwire. If either one moves meaningfully in the weeks ahead with nothing else in your setup changing, that is your signal to look closer, rather than reacting to someone else’s alarmed blog post as though it were your own data.

Reconcile Search Console against GA4 weekly for the next month, instead of your usual monthly cadence. A real attribution gap, if one exists, would show up as a widening divergence between the two figures over time, not as a single dramatic jump you would notice immediately anyway.

Check your GA4 referral exclusion list for any new entries appearing as google.com/goto. If Google’s own redirect domain starts showing up there as a distinct referral source, rather than resolving cleanly through to Organic Search, add it to your exclusions so it does not fragment your organic channel into two separate, harder-to-reconcile pieces.

Hold off on reacting to a rank-tracker alert this week unless you have confirmed that specific tool already adjusted its parser to read the new /goto format correctly. Given that SE Ranking and Semrush reported no impact while SerpAPI and Ahrefs did, an alert from a tool that has not caught up yet is more likely a parsing problem on their end than an actual ranking change on your site.

And if you are already doing any AI visibility tracking, apply the same caution to what you see there. A cited source appearing as a raw /goto link rather than a resolved domain in your reporting is a sign your tool needs to catch up, not evidence that your underlying citation count has actually changed.

Where this leaves you

Google confirmed the redirect itself on August 26. It has not been confirmed, and the direct testing done so far does not support a GA4 attribution problem. Some SEO tools broke, others did not, and the ones that did have mostly already fixed their parsers by now. The plausible risk to your own analytics is real enough to baseline and monitor closely. It is not, as of this writing, a confirmed, active problem serious enough to justify the level of alarm some coverage is giving it, and treating an unconfirmed risk as settled fact is its own kind of mistake, one that tends to send teams chasing a problem that is not actually there yet while a genuinely useful baselining exercise gets skipped entirely.

Frequently Asked Questions

1. Is Google’s /goto redirect confirmed?
Answer: Yes. A Google spokesperson confirmed the rollout on August 26 and described it as a technical measure to protect Google’s services and users from evolving abuse. The rollout itself is not in dispute anywhere in the coverage. What remains unsettled is how far its effects reach.

2. Is my GA4 organic traffic being misattributed because of it?
Answer: Not as far as anyone has confirmed. Google has not acknowledged a GA4 attribution impact, and one technical test across ten device and browser combinations found referrer data stayed intact, with sessions classified as Organic Search. The risk is plausible in principle, so it is worth monitoring, but it is not a confirmed problem.

3. Why is my rank tracker showing odd data?
Answer: It depends on the tool. SerpAPI and Ahrefs confirmed some impact, with Ahrefs calling it a temporary inconsistency, while SE Ranking and Semrush confirmed none. Check whether your vendor has published a statement or a fix before assuming your rankings actually moved.

4. Does this affect AI citation tracking?
Answer: Possibly, but nothing is confirmed. /goto-wrapped links are reportedly appearing as cited sources in ChatGPT, Perplexity, and Claude. A tool that cannot parse them could undercount your citations. Treat any sudden citation drop as a possible tracking issue first, and verify it manually.

5. What should I check first?
Answer: Record this week’s ratio of Search Console clicks to GA4 organic sessions, plus your organic-to-direct traffic split. These two numbers are your baseline. If either shifts meaningfully with nothing else changing, investigate then.

6. How often should I reconcile Search Console and GA4?
Answer: Weekly for the next month, instead of monthly. A genuine attribution gap would show up as a widening divergence between the two over several weeks, not as a single sudden jump.

7. Should I change my SEO strategy because of this?
Answer: No. Nothing about the redirect changes how rankings are earned. Keep your strategy as it is, baseline your data, and update only if a confirmed impact emerges.

If you want a second set of eyes on whether your own reporting, or your AI visibility specifically, is being affected, that is exactly what we check in a free AI Visibility Audit.

On September 12, Glenn Gabe posted something he’d sat on for a full day first, waiting for the data to firm up before going public. His read: an unconfirmed update rolled out in early September, sometime around the 3rd into the 4th. Marie Haynes reached the same conclusion independently, placing the shift closer to September 2. Two of the more measured, data-first voices in the SEO industry, arriving at the same window without coordinating, is not nothing.

Google has said nothing at all.

Here is the part that makes this genuinely confusing rather than simply another unconfirmed update: two days before Gabe and Haynes went public, a separate outlet checked the two most common volatility trackers and found almost nothing unusual. Semrush’s Sensor read 0.6 out of 10 on September 9, labelled Low. DataForSEO’s volatility index read 5.82 on September 8, a middling number with no sharp spike against its own recent baseline. Neither tool was flashing a warning.

So which is it. Did something real happen in early September, or did two respected analysts read noise into a quiet week that the aggregate trackers correctly saw as unremarkable.

Why the tools and the analysts can both be right

This isn’t actually a contradiction once you understand what each source is measuring.

Volatility trackers like Semrush Sensor and DataForSEO work by fingerprinting a large basket of tracked keywords and measuring how much the top results shuffle across that basket, in aggregate, across the whole web. That’s a genuinely useful signal for catching a broad core update. It is a much weaker signal for catching something narrower, a change that hits a specific content type, a specific vertical, or a specific query pattern hard while leaving most of the basket untouched.

Gabe and Haynes work differently. Their read comes substantially from looking at real client Search Console data directly, property by property. A shift that’s too narrow or too unevenly distributed to move an aggregate sensor can still show up clearly in the actual accounts they’re watching. This kind of week-to-week vigilance, checking real account data rather than waiting for a tool to flash red, is exactly what ongoing search engine optimization work is supposed to catch before a quiet shift turns into a real problem.

Neither approach is wrong. They’re measuring different things at different resolutions. Which means the honest starting position here is not “an update happened” or “an update didn’t happen.” It’s that something may have shifted for a meaningful subset of sites, without being broad enough to register clearly on tools built to catch a wide core update.

That distinction should change how you read your own data, not just whether you believe an update occurred. It also tells you something about which kind of site is more likely to feel this. A large publisher with thousands of tracked queries feeding into an aggregate sensor is exactly the profile a broad tool is built to catch. A smaller, more specialised site sitting in one content vertical is exactly the profile that can move meaningfully in its own Search Console data while barely registering on a basket built from the whole web. If you run a niche or narrowly scoped site, a quiet volatility sensor tells you less than it would for a large, broad publisher.

September has history, and that cuts both ways

Before assuming this fits a pattern, it’s worth knowing what the pattern actually is. Google’s confirmed rollout record shows real updates landing in or reaching into September repeatedly: an August 2025 spam update that ran all the way from August 26 through September 22, an August 2024 core update that carried into early September, a September 2023 helpful content update, and a September 2022 core update named for the month itself.

September is a genuinely plausible window for a rollout, based on that history. It is not, on its own, evidence that this specific unconfirmed shift is one. Google’s own recent cadence has been uneven, updates roughly 8 weeks apart at one point in 2026 and over 5 months apart at another. History tells you a September update wouldn’t be surprising. It doesn’t tell you this is one, and treating “September has a history” as confirmation is exactly the kind of shortcut that leads to premature action.

Rule out the boring explanations first

Before you treat a September dip as an algorithm story, rule out the things that look identical to one but aren’t.

Google Analytics reportedly showed missing data for September 1, including accounts reading zero users for part of that day. Separately, Google confirmed a brief Search Console indexing-reporting issue that existed and was resolved around September 9, with no exact start time given. Neither of these is a ranking change. Both can produce a chart that looks exactly like one if you’re only glancing at a dashboard rather than checking what’s actually being measured.

There’s a third confound worth naming: Google has also clarified how AI Overview impressions get counted inside Search Console, and average position no longer maps cleanly onto the old idea of ten blue links. This is precisely the shift that makes generative engine optimization and answer engine optimization work alongside traditional ranking now, not instead of it. A position metric that shifts because the reporting logic changed underneath it looks identical, on a graph, to a position metric that shifted because your rankings actually moved. And if a meaningful share of your queries now triggers an AI Overview that didn’t before, your click and position numbers can move for reasons that have nothing to do with a ranking algorithm changing at all.

There’s a fourth, narrower confound if a meaningful share of your traffic is European: separate reporting this same week covered changes to how Google’s results behave in the EU specifically. If your traffic is heavily skewed toward European markets, a regional change could easily be mistaken for a global algorithm shift when it’s actually confined to one geography.

Check these before anything else: was your reporting tool itself affected on the specific dates in question, is the change specific to position or AI Overview counted queries, does a large share of the affected traffic sit in Europe, and does the timing match a known reporting hiccup rather than the September 2-4 window Gabe and Haynes described.

Reddit is not a reliable second opinion here

If you go looking for corroboration in SEO forums, be careful what you count as confirmation. A review of early September threads across the main SEO communities found accounts that don’t cleanly agree with each other or with the Gabe/Haynes window. One report placed an initial drop on August 2-3, with a second decline on August 13, well before the window in question. Another, posted September 10, described clicks rising while impressions and position fell, a different pattern entirely, with no clear onset date attached. Cross-posted complaints without dated, corroborated specifics aren’t a second data point. They’re the same uncertainty wearing crowd.

How to actually read your own data

Once you’ve ruled out reporting glitches, the diagnosis comes down to three questions, in this order.

First, is the shift concentrated or spread out. Pull Search Console, filtered by page and by query, for September 2 through 8 against the week before. A decline that’s isolated to one content cluster or query type is a different problem than one that touches everything evenly. The former points toward something specific to that content. The latter points more toward something systemic, either on Google’s side or in a technical issue of yours.

Second, which metric actually moved. If clicks fell while impressions held steady, your visibility didn’t change, people just stopped clicking, which usually points to a SERP layout change or an AI Overview absorbing the click rather than a ranking loss. If impressions and clicks both fell while your average position held, Google is showing you for fewer queries than before, a relevance signal rather than a ranking signal. If position itself moved and the rest followed, that’s the pattern most people assume by default, and it’s worth confirming rather than presupposing.

Third, compare like for like. Use the same days of the week on both sides of the comparison, not a rolling seven days that happens to straddle a weekend dip. A lot of false alarms are just a Friday being compared against a Tuesday.

What not to touch until the picture is clear

The instinct to do something productive is exactly what causes the most damage here. Rewriting or gutting pages removes the version Google was already evaluating, so if this reverses on its own, you’ve destroyed the thing that would have recovered. Mass title tag edits add a new variable on top of an already unclear signal, and you won’t be able to tell which change caused which outcome. Filing a disavow request in response to a ranking dip is treating a possible relevance shift as a link penalty, which it almost certainly isn’t unless you have an actual manual action notice. And publishing new content quickly to “fill the gap” runs directly against whatever quality signal might be involved in the first place.

Every one of these actions makes sense emotionally and makes the diagnosis harder afterward.

When you actually have enough to act on

Give it a genuinely stable two-week window once volatility settles, not the first quiet Tuesday after a rocky week. Compare that window against the two weeks before September 2, same days, same metrics. If a clear, sustained pattern holds across that full window, you have something real to work from.

Then build the response around the specific pages and query clusters that actually moved, not the whole site. A shift this narrowly sourced, disagreed on even between two separate volatility tools, is unlikely to call for a site-wide response. It calls for a response scoped to wherever your own data actually shows movement.

Frequently asked questions

1. Is this a confirmed Google update?
Answer: No. Two independent, well-regarded analysts, Glenn Gabe and Marie Haynes, both reported evidence of an unannounced shift in early September, dated to roughly September 2 through 4. Google has not confirmed anything, and standard volatility trackers were reading low to moderate just before those reports went public.

2. Why did Semrush and DataForSEO not pick this up if something really happened?
Answer: Aggregate volatility tools measure shuffling across a large basket of tracked keywords site-wide across the web. A shift narrow enough to hit a specific content type or a specific set of properties hard, without moving the wider aggregate much, can be real and still not register clearly on those tools.

3. My traffic dropped around September 1. Is this the same thing?
Answer: Check your reporting tools before assuming so. Google Analytics reportedly had missing data for September 1, and a separate Search Console indexing-reporting issue existed and was resolved around September 9. Rule both out against your exact dates before treating a September 1 dip as part of this update.

4. How long should I wait before making changes?
Answer: At minimum, two full weeks of stable data after the volatility settles, compared against a matching two-week window before September 2. For an unconfirmed shift with no announced end date, waiting longer than you would for a named core update is the safer default.

5. What should I actually change if the pattern holds up after two weeks?
Answer: Only what your own segmented data points to. If the drop is concentrated in a specific content cluster or query type, address that cluster specifically. A site-wide response to a narrowly sourced shift usually does more harm than the shift itself.

If you want a second set of eyes on your own September numbers, whether the underlying issue is technical SEO, generative engine optimization, or plain reporting noise, that is exactly what we check in a free AI Visibility Audit.

On 22 July 2026, Barry Schwartz of Search Engine Roundtable and algorithm analyst Glenn Gabe both spotted the same thing within hours of each other. Google has quietly rewritten its “Optimize your crawl budget” documentation, the guide that tells large sites how Googlebot decides what to crawl and how much.

Google’s stated reason was modest, improving clarity, terminology consistency, and flow. The actual content of the rewrite goes further than a wording cleanup. Three real changes sit inside it, and one of them affects every site running AI crawlers alongside Googlebot, whether that site is actively doing generative engine optimization work or not.

What crawl budget actually means, before the changes

The documentation splits the crawl budget into two separate ideas that are easy to blend together but behave differently. Crawl demand is Google’s own interest in fetching your URLs, driven by how valuable and how fresh Google judges your content to be. Crawl capacity is a separate ceiling, how much load your server can handle before Google backs off to avoid causing problems for your site. A site can publish millions of technically crawlable URLs and still see very little crawling, because demand, not the raw count of pages, is what is actually constraining it. Capacity, by contrast, is something your own server behaviour can move, largely independent of how interesting Google finds your content.

That distinction matters for reading everything that changed on 22 July, because the rewrite touches capacity specifically, not demand.

What Google says changed

The most significant addition is about how crawl capacity begins. Every site now starts with the same default, conservative crawl capacity limit. Google raises that limit over time only if two conditions hold, there is genuine crawl demand for your content, and your server stays fast and healthy while serving it. There is no earned baseline you carry in from your site’s age, authority, or size. Everyone starts in the same place.

Google has not published what that default number actually is. Multiple sites covering the update have said this explicitly, there is no new published crawl limit. Any specific figure you see attached to this story did not come from Google’s own documentation.

The second change matters more for anyone running AI crawlers alongside traditional search indexing. The rewrite confirms that crawl capacity is shared across all of Google’s own crawlers. Google does not run one crawler, it runs several, Googlebot for standard pages, Googlebot-Image, AdsBot for ad landing pages, and a separate crawler for Shopping and Merchant feeds, among others. All of them draw from the same pool of capacity on your server. Heavy demand from one reduces what is left for the others.

The third change is more tactical. The documentation now gives clearer emphasis to two efficiency levers that were always available but were not framed as prominently before. Faster server response times let Google fetch more within the same capacity window. Supporting HTTP 304 Not Modified responses, using ETag or Last-Modified headers, tells Googlebot it can reuse a cached version of a page instead of redownloading it, which frees that saved capacity for new or updated URLs instead.

One more housekeeping detail worth knowing if you have ever bookmarked or cited Google’s crawl budget guidance. The documentation moved. The older URL, under the large site managing crawl budget path, now issues a permanent redirect to a new address under Google’s crawling docs section. If you have internal documentation or a past search engine optimization audit referencing the old link, it still works through the redirect, but it is worth updating.

Why the shared capacity detail matters beyond Google’s own crawlers

The documentation itself talks about Google’s own crawlers competing for the same pool. It does not need to say the obvious follow-on, because every technical SEO reader already knows it. Your server does not distinguish between Googlebot and every other bot hitting it. If your site is being crawled heavily by AI crawlers, whether for model training or for live retrieval when someone asks ChatGPT or Perplexity a question, that traffic is competing for the same server response headroom Googlebot needs to do its own job well.

This is the same underlying mechanic we wrote about when Cloudflare changed its default AI crawler settings. A slow or overloaded server reads as a signal to Googlebot to back off, which caps how much of a large site actually gets crawled and indexed in a given period. If AI crawler traffic is heavy enough to slow your server down, you are not just making a decision about AI training data. You are quietly affecting how much of your site Google itself chooses to crawl.

Separate research on crawl budget mechanics, not part of this specific July rewrite but relevant context, has found that crawlers like GPTBot can consume up to 40 percent of available server bandwidth during deep crawl cycles. That same research cited data suggesting sites that block GPTBot entirely in robots.txt were cited 73 percent less often in ChatGPT responses. I am flagging that stat with its actual source rather than presenting it as part of Google’s July update, because it comes from separate technical SEO research, not from Google’s documentation itself. But it illustrates exactly why the crawl capacity sharing point is not academic. Blocking AI crawlers protects server capacity for Googlebot. It also appears to reduce your citation rate inside AI answers, which is the entire premise behind doing generative engine optimization work in the first place. There is a real tension here, and Google’s rewrite does not resolve it, it just makes the underlying mechanics clearer.

Why this update is arriving now

Google did not explain its timing, and the documentation itself frames the changes as clarity improvements rather than a response to any specific pressure. But the context is hard to ignore. The volume of non-Googlebot traffic hitting servers, from AI training crawlers, live AI retrieval agents, and third party scraping tools, has grown substantially industry wide over the past two years. A documentation update that makes shared capacity explicit, when it was previously left implicit, reads naturally as Google catching its own guidance up to a server environment that looks different than it did when the original guidance was written.

What this means if you run a large site

If your site has thousands or millions of URLs, this update is worth reading in full rather than taking secondhand. Two practical questions follow directly from it.

First, is your server capacity being spent efficiently. The documentation’s own answer is to check your logs, not to assume. Which URL patterns is Googlebot actually requesting, and how often. Are other Google crawlers, or aggressive AI and third-party crawlers, consuming capacity that would otherwise go to your most important pages. A server log analysis, even a basic one, will show you the actual split between Googlebot requests, other identified bots, and everything else, which is a more reliable starting point than reading the documentation and guessing where your own site stands.

Second, is your crawl demand actually low, or is your capacity the constraint. These are different problems with different fixes. A site can expose millions of crawlable URLs and still see very little crawling, because Google’s interest in those URLs, the demand side, is the actual limit, not how many pages you have published. Improving server speed raises your capacity ceiling. It does nothing for a site full of URLs Google has no interest in crawling in the first place. Pruning thin or duplicate URL inventory raises effective demand per page that actually matters, without touching your server at all. Treating a demand problem as a capacity problem, or the reverse, means fixing the wrong thing while the actual constraint stays exactly where it was.

What this means if you run a smaller site

If your site is not operating at large scale, thousands of pages or more, the honest answer every source covering this update gives is the same one Google has given for years. Crawl budget is not something you need to actively manage. Google’s systems can typically crawl a smaller, healthy site fully without the capacity constraints this documentation is written for. This update does not change that guidance. It exists for the specific case of very large sites where crawl demand genuinely exceeds what Google is willing to spend crawling everything, which is simply not the situation most smaller sites are in.

Where to actually check this on your own site

Search Console’s Crawl Stats report is the relevant measurement surface here, not the crawl budget documentation itself. It shows request volume by response type, by file type, and by Googlebot type, which lets you see whether crawling is trending down, flat, or being spent disproportionately on low value URL patterns. Look specifically at the trend over recent months rather than a single day, since crawl volume naturally fluctuates and a single low reading is not necessarily meaningful on its own.

If you also run AI crawlers against your site, whether deliberately allowed for generative engine optimization purposes or simply not blocked, cross-referencing your server logs against both Googlebot and known AI crawler user agents will tell you whether the two are genuinely competing for capacity on your specific server, rather than guessing based on what the documentation describes in general terms. This is a few hours of log analysis for most sites, and it replaces speculation with an actual answer specific to your own infrastructure.

Frequently asked questions

1. Does this update mean my site has a new, lower crawl limit than before?
Answer: No specific new limit has been published anywhere in Google’s documentation. What changed is the description of how the limit begins, at a conservative default for every site, rising over time based on demand and server health, rather than any published number changing for existing sites.

2. Does blocking AI crawlers protect my Googlebot crawl capacity?
Answer: In principle, yes, since capacity is shared across whatever is hitting your server. In practice, separate research suggests sites blocking crawlers like GPTBot see meaningfully reduced citation rates in AI answers. The trade-off is real, and this update does not remove it, it just confirms the shared capacity mechanic that makes the trade-off exist.

3. Do I need to worry about the crawl budget if I run a small business website?
Answer: No. Every source covering this update agrees on that point, including implicitly Google’s own documentation, which is written for large sites managing crawl demand at scale. A small, healthy site is very unlikely to hit a capacity constraint Google’s systems cannot handle by default.

4. What is the difference between crawl demand and crawl capacity in practical terms?
Answer: Demand is Google’s interest in your content, driven by perceived value and freshness. Capacity is a ceiling for your own server performance controls. A slow server lowers your capacity regardless of how much Google wants to crawl you. Thin or low value content lowers demand regardless of how fast your server responds. They need different fixes, and confusing the two leads to solving the wrong problem.

5. What is the single most useful thing to do after reading this?
Answer: Check your Search Console Crawl Stats report before assuming anything about your own site based on this article. The documentation change is general guidance. Your logs are the only source that tells you whether shared crawl capacity is actually a live constraint for your specific site.

6. How does this connect to AI visibility work specifically?
Answer: Crawl access is the prerequisite underneath everything else. An AI system, or Google’s own AI features, cannot cite content it cannot successfully retrieve. If crawl capacity constraints or AI crawler blocking are limiting what gets fetched from your site, that is a foundational issue sitting underneath any search engine optimization or SEEO work layered on top of it.

If you want to know whether crawl access, AI crawler blocking, or something else entirely is limiting your visibility in AI answers, that is exactly what we check in a free AI Visibility Audit.

In August 2025, Google’s own John Mueller warned the SEO industry about something specific. Speaking about the growing pile of new acronyms, GEO, AIO, AEO, he warned that pushing new terminology too aggressively was often a signal of low quality tactics rather than genuine innovation. A month later, in September 2025, when a fake screenshot claimed Google had built a dedicated AI Overview filter inside Search Console, Mueller shut that down too, calling the screenshot fake and confirming no such feature existed.

Eleven months later, on 31 August 2026, Google built exactly that feature, for real, and rolled it out to every website on earth.

I want to walk through what actually changed, why the timing and the backstory matter more than the feature itself, and exactly how to check this on your own site.

The rumour that turned out to be a preview of the future

The story is worth telling properly, because it says something about how much pent up demand existed for this.

On 15 September 2025, a user holding Platinum Product Expert status in Google’s own Search Console help forums, Adrian Coutin, posted that Google had integrated data for AI-generated search features directly into Search Console’s Performance reports. The post included a fabricated screenshot showing a new Search Appearance filter specifically for AI Overview data. It spread fast, because it was exactly what site owners had been asking for.

Mueller responded on LinkedIn within hours. “There’s no filter like this in Search Console, and the screenshot itself is fake,” he wrote. Coutin deleted his original post and apologised for the error.

For the following year, Google’s official position stayed consistent, AI Overview and AI Mode data was folded into the standard performance numbers, with no way to separate it out, and no committed timeline to change that. Multiple SEO guides published through late 2025 and into early 2026 describe workarounds involving third party tools precisely because Google offered nothing native.

Then, in June 2026, Google quietly began testing a real version of exactly the feature Coutin had faked, on a limited subset of properties. On 31 August, that testing phase ended, and the feature went live everywhere.

What actually shipped

Google confirmed the global rollout on its own Search Central blog, describing the new reports as dedicated views of impressions specifically within generative AI features on Search, covering AI Overviews and AI Mode, as well as the generative AI features that now appear inside Discover.

Search Engine Journal’s coverage of the global launch adds a detail worth knowing before you go looking for it. Not every property has access yet, and sites with a low volume of AI impressions may not show meaningful data in the report even where it is available. If you check and see very little, that is not necessarily a sign the report is broken. It may simply reflect where your content currently sits in AI systems.

The report breaks impressions down by page, by country, and by date. What it does not include, and this is the detail every source I checked agrees on without exception, is clicks, click through rate, or the specific queries that triggered an appearance. You can see that a page from your site showed up inside an AI generated answer. You cannot see what someone typed to get that answer, and you cannot see whether they clicked through to you afterward.

The report is best understood as a record of where you showed up, not a measure of what that appearance actually earned you in traffic or business.

Google also shipped an opt out control alongside the reporting, letting site owners remove themselves from these AI features entirely. Google has stated that using this toggle does not affect a site’s ranking anywhere else in standard Search results, which matters, because it means the choice to opt out is a genuine preference rather than a trade-off against traditional visibility.

Why the backstory matters more than the button

I keep returning to the Mueller timeline because it tells you something the feature announcement alone does not.

In August 2025, Google’s own search advocate was publicly wary of the entire AI visibility conversation, treating the proliferation of GEO and AEO terminology as a likely signal of low quality hype rather than a legitimate new discipline. A month later, Google was actively denying it had built any tooling to support that conversation.

Less than a year on, Google built the tooling anyway, at a global scale, unprompted by any specific competitive pressure that forced its hand. That sequence is a stronger signal than the launch blog post itself. It suggests the internal case for treating AI visibility as a distinct, measurable category became undeniable even to a company that was publicly skeptical of the framing not long before.

For anyone running SEO or GEO work for a client, that timeline is useful ammunition. The scepticism you may have encountered from more traditional stakeholders, the idea that AI visibility is a marketing buzzword rather than something worth the budget, gets harder to sustain once the platform itself has built a dedicated reporting surface for exactly that.

The data that explains why Google finally built this

Two independent data points, unrelated to this launch, explain the pressure Google was likely responding to.

Semrush’s AI Visibility Index, tracking brand mentions across Google’s AI Mode over several thousand prompts, found a 4 percent drop in mention share between August and October last year, while the diversity of sources being cited across the same period rose 13 percent. Visibility was getting harder to hold onto and more competitive at the same time, with no native way for an affected business to even confirm it was happening.

BrightEdge’s industry wide data adds the commercial pressure point. Search impressions are up 49 percent year over year, while click through rate on those impressions is down 30 percent over the same period. Businesses have been watching their visibility numbers climb while their actual traffic stalls or falls, with no first party data source able to explain why. That is precisely the gap this report is built to close, even if only partially.

How to actually find and use this on your own site

Coverage of exactly where this sits inside the Search Console interface is not fully consistent across sources I checked, some describe it as a dedicated left navigation item, others as a filter within the existing Performance report. Rather than send you hunting for one specific click path that may not match what you see, the reliable approach is this. Open your Performance report inside Search Console for the property in question, and look for a Generative AI or AI features option, either as a separate section or as a filter on your existing search appearance data. If it is not visible yet, that is consistent with Google’s own rollout note that access is expanding property by property rather than appearing identically for everyone on day one.

Once you find it, compare the AI impression volume against your total Web impressions for the same period. If AI generated impressions represent a meaningful share of your total visibility, and your click through rate has been falling without a ranking drop to explain it, that gap is very likely hiding inside exactly this data. This is the same pattern the BrightEdge numbers describe industry wide, positions can hold while clicks fall, because an increasing share of answers are being delivered before anyone reaches your listing.

If the number is small or close to zero, treat that as informative in a different way. It likely means your content is not currently being retrieved for the kinds of questions that trigger these AI features in your category, which is a different and in some ways more urgent problem than a visibility measurement gap.

What not to do with this data yet

Do not draw conclusions from a single week. This is newly global infrastructure, and Google’s own historical pattern with new reporting features is that data takes time to stabilise as more properties gain access and reporting pipelines mature.

The useful read is a trend over four to eight weeks, not a snapshot. Is your share of AI impressions climbing, flat, or falling relative to your total visibility over that window. That trajectory tells you far more than any single day’s number, particularly while the feature is still rolling out unevenly across different sites.

Frequently asked questions

1. Does this show me if ChatGPT or Perplexity cite my site?
Answer: No. This report is scoped entirely to Google’s own AI features, AI Overviews, AI Mode, and Discover’s generative surfaces. It has no visibility into any AI platform outside Google’s own products. Measuring citation inside ChatGPT, Claude, Gemini, or Perplexity still requires testing those platforms directly, since none of them currently offer a first party reporting tool of their own.

2. Does a high AI impression count mean I am getting more traffic?
Answer: Not necessarily, and this is the central limitation to keep in mind. The report measures impressions only. BrightEdge’s industry data shows click through rate falling even as impressions rise broadly, so a strong impression number does not guarantee a proportional lift in actual visits.

3. Can I see which search queries triggered my AI impressions?
Answer: No, and every source covering this launch agrees on that point. Query level detail is one of the more consistently requested features Google has not shipped, alongside click data.

4. Should I use the opt out toggle?
Answer: For most businesses, no. Google has confirmed opting out does not improve or protect your standing in standard Search results, so opting out only removes a visibility channel without gaining you anything in return. It exists mainly for edge cases such as publishers protecting content behind a specific business model, not for typical service or B2B businesses trying to be found.

5. Why did it take Google so long to build this, given the September 2025 rumour showed clear demand?
Answer: Google’s public position throughout that period was that AI Overview data belonged inside standard performance reporting rather than a separate view. The shift to building a dedicated report suggests the internal case changed, likely under the same pressure reflected in the Semrush and BrightEdge data, impressions climbing, clicks falling, and no way for site owners to see why.

If you want visibility that goes further than what Google’s own tools can show, including whether ChatGPT, Claude, Gemini, and Perplexity are actually citing you, that is exactly what we check in a free AI Visibility Audit.

On 17 August, Google’s A2A protocol became a hosted project of the Agentic AI Foundation at the Linux Foundation, the same neutral body that already stewards Anthropic’s MCP. Axios broke the story first, and coverage followed within two days across the AI trade press. Nothing about the technology changed. No specification was rewritten and no API broke. What changed is who is responsible for where these standards go next, and that answers a genuine, practical fear for anyone buying agent technology right now: whether committing to one vendor’s agents locks you out of everyone else’s.

At the same time, the agentic AI adoption numbers tell a very different story from the governance news. Most enterprises still cannot get an agent past a pilot. Both things are true at once, and understanding why matters more than either headline on its own.

What actually changed on 17 August

Two protocols now sit under the same governance roof at the Agentic AI Foundation, AAIF for short.

MCP, the Model Context Protocol, was Anthropic’s founding contribution to AAIF when the foundation launched on 9 December 2025. MCP defines how a single AI agent connects to tools, data and applications, essentially the wiring between an agent and everything it needs to actually do work.

A2A, the Agent to Agent protocol, is what Google built to solve a different problem, how independent agents built by different vendors discover each other, hand off tasks and coordinate across organisational boundaries. Google had already donated A2A to the Linux Foundation back in June 2025. What happened on 17 August was narrower and more specific, A2A moved from the Linux Foundation’s general portfolio into AAIF specifically, the foundation built for agentic AI, joining MCP under one roof.

It is worth being precise about what this was not. Coverage of the move has been careful to point out that this is not an ownership event. Each protocol keeps its own maintainers, its own specification process and its own release schedule. What the foundation actually settled is who stewards the specifications going forward, not who controls them technically. What it left unsettled is arguably more important for a business evaluating this, which agent gets to read which data when multiple vendors are involved. Shared governance answers the communication question. It does not answer the access and responsibility question, and that gap is still something every enterprise has to work out contractually, not technically.

AAIF has grown fast since December, from under 40 member organisations to more than 250. The platinum members list reads like most of the industry that matters here, AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI all sit on it together, which is notable given how rarely these companies share governance of anything.

Google Cloud’s VP for agent infrastructure, Rao Surapaneni, explained the practical reasoning to Axios plainly. Enterprises are deploying agentic systems from multiple technology providers, and those agents need to actually work together. A protocol that only one vendor controls does not solve that problem. A protocol under neutral, shared governance at least has a chance to.

Why this is a bigger deal than it sounds

If you are not building agent infrastructure yourself, a protocol governance change can sound like plumbing news, and mostly it is. But the practical question underneath it is one every business evaluating AI agent vendors right now should be asking.

Before this kind of consolidation, building a multi-agent system meant either committing to one vendor’s full stack, or writing custom integration code for every agent-to-agent handoff yourself. Neither is a comfortable position. The first creates lock-in. The second creates a maintenance burden that grows with every new agent you add.

With MCP and A2A both governed by the same neutral body, the practical effect is that agents built on different platforms have a real, shared standard for talking to each other, rather than a patchwork of vendor specific bridges that break every time one side updates. That does not eliminate vendor lock-in entirely, plenty of it can still happen at the platform layer above these protocols, but it meaningfully lowers the risk of choosing a vendor today and finding yourself boxed in a year from now.

This is not purely theoretical. A2A has already moved past the pilot stage in its first year, with reported adoption spanning supply chain, financial services, insurance and IT operations, sectors where coordinating autonomous systems across multiple tools, vendors and environments is not optional, it is the whole point. Those are also, not coincidentally, some of the same sectors leading on actual production use of agents generally, which suggests the businesses that need multi-vendor coordination most are the ones pushing hardest for exactly this kind of shared standard.

For a business evaluating who to build an AI agent strategy with, this is now a fair question to ask any vendor directly: do your agents speak MCP and A2A, or only your own proprietary protocol.

The number that matters more than the governance news

Here is the part most coverage of this story skipped entirely, and it is the more important half.

Gartner’s most recent enterprise survey found that 80 percent of enterprise applications shipped or updated in the first quarter of 2026 now embed at least one AI agent, up from just 33 percent two years earlier. The range is wide, everything from a customer service deflection bot handling routine queries to a fully autonomous coding agent opening pull requests against a shared repository. That sounds like near universal adoption, and by one measure, it is.

Separate research from S&P Global Market Intelligence and McKinsey tells a different part of the story. Only 31 percent of enterprises actually have an agent in production. Adoption and production are not the same thing, and the gap between them is enormous. Banking and insurance lead at roughly 47 percent in production. Healthcare sits at 18 percent, government at 14 percent.

A separate KPMG survey from earlier this year adds another layer to the same picture. 42 percent of US enterprises have tested or deployed AI agents in some form, but only 15 percent have actually achieved scaled, orchestrated multi-agent adoption, meaning multiple agents working together rather than one isolated tool running in one workflow. Most organisations that have started are still stuck well short of the coordinated setup that actually needs a protocol like A2A in the first place.

Research from MIT’s NANDA initiative puts a number on exactly where projects stall. Of custom enterprise AI tools built, roughly 60 percent get evaluated, about 20 percent make it to a pilot, and only 1 in 20, five percent, actually reach production. The drop happens overwhelmingly between pilot and production, not between idea and pilot. Getting something working in a demo has never been the hard part.

Gartner’s own forecast is blunter still, more than 40 percent of agentic AI projects are expected to be cancelled before the end of 2027, cited reasons being escalating costs, unclear business value and inadequate risk controls.

A governance standard for how agents talk to each other does not fix any of that. AI agent interoperability was never the reason most agent projects stall between pilot and production. The reasons are the same ones we wrote about a fortnight ago covering AI readiness generally, the wrong use case gets chosen, the data underneath the agent was never actually ready, nobody owns the system once it is live, and success was never clearly defined before the build started. A protocol under good governance still fails against a process that never met those four conditions to begin with.

What this actually means if you are building an agent strategy

Two separate decisions are getting easier to make right now, and it is worth treating them as separate, because conflating them is exactly how a business ends up with a technically sound agent that never earns its keep.

Which protocol standard to build on just got clearer. MCP and A2A, under shared neutral governance with the backing of every major cloud and AI lab, are a safer long term bet than a vendor’s proprietary alternative. Ask any agent vendor directly whether they support both, and treat a vague answer as a warning sign rather than a technicality to sort out later.

Whether your business is actually ready to run an agent in production has nothing to do with this news at all. That question is still answered the same way it always was, by checking whether the process you want to automate is repeatable, runs at real volume, follows consistent rules, and is expensive enough in hours that solving it is worth the build. A governance standard makes the plumbing safer. It does not make a badly scoped project succeed, and it will not move you from the 69 percent still stuck outside production into the 31 percent who have actually gotten there.

The businesses currently sitting in that 31 percent did not get there because they picked the right protocol first. They got there because they picked the right process first, and only then worried about the technical layer underneath it.

Frequently asked questions

1. Did the protocol itself change on 17 August?
Answer: No. No specification was rewritten and no API changed for existing users of either MCP or A2A. What changed is which body stewards A2A going forward, moving it into the Linux Foundation’s Agentic AI Foundation alongside MCP rather than sitting in the Foundation’s broader, less specialised portfolio.

2. What is the actual difference between MCP and A2A?
Answer: MCP connects a single AI agent to the tools, data and applications it needs to do its job, essentially agent to tool. A2A connects independent agents to each other, so agents built by different vendors or teams can discover one another and hand off work, essentially agent to agent. They solve different layers of the same overall problem.

3. Does this mean vendor lock-in with AI agents is solved?
Answer: No, and no announcement has claimed that. Lock-in can still happen at the platform layer above these protocols through proprietary extensions or platform specific features. What has improved is the baseline, the core communication layer is now under shared governance rather than controlled by any single company. Data access and responsibility between agents from different vendors is still something you need to settle contractually, governance of the protocol does not settle it for you.

4. Why do 80 percent of companies have agents but only 31 percent have them in production?
Answer: The two figures measure different things. Having at least one agent embedded somewhere in an application is a low bar that most enterprises have now cleared. Running an agent reliably in production, with proper monitoring, ownership and a clear success measure, is a much higher bar, and most organisations have not built the operating discipline for it yet. Separate research puts the actual production rate for custom built tools as low as 5 percent, with most of the drop-off happening between pilot and production specifically.

5. Which industries are actually using this in production already?
Answer: Banking and insurance lead general agent production use at around 47 percent. On the interoperability side specifically, A2A’s first year of adoption has concentrated in supply chain, financial services, insurance and IT operations, sectors where coordinating agents across multiple vendors and systems is a core requirement rather than a nice to have.

6. Should this change which AI agent vendor we choose?
Answer: It is worth adding as one factor. Ask whether a vendor’s agents support MCP and A2A as open standards, since that reduces your long term switching cost. It should not be the only factor. Whether the vendor can actually help you scope a use case that clears the readiness bar matters more than protocol support alone.

If you are trying to work out whether a specific process in your business is actually ready for an AI agent, or whether the agent conversation you are having is solving the wrong problem entirely, that is exactly what we walk through in a free AI Readiness Audit.

Two separate things happened to Google Search in August 2026, and most of the coverage online is treating them as one event. Between 1 and 6 August, several third-party trackers reported ranking volatility with no confirmation from Google. Then on 18 August, Google rolled out a confirmed Google spam update, its third of the year. If your traffic moved in the first week of the month, that was not this update. If it moved after the 18th, it probably was.

Here is the confirmed timeline, what the update actually targets, and what to check on your own site before you assume the worst.

What actually happened, with dates

1 to 6 August. Search Engine Roundtable and several rank tracking tools reported noticeable fluctuation across search results. Sites saw movement in both directions, some up, some down, with no clear pattern by industry or region. Google’s own Search Status Dashboard showed no confirmed incident during this window. This matters because a lot of site owners who saw a dip in the first week have been blaming a spam update that had not happened yet, when the actual cause was more likely a routine ranking fluctuation, a competitor’s content going live, or something unrelated to Google entirely.

18 August, 9:27 AM Pacific. Google confirmed the launch of the August 2026 update on its Search Status Dashboard. This is the third spam update of the year, following updates in March and June. Each of the three followed a similar pattern, no advance warning, a short dashboard note, and a rollout lasting a few days.

21 August. Google confirmed the rollout was complete, roughly two days and sixteen hours after it started. That is a normal duration for a spam update. Google’s own core updates, which are broader and touch relevance and quality signals across the entire index, tend to run one to two weeks. Spam updates, which target specific manipulative practices rather than reassessing the whole web, tend to run shorter, usually under three days.

Google did not publish a dedicated blog post for this one and did not add any new spam policy categories. The release note on the dashboard was short: the update is live, it is global, it applies to all languages, and it may take a few days to fully roll out. Google Search Central posted near identical language on X and LinkedIn shortly after the dashboard update appeared, which is standard practice for a spam update as opposed to a core update, which usually gets more detailed communication.

What it actually targets

Google has not published a tactic-by-tactic target list for this update, which is normal practice. Google rarely names specific tactics for spam updates, since doing so would hand a roadmap to the people trying to game the system. What we do know, based on the existing spam policies and reporting from Search Engine Roundtable, is this.

The policies that generally apply during a spam update:

Scaled content abuse. Large volumes of pages produced mainly to rank, offering little value to an actual reader, regardless of who or what produced them. This includes location pages that only swap a city name, product pages that only swap a colour or size with no other differentiation, and any page that exists primarily to catch a keyword variant rather than serve a specific reader need.

Cloaking. Showing search engines different content than what a visitor actually sees. This is one of the oldest spam tactics on the list and remains a manual action risk, not just an algorithmic one.

Doorway pages. Near duplicate pages targeting slightly different keyword or location variants, all funnelling to the same destination or offer. A business with fifty pages for fifty nearby towns, each one nearly identical apart from the town name, is a textbook example.

Expired domain abuse. Buying an aged domain with existing authority and backlink history, then repurposing it for unrelated content to borrow that authority. This has become more common as domain marketplaces have made aged domains easier to buy at scale.

Keyword stuffing, hidden text, and sneaky redirects. The long standing basics that have been spam policy violations for over a decade and remain so.

One detail worth knowing if you are trying to diagnose a drop on your own site: Search Engine Roundtable reports that this particular rollout does not appear to specifically target link spam or site reputation abuse. Those policies still apply generally and can still trigger a manual action independently, they just do not seem to be the primary focus of this specific algorithmic update. If your drop looks like it is tied to a sudden loss of backlinks or a third-party content partnership, that is more likely a separate issue than this update.

The part most coverage is skipping

Here is the detail that actually matters if you are thinking about AI content or AI search visibility, and it is why we are covering this on our own blog rather than just linking out to someone else’s summary of the dashboard note.

On 15 May 2026, Google quietly rewrote the opening line of its search spam policies. The updated definition now explicitly includes attempting to manipulate generative AI responses in Search, alongside the long standing language about manipulating traditional rankings. In plain terms, the same spam rules that have always applied to blue links now apply to AI Overviews and AI Mode as well, in the same document, under the same policy framework.

This does not mean the August update specifically targeted AI generated content as a category. Google has been clear, repeatedly, across multiple public statements, that using AI to write is not itself a violation. The actual bar is whether a page adds value for a reader. A page written entirely by a person that exists only to catch a keyword variant fails the same test as a page written entirely by AI for the same reason. Neither authorship method gets a pass, and neither gets singled out either.

What has changed is the scope of what counts as manipulation. If your content strategy has been leaning on producing a high volume of thin pages specifically to get pulled into an AI Overview or cited by ChatGPT, that now falls under the same scaled content abuse policy as producing thin pages purely to rank in traditional blue link results. The target was never AI as a technology. The target has always been volume without value, and that definition has simply been extended to explicitly cover the newer surface where people are now trying to get seen.

Practically, this means a business that has been publishing dozens of near identical FAQ pages purely to try to win a featured snippet or an AI citation is now exposed to the exact same risk as a business that was doing the same thing purely for traditional rankings five years ago. The venue changed. The underlying rule did not.

How to check if this actually affected you

Before assuming a spam update hit your site, check four things in Search Console.

Performance report, filtered to the last 30 days. Look specifically at the period after 18 August. A drop that starts cleanly on or after that date lines up with this update. A drop in the first week of August lines up with the earlier, unconfirmed volatility instead, which may have been unrelated to Google entirely.

Compare clicks against impressions. If impressions held steady but clicks fell, that points toward something outside a spam update, most likely an AI Overview appearing above your result and absorbing the click. If both impressions and clicks dropped together, that is more consistent with an actual ranking change from this update.

Check page level data, not just the site total. Spam updates typically hit specific sections of a site rather than the whole domain uniformly. If the drop is concentrated in one content type, for example a large batch of near identical location or product pages, that is a strong signal worth investigating against the scaled content policy specifically, rather than assuming your whole site has a problem.

Look at the Manual Actions report separately. A search console ranking drop tied to an algorithmic spam update will not show anything here. If you do see an entry in Manual Actions, that is a different and more serious situation, handled by a human reviewer rather than the automated update, and it requires a reconsideration request rather than just a content fix.

A ranking drop on its own is not proof of a manual action or an algorithmic penalty. It can also be entirely normal fluctuation as Google’s systems reassess the wider web following an update, with rankings settling back over the following days as the rollout completes.

What to actually do

If the timing and the pattern point to this update, the fix is the same one Google has been giving for every spam update this year, worded slightly differently each time but consistent in substance. Review whether the affected pages would still be worth publishing if you could not link them from your sitemap and had no other way to drive traffic to them. If the honest answer is no, either rewrite them with genuine, specific value that a competitor’s page does not already offer, or remove them and redirect if there is equity worth preserving.

Google has also said that recovery is not immediate even after a fix is made. Automated systems need time to recrawl and reassess a site, and that process can take weeks rather than days. Do not make a second round of drastic changes a few days after the first if nothing has moved yet, give it the time Google itself says it needs.

Frequently asked questions

1. Did the August 2026 update specifically target AI generated content?
Answer: No. Google has not said this update targets AI content as a category. The relevant policy, scaled content abuse, applies to any high volume, low value content regardless of whether it was written by a person, an AI tool, or a mix of both.

2. My website traffic drop happened in the first week of August. Was that this update?
Answer: Almost certainly not. This update launched on 18 August. Volatility reported between 1 and 6 August was not confirmed by Google on its own Search Status Dashboard, and is more likely attributable to another cause entirely, possibly unrelated to Google at all.

3. How long does a Google spam update take to complete?
Answer: This one took roughly two days and sixteen hours, from 18 to 21 August. Spam updates in 2026 have generally completed faster than core updates, typically under three days from start to finish.

4. Does a ranking drop after this update mean I received a manual penalty?
Answer: Not necessarily. Spam updates are algorithmic, not manual actions. A drop can reflect Google’s systems reassessing your content against existing policy automatically, which is different from a manual action applied by a human reviewer and logged in the Manual Actions report.

5. Is this the same as an AI Overviews policy change?
Answer: Not exactly, but they are connected. Google’s May 2026 policy rewrite extended its spam definition to explicitly cover attempts to manipulate generative AI responses, which means content built purely to be cited in an AI Overview is now held to the same value standard as content built purely to rank in traditional results.

6. Should I stop using AI to write content because of this update?
Answer: No, and Google has said as much directly. The policy has never been about the tool used to produce content. It has always been about whether the resulting page adds genuine value at the volume it is being produced. AI assisted content that is researched, fact checked, and adds something a reader cannot get elsewhere is treated the same as any other well made page.

If you are not sure whether your drop is this update, a stale Search Console habit, or something in your AI visibility specifically, that is exactly what we look at in a free AI Visibility Audit. We check what is actually happening across search and AI platforms rather than guessing from a traffic graph.