Blog Category: Industry Notes

Most companies have a policy on which software employees can install. Far fewer have one for AI agents, the programs that can read files, call tools, and take actions on a person’s behalf. That gap is now the subject of a commercial product category, and the clearest sign came on September 1, 2026, when CrowdStrike launched Falcon Guardian at its Fal.Con conference in Las Vegas.

The launch is worth reading closely, not because a single product settles anything, but because of what it assumes: that unapproved AI agents are already running on company machines and that the endpoint is where they need to be caught. Two statistics have been attached to the story, and they need careful handling. Here is what is confirmed, what the numbers actually show, and what the practical lesson is for AI security and AI governance teams.

What CrowdStrike announced

According to CrowdStrike’s press release and coverage from SiliconANGLE, Security Boulevard, and BizTech, Falcon Guardian does four things.

First, it discovers known and shadow AI agents across Windows and macOS endpoints. Second, it blocks agents that are not on an approved list from running on managed systems. Third, it ties agent behavior to endpoint telemetry, linking user prompts to identities, the tools an agent invoked, and the resulting system changes. Fourth, it detects attacks aimed at agents and agents that misbehave, and it estimates the blast radius when an incident occurs.

CrowdStrike also announced supporting pieces: an AI Gateway for centralized control of enterprise AI traffic, a managed service called Falcon Complete for Guardian, a threat hunting service called Falcon Adversary OverWatch for Guardian, and integration with its Next-Gen SIEM.

Availability is uneven, and that matters for anyone planning around it. SiliconANGLE reported that the core Guardian features and the managed threat hunting service are available now, while the AI Gateway is pre-beta and expected to reach general availability next quarter, and Falcon Complete for Guardian is due later this quarter. CrowdStrike’s press release did not list pricing.

CEO George Kurtz framed the pitch in one line: AI has not changed the attack, it has changed its speed. The company’s argument is that the endpoint, which it has long positioned as the control point for stopping attacks, is also the place where agents execute.

What the sources do not say is equally useful. They name Windows and macOS as the supported endpoints and say nothing about other environments. They do not list which agent tools or frameworks Guardian recognizes. And none of the coverage we reviewed includes an independent evaluation of how well it works. Treat this as a vendor announcement, not a tested result.

What shadow AI means in practice

The term is borrowed from shadow IT, where employees adopt tools without approval from the technology or security team. Shadow AI is the same pattern applied to AI: assistants, coding agents, browser extensions, and automation tools that staff install or connect on their own.

It happens for understandable reasons. The tools are free or cheap, they are useful on day one, and many can be installed in minutes without any request to IT. A developer adds a coding agent. A marketer connects an assistant to a shared drive. A finance analyst runs an automation that reads email. Each decision looks small. Together they create a set of programs with real access to company data that nobody has inventoried.

Agents raise the stakes over ordinary shadow IT because they act, not just store. A file-sharing app that nobody approved holds data. An agent that nobody approved can read that data, send it somewhere, and run commands, often with the permissions of the person who installed it.

The two numbers, and what they do and do not show

Two statistics have been attached to this story. They come from different sources and they measure different things.

The first is 89%. CrowdStrike’s 2026 Global Threat Report, published on February 24, 2026, states that AI-enabled adversaries increased their activity by 89%, measured year over year from 2024 to 2025. That is a statement about attackers using AI, not about employees installing unapproved agents. It is also about activity, which is broader than the attacks some summaries describe. The same report says adversaries exploited legitimate generative AI tools at more than 90 organizations by injecting malicious prompts to steal credentials and cryptocurrency. That second figure is closer to the shadow AI concern, because it shows AI tools themselves being used as an attack path.

The 89% is real, and it comes from the company selling the product. It supports the argument that the threat is accelerating. It does not show how many unapproved agents are running inside any given company.

The second number is 17,800. AIR Security, a startup that announced $50 million in funding on September 3, 2026, reported finding more than 17,800 public AI add-ons, with 6.7 million installations in total, that rely on untrusted external sources for their instructions. The company also reported finding AI skills that impersonate Anthropic and OpenAI and are designed to get past security reviews and run arbitrary code. Coverage describes add-ons as skills, plugins, and MCP servers, which are the extensions that give agents new abilities.

Two cautions apply. AIR Security sells a firewall for AI agents, so it has a commercial interest in the finding, and it is a separate company from CrowdStrike. The coverage we reviewed also did not include a published methodology or a link to a full report, so the count cannot be independently checked. That does not make it wrong. It means it should be read as a vendor’s research and used to understand the type of risk, not as a measured baseline.

Together the two figures make a reasonable case for taking the issue seriously. Attackers are using AI more, and the supply chain of extensions that agents rely on is largely unvetted. Neither figure tells you your own exposure.

