Tag: generative engine optimization

On August 27, SEO consultant Chris Long spotted something new in live search results and posted it immediately: “Holy moly SEOs: Google is now revealing the AI Mode prompt box BY DEFAULT for some queries.” His reading was blunt. “This is how Google continues to push AI Mode as the default search experience.”

Google confirmed it the next day. In a statement to Search Engine Roundtable, the company said: “For some queries, AI Overviews may dynamically expand for topics where our systems determine it’s most useful for people. Our research has shown that with this dynamic experience, users find Search more helpful and engage deeper in follow-up exploration.” Robby Stein, VP of Product for Google Search, added a detail that matters if you’re mid-read: “If you’ve already started scrolling, the expansion stops to keep your place.”

What actually changed is this. An AI Overview used to load as a short snippet, with a manual “Show More” click needed to see the full answer. For some queries now, it loads fully expanded from the start, with an open “Ask anything” box sitting underneath it, the same interface AI Mode uses. Google has not said which share of queries trigger this, whether that share will grow, or when the behaviour might change again. Stein was explicit that it’s still being tuned: “We’re always testing and tuning these experiences, so we’ll continue to refine based on user feedback.”

A related change, one week earlier

A week before dynamic expansion, on August 19, Google rolled out a related but separate change: generative UI moving from AI Mode into AI Overviews. This is the feature that builds a custom interactive tool for a query instead of describing an answer in text. Google’s own example is searching “ph scale” and getting an interactive visual built on the spot inside the overview, not a paragraph explaining one. Practice quizzes for exam prep, custom document generation, and a homework-helper feature using Lens all shipped alongside it.

These two changes are easy to conflate because they’re pushing the same direction, but they were confirmed on different dates for different reasons, and it’s worth keeping them separate when you’re explaining this to a client. Generative UI changes what the answer looks like. Dynamic expansion changes how much of it you see before doing anything at all.

Neither is really a standalone event either. Both sit inside a longer arc that started at Google’s I/O in May 2026, when AI Overviews and AI Mode formally merged into one integrated search experience running on Gemini 3.5 Flash. Everything since then, including this, has been Google steadily erasing the line between a summary above the results and a conversation instead of the results.

The 48% and the 58% are not the same statistic

Coverage of this topic has been sloppy about one thing, and it’s worth being precise here because it’s an easy stat to misquote. BrightEdge found, in March 2026, that AI Overviews appear on roughly 48% of tracked queries, with the rate far higher in specific verticals: 88% for healthcare, 83% for education, 82% for B2B technology. Separately, Ahrefs found in February 2026 that when an AI Overview appears, the top organic result’s click-through rate falls by 58%. One is a prevalence number. The other is a click-loss number. They come from different studies, measuring different things, and citing them together as one connected trend, the way they often get repeated, overstates what either study actually claims on its own.

What both numbers agree on, independently, is the direction. AI Overviews show up on a large and growing share of searches, and when they do, fewer people click through afterward. Two separate, peer-reviewed studies this year support the second half of that. Pew Research found clicks on 8% of visits where an AI Overview appeared, against 15% where it didn’t, a gap that held even after controlling for query length and individual searcher habits. A randomized field experiment in July found that hiding AI Overviews entirely lifted outbound clicks by roughly 40% per search. A second randomized experiment in August found a smaller but still real 8.8 percentage point lift, and a genuinely interesting null result alongside it: removing the AI Overview didn’t measurably change how satisfied or trusting people felt about their search. The benefit Google says it delivers isn’t showing up in what users report either way.

Why “position” barely means what it used to

Here’s the detail most content advice skips, and it’s the one that should change how you think about your own reporting. Google’s own Search Console documentation states that an AI Overview occupies a single position in search results, and every link inside that overview is assigned that same shared position. There is no internal ranking. You cannot see whether your link sat first or fourth inside the answer, only that the whole block sat wherever it sat. This is exactly why treating an AI Overview citation as a traditional search engine optimization ranking problem misses the point, there is no position left to optimize toward once you’re inside the block.

The impression rule is stricter too. A normal search result counts as an impression once it’s served on the page. A link inside an AI Overview only counts once it’s actually scrolled or expanded into view. Two links from the same site inside one overview count as a single impression on the chart-level view, though they’re counted separately on the page-level table, which means the two numbers in your own Search Console won’t always add up to each other, and that’s not a bug, it’s two different ways of aggregating the same event.

