« Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) » : cette chaîne de caractères, comparée à celle du Googlebot dit desktop, révèle à quel point les deux versions du même robot se ressemblent tout en restant clairement distinctes pour qui sait où regarder.
Depuis l’achèvement du passage à l’indexation mobile-first, un point que Google a confirmé courant 2021 pour la quasi-totalité des sites, la version mobile de Googlebot sert de référence principale pour explorer et indexer le contenu. Cette réalité technique continue pourtant de créer de la confusion chez des développeurs qui filtrent leurs journaux ou configurent des règles serveur en se basant sur une compréhension approximative de cette distinction.
Deux user-agents, un seul robot d’indexation principal
Techniquement, Google exploite plusieurs variantes de user-agent pour Googlebot, mais la distinction qui compte le plus au quotidien oppose la version qui s’identifie comme un appareil mobile à celle qui s’identifie comme un ordinateur de bureau. Depuis le passage complet à l’indexation mobile-first, la version mobile constitue le robot de référence pour la grande majorité des sites, y compris pour évaluer le contenu qui sera indexé.
- La version mobile inclut une chaîne de type appareil Android dans son identifiant.
- La version desktop conserve une structure plus proche d’un navigateur de bureau classique.
- Les deux versions partagent le même identifiant final
Googlebot/2.1suivi du lien vers la documentation officielle.
Pourquoi filtrer uniquement sur la chaîne « Mobile » pose problème
Une règle de filtrage serveur qui chercherait uniquement la présence du mot « Mobile » dans le user-agent pour identifier Googlebot capturerait aussi une quantité considérable de navigateurs mobiles humains classiques, dont la chaîne contient également ce terme. À l’inverse, ne filtrer que sur « Googlebot » sans distinction capture indifféremment les deux versions, ce qui peut fausser une analyse qui chercherait spécifiquement à isoler le comportement de la version mobile.
grep "Googlebot" access.log | grep "Mobile" | wc -l # Version mobile
grep "Googlebot" access.log | grep -v "Mobile" | wc -l # Version desktop
Le piège de l’usurpation de user-agent
N’importe quel client HTTP peut déclarer la chaîne Googlebot dans son en-tête, sans que cela garantisse la moindre authenticité. Un développeur qui se fierait uniquement au user-agent pour adapter le contenu servi, une pratique déjà risquée en elle-même, s’expose à ce qu’un robot malveillant se fasse passer pour Googlebot afin d’accéder à une version différente du contenu.
La méthode fiable pour authentifier un passage de Googlebot combine systématiquement deux vérifications : la présence de la chaîne attendue dans le user-agent, puis une résolution DNS inverse de l’adresse IP source, confirmée par une résolution DNS directe vers un domaine appartenant à Google.
host 66.249.66.1
# Doit renvoyer un nom se terminant par .googlebot.com ou .google.com
Ce que cela change pour un développeur qui adapte son rendu
| Pratique | Fiabilité |
|---|---|
| Filtrer uniquement sur la chaîne « Googlebot » | Faible, facilement usurpable |
| Distinguer mobile et desktop par mot-clé simple | Moyenne, source de faux positifs |
| Combiner user-agent et résolution DNS inverse confirmée | Élevée, méthode recommandée |
Un user-agent reste une déclaration, jamais une preuve ; seule une vérification réseau confirme réellement qui explore un site.
En résumé
Distinguer les deux versions de Googlebot par leur user-agent reste utile pour analyser des journaux serveur, mais ne suffit jamais à garantir une authentification fiable. Depuis que l’indexation s’appuie en priorité sur la version mobile, s’assurer que le rendu servi à cette version reflète fidèlement le contenu du site importe davantage que la distinction elle-même entre les deux user-agents.
Un dernier réflexe mérite d’être gardé en tête : documenter, quelque part dans le projet, la méthode de vérification retenue et la date du dernier contrôle des plages d’adresses. Un an plus tard, quand un nouveau développeur reprend la maintenance du site, cette trace évite de reproduire à l’identique une confusion déjà résolue une première fois.