Why this is a governance problem first

The most important detail in the product description is easy to miss. Guardian blocks agents that are not on an approved list. That means someone has to create the list.

A detection tool can tell you which agents are running. It cannot decide which ones should be. That decision is AI governance: defining which agents are allowed, for which tasks, with which permissions, approved by whom, and reviewed how often. Without it, a discovery tool produces an inventory and a set of alerts with no policy to measure them against.

Kurtz described the aim as turning policy into protection. The order of that phrase is the point. Policy comes first. Organizations that buy enforcement tooling before they write the policy tend to discover that the hardest questions were never technical. Who can approve a new agent? What counts as sensitive data an agent may not touch? Which extensions and MCP servers are acceptable? What happens when a team needs something that is not on the list?

What a practical response looks like

You do not need to buy a product to start. The same steps apply whether you use an endpoint platform, a gateway, or manual review.

Find out what is already running. Ask every team which AI assistants, agents, and extensions they use, and check managed devices where you have the tooling to do so. Expect the first answer to be incomplete.

Write an approved list and a request path. If the only answer to a new tool is no, people will route around you. Make it easy to ask, and give a fast answer.

Vet the extension supply chain. Skills, plugins, and MCP servers can pull in instructions from outside your control. Review where each one loads content from, what permissions it requests, and who publishes it. Be cautious with anything that carries a familiar brand name but comes from an unverified publisher.

Apply least privilege. This is basic AI security hygiene, and it applies to agents as much as to people. Give agents the narrowest access they need. An agent that only has to read one folder should not be able to reach the whole drive or run commands on the machine.

Log what agents do. Record which identity started an agent, which tools it invoked, and what it changed. If something goes wrong, that record is what lets you estimate the blast radius.

Plan the response. Decide in advance who can disable an agent, revoke its credentials, and notify affected teams.

Evaluate vendors on evidence. When assessing any agent security product, ask which agents and platforms it covers, how discovery works, what it does when it finds an unapproved agent, and what independent testing exists.

For companies that build agents for customers or for internal use, this also shapes design. Teams working on AI agent development should build in identity, scoped permissions, and audit logging from the beginning, so that the agents they ship are ones a security team can actually govern.

Where this leaves you

Falcon Guardian is a confirmed product launch with a defined feature set, some parts available now and others still to come. The 89% figure is CrowdStrike’s own finding about attacker activity. The 17,800 figure is a separate vendor’s research with no published methodology in the coverage we reviewed. None of these prove that your company has a shadow AI problem today.

What they do show is that the industry now treats unapproved agents as an AI security category worth building products for, and that the endpoint is one place to look. The durable part of the story is the AI governance work underneath: an inventory, an approved list, vetted extensions, limited permissions, and a record of what agents do. Companies that have those in place can evaluate any tool from a position of strength. Companies that do not will be buying software to solve a policy gap.

Frequently Asked Questions

1. What is Falcon Guardian?
Answer:Falcon Guardian is CrowdStrike’s AI agent security product, launched on September 1, 2026 at Fal.Con. It discovers known and shadow AI agents on Windows and macOS endpoints, blocks agents that are not approved, and links agent behavior to endpoint telemetry.

2. What is shadow AI?
Answer: Shadow AI refers to AI tools and agents that employees use or install without approval from IT or security. Because agents can read data and take actions, they carry more risk than ordinary unapproved apps.

3. Where does the 89% figure come from?
Answer: It comes from CrowdStrike’s 2026 Global Threat Report, published February 24, 2026, which says AI-enabled adversaries increased their activity by 89% year over year. It measures attacker activity, not unapproved agents inside companies.

4. Is the 17,800 add-ons figure from CrowdStrike?
Answer: No. It comes from AIR Security, a separate startup that sells an AI agent firewall. It reported more than 17,800 public add-ons with 6.7 million installations relying on untrusted instruction sources. The coverage reviewed did not include a published methodology.

5. Do I need a product like Falcon Guardian?
Answer: Not necessarily. Start with an inventory of the agents in use, an approved list, and a request process. A tool can enforce that policy, but it cannot write it for you.

6. What should an AI governance policy for agents include?
Answer: It should define who can approve agents, which data they may access, which extensions and MCP servers are acceptable, what permissions they receive, how their actions are logged, and who can shut them down.

If you want to know which AI agents and tools your teams are already relying on, and where the governance gaps are, that is exactly what we look at in a free AI Readiness Audit.

Our earlier piece on MCP and A2A governance looked at the open standards that decide how agents connect to tools and to each other. This one looks at the layer underneath those standards, which is the model itself, and at a recent event that shows how quickly access to that layer can change for reasons that have nothing to do with your product.

