Google explique la différence entre Google-Agent et Googlebot pour l'accès des IA et l'indexation

Google a officiellement séparé deux types d'accès aux sites : le Googlebot habituel, pour l'indexation, et le nouveau Google-Agent, pour les actions que l'utilisateur déclenche lui-même via les services d'IA de l'entreprise. Pour les développeurs et les propriétaires de sites, la distinction compte : des visites d'apparence identique, issues de l'infrastructure de Google, peuvent désormais correspondre à des scénarios très différents.

Où passe la frontière

Googlebot reste le robot d'exploration classique du moteur de recherche. Sa mission : parcourir automatiquement les pages, collecter des données pour l'index de recherche, mettre à jour la représentation que Google a du contenu d'un site et respecter les règles définies dans robots.txt. C'est pourquoi une requête de Googlebot est généralement liée au SEO, à la visibilité dans la recherche, aux surfaces d'actualités, aux images, aux vidéos et à d'autres produits qui dépendent d'une exploration régulière du web, sans intervention d'un utilisateur précis.

Google-Agent relève d'une autre catégorie : les user-triggered fetchers, c'est-à-dire des systèmes qui envoient une requête non de leur propre initiative, mais sur ordre d'un utilisateur au sein d'un produit Google. Dans sa documentation, l'entreprise écrit explicitement que cet agent sert à naviguer sur le web et à exécuter des actions à la demande de l'utilisateur, et cite Project Mariner en exemple. Le point clé : ce n'est pas un indexeur de recherche. Il arrive sur le site au moment où une personne a réellement besoin d'un résultat, et non lorsque Google met à jour son index selon un calendrier.

Comment les distinguer dans les journaux

Dans les journaux du serveur, la différence devient concrète. Dans la chaîne user-agent, Googlebot porte sa signature habituelle, Googlebot/2.1, tandis que le nouveau client apparaît sous la forme Google-Agent à l'intérieur d'un modèle de navigateur mobile ou de bureau. Mais Google prévient séparément qu'une chaîne user-agent ne suffit pas, car elle peut être falsifiée. Ces requêtes doivent être vérifiées par adresse IP, DNS inverse et listes JSON de plages publiées ; sinon, il est facile de confondre le vrai trafic de Google avec des bots qui se font simplement passer pour lui.

• Googlebot utilise des plages distinctes de common-crawlers.json et des hôtes du type googlebot.com
• Google-Agent utilise les plages de user-triggered-agents.json
• Les user-triggered fetchers peuvent se résoudre en google.com ou gae.googleusercontent.com
• Google teste déjà web-bot-auth et l'identifiant agent.bot.goog pour ces agents

Ce qui change pour les sites

Pour les propriétaires de sites, cela signifie que tout le trafic « Google » ne peut plus être rangé dans le même panier. L'exploration automatique pour la recherche, les requêtes ponctuelles d'outils comme NotebookLM et les actions agentiques dans le navigateur fonctionnent désormais selon des modes techniques différents. Si la logique était simple auparavant (Googlebot indexe, le reste est secondaire), les sites se posent maintenant des questions distinctes sur l'analytique, le rate limiting, la protection contre l'automatisation et les règles d'accès pour les scénarios d'IA qui agissent au nom de l'utilisateur.

Il existe aussi une couche de distinctions plus fine. Par exemple, Google-CloudVertexBot sert à une exploration que le site autorise lui-même afin de construire des Vertex AI Agents, et il n'influe pas sur les résultats de recherche. Quant à Google-Extended, ce n'est pas du tout un robot distinct, mais un jeton qui contrôle si le contenu peut servir à entraîner les futures générations de Gemini et au grounding dans certains produits. Dans ce paysage, Google-Agent apparaît comme une classe d'accès à part entière : ni recherche, ni entraînement de modèle, ni import de données d'entreprise, mais l'exécution en direct d'une tâche de l'utilisateur sur le web.

Ce que cela signifie

Google prépare de fait le web à l'ère des requêtes agentiques, où l'IA ne se contente pas de lire les pages, mais agit à l'intérieur. Pour les développeurs, c'est le signal qu'il faut séparer l'indexation, l'entraînement des modèles et les actions d'IA déclenchées par l'utilisateur dès le niveau des journaux, des politiques d'accès et de la supervision. Pour les équipes SEO, les développeurs backend et les ingénieurs en sécurité, ce n'est plus un terme de documentation, mais une nouvelle entité dont il faudra tenir compte dans le filtrage du trafic, les alertes et les rapports.