Declaration officielle
Google confirme que le user agent de Googlebot contient explicitement le mot 'Googlebot', ce qui permet d'adapter la diffusion de contenu en fonction du crawler. Cette détection peut notamment servir à servir du contenu pré-rendu aux bots au lieu d'une SPA classique. Attention toutefois : le user agent seul ne suffit pas à authentifier Googlebot avec certitude, d'autres étapes de vérification sont nécessaires pour éviter les abus.
Ce qu'il faut comprendre
Comment Googlebot s'identifie-t-il dans ses requêtes HTTP ?
Chaque fois que Googlebot visite une page, il envoie une requête HTTP classique avec un en-tête user agent qui l'identifie. Ce user agent contient littéralement le mot 'Googlebot', ce qui permet aux serveurs de reconnaître immédiatement qu'il s'agit du crawler de Google.
Cette identification est volontaire et documentée : Google ne cherche pas à masquer ses robots. Le user agent typique ressemble à Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html). La présence du mot-clé 'Googlebot' est donc un premier filtre simple et fiable.
Pourquoi adapter le contenu servi à Googlebot ?
Martin Splitt évoque explicitement le cas des applications monopages (SPA), qui reposent sur JavaScript pour générer le contenu côté client. Pour ces sites, servir une version pré-rendue à Googlebot accélère le crawl et garantit que tout le contenu soit indexable sans attendre l'exécution JS.
Cette pratique — appelée dynamic rendering — n'est pas du cloaking si elle est appliquée correctement. Google l'encourage même officiellement pour les sites techniquement complexes. Le user agent permet justement de déclencher ce rendu différencié de manière légitime.
Cette méthode est-elle vraiment sécurisée ?
Soyons honnêtes : n'importe qui peut falsifier un user agent. Un script malveillant ou un concurrent peut très bien se faire passer pour Googlebot en modifiant cet en-tête HTTP. Si vous vous basez uniquement sur le user agent pour servir du contenu privilégié, vous vous exposez à des abus.
Google recommande donc de compléter cette détection par une vérification DNS inverse : résoudre l'IP de la requête pour vérifier qu'elle appartient bien aux plages officielles de Google. C'est la seule méthode fiable pour authentifier Googlebot avec certitude.
- Le user agent contient explicitement 'Googlebot' et permet une détection rapide
- Adapter le contenu servi (ex: pré-rendu) est légitime si fait correctement (dynamic rendering)
- Ne jamais se fier au user agent seul : compléter par une vérification DNS inverse
- Cette approche est documentée et encouragée par Google pour les sites à forte dépendance JS
- Toute détection basée uniquement sur le user agent expose à des risques de fraude
Avis d'un expert SEO
Cette déclaration est-elle cohérente avec les pratiques observées ?
Oui, et c'est même une des rares positions de Google parfaitement alignées avec la réalité terrain. Les logs serveur montrent depuis toujours que Googlebot s'identifie clairement via son user agent. Aucune surprise ici : Google a tout intérêt à faciliter la détection de ses crawlers pour éviter les blocages involontaires.
Le point faible, c'est que Splitt ne mentionne pas explicitement les risques de spoofing. Un praticien non averti pourrait croire qu'un simple if (userAgent.includes('Googlebot')) suffit. Or on sait que des concurrents ou des scrapers utilisent couramment cette technique pour contourner des restrictions.
Quelles nuances faut-il apporter à cette méthode ?
D'abord, il existe plusieurs user agents Googlebot : Googlebot Desktop, Googlebot Smartphone, Googlebot Image, Googlebot News, etc. Tous contiennent le mot 'Googlebot', mais leur format exact varie. Si vous voulez affiner votre détection, il faut connaître ces variantes.
Ensuite, attention au dynamic rendering : servir du pré-rendu à Googlebot tout en envoyant du JS côté client aux utilisateurs réels est légitime, mais uniquement si le contenu final est équivalent. Si vous servez du contenu différent pour manipuler le ranking, c'est du cloaking et vous risquez une pénalité manuelle. [À vérifier] dans vos logs régulièrement pour garantir la cohérence.
Dans quels cas cette détection peut-elle poser problème ?
Premier écueil : les CDN et proxies. Si votre infrastructure passe par un WAF ou un reverse proxy, vérifiez que l'en-tête user agent original est bien transmis. Certaines configs écrasent ou normalisent cet en-tête, ce qui casse toute détection côté applicatif.
Deuxième piège : les faux positifs. Si vous bloquez ou ralentissez toute requête qui ne contient pas 'Googlebot' dans le user agent, vous risquez de pénaliser les utilisateurs réels utilisant des navigateurs atypiques ou des outils de test SEO légitimes.
Impact pratique et recommandations
Que faut-il faire concrètement sur son infrastructure ?
Première étape : logger les user agents dans vos analytics ou vos fichiers de logs serveur. Cela vous permet de vérifier que Googlebot visite bien votre site et d'identifier d'éventuelles anomalies (pics de crawl, user agents suspects, etc.).
Si vous opérez un site SPA ou une PWA, mettez en place du dynamic rendering. Des solutions comme Puppeteer, Rendertron ou des services tiers (Prerender.io, etc.) peuvent générer du HTML statique à la volée pour Googlebot. Déclenchez cette logique dès que le user agent contient 'Googlebot', mais validez l'IP par DNS inverse avant de servir la version pré-rendue.
Quelles erreurs éviter dans la détection de Googlebot ?
Ne vous contentez jamais d'un simple userAgent.includes('Googlebot') sans vérification supplémentaire. Un attaquant peut spoofér ce header en quelques secondes. Utilisez la méthode officielle : résolution DNS inverse (reverse DNS lookup) pour confirmer que l'IP appartient bien à googlebot.com ou google.com.
Évitez aussi de bloquer ou de pénaliser les requêtes qui ne s'identifient pas comme Googlebot. Certains outils SEO légitimes ou navigateurs moins courants n'ont pas de user agent standard. Si vous mettez en place un rate limiting, basez-le sur l'IP et le comportement, pas uniquement sur le user agent.
Comment vérifier que mon site est conforme ?
Testez votre implémentation avec l'outil d'inspection d'URL de la Search Console : il simule Googlebot et vous montre exactement ce que le crawler voit. Comparez cette vue avec ce qu'un utilisateur réel obtient. Si vous pratiquez le dynamic rendering, les deux versions doivent être équivalentes en contenu.
Auditez régulièrement vos logs serveur pour détecter des patterns suspects : user agents Googlebot provenant d'IPs non vérifiées, pics de requêtes anormaux, tentatives de scraping massif. Un monitoring actif vous permet de réagir rapidement en cas d'abus.
- Logger systématiquement les user agents dans vos analytics ou logs serveur
- Implémenter une vérification DNS inverse pour authentifier Googlebot avec certitude
- Si SPA/PWA, mettre en place du dynamic rendering déclenché par le user agent Googlebot
- Tester régulièrement avec l'outil d'inspection d'URL de la Search Console
- Comparer le contenu servi aux bots vs. utilisateurs pour éviter le cloaking
- Auditer les logs pour détecter les tentatives de spoofing ou de scraping
❓ Questions frequentes
Peut-on se fier uniquement au user agent pour identifier Googlebot ?
Le dynamic rendering est-il considéré comme du cloaking par Google ?
Quels sont les différents user agents Googlebot à connaître ?
Comment vérifier qu'une IP appartient vraiment à Googlebot ?
Faut-il logger les user agents dans ses analytics SEO ?
🎥 De la même vidéo 3
Autres enseignements SEO extraits de cette même vidéo Google Search Central · durée 16 min · publiée le 22/05/2019
🎥 Voir la vidéo complète sur YouTube →
💬 Commentaires (0)
Soyez le premier à commenter.