Category: Industry

On September 24, 2026, Google began rolling out its September 2026 spam update. Spam updates usually finish in a couple of days, so most site owners are used to a short burst of volatility followed by a clear before and after. This one is different. Google says the rollout may take up to two weeks, which means that for a full fortnight, every ranking change you see is a reading from a moving target.

That changes how you should respond. This piece covers what Google has confirmed, what it has not said, what early volatility data does and does not show, and a practical plan for the days between now and the end of the rollout. It is written for anyone responsible for search engine optimization at their company, whether you run a small site or manage a large content library.

What is confirmed

The core facts come from Google’s Search Status Dashboard and are consistent across Search Engine Land, Search Engine Journal and Search Engine Roundtable.

The update began on September 24, 2026, at 9:15 a.m. Pacific time. It applies globally and to all languages. Google’s dashboard says the rollout may take “up to two weeks to complete”, which puts the latest possible finish around October 8. It is the fourth spam update of 2026, following releases in March, June and August.

The rollout window is what stands out. The dashboard lists the earlier 2026 spam updates at 19 hours and 30 minutes for March, 2 days and 1 hour for June, and 2 days and 16 hours for August. Two weeks is several times longer than any of them. One point of precision matters here: two weeks is the announced maximum, not a measured duration. The update could finish sooner, and until Google marks it complete, nobody outside Google knows how long it will really take.

What Google has not said

Google has not said what this update targets. According to PPC Land, Search Central described it only as a normal spam update, with no new policy, no named category and no figures on how many queries are affected. That gap matters, because much of the commentary this week has filled it with confident claims about which sites are being hit and why. Treat those claims as hypotheses. The only firm statement from Google is that sites which see a change should review its spam policies. Anything more specific is inference from other people’s data.

What early data shows, and what it does not

Search Engine Roundtable reported that a long list of volatility trackers showed significant movement across the first weekend, September 25 to 27. The tools it named include Semrush Sensor, AccuRanker, Mozcast, Sistrix, Algoroo and several others. When that many independent trackers move at once, it is a reasonable signal that something real is happening in the results.

Glenn Gabe, a well-known analyst of Google updates, reported big drops across a number of sites in multiple verticals and countries. He described AI-generated content sites and programmatic content farms as among those losing rankings. That is one experienced observer’s read of the sites he tracks, and it fits how Google’s spam policies treat scaled content, but it is not confirmed by Google and it is not a full picture of who is affected.

There are three reasons to be careful with early data.

First, volatility is not damaging. Trackers measure how much results moved, not who won or lost. A large reading can come from a few sites moving a long way.

Second, the update is not finished, so the pattern on day five may look different by day ten.

Third, you are reading a mix of signals. Seasonal demand, your own recent changes, other Google systems and ordinary news cycles all move traffic at the same time. Attributing a dip to the spam update before it ends is a guess.

What to do while it rolls out

The most useful thing to do during a long rollout is resist the urge to react. Here is a working plan.

Record a baseline. Before anything else, capture your current position. Export Search Console performance data for the last 90 days by page and by query, along with clicks, impressions, average position and the countries you care about. Note recent changes such as redesigns, migrations, new content batches and link campaigns.

Annotate the timeline. Mark September 24 in your analytics and reporting tools, and add a note when Google marks the rollout complete.

Compare like with like. Weekday traffic and weekend traffic behave differently for many sites. Compare the days since September 24 with the same weekdays in earlier weeks.

Segment before you conclude. A sitewide traffic drop is rarely uniform. Split the data by page type, by folder, by template and by query group. If the loss is concentrated in one section, such as a batch of AI-assisted pages or a subdirectory of third-party content, that tells you far more than a total.

Do not make sweeping changes. Deleting hundreds of pages, rewriting templates or disavowing links mid-rollout makes it impossible to tell what caused what. If you suspect a policy problem, plan the fix and stage it.

Fix what is clearly broken. If you find hacked content, injected links, broken redirects or a security issue, fix it immediately.

Hold your publishing rhythm. Search Engine Land’s coverage advises sites that are not affected to keep doing what they were doing.

Audit against Google’s spam policies now

Whether or not you see a drop, this is a good week to check yourself against the policies Google points to. Google’s documentation names categories including cloaking, doorway abuse, expired domain abuse, hacked content, hidden text and links, keyword stuffing, link spam, scaled content abuse, scraping, site reputation abuse, sneaky redirects, thin affiliation and user-generated spam.

Three of these tend to matter most for modern content teams.

Scaled content abuse is about producing large volumes of low-value pages in order to manipulate rankings, whether the pages are written by people, generated by AI tools or scrapped. The test is value per page, not the tool used. A large batch of near-duplicate location pages or templated question pages with thin answers is the pattern to look for.

