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

Google has formally separated two types of site access: the familiar Googlebot for indexing and the new Google-Agent for actions initiated by users through Google's AI services. For developers and site owners, this is an important distinction: visually similar visits from Google's infrastructure now can mean very different scenarios.

Where the boundary lies

Googlebot remains a classic search crawler. Its task is to automatically traverse pages, collect data for the search index, update Google's understanding of site content, and comply with rules set through robots.txt. This is why requests from Googlebot are typically associated with SEO, search visibility, news feeds, images, videos, and other products that depend on regular web scanning without the involvement of any specific user.

Google-Agent falls into a different category—user-triggered fetchers, systems that make a request not on their own initiative but on a user's command within a Google product. In its documentation, the company explicitly states that such an agent is used for web navigation and performing actions at the user's request, citing Project Mariner as an example. The key detail is that this is not a search indexer: it visits a site when a person actually needs a result, not when Google regularly updates its index.

How to distinguish in logs

For server logs, the difference becomes practical. In the user-agent string, Googlebot will have its familiar Googlebot/2.1 signature, while the new client will have Google-Agent within a mobile or desktop browser template. However, Google separately warns that a user-agent string alone is insufficient, as it can be spoofed. Such requests must be verified by IP addresses, reverse DNS, and published JSON lists of ranges; otherwise it's easy to confuse real Google traffic with bots simply masquerading as it.

• Googlebot uses separate ranges from common-crawlers.json and hosts like 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 that all "Google" traffic can no longer be lumped into one basket. Automatic scanning for search, one-off requests from tools like NotebookLM, and agent actions in the browser now operate in different technical modes. If before the logic was simple—Googlebot indexes, everything else is secondary—now sites face separate questions about analytics, rate limiting, automation protection, and access rules for AI scenarios that act on behalf of users.

There is also a more subtle layer of distinctions. For example, Google-CloudVertexBot is needed for crawling that the site itself permits in order to build Vertex AI Agents, and it doesn't affect search results. And Google-Extended is not a separate crawler at all, but a control token for whether content can be used to train future generations of Gemini and for grounding in certain products. Against this backdrop, Google-Agent appears as yet another independent class of access: not search, not model training, and not corporate data import, but live execution of a user task on the web.

What this means

Google is effectively preparing the web for an era of agent-driven requests, where AI not only reads pages but acts within them. For developers, this is a signal to separate indexing, model training, and user-initiated AI actions already at the level of logs, access policies, and monitoring. For SEO teams, backend developers, and security engineers, this is no longer just a term in documentation, but a new entity that will need to be accounted for in traffic filtering, alerts, and reports.