On August 28, 2026, OpenAI announced that it will end Cursor’s access to its models on November 12. The immediate story is about two companies and an acquisition. The lasting story is about every business that has built a workflow on top of someone else’s model. Here is what is confirmed, what is disputed, and what a sensible response looks like.

What is confirmed

The sequence is short. SpaceX acquired Anysphere, the company behind the Cursor coding editor, in an all-stock deal reported at $60 billion, which closed on August 14, 2026. Two weeks later, on August 28, OpenAI published a post explaining its decision to end Cursor’s access to OpenAI models, with November 12, 2026 as the date.

OpenAI’s stated reason is trust. It said it cannot be confident that SpaceX will use its technology within OpenAI’s terms of service, and it pointed to a history of contract disputes involving Elon Musk’s companies, including, in OpenAI’s account, xAI’s violation of OpenAI’s own service terms. OpenAI also said it was giving the maximum notice its agreement allowed, which works out to a little over ten weeks, and that its contract included a limited window to cancel after a change of control.

OpenAI’s help center article adds practical detail. It describes November 12 as the end of a transition period and says the formal termination date will be confirmed later. The affected features are the local Chat and Agent modes that currently offer OpenAI models. The unaffected features are Cursor Tab and autocomplete, Auto model selection, Cloud and Background Agents, Automations, the Cursor CLI, and the Cursor API and SDK, all of which continue to use models supplied by Cursor.

Users who want to keep using OpenAI models have three routes. They can bring their own OpenAI API key, which is billed separately from any Cursor or ChatGPT subscription. They can install OpenAI’s Codex extension and sign in with a ChatGPT plan or an API key. Or they can connect through an AI gateway their organization already manages, such as Amazon Bedrock or Azure. One detail matters for budgets: a ChatGPT subscription does not include API usage, so a team that switches routes may see a new line item.

Anthropic responded quickly. Co-founder and Chief Compute Officer Tom Brown said the company will keep increasing compute to support Claude models in Cursor.

What is disputed or still unclear

Several points are less settled than the headlines suggest, and they are worth separating from the confirmed facts.

Cursor CEO Michael Truell said OpenAI models account for only about 5% of Cursor’s traffic. That is Cursor’s own claim, not an independent measurement, and DevOps.com reported that it was widely questioned on social media. Treat it as Cursor’s position, not as an established number.

Truell also said Cursor was in talks with OpenAI to find a solution. Nothing in the sources reviewed shows that those talks have produced an outcome, and no response from SpaceX appears in the coverage we could verify. The November 12 date could still change, either through negotiation or through the formal notice OpenAI’s help article mentions.

The $60 billion price and the August 14 closing date come from reporting on the deal. The OpenAI post and the help article do not discuss the price. So the accurate framing is that the deal was reported at that value.

None of this changes the central lesson. Even if OpenAI models are a small share of Cursor’s traffic, the event shows how a change of ownership can turn a supplier into a gatekeeper overnight.

Why this is not really a Cursor story

Every company that builds on a third-party model has the same exposure Cursor just discovered. The contract you signed can be ended by the supplier under conditions you do not control, and an acquisition, on either side, is one of the most common triggers. In this case the acquired party was the customer. It could as easily be the supplier, whose new owner may reprice, restrict, or retire the product you rely on.

There is also a competitive dimension. Within hours of OpenAI’s announcement, a rival lab publicly reaffirmed its support for Cursor. That is good news for the customer in the short term, but it moves the dependency instead of removing it. A team that swaps one model vendor for another is still exposed to the same category of risk, only with a different counterparty.

Treat model access the way finance teams treat any critical supplier. Ask who owns the vendor, what happens if that changes, how much notice the contract requires, and what your fallback is. Most engineering roadmaps never ask these questions, because the model feels like infrastructure. It is closer to a contract that can be ended.

Switching models is not a configuration change

The technical half of the risk is easy to underestimate. Standards like MCP and A2A make it easier to connect an agent to tools and to other agents. They do not make one model behave like another.

Analysts quoted by CIO made this point directly. Manoj Chandra Jha of Nord-IQ Research said prompts and agent instructions that work well with OpenAI models can produce different results with another model, which forces enterprises to retune both prompts and evaluations. Abhishek Satapathy of Avasant listed where the differences show up in coding agents: repository-level work, debugging, refactoring, test generation, multi-file changes, and tasks where an agent must inspect a codebase, make changes, run tests, and correct its own errors.

That list should look familiar to anyone doing AI agent development. Agents chain many steps together, so a small difference in how a model interprets an instruction can compound across a workflow. A prompt that produced clean output on one model can drift on another, with tool calls made in a different order, formats interpreted differently, or errors handled in a different way.