Site reputation abuse covers publishing third-party content on an established site mainly to borrow its ranking strength. Sponsored sections or partner content hubs on an established site are examples.

Link spam covers buying, exchanging or generating links mainly to manipulate rankings. If you have inherited a backlink profile from a past agency, this is the moment to review it critically, not defensively.

If you find something that fits, note what it is, how many pages it affects and what you would do about it. You need not act during the rollout, but be ready to.

What recovery looks like

If you are affected, it helps to set expectations early. Google’s spam update documentation says that fixing problems may help a site improve if its automated systems learn “over a period of months” that the site complies with its policies. It also warns that for link spam, changes may not bring an improvement, because ranking benefits from those links cannot be regained.

So recovery is not a matter of days, and it is not guaranteed. The right frame is a remediation plan measured in months, not a quick reaction to a bad week.

Spam updates also occasionally catch sites that were not breaking the rules. Search Engine Land notes that this should not typically happen but sometimes does. If you believe you were caught unfairly, audit yourself carefully, document your evidence and keep monitoring.

Why this matters beyond classic rankings

Most teams now think about visibility in more places than the ten blue links. Generative engine optimization and answer engine optimization are about being cited and recommended in AI answers, which draw on the wider web and on search results. No one has published data showing how this specific spam update affects citations in AI Overviews, ChatGPT or Perplexity, and it would be a mistake to claim otherwise.

What can be said is narrower and more practical. Pages that lose organic visibility in Google lose a route to being seen and cited, and the qualities that spam policies punish, such as thin, repetitive, mass-produced content, are also poor candidates for being quoted in an AI answer. Strong search engine optimization, generative engine optimization and answer engine optimization all tend to rest on the same base: original, useful pages that answer a real question well. If you are building visibility for AI search, the spam policies are a sensible floor.

If you track AI citations, set that baseline now too, and compare again after Google says the update is complete.

Where this leaves you

The confirmed facts are these. Google started the September 2026 spam update on September 24, it is global, and it may take up to two weeks. It is the fourth spam update this year and the longest announced window. Google has not said what it targets. Early volatility is real, and some analysts report losses among AI-generated and programmatic sites, but that is observation, not confirmation.

The practical response for any search engine optimization team is patience with discipline. Take a baseline, mark the dates, segment your data, audit your own site against the spam policies, fix genuine defects and hold back on big changes until the rollout ends. A two-week update rewards teams that measure carefully, not teams that react fastest.

Frequently Asked Questions

1. When did Google’s September 2026 spam update start, and when will it finish?
Answer: It began on September 24, 2026, at 9:15 a.m. Pacific time. Google says the rollout may take up to two weeks, so the latest expected finish is around October 8. It could end sooner.

2. Why is this spam update considered the longest of 2026?
Answer: Because the announced window of up to two weeks is far longer than the earlier 2026 spam updates, which the dashboard lists at 19 hours and 30 minutes, 2 days and 1 hour, and 2 days and 16 hours. Two weeks is a maximum, not a confirmed actual duration.

3. What does the September 2026 spam update target?
Answer: Google has not said. It applies worldwide to all languages. Some analysts report ranking losses among AI-generated content sites and programmatic content farms, but that is their observation, not a statement from Google.

4. Should I change my site while the update is rolling out?
Answer: Not in a sweeping way. Record a baseline, annotate the dates, and segment your data. Fix clear defects such as hacked content or broken redirects immediately, but avoid large deletions, rewrites or disavows until the rollout is complete.

5. How long does it take to recover from a spam update?
Answer: Google says recovery can take months, because its automated systems must learn over time that a site follows its spam policies. For link spam, ranking benefits from those links may not return at all, even after cleanup.

6. Does the spam update affect visibility in AI answers?
Answer: No data has been published on that yet. Pages that lose Google visibility lose one route to being cited, and low-value mass-produced content is a poor candidate for citation anyway. Measure AI citations before and after the rollout and compare, and do not draw conclusions from one week.

7. How can I check whether my site is at risk?
Answer: Audit against Google’s spam policies, especially scaled content abuse, site reputation abuse and link spam. Then compare your Search Console data by page type and query group against a 90-day baseline.

If you want to know where your brand appears, and where it is missing, across Google and AI answer engines, that is exactly what we look at in a free AI Visibility Audit.

For the last two years, enterprise AI has mostly been sold as a feature: a chatbot in the corner of a screen, a summarize button, an assistant that answers one question at a time. On September 11, 2026, Salesforce made a different kind of pitch. It introduced seven named Agentforce agents, each built for a specific job, and described one of them as able to pursue a goal across weeks instead of a single conversation.