There’s a real attribution problem sitting underneath all of this too. One publisher who tracked this properly, using a custom GA4 dimension that catches the text-fragment links Google sometimes appends to AI Overview citations, found that 22.4% of that traffic was landing in their analytics as Direct, not Organic Search. Nothing in a standard analytics setup tells you this is happening. If you get meaningful AI Overview citations, some real share of that traffic is currently invisible to whoever reports on your channels.

The surface nobody’s talking about

There’s one more wrinkle worth knowing if you’re trying to explain the scale of this to a client. A separate but related surface, People Also Ask, has effectively been taken over by the same shift. Independent tracking in early September found 97% of People Also Ask answers are now AI Overviews, up from just 12.6% a year earlier. A second, independently run dataset checking the old snippet endpoint directly found it had stopped returning results at all from August onward. Whatever you think dynamic expansion means for search results generally, the box that used to sit quietly beneath a query with a handful of related questions has already, almost entirely, become the same AI-generated surface this whole piece is about.

What to actually check on your own site

Pull Search Console and look at click-through rate by query, not just average position. A page holding position one or two with a falling CTR on an informational query is a strong sign an AI Overview is intercepting the click before your listing is ever really seen, whatever the position column says.

Separate your query types honestly. Local, transactional, and highly specific searches remain far harder for an AI Overview to fully resolve on its own, and that’s still where organic clicks convert. Simple factual and broad comparison queries are exactly the ones dynamic expansion is built for, and they’re the ones where you should expect this to get worse before it gets better.

Check whether your content is actually being cited inside the overview for your target terms, separate from whether you rank underneath it. Under dynamic expansion, being the source Google pulls from now matters more than the position of the blue link sitting below a fully expanded answer nobody has to click to read. This is the whole premise behind generative engine optimization and answer engine optimization as disciplines distinct from traditional ranking work, earning the citation itself rather than the position beneath it.

And don’t chase this as if it were a ranking algorithm problem, because it isn’t one. This is an interface change, not a core update. Rewriting content to win back a click that an interface decision is now suppressing by design treats the wrong layer of the problem.

What this means going forward

Google’s Search Console rolled its generative AI performance reports out to every property worldwide on August 31, closing the gap for site owners who previously had no visibility into any of this at all. It’s worth using, even with its limits: impressions only, no clicks, no queries, and the counting quirks above. It’s still the closest thing to a first-party signal you’ll get for how often your content actually surfaces inside these expanding answers.

The broader shift is straightforward to state and harder to act on. A “Show More” click used to be a small piece of friction that gave your listing a chance to be seen before someone gave up and left. That friction is being removed, query by query, and Google has told you plainly that it intends to keep tuning the removal rather than reverse it. Structuring content so it earns the citation inside the answer, not just a ranking beneath it, through deliberate answer engine optimization and generative engine optimization work rather than traditional keyword targeting alone, is no longer a forward-looking recommendation. It’s the baseline for anything you publish from here.

Frequently asked questions

1. Is “dynamic expansion” a new Google algorithm update?
Answer: No. It’s an interface change to how AI Overviews display, confirmed by Google on August 28, not a change to the ranking algorithm. It affects how much of an AI-generated answer a searcher sees automatically, not which pages rank where beneath it.

2. Are the 48% and 58% AI Overview statistics from the same study?
Answer: No, and they measure different things. BrightEdge’s 48% (March 2026) is how often AI Overviews appear across tracked queries. Ahrefs’ 58% (February 2026) is how much the top organic result’s click-through rate falls when an AI Overview appears. They’re often quoted together as if connected, but they come from separate research.

3. Does average position still mean anything if I’m cited inside an AI Overview?
Answer: Less than it used to. Google’s documentation confirms every link inside an AI Overview shares one single position value, with no visibility into internal ordering. Whether you’re cited at all now matters more than where within the overview that citation sits.

4. Why is my AI Overview traffic showing up wrong in my analytics?
Answer: A documented case found 22.4% of one site’s AI Overview traffic was misattributed as Direct rather than Organic Search, due to how citation links are sometimes formatted. Standard analytics setups don’t catch this automatically.

5. What should I actually change first?
Answer: Start with Search Console’s generative AI performance report, live worldwide since August 31, and cross-check it against click-through rate by query in your normal performance report. Prioritise fixing content for the query types AI Overviews answer most fully rather than reacting site-wide.

If you want to know whether your content is actually earning citations inside AI Overviews and AI Mode, or just ranking beneath answers nobody clicks through, 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.