CIO also quoted Pareekh Jain, who advised enterprises to support multiple models, test alternatives regularly, and “avoid making important workflows too dependent on one model.” The word regularly matters. A fallback model that has never been tested is only a hope.

What resilience looks like

Cursor itself offers a useful example of preparation. Most of its product does not depend on OpenAI’s models at all. Tab completion, Auto selection, cloud agents, automations, the CLI, and the API all continue on Cursor-supplied models. A Forbes analysis argued that this reflects deliberate investment in its own coding model, Composer 2.5, built on open-source checkpoints, which lets Cursor treat frontier model access as something it can substitute. That is an analyst’s interpretation rather than a confirmed account of Cursor’s strategy, but the product structure supports the point. The features most exposed are the ones where users chose an OpenAI model by name.

Very few companies can train their own model. The principle still applies at smaller scale: keep the part of your product that users experience separate from the part that depends on a single supplier. For teams working on AI agent development, that usually means keeping business logic, tool definitions, and evaluation data in your own repository, and treating the model as a component you can replace. Prompts written for one model should be documented as model-specific, so nobody assumes they will transfer.

A practical checklist for model dependency

Whether you are building internal tools, customer-facing agents, or a full product, the same steps reduce the risk. This is the kind of work that belongs in any serious AI development plan from the start.

Inventory every model dependency. List each workflow, which model it calls, through which route, and under which contract. Include shadow usage, such as teams running personal API keys.

Put an abstraction layer between your application and the model. Route calls through one internal interface so that changing the model is a change in one place, not a rewrite.

Build an evaluation suite before you need it. A set of representative tasks with expected outcomes lets you compare a replacement model on evidence instead of impressions. This is the piece Jha’s comment points to, and it is the one teams most often skip.

Test a fallback model on a schedule. Run the evaluation suite against at least one alternative every quarter, and keep prompts tuned for it, not only for your primary.

Read the contracts. Look for change-of-control clauses, notice periods, usage restrictions, and pricing terms. Note who can end the agreement and under what conditions.

Understand the billing routes. As the Cursor case shows, subscriptions and API access are often billed separately. Know which one each workflow actually uses.

Assign an owner. Model dependency is a business risk, so it needs an owner outside the engineering team who reviews it alongside other supplier risks.

Where this leaves you

OpenAI’s decision on Cursor is confirmed, with November 12 as the announced end date, though the formal termination date and the outcome of talks remain open. The claim that OpenAI models are 5% of Cursor’s traffic is Cursor’s own. The wider point does not depend on either detail. Access to a model is a supplier relationship, and supplier relationships change when ownership changes.

For teams investing in generative AI development and agent workflows, the response is measured, not alarmed. Inventory the dependencies, build the evaluation suite, test the fallback, and review the contracts. The cost is a few weeks of engineering time. The alternative is discovering your dependency on a Tuesday afternoon with a ten week clock running.

Frequently Asked Questions

1. When does OpenAI stop providing models to Cursor?
Answer: OpenAI announced on August 28, 2026 that access ends on November 12, 2026. Its help center describes that date as the end of a transition period and says the formal termination date will be confirmed later.

2. Why did OpenAI end the agreement?
Answer: OpenAI said it cannot be confident SpaceX will use its technology within its terms of service, following SpaceX’s acquisition of Cursor’s parent company. It cited a history of contract disputes involving Elon Musk’s companies.

3. What still works in Cursor after the cutoff?
Answer: Cursor Tab, Auto model selection, Cloud and Background Agents, Automations, the CLI, and the API and SDK continue on Cursor-supplied models. The affected features are local Chat and Agent modes that offer OpenAI models.

4. Can developers keep using OpenAI models in Cursor?
Answer: Through other routes, yes. OpenAI lists bringing your own API key, using the Codex extension, or connecting through an AI gateway such as Amazon Bedrock or Azure. API usage is billed separately from a ChatGPT subscription.

5. Is it true that OpenAI models are only 5% of Cursor’s traffic?
Answer: That is what Cursor CEO Michael Truell said, but it is Cursor’s own figure and was questioned publicly. It has not been independently verified.

6. How can my business reduce model dependency risk?
Answer: Inventory every model dependency, put an abstraction layer between your application and the model, build an evaluation suite, test a fallback model regularly, and review supplier contracts for change-of-control terms.

If you want to know how exposed your own workflows are to a single vendor, that is exactly what we look at in a free AI Readiness Audit.

If your entire AI visibility plan is to publish better pages on your own site, the research says you are working on the smaller half of the problem. Two academic studies and one large industry analysis, each looking at a different slice of AI search, land on the same practical conclusion: what other people publish about you carries far more weight in AI answers than what you publish about yourself.

