Une analyse de logs annonce une hausse brutale de Googlebot, des milliers de 404 et une saturation nocturne. L’équipe SEO imagine un problème de crawl, l’infrastructure prépare une règle d’urgence et la sécurité soupçonne une collecte hostile. Pourtant, le seul élément disponible est un User-Agent copié dans chaque requête : n’importe quel client peut l’envoyer.
Une mauvaise identité contamine tous les calculs qui suivent : fréquence par gabarit, taux d’erreur, coût origine, latence de découverte et priorisation du catalogue. Le protocole doit donc retrouver une IP source fiable, vérifier son appartenance et conserver le résultat avant toute agrégation.
Le vrai enjeu est de produire une identité opposable avant toute statistique. En réalité, ce n’est pas « reconnaître le nom Googlebot », c’est valider l’adresse et conserver la preuve. Contre-intuitivement, un nom qui se termine par googlebot.com ne suffit pas ; sa résolution directe doit ramener l’adresse initiale, ou l’adresse doit appartenir aux plages CIDR publiées.
Une mission Tech SEO et performance web organise cette chaîne de confiance entre CDN, sécurité, SRE et analystes. L’objectif n’est pas seulement de bloquer des intrus : il est de produire des logs dont chaque conclusion peut être défendue et rejouée.
Mesurer le risque d’une identité non vérifiée
L’usurpation la plus simple consiste à envoyer l’agent utilisateur officiel depuis une autre adresse. Elle suffit à polluer une requête qui filtre Googlebot dans une colonne texte. Une campagne de scan, un outil SEO ou un bot commercial peut alors être compté dans le crawl de Google sans intention malveillante particulière.
Le risque dépend des décisions branchées sur la donnée. Un tableau de tendance erroné coûte du temps ; une règle de pare-feu, une exemption de limitation ou un changement de capacité produit un impact plus fort. Plus la décision est automatisée, plus la validation doit être proche de la collecte et explicite.
Deux signaux faibles révèlent souvent la pollution. Le premier est une signature Googlebot avec méthodes, en-têtes ou cadence très éloignés du comportement habituel. Le deuxième est une hausse spectaculaire dans les logs applicatifs sans mouvement cohérent dans les journaux CDN ou les statistiques d’exploration. Ces indices ouvrent l’enquête, mais ne remplacent pas la preuve d’adresse.
Le coût complet inclut les faux diagnostics SEO, la capacité réservée, le stockage de journaux et le risque de laisser passer un trafic hostile au nom d’une exception Google. Une validation robuste paie surtout lorsqu’elle évite une décision d’exploitation prise sur une identité déclarative.
Distinguer les catégories de crawlers Google
Google documente plusieurs catégories. Les crawlers communs, dont Googlebot, servent ses produits et respectent les règles robots lors des crawls automatiques. Les crawlers spéciaux remplissent des fonctions particulières et peuvent se comporter différemment. Les fetchers déclenchés par un utilisateur répondent à l’action d’une personne et peuvent ignorer robots.txt.
Cette distinction évite un classement binaire trop pauvre. Une adresse Google vérifiée n’est pas forcément Googlebot Search. La preuve doit retourner au minimum la classe, la plage correspondante et, si nécessaire, l’agent déclaré. Les analyses SEO retiennent les crawlers pertinents ; la sécurité conserve les autres comme trafic Google vérifié d’une autre nature.
Les masques reverse diffèrent aussi : googlebot.com pour les crawlers communs, google.com pour certains crawlers spéciaux ou fetchers, et gae.googleusercontent.com pour certains fetchers déclenchés. Le suffixe devient acceptable seulement après un contrôle de frontière de domaine et une résolution aller-retour.
Une politique qui autorise toute adresse Google dans une exemption large confond produit, intention et niveau de confiance. Elle peut ouvrir une voie inutile à des fetchers sans rapport avec la recherche. La liste des classes autorisées doit donc correspondre à l’usage : analyse, limitation, pare-feu ou supervision.
Retrouver l’adresse source derrière CDN et proxies
Le reverse DNS appliqué à la mauvaise IP valide seulement le dernier proxy. L’équipe commence par cartographier le chemin : load balancer, CDN, WAF, ingress et application. Elle identifie le composant qui termine la connexion publique et le champ où celui-ci écrit l’adresse client validée.
X-Forwarded-For n’est fiable que si chaque intermédiaire de confiance supprime ou reconstruit la valeur reçue. Lire naïvement le premier élément permet au client de fournir sa propre adresse. Le parseur part du côté connu de la chaîne, retire les proxies explicitement approuvés et s’arrête sur la première adresse externe.
Tester la politique de confiance du proxy
Les en-têtes propriétaires d’un CDN peuvent simplifier le traitement, mais leur authenticité dépend du réseau : l’application ne doit les accepter que depuis les plages du CDN ou une liaison privée. La configuration est testée avec une requête directe, une chaîne forgée et les chemins IPv4/IPv6.
La preuve conserve l’adresse socket, la chaîne transmise, l’adresse retenue et la version de la politique proxy. Lorsqu’un nouveau reverse proxy entre en production, une modification de cette version rend les comparaisons visibles. Sans cette trace, une migration d’infrastructure peut faire apparaître soudainement toutes les requêtes sous une même IP.
Un signal faible particulièrement utile est une adresse source interne ou appartenant au CDN après extraction. Il indique une chaîne incomplète, pas un robot Google. L’analyse doit s’arrêter plutôt que d’interroger le DNS avec une donnée qui ne représente pas le client.
Exécuter reverse puis forward DNS sans raccourci
Contrôler le PTR et la frontière du domaine
La première étape effectue un lookup PTR sur l’adresse retenue. Le résultat est normalisé en minuscules et sans point terminal. Le validateur accepte uniquement un nom égal au domaine autorisé ou terminé par un point suivi de ce domaine. crawl.googlebot.com.example.net et fakegooglebot.com échouent donc malgré leur sous-chaîne séduisante.
Le suffixe accepté dépend de la classe recherchée : googlebot.com, google.com ou googleusercontent.com selon la documentation officielle. Le code ne généralise pas à « contient google », et ne conclut pas depuis l’organisation du certificat TLS ou le propriétaire ASN.
Résoudre le nom et retrouver l’adresse initiale
La seconde étape résout les enregistrements A et AAAA du nom obtenu. Au moins une réponse doit être exactement l’adresse initiale. Cette vérification forward-confirmed reverse DNS empêche un attaquant qui contrôle son PTR de choisir un nom trompeur sans contrôler la résolution du domaine correspondant.
Les réponses multiples sont valides si l’adresse d’origine figure dans l’ensemble. Le code compare des représentations binaires d’IP, pas des chaînes IPv6 dont l’écriture peut varier. Il consigne le nom, les réponses et le temps de résolution pour permettre un audit.
Une absence de PTR, un timeout, SERVFAIL ou une réponse forward vide porte un motif distinct. Le résultat devient unknown_dns_error ou unverified, selon le cas. Cette granularité évite qu’une panne de résolveur fasse croire à une attaque et permet de rejouer les événements plus tard.
Industrialiser la validation avec les plages CIDR
Google publie des fichiers JSON séparés pour crawlers communs, crawlers spéciaux et fetchers déclenchés. Une solution à grand volume récupère ces fichiers, valide leur structure, transforme chaque préfixe IPv4 ou IPv6 en structure de recherche et classe l’adresse sans lookup DNS par requête.
La mise à jour est atomique : télécharger vers une version candidate, vérifier date, nombre de préfixes, syntaxe CIDR et échantillons, puis remplacer la version active. Si le téléchargement échoue, la dernière liste saine reste utilisée pendant une durée bornée. Une liste vide ne doit jamais remplacer silencieusement la production.
Versionner la source CIDR officielle
Le chemin officiel a changé en 2026 vers /crawling/ipranges/. Les intégrations qui figent l’ancien répertoire /search/apis/ipranges/ doivent migrer. La source, l’heure de récupération, l’empreinte et la date de création du JSON restent attachées à chaque décision automatisée.
La validation CIDR et le couple reverse/forward sont deux méthodes officielles, pas deux obligations à exécuter toujours ensemble. Une entreprise peut utiliser CIDR pour le flux et DNS pour l’investigation, ou exiger les deux pour une exception de sécurité très sensible. La politique décrit le niveau retenu.
Le coût caché d’un lookup systématique apparaît avec les volumes et les délais DNS. La table CIDR offre une décision rapide, tandis que le DNS apporte un nom explicable. Le choix équilibre performance, disponibilité et niveau de preuve au lieu d’imposer un rituel uniforme.
Mettre en cache sans figer une ancienne preuve
Le cache DNS respecte idéalement les TTL positifs et négatifs. Il réduit les requêtes répétées pour une même adresse sans transformer une réponse ancienne en vérité permanente. Une durée maximale interne peut borner les TTL très longs pour maintenir la fraîcheur de la preuve.
Le cache CIDR suit la version du fichier et son âge. Une alerte se déclenche avant expiration opérationnelle. L’application distingue une validation effectuée avec la version courante d’une décision servie depuis une liste dégradée mais encore autorisée.
Les résultats inconnus peuvent entrer dans une file de reprise asynchrone. La requête web n’attend pas plusieurs secondes un résolveur ; elle est journalisée, puis enrichie hors ligne. La première analyse exclut les inconnus des agrégats Googlebot tout en publiant leur volume.
Une politique de cache doit aussi considérer les adresses partagées et les changements de plage. L’identité appartient à la requête observée à un instant, avec une preuve datée. Réinterpréter tout l’historique depuis la liste actuelle peut produire une autre conclusion ; les deux lectures doivent être nommées.
Conserver une preuve exploitable dans les logs
Chaque événement enrichi garde l’adresse source extraite, l’agent déclaré, la méthode de validation, le verdict, la classe, le hostname éventuel, la version CIDR, le motif d’échec et l’horodatage. Les requêtes brutes sensibles suivent la politique de rétention et de minimisation de l’entreprise.
Le schéma sépare claimed_googlebot de verified_google_common_crawler. Une troisième valeur décrit les fetchers ou crawlers spéciaux. Cette taxonomie empêche une requête signée « Googlebot » mais inconnue d’être silencieusement incluse ou supprimée.
Les agrégats SEO filtrent uniquement la classe documentée et gardent à côté la proportion d’inconnus. Si celle-ci dépasse le seuil prévu, le rapport est déclaré incomplet. Une baisse spectaculaire du crawl après activation peut ainsi être interprétée comme une correction de pollution, non comme une chute réelle de Googlebot.
Le dossier de preuve inclut quelques requêtes positives, négatives et inconnues, avec leurs résolutions. Il est reproductible depuis un outil indépendant. La sécurité peut contester la chaîne de proxy ; le SEO peut vérifier la population incluse ; SRE peut mesurer le coût.
Mesurer pollution, inconnus et coût de contrôle
Le premier indicateur est la part des requêtes revendiquant Googlebot qui sont vérifiées, usurpées ou inconnues. Il est segmenté par host, chemin, centre de données et version de collecte. Une moyenne globale peut cacher un proxy régional qui perd l’adresse source.
Le deuxième groupe mesure la chaîne elle-même : taux d’échec DNS, latence p50/p95, âge de la liste CIDR, nombre de préfixes, cache hit et file de reprise. Ces chiffres déclenchent une correction du validateur, pas une conclusion SEO.
Les métriques de crawl viennent seulement après : hits vérifiés, URL distinctes, statuts, octets, temps serveur et fréquence par gabarit. Elles sont comparées avant/après activation pour expliquer la rupture de série. Un rapport doit annoter le jour où la définition a changé.
Le seuil d’alerte dépend de l’usage. Un taux inconnu de 1 % peut être acceptable pour une tendance exploratoire, mais bloquant pour une exemption de pare-feu. La politique relie donc chaque seuil à une décision et à un propriétaire.
Séparer observabilité SEO et décision de sécurité
La validation prouve une origine documentée par Google, pas la légitimité absolue de chaque requête ni son absence de coût. Les crawlers communs respectent robots.txt, mais un trafic vérifié peut encore révéler un espace d’URL infini ou surcharger une route fragile.
La sécurité utilise la classe pour appliquer une politique proportionnée. Elle n’accorde pas automatiquement un accès aux zones privées, ne contourne pas l’authentification et ne désactive pas toute limite. Les pages publiques doivent rester sûres pour un client anonyme.
L’analyste SEO, lui, exclut les usurpations de ses ratios et examine les hits valides. Les décisions de blocage, de limitation et de robots appartiennent à des couches différentes. Un faux Googlebot peut être limité pour abus ; un vrai bot très actif conduit à réparer l’inventaire ou la capacité.
Un runbook commun précise qui peut modifier WAF, extraction proxy, liste CIDR et filtres analytiques. Les changements sont canariés, car une erreur de validation peut masquer tout le trafic officiel ou autoriser une population trop large.
Trier un trafic entièrement simulé
Prenons un jeu fictif de 48 millions de requêtes sur sept jours. Trois millions déclarent Googlebot. La première extraction naïve les compte toutes ; le nouveau validateur en classe 2,42 millions comme crawler commun, 90 000 comme autre fetcher Google, 410 000 comme usurpations et 80 000 comme inconnues à cause d’un résolveur instable.
Exemple concret simulé. Les faux bots concentrent 72 % des requêtes vers une recherche interne coûteuse et expliquent la majorité du pic nocturne. Les Googlebots vérifiés rencontrent toutefois 6 % de 5xx sur un template produit. La sécurité limite la population usurpée, tandis que SRE corrige séparément la route produit.
Seuils fictifs. Le changement est étendu si 100 % d’un échantillon de 500 événements connus est correctement classé, si les inconnus restent sous 2 %, si le p95 d’enrichissement asynchrone reste sous cinq minutes et si aucune adresse officielle testée n’est rejetée. Une hausse des inconnus au-delà de 5 % place les décisions de pare-feu en mode prudent.
Ce cas montre pourquoi une seule étiquette masque deux incidents. Nettoyer l’usurpation ne résout pas les 5xx vus par le vrai crawler ; corriger le serveur n’arrête pas le trafic hostile. La preuve d’identité ouvre le bon dossier pour chaque équipe.
Prévoir panne DNS et changement de plages
Le résolveur peut tomber, renvoyer SERVFAIL ou ralentir. Le système bascule alors vers la liste CIDR saine, place le DNS en reprise et rend visible son niveau de dégradation. Il n’invente pas un verdict négatif pour préserver un pourcentage.
Le téléchargement des plages peut également échouer. Une durée maximale d’utilisation de la dernière version, par exemple quelques jours décidés selon le risque, évite à la fois l’arrêt immédiat et la confiance permanente. Au-delà, les exemptions automatiques se durcissent tandis que les événements restent collectés.
Une modification de chaîne proxy est testée avant production avec adresses connues, requêtes forgées et IPv6 compressée. Le rollback restaure la politique précédente, pas des en-têtes client non fiables. Le journal de version explique toute rupture de série analytique.
La reprise reclassifie éventuellement les événements inconnus, mais conserve le verdict initial et le verdict enrichi. Cette double temporalité permet d’auditer ce que le système savait lors de la décision.
Pour qui adapter le protocole au volume et au risque
Pour un audit ponctuel de quelques IP, les commandes host ou dig appliquées manuellement suffisent si les résultats sont conservés. La procédure reverse puis forward reste la même et une seconde personne peut la reproduire.
À plusieurs millions de requêtes, une validation CIDR dans le flux et un enrichissement DNS échantillonné offrent un meilleur coût. Les équipes de sécurité peuvent exiger une preuve renforcée pour une exemption, tandis que l’analyse SEO utilise la classe CIDR.
Les sites derrière plusieurs CDN doivent centraliser la logique ou publier un contrat identique. Une implémentation différente par host crée des séries incomparables. Le schéma d’événement et les tests deviennent le point commun.
Erreurs fréquentes : trois validations dangereuses
Faire confiance au seul agent utilisateur
Cette valeur est une chaîne déclarative. Elle sert à identifier l’intention annoncée après vérification de l’adresse, jamais à établir l’origine. Une règle WAF fondée uniquement sur elle est triviale à contourner.
Le rapport conserve malgré tout l’agent revendiqué pour mesurer l’usurpation. Le jeter trop tôt empêcherait de comprendre la pollution et ses cibles.
Accepter un nom qui contient « google »
Un domaine contrôlé par un tiers peut inclure cette chaîne. Le validateur contrôle une frontière DNS exacte, puis exige que la résolution A ou AAAA contienne l’adresse initiale. Le PTR seul ne suffit pas.
Les suffixes autorisés sont ceux de la documentation et dépendent de la classe. Une liste improvisée devient rapidement trop large ou obsolète.
Transformer toute panne de résolution en usurpation
Un timeout décrit l’état du résolveur, pas l’origine de la requête. Classer ce cas comme faux peut bloquer des crawlers officiels lors d’un incident interne. Le statut inconnu, sa reprise et son volume doivent rester visibles.
À l’inverse, autoriser tous les inconnus annule la protection. La politique de repli dépend de la décision : exclusion prudente d’un rapport, limitation neutre ou attente avant exemption.
Plan d’action : fiabiliser la chaîne en dix jours
- Valider Googlebot dans les logs serveur avant d’interpréter budget de crawl, crawl et codes HTTP.
- Contrôler sitemap XML, maillage interne, canonicale et indexation seulement sur le trafic officiellement vérifié.
- Séparer robots.txt, noindex, redirection 301 et cache des décisions de sécurité prises sur une adresse inconnue.
- Rapprocher Search Console, hreflang, données structurées et Core Web Vitals après nettoyage de l’identité.
- Choisir l’adresse source : si la requête traverse un proxy approuvé, alors dépiler la chaîne reconstruite ; sinon retenir l’adresse de connexion.
- Corriger la preuve : exécuter reverse puis forward DNS, vérifier la frontière de domaine et comparer le CIDR plutôt que croire le
User-Agent. - Refuser un verdict forcé : si DNS ou JSON officiel est indisponible, alors classer la requête inconnue ; en revanche, ne jamais la convertir en usurpation.
- Choisir l’action : compter les classes validées en SEO, isoler les faux bots en sécurité et déclencher le rollback si les inconnues dépassent 5 %.
Implémenter le validateur dans le pipeline
L’endpoint reçoit l’adresse et la chaîne proxy. La responsabilité SRE couvre l’entrée ; sécurité possède la sortie, l’instrumentation, le monitoring et le seuil de la dépendance DNS. La QA contrôle canonicals, JavaScript et rendu avant l’agrégation.
La journalisation assure la traçabilité du JSON CIDR. Un retry idempotent alimente la file d’audit. Si le seuil est franchi, alors le rollback active le repli asynchrone selon le runbook et désactive le blocage automatique.
Jours 1 à 3 : cartographier et tester l’adresse source
SRE dessine CDN, WAF, load balancer et application, puis nomme l’en-tête reconstruit par chaque intermédiaire. La sécurité tente une injection directe et vérifie que le service public ne peut pas forger l’adresse retenue. Les tests couvrent IPv4, IPv6, connexions directes refusées et plusieurs proxies. La sortie est une fonction d’extraction versionnée, documentée et accompagnée d’exemples positifs et négatifs.
L’analyste mesure ensuite combien d’événements historiques possèdent les champs nécessaires. Si un host perd l’IP, ses données restent hors des agrégats Googlebot jusqu’à correction.
Jours 4 à 6 : implémenter les deux méthodes officielles
Le développeur construit le contrôle PTR, la validation des suffixes sur frontière de label et la résolution A/AAAA. En parallèle, il télécharge les fichiers CIDR actuels, vérifie leur structure et prépare une mise à jour atomique. Les résultats distinguent crawler commun, spécial, fetcher, usurpation et inconnu. Les tests rejouent des adresses officielles documentées, un PTR contrôlé par un tiers, une réponse multiple et un timeout.
Le cache suit TTL et version de fichier. Les métriques de latence, échec et âge sont disponibles avant activation pour éviter qu’un enrichissement de sécurité ne devienne une dépendance silencieuse.
Jours 7 à 10 : canarier, comparer et transmettre
La nouvelle logique tourne en parallèle de l’ancienne sans bloquer. Une revue manuelle porte sur plusieurs centaines d’événements stratifiés par verdict, host et protocole. L’équipe compare volumes, 5xx, routes et coût avant de modifier rapports ou WAF. La rupture de définition est annotée ; les inconnus restent publiés.
Le passage actif exige un propriétaire, une alerte de liste périmée, une procédure de panne DNS et un rollback. Une personne extérieure reproduit cinq validations depuis les données conservées. Le plan couvre ainsi extraction, preuve, résilience, mesure et responsabilité au lieu de se limiter à une commande DNS isolée.
Prolonger par le crawl et les incidents serveur
Relire les erreurs vues par les bots vérifiés
La procédure consacrée aux clusters de 5xx vus par les bots montre comment remonter du statut jusqu’au service défaillant.
La validation d’identité garantit que cette investigation repose sur le bon trafic et empêche un bot usurpé de déplacer la priorité d’incident.
Reconstituer le host derrière plusieurs domaines
L’article consacré aux logs multi-domaines derrière CDN et reverse proxy approfondit la conservation du host, du chemin et des identifiants de requête.
Il complète la chaîne d’adresse lorsque plusieurs couches réécrivent les champs avant l’application.
Séparer anciennes URL et opportunités
La méthode des pages orphelines présentes dans les logs utilise ensuite le trafic vérifié pour distinguer héritage, piège et page active.
Elle évite de réintégrer une URL simplement parce qu’un agent déclaratif continue de la demander.
Consulter les références Google actuelles
Google documente la procédure de vérification des requêtes de ses crawlers et fetchers, avec reverse DNS, forward DNS et listes de plages IP.
Les plages des crawlers communs sont publiées au format JSON et doivent être consommées depuis leur emplacement actuel. L’annonce du déplacement des fichiers IP explique la migration vers le répertoire général de crawling.
Ces références établissent l’origine et les classes. Elles ne remplacent ni la sécurité de la chaîne proxy, ni la politique interne d’accès, de limitation et de rétention.
Conclusion : vérifier avant d’agréger
Un agent utilisateur revendique une identité ; l’adresse source et sa preuve l’établissent. Toute analyse de crawl doit commencer par cette frontière.
Le reverse DNS doit être confirmé par une résolution directe, tandis que les plages CIDR offrent une validation industrielle et classée. Les erreurs DNS restent inconnues jusqu’à reprise.
Une chaîne fiable conserve proxy, méthode, version et verdict. Elle sépare incident sécurité, erreur serveur et comportement réel des crawlers sans casser la série silencieusement.
- Reconstruire l’adresse source uniquement depuis les proxys explicitement approuvés.
- Classer une résolution incomplète comme inconnue plutôt que comme usurpation certaine.
- Séparer la décision SEO de la réponse de sécurité appliquée au trafic.
Pour auditer les journaux, sécuriser les proxys et transformer le trafic vérifié en décisions techniques, l’accompagnement Tech SEO et performance web de Dawap fournit protocole, instrumentation et gouvernance d’exploitation.