The naming is not a cosmetic detail. It signals a shift in how vendors want buyers to think about AI: less as software you configure and more as labour you deploy. This piece follows on from our earlier look at MCP and A2A governance, and it covers what Salesforce announced, what its customer results do and do not show, and what a buyer should ask before treating an AI agent like an employee.

What Salesforce announced

According to Salesforce’s announcement and coverage from Unite.AI and Startup Fortune, the seven agents and their jobs are as follows.

Casey is a help agent for customer service, working across voice, SMS, WhatsApp, and web chat. Paige handles IT and HR requests for employees, including through Slack and employee portals. Carter is a shopper agent that helps with product discovery, comparison, and checkout. Marshall is a supply chain agent that orchestrates back-office processes with audit trails. Piper handles inbound lead generation, engaging and qualifying leads for B2B sales. Fin is a customer agent that resolves complex customer-experience workflows. Hunter is an outbound sales agent that manages a pipeline from research through outreach.

Availability differs. Six of the seven, Casey, Paige, Carter, Marshall, Piper, and Fin, are generally available now. Hunter is in pilot, with general availability planned for November 2026.

Hunter is also the agent that uses a new long-horizon runtime. Salesforce describes it as built on three capabilities: memory, which preserves context across sessions; durable execution, which keeps a plan running over time; and dynamic steering, which adapts behavior based on feedback from users. The point of the runtime is that an agent can work toward a goal across days and weeks, instead of finishing one task and forgetting it. Hunter is the first agent to run on it.

The announcement included other platform pieces. Multi-Agent Orchestration, which routes work across coordinated teams of agents, is generally available. Agentforce Coworker, an employee-facing agent with AI Skills, and Agent Optimizer, a tool for refining agents, are scheduled for general availability in October 2026. Salesforce also introduced Agent Script, an open-source language for defining agent behavior with deterministic rules, which matters because it gives builders a way to fix certain steps in place instead of leaving everything to the model. None of the coverage we reviewed gave pricing.

How long the memory lasts

Some headlines around this launch describe agents with months of memory. The sources we reviewed do not support that. Salesforce’s own description is days and weeks. That is still a meaningful change, but the difference matters when a buyer is estimating how long an agent can hold onto a plan.

The customer results, and why to read them carefully

Salesforce published six customer results with the launch. All of them are reported by Salesforce, and none of the coverage we reviewed included independent verification or a definition of how each metric was measured.

Engine reported that 50% of chat inquiries are fully resolved by its help agent, which it calls Eva. Perk reported that Hunter built 60% of its sales pipeline. Autism Queensland reported that Paige resolves 70% of administrative requests. Hibbett reported that an agent handles 90% of core shopper journeys, after going live in six weeks. Asana reported 4x conversation volume driven by Piper. Anthropic reported that Fin resolves 79% of conversations autonomously.

These are useful as directional evidence. They are not benchmarks, and four things are missing that any buyer should ask about.

The first is definitions. Resolved could mean that a customer got a correct answer, or it could mean that the conversation ended without escalation. Those are very different outcomes. The second is baselines. Fifty percent resolved means more or less depending on what was resolved before the agent arrived. The third is scope. A figure for one team, one region, or one channel may not transfer to your business. The fourth is selection. Vendors highlight their strongest results, so a set of six published numbers says little about the distribution of outcomes across all customers.

There is one specific point on Perk. Hunter is still in pilot, so that result necessarily comes from early use, not a generally available product. Startup Fortune’s coverage made the same overall point, describing the results as early evidence and not a guarantee.

The governance layer was announced separately

Coverage of this launch sometimes lumps the AI Control Plane in with the seven agents. It was announced separately, one day earlier, on September 10, alongside what Salesforce calls a Trusted Enterprise AI Harness.

According to AI Weekly, the control plane provides routing, lineage, and cost and observability across both Salesforce and third-party AI, and it is positioned as a governance layer over a multi-vendor agent landscape. An analyst blog covering Dreamforce described it as a central registry of agents, MCP servers, and APIs with automatic discovery and a single gateway for model, MCP, and agent calls, and said it is designed to cover agents beyond Salesforce’s own.

Two cautions apply. AI Weekly reported that most capabilities are live while the rest are scheduled for fiscal year 2028, so buyers should not assume everything described is available today. And the same analyst blog noted that the control plane was initially previewed in 2025, which suggests some of it is an evolution of earlier work and not new this month. Neither source gave a general availability date for the full set.