That is a strong claim, and it is also one that gets stretched in the retelling. The headline figure of 93% applies to specific engines in a specific kind of query, not to every AI platform in every situation. Here is what each source actually measured, where the numbers hold, where they do not, and what it means for how you spend a marketing budget.

Study one: a small group of outlets dominates news citations

The first paper is “News Source Citing Patterns in AI Search Systems” by Kai-Cheng Yang, posted to arXiv on July 7, 2025. It analyzed 366,087 citations across 12 AI search models from three providers: OpenAI, Perplexity, and Google. The data was collected over seven weeks between March and May 2025 from the AI Search Arena dataset.

A little over 9% of those citations, 32,865 in total, pointed to news outlets. That is worth stating up front, because it means the paper is not claiming that AI engines mostly cite journalism. It is examining the news slice of citations and finding that the slice is extremely concentrated.

The concentration differs sharply by provider. The paper reports that the 20 most frequently cited news sources account for 67.3% of citations for OpenAI models, compared with 31.9% for Google and 28.5% for Perplexity. Reuters and the Associated Press alone were cited at rates of 22.8% and 12.2% for OpenAI models. In other words, when ChatGPT-style models reach for a news source, they reach for a very short list.

One caution applies. The paper is a preprint posted on arXiv, so read it as a well-documented research finding rather than settled consensus, and note that it covers models tested in 2025.

The takeaway for marketers is narrower than the headline suggests. If you want news-based visibility in OpenAI-powered answers, the door is small, and the outlets standing in it are wire services and major national publishers. That does not make earned media pointless. It tells you that not all earned media is equal.

Study two: earned media versus your own site

The second paper is “Generative Engine Optimization: How to Dominate AI Search” by Mahe Chen, Xiaoxuan Wang, Kaiwen Chen, and Nick Koudas, submitted on September 10, 2025. The authors ran controlled experiments across ten consumer product verticals, with 100 queries each, and classified every cited source as earned media, brand-owned, or social content. Their abstract describes a systematic and overwhelming bias toward earned media, meaning third-party authoritative sources, over brand-owned and social content.

The numbers vary by engine, and the variation matters. In the consumer electronics vertical, Claude drew about 93.7% of its citations from earned media and ChatGPT about 93.6%. Perplexity was far lower at 53.3% earned, with 31.6% from brand-owned sites and 15.1% from social platforms.

Across the paper’s broader brand tests, the pattern held. For well-known brands, ChatGPT cited earned media 93.5% of the time and brand-owned pages 6.5%. Claude sat at 87.3% earned and 6.8% brand-owned. Perplexity came in at 67.4% earned and 8.8% brand-owned, with 23.8% from social. Gemini showed 63.4% earned and 25.1% brand-owned. For niche brands, ChatGPT reached 95.1% earned and 4.9% brand-owned, and Claude 86.3% earned and 10.6% brand-owned.

So the tidy line that AI engines cite earned media 93% of the time is accurate for ChatGPT and, in one vertical, for Claude. It is not accurate for Perplexity, and it clearly overstates the case for Gemini, which gave brand-owned pages a quarter of its citations in the well-known brand test. Your own website is close to invisible for ChatGPT on product queries. It is a real contributor to Gemini.

Note also that this is a preprint, and the queries are consumer product comparisons. A B2B services buyer asking about agencies or software may see different source mixes. Treat the paper as strong evidence about direction, not a guarantee for your category.

The third source: most citations do not come from Google’s first page

Ahrefs added two findings that support the same conclusion from a different angle.

In an analysis of 15,000 long-tail queries published on August 11, 2025, Ahrefs found that only 12% of URLs cited by ChatGPT, Gemini, and Copilot also appeared in Google’s top 10 for the same prompt. Put the other way, roughly 88% did not. Perplexity was the exception, with 28.6% overlap. This is why ranking well on Google, while still valuable, does not guarantee a citation. The AI engines are retrieved from a different set of pages.

The second finding is more useful for anyone planning outreach. Ahrefs examined the 1,000 pages ChatGPT cited most in September 2025 and concluded that roughly two-thirds of them are effectively off-limits to traditional outreach. The breakdown was Wikipedia at 29.7%, homepages and landing pages at 23.8%, educational pages at 19.4%, app stores at 6.6%, reviews at 5.8%, news and media at 5.2%, language and grammar sites at 4.0%, dictionary and reference at 2.2%, blog articles at 1.9%, community forums at 0.9%, and corporate pages at 0.5%.

Ahrefs counted only four categories as influenceable: educational pages, reviews, news and media, and blog articles. Together they make up 32.3% of the top 1,000.

