Google explains the difference between Google-Agent and Googlebot for AI access and indexing

Google has formally separated two types of access to websites: the familiar Googlebot for indexing, and the new Google-Agent for actions that users themselves trigger through the company's AI services. For developers and site owners, this distinction matters: visits that look identical and come from Google infrastructure can now mean entirely different things.

Where the line falls

Googlebot remains the classic search crawler. Its job is to automatically walk through pages, collect data for the search index, update Google's picture of a site's content and respect the rules set in robots.txt. That is why a Googlebot request is usually tied to SEO, search visibility, news surfaces, images, video and other products that depend on regular web crawling without any specific user involved.

Google-Agent belongs to a different category: user-triggered fetchers, meaning systems that make a request not on their own initiative but on a user's command inside a Google product. The company's documentation states directly that this agent is used to navigate the web and perform actions at a user's request, and cites Project Mariner as an example. The key detail is that it is not a search indexer: it arrives at a site at the moment a person actually needs a result, not when Google is routinely refreshing its index.

How to tell them apart in logs

For server logs, the difference becomes practical. Googlebot's user-agent string carries the familiar Googlebot/2.1 signature, while the new client shows Google-Agent inside a mobile or desktop browser template. But Google separately warns that a user-agent string alone is not enough, because it can be spoofed. Such requests should be verified by IP address, reverse DNS and the published JSON lists of ranges. Otherwise it is easy to confuse genuine Google traffic with bots that simply masquerade as it.

• Googlebot uses separate ranges from common-crawlers.json and hosts of the form googlebot.com
• Google-Agent uses ranges from user-triggered-agents.json
• User-triggered fetchers may resolve to google.com or gae.googleusercontent.com
• Google is already testing web-bot-auth and the agent.bot.goog identifier for such agents

What changes for sites

For site owners, this means all "Google" traffic can no longer go into one bucket. Automatic crawling for search, one-off requests from tools such as NotebookLM, and agentic actions in the browser now run in different technical modes. If the logic used to be simple (Googlebot indexes, everything else is secondary), sites now face separate questions about analytics, rate limiting, automation protection and access rules for AI scenarios that act on a user's behalf.

There is also a subtler layer of distinctions. For example, Google-CloudVertexBot is meant for crawling that a site itself permits in order to build Vertex AI Agents, and it does not affect search results. Google-Extended is not a separate crawler at all, but a control token that governs whether content can be used to train future generations of Gemini and for grounding in some products. Against this background, Google-Agent looks like yet another self-contained class of access: not search, not model training and not corporate data import, but live execution of a user's task on the web.

What this means

Google is effectively preparing the web for an era of agentic requests, in which AI does not just read pages but acts inside them. For developers, this is a signal to separate indexing, model training and user-initiated AI actions at the level of logs, access policies and monitoring. For SEO teams, backend developers and security engineers, this is no longer a term from the documentation but a new entity that must be accounted for in traffic filtering, alerts and reports.