A registry of agents, MCP servers, and APIs is exactly the kind of inventory that AI governance requires. It is also a reminder that governance products from a platform vendor cover that vendor’s view of the world first, so a company running agents from several suppliers should test how well the third-party coverage actually works.

Why names and job titles matter

Giving an agent a name and a role is a marketing decision, and it is also a framing decision. A named agent with a job title invites the same expectations we place on a person in that role: that it owns an outcome, that someone is accountable for it, and that it can be evaluated like a hire.

That framing has real benefits. It gives buyers a clearer mental model than a generic assistant. It pushes vendors to tie agents to measurable jobs such as resolving support tickets or qualifying leads, which is what sensible AI automation projects do anyway. And it makes it easier for a business to ask what work is being replaced, augmented, or created.

It also creates a risk. Names encourage people to trust an agent in the way they would trust a colleague, and an agent is not a colleague. It has no professional judgment, no personal accountability, and no understanding of context beyond what it has been given. Startup Fortune raised the question directly: “which decisions stay with people, which ones the agent takes alone?” That question should be answered in writing before an agent goes live, not discovered after an error.

Why weeks-long agents change the risk

The long-horizon runtime deserves separate attention, because it changes what can go wrong. A chatbot that answers one question and forgets it produces contained errors. An agent that holds a plan for weeks, remembers past interactions, and adjusts its behavior can compound a mistake, act on stale information, or continue a course of action after circumstances have changed.

Memory also raises data questions. What does the agent retain, for how long, and who can see or delete it? Durable execution raises control questions. How do you pause or stop an agent that is mid-plan, and how do you review what it did while nobody was watching? Dynamic steering raises accountability questions. When feedback changes an agent’s behavior, who approved that change?

These are design questions for anyone working on AI agent development, and they are procurement questions for anyone buying agents. The sensible default for a weeks-long agent is tighter limits: narrow permissions, explicit approval for irreversible actions, clear stop conditions, and a complete log of what it decided and why.

What to ask before you deploy a job-ready agent

Whether you buy from Salesforce or another vendor, the same questions apply.

What exactly is the job, and how is success measured? Define the metric before the pilot, including what counts as resolved or qualified.

What does the agent decide alone, and what needs a person? Write the boundary down and test it.

What data does it read, retain, and write? Confirm retention periods and deletion.

How do you audit and stop it? This is the core of AI governance for agents. Ask to see the logs and the pause controls.

How does it behave when it is wrong? Test escalation paths and error handling with real edge cases.

What is the fallback? Keep a documented way to run the process without the agent.

How does it fit with the rest of your agents? If you run agents from more than one vendor, check whether the governance layer really covers them.

Where this leaves you

The confirmed facts are these. Salesforce launched seven named agents on September 11, 2026. Six are generally available and Hunter is in pilot until a planned November release. Hunter runs on a new runtime designed to pursue goals over days and weeks. A separate governance announcement the day before introduced an AI Control Plane, with parts still to roll out. All customer results are Salesforce-reported and lack published definitions.

The broader shift is real. Enterprise AI is increasingly sold as a defined piece of work with a name attached. That makes it easier to evaluate, provided you insist on definitions, baselines, and limits. Businesses exploring AI automation, AI agent development, or generative AI development can borrow the useful part of the framing, which is to scope each agent to a specific job, and skip the risky part, which is treating it like a person.

Frequently Asked Questions

1. What are the seven Agentforce agents?
Answer: Casey (customer service), Paige (IT and HR), Carter (shopping), Marshall (supply chain), Piper (inbound lead generation), Fin (customer experience workflows), and Hunter (outbound sales). Salesforce announced them on September 11, 2026.

2. Which agents are available now?
Answer: Casey, Paige, Carter, Marshall, Piper, and Fin are generally available. Hunter is in pilot, with general availability planned for November 2026.

3. What is the long-horizon runtime?
Answer: It is a new runtime that lets an agent pursue goals across days and weeks using memory, durable execution, and dynamic steering. Hunter is the first agent to use it.

4. Are Salesforce’s customer results independent?
Answer: No. All six results are reported by Salesforce, and the coverage reviewed did not define how metrics such as resolved were measured. Treat them as directional evidence, not benchmarks.

5. What is the AI Control Plane?
Answer: It is a governance layer announced separately on September 10, 2026 that provides routing, lineage, cost and observability across Salesforce and third-party AI. Some capabilities are live and the rest are scheduled for fiscal year 2028.

6. How should a business evaluate an AI agent before deploying it?
Answer: Define the job and success metric, set the boundary between agent and human decisions, confirm data retention, check audit logs and stop controls, and test failure handling.

If you want to know which of your workflows are ready for AI agents and where the risks sit, that is exactly what we look at in a free AI Readiness Audit.

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