This corrects a common retelling. Several summaries describe the off-limits share as Wikipedia, government sites, education, and major news. That is not what Ahrefs found. In the Ahrefs breakdown, educational pages and news were on the influenceable side, and the off-limits side was mostly Wikipedia, other organizations’ homepages, and reference-style sites. The opportunity is in educational content, reviews, news mentions, and articles.

What this does and does not prove

It proves that publishing on your own domain is not enough to earn citations from ChatGPT or Claude on product research queries. It supports the case that third-party mentions matter, and that they matter more on some engines than others.

It does not prove that your own website is irrelevant. Brand-owned content still accounts for 5% to 25% of citations in the Chen study depending on the engine, and pages that AI systems retrieve from your site are part of what makes third-party coverage credible. Your site is where a cited claim gets verified.

It also does not prove that any earned mention helps. The Yang paper shows that the citation pool for news is narrow, and the Ahrefs data shows that news is only 5.2% of ChatGPT’s most cited pages. A mention in a low-authority outlet is unlikely to move the needle.

What this means for link building and digital PR

The strongest business case in this research is for redefining what link building and digital PR are for. For years, the goal was a link that passed ranking signals. The goal now includes being named, described, and reviewed in the places AI engines already trust.

That changes priorities in four ways.

Prioritize the sources engines already cite. Before pitching anyone, check which publications, review platforms, and educational sites appear in AI answers for your category. Build the target list from that, not from domain authority alone.

Pursue reviews and comparisons, not just news. Reviews and educational pages are a much larger share of ChatGPT’s influenceable citations than news. Accurate, current listings on review platforms and inclusion in independent comparison content deserve more of the budget than they usually get.

Create material that other people want to cite. Original data, clear definitions, and expert commentary give journalists and educators a reason to reference you. This is the foundation of effective digital PR, and it also gives educational and blog sources something to link to.

Keep your own site accurate and consistent. When an outlet mentions you, engines and users will check your site. Consistent naming, clear service descriptions, and current facts make the third-party mention easier to trust.

Treat Wikipedia as a consequence, not a target. At 29.7% of ChatGPT’s top 1,000 cited pages, it is the single largest source, and Ahrefs places it outside the reach of outreach. Trying to force an entry is the wrong response. The sustainable route is to earn the independent coverage that makes a company notable in the first place, which is exactly what a disciplined digital PR program produces over time.

Expect a slow payoff. Third-party coverage takes weeks to publish and longer to be picked up by AI engines, so judge a campaign over quarters, not days. Pair the outreach with a monthly citation check so you can see which placements actually change what the engines say.

Set a baseline before you begin. Record which prompts cite your brand today, on which platforms, and from which sources. Repeat monthly. Without that, you cannot separate the effect of an outreach campaign from ordinary platform variability.

Where this leaves you

Optimizing your own site remains necessary. Sound search engine optimization fundamentals still determine whether you are found and understood. But the evidence now points to a second requirement that sits outside your domain. On ChatGPT and Claude, earned media supplies roughly nine in ten citations for product research. On Perplexity and Gemini the share is lower but still a majority. That is the reason generative engine optimization and answer engine optimization now include off-site work, and why link building teams are being asked to think about mentions, reviews, and reference sources, not just links.

Frequently Asked Questions

1. Do AI engines really cite earned media 93% of the time?
Answer: For ChatGPT and Claude in the consumer electronics vertical of the Chen study, yes: about 93.6% and 93.7%. Perplexity was near 53% and Gemini near 63% to 66% in other tests, so the figure does not apply to every engine.

2. What counts as earned media in these studies?
Answer: Third-party authoritative sources such as independent reviews, journalism, and expert publications. Brand-owned pages and social content are classified separately.

3. Does this mean my website does not matter for AI visibility?
Answer: No. Brand-owned pages still receive about 5% to 25% of citations depending on the engine, and your site is where third-party claims get checked. It is necessary but not sufficient, which is why answer engine optimization now includes off-site work.

4. Is it true that two-thirds of ChatGPT’s top citations cannot be influenced?
Answer: Ahrefs reported that roughly 67% of ChatGPT’s top 1,000 cited pages fell outside traditional outreach. Educational pages, reviews, news, and blog articles, about 32.3%, were the influenceable share.

5. Which earned media should I prioritize?
Answer: Start with sources AI engines already cite in your category: review platforms, educational content, and a short list of authoritative publications. Wire services and major national outlets dominate news citations for OpenAI models.

6. How do I measure whether digital PR is improving my AI citations?
Answer: Track a fixed set of buyer prompts on ChatGPT, Claude, Perplexity, and Gemini each month, and record whether your brand is cited and from which source.

