Le User-Agent est une déclaration, pas une preuve d’identité. Avant d’accorder une exception ou d’interpréter une activité comme celle d’un moteur, vérifiez la requête selon les méthodes de l’opérateur. Conservez les résultats et tenez compte des intermédiaires réseau.
Partir d’une requête précise
Relevez heure, chemin demandé, statut et adresse observée au bon niveau de l’infrastructure. Si un proxy ou un CDN se trouve devant le serveur, vérifiez comment l’adresse d’origine est transmise et quelles sources sont fiables. Un en-tête fourni par n’importe quel client ne doit pas suffire à identifier une machine. Travaillez sur quelques cas avant de généraliser à tous les journaux.
Appliquer la méthode officielle
Google documente la vérification par ses listes d’adresses et la méthode DNS. Pour une vérification DNS, il faut contrôler le nom obtenu puis confirmer que sa résolution directe correspond à l’adresse initiale, avec le suffixe attendu pour la catégorie. Ne validez pas un nom uniquement parce qu’il contient le mot Google. Consultez les informations officielles à jour lors de l’implémentation.
Relier l’adresse observée à la bonne catégorie de robot
La documentation de Google distingue plusieurs catégories de robots et d’outils de récupération. Les adresses et les motifs de noms ne sont pas à interpréter hors de cette catégorie. Avant de conclure qu’une requête provient de Googlebot, utilisez la méthode officielle adaptée et l’adresse réellement observée à la frontière fiable de votre infrastructure. Une adresse recopiée depuis un en-tête non vérifié peut être choisie par le client qui envoie la requête.
| Étape | Contrôle | Raccourci à éviter |
|---|---|---|
| Adresse de départ | Identifier la source fiable dans les journaux | Faire confiance à tout en-tête reçu |
| Résolution inverse | Obtenir le nom associé à l’adresse | Accepter un nom contenant seulement le mot Google |
| Nom et catégorie | Vérifier le domaine attendu selon la documentation | Confondre outil déclenché par un utilisateur et robot courant |
| Résolution directe | Retrouver l’adresse initiale depuis le nom obtenu | S’arrêter à la résolution inverse |
| Autorisation | Appliquer le périmètre d’accès prévu | Ouvrir une zone privée parce que l’identité est reconnue |
Un suffixe doit être vérifié avec une frontière de domaine, pas par une simple recherche de texte. Un nom comme googlebot.com.example.net n’appartient pas au domaine googlebot.com. La comparaison du nom ne suffit toutefois pas à elle seule : conservez la vérification de résolution directe ou utilisez les listes d’adresses publiées selon la méthode retenue.
Séparer identité et autorisation
Un robot identifié ne doit accéder qu’aux ressources qui lui sont destinées. Une page publique et une interface d’administration n’ont pas le même périmètre. Documentez les exceptions de pare-feu et leur objectif. L’identification aide à analyser la charge et les erreurs ; elle ne remplace pas une politique d’accès, une limitation adaptée et la protection des fonctions sensibles.
Exemple fictif : une hausse de requêtes
Un site voit de nombreux accès portant un nom de moteur, avec des chemins inhabituels. L’équipe vérifie un échantillon et constate que certaines adresses ne correspondent pas aux méthodes de validation publiées. Elle sépare alors trafic vérifié et trafic déclaré pour comprendre la charge. Elle ne conclut pas que le moteur officiel a lancé cette activité sur la seule base d’un libellé.
Exécuter une vérification ponctuelle et garder sa trace
Depuis une invite Windows disposant de l’outil nslookup, commencez par l’adresse de la requête que vous examinez, puis interrogez le nom effectivement obtenu. Les deux lignes ci-dessous sont des modèles à remplacer, pas un résultat de contrôle. Ne publiez pas vos journaux bruts ni des paramètres pouvant contenir des informations sensibles pour illustrer un article.
nslookup ADRESSE_IP_OBSERVEE
nslookup NOM_RETOURNE_PAR_LA_PREMIERE_REQUETE- Notez la requête de départ, la date et le niveau d’infrastructure où l’adresse a été collectée. Si un proxy intervient, documentez la configuration qui rend cette adresse fiable.
- Confrontez le nom et les résultats de résolution aux méthodes officielles de Google. Si une étape est indisponible ou ambiguë, gardez le statut à vérifier plutôt que de valider par défaut.
- Pour un volume important, préparez une vérification automatisée adaptée avec une politique de mise à jour et de gestion des erreurs. Évitez une dépendance lente ou bloquante sur chaque requête publique.
- Analysez ensuite l’accès et la charge séparément. Une identité vérifiée ne prouve ni une indexation réussie ni la qualité de la réponse servie.
Le résultat utile est une classification traçable : identité vérifiée selon telle méthode, identité non confirmée ou vérification incomplète. Reliez cette information au diagnostic du CDN et du pare-feu pour comprendre un refus d’accès, sans confondre la déclaration du robot avec la décision de votre infrastructure.
Rendre le contrôle maintenable
Prévoyez mise à jour des listes, gestion des échecs temporaires et journalisation limitée aux éléments nécessaires. Évitez les recherches DNS bloquantes à chaque requête publique ; choisissez une architecture adaptée avec votre équipe technique. Après correction, contrôlez erreurs et accès utiles. Complétez avec le diagnostic des blocages CDN pour distinguer un problème d’identité d’un problème de réponse servie.