If you want to see which third-party sources are shaping AI answers about your brand today, that is exactly what we cover in a free AI Visibility Audit.

This is the third piece in our series on how AI platforms decide who gets cited. The first looked at how much AI referral traffic ChatGPT controls. The second looked at how selective it is about which sources it trusts. This one asks the practical follow-up: if two of the biggest AI platforms disagree this much about sources, what does that do to the way you measure visibility?

The headline number is that only about 11% of domains are cited by both ChatGPT and Perplexity. It has been repeated in dozens of articles this year, usually with a sentence claiming that single-platform tracking leaves 89% of your visibility invisible. That last part goes further than the data supports. The 11% figure is real and worth acting on, but it is also easy to misread, and several of the studies stacked underneath it measure different things. Here is what each one actually found, and what it means for how you track your brand.

Where the 11% comes from

The figure appears in three related but distinct places, and they are not the same study repeated three times.

The first is a dataset of 680 million citations covering August 2024 to June 2025, analyzed by Profound and cited in Averi’s B2B SaaS benchmark report. Averi’s report states that only 11% of domains are cited by both ChatGPT and Perplexity. Worth noting: the 680 million analysis is Profound’s work, and Averi uses it as a supporting reference rather than presenting original research of its own. Several articles online attribute the analysis to Averi directly, which is a small but real attribution error.

The second is a Qwairy analysis of 118,000 AI responses collected between January and March 2026 across ChatGPT, Perplexity, Google AI Mode, and Claude, which Whitehat SEO cites in its own comparison. It found that only 11% of cited domains appeared across multiple platforms. That is a slightly different measurement from the first one. It looks across four platforms at once instead of comparing ChatGPT and Perplexity as a pair, so the matching 11% is a coincidence of two different methods, not one result confirmed twice.

The third is a Wellows study of 22.7 million citations across 1.15 million questions, covering January to June 2026. It approaches the same question from the opposite direction and reports that 89% of websites ChatGPT cited on a given question were never cited by Perplexity on that same question. That is essentially the mirror image of the 11% figure, measured at the website level, on identical questions.

So three datasets, three time windows, and two different definitions of overlap all point the same way: the two platforms draw on substantially different sets of sources. That agreement is the meaningful finding. The exact percentage matters less than the direction.

What the 11% does and does not mean

Now for the overreach. A low overlap between two platforms’ cited domains does not mean 89% of your potential visibility is hidden from you. Authority Tech, which curates and compares these studies, states explicitly that the figure does not imply that. There are three reasons.

First, the overlap is measured across all domains cited, not across your domain. Your brand could appear consistently on both platforms while the rest of the web fragments around you. The 11% describes the whole citation landscape, and your own footprint inside it is a separate question.

Second, Wellows itself is careful about this. Its authors describe the gap as a different candidate pool rather than a more unpredictable engine, and they point out that the number measures which sources answer a particular question, not which websites are permanently available to each platform.

Third, overlap depends heavily on how strictly you match. Wellows reports different results at website level, page level, and with different levels of address cleanup. A percentage that moves that much with the matching rule should be read as a range, not a fixed law.

The accurate version of the claim is narrower and still useful: if you only measure one platform, you are measuring a different slice of the web than the one your buyers see on the other. That alone is reason enough to change how you track.

A different 12% that gets mixed in

Ahrefs published a widely quoted 12% figure that often gets bundled into this conversation, and it deserves separating out. Ahrefs analyzed 15,000 long-tail queries in a study published on August 11, 2025, and found that only 12% of URLs cited by ChatGPT, Gemini, and Copilot also ranked in Google’s top 10 for the same prompt. The measurement compares AI citations with Google rankings. It does not compare one AI platform with another.

The Ahrefs data does contain a useful platform-level detail, though. Perplexity’s overlap with Google’s top 10 was 28.6%, far higher than ChatGPT at around 8%. So Perplexity leans on pages that also rank well in traditional search, while ChatGPT draws more heavily from pages that do not. Placed next to the 11% cross-platform figure, that goes a long way toward explaining why the two platforms disagree. They are retrieving from different places.

For anyone doing search engine optimization alongside AI visibility work, this is the important takeaway. Ranking well in Google helps you with Perplexity noticeably more than it helps you with ChatGPT. Treating them as one channel with one strategy will over-serve one and under-serve the other.

The same brand, very different results

Two more datasets show what this looks like at the brand level, and both are better evidence for multi-platform tracking than the 11% headline.

Superlines analyzed 34,234 AI responses across 10 platforms between January 14 and February 13, 2026, and reported a 615x gap in citation volume between the highest-citing platform, Grok at a 27.01% citation rate, and the lowest, Claude, at close to zero. The number is striking, but it needs context. It reflects how differently each platform handles linking out to commercial brand sites, which is partly a product design difference and not purely a measure of how much each platform likes any given brand.

Slate HQ published a 90-day study on March 30, 2026, tracking six B2B SaaS brands across ChatGPT, Perplexity, Gemini, Claude, Google AI Overview, and Google AI Mode, with more than 300,000 citation data points. Its central finding is that 76.3% of all citations went to domains that were neither the brand nor its direct competitors. Most of the visibility lives on third-party sources.

The per-platform breakdown Slate published for one email security client illustrates the spread. Brand-owned citation share was 10.2% on Google AI Mode, 10.0% on Google AI Overview, 9.1% on Claude, 6.9% on Gemini, 6.8% on Perplexity, and 4.5% on ChatGPT. Those are the numbers for one client, not an average across all six brands, and it would be wrong to say ChatGPT was the weakest platform for every company studied. But the spread within that single brand, more than double between the highest and lowest platform, makes the point clear. The same company can look strong on one platform and weak on another during the same 90 days.

Slate also found that Claude had the narrowest external source pool at 54% unidentified sources, while Perplexity cast the widest net at 67.7%. Different platforms are not just citing different pages. They are behaving differently in how broadly they search.

What to do with this

The practical response is not to panic about an invisible 89%. It is to stop treating AI visibility as a single number.

Track each platform separately. A blended score hides exactly the variation the studies above describe. At a minimum, report ChatGPT, Perplexity, Google AI Overviews, and Claude as separate lines, and watch each for movement independently. This is the foundation of any serious generative engine optimization program.

Identify which sources each platform trusts in your category. Since most citations go to third-party domains, your visibility depends on where you are mentioned as much as on what you publish. Check which review sites, directories, and community platforms each engine leans on for your topics, then look at whether you are present there.

Match your optimization to the platform. Because Perplexity correlates more strongly with Google rankings, traditional ranking work supports it. ChatGPT draws from a broader mix, so entity clarity, third-party mentions, and presence on the sources it favors carry more weight. This is where generative engine optimization and answer engine optimization diverge in practice, even though they are often discussed as one thing.

Set a baseline before changing anything. Record your citation presence per platform for a fixed set of prompts this week, then repeat monthly. Without a starting point, you cannot tell whether a change came from your work or from platform variability.

Treat every overlap statistic as a range. Different matching rules produce different percentages, and the sample sizes, time windows, and definitions vary. Use the studies to understand direction, then validate against your own prompts.

Where this leaves you

Only 11% of domains being cited by both platforms is a real signal, backed by three independent datasets using different methods. It does not mean 89% of your visibility is lost, and it is not the same as the Ahrefs 12% figure, which compares AI citations with Google rankings. What it does show is that ChatGPT and Perplexity behave like separate channels with separate source preferences, and that measurement built around one will miss what the other is doing. Track them separately, benchmark against a baseline, and treat the percentages as direction, not precision. That is the discipline answer engine optimization now demands.

Frequently Asked Questions

1. Is it true that only 11% of domains are cited by both ChatGPT and Perplexity?
Answer: Yes, that figure appears in several studies, including a 680 million citation dataset analyzed by Profound and a Qwairy analysis of 118,000 responses. Definitions differ slightly between studies, so treat 11% as an approximate indicator of low overlap, not an exact constant.

2. Does this mean 89% of my AI visibility is hidden if I only track one platform?
Answer: Not exactly. The 11% describes overlap across all cited domains, not your own brand. It does show that each platform draws on a different pool of sources, so single-platform tracking gives you an incomplete picture.

3. Is the Ahrefs 12% the same statistic?
Answer: No. Ahrefs found that only 12% of URLs cited by ChatGPT, Gemini, and Copilot also rank in Google’s top 10 for the same prompt. That compares AI citations with Google rankings, not one AI platform with another.

4. Which platform gives brands the highest citation share?
Answer: It depends on the brand and category. In Slate HQ’s example for one email security client, Google AI Mode and AI Overview were highest and ChatGPT was lowest. That is a single-client result and should not be generalized to every company.

5. What does the 615x citation gap mean?
Answer: Superlines found a 615x difference in citation volume between the highest platform, Grok, and the lowest, Claude, across 34,234 responses. It reflects how differently platforms link to commercial sites, so it shows platform behavior more than brand preference.

6. What should I track first?
Answer: Start with a fixed list of prompts your buyers actually ask, then record whether your brand is cited on ChatGPT, Perplexity, Google AI Overviews, and Claude separately. Repeat monthly and compare against that baseline.

If you want to see where your brand stands on each platform, not just one, that is exactly what we cover in a free AI Visibility Audit.

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 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.

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.