Un rapport de logs peut conclure qu’une section absorbe 42 % du crawl alors qu’un outil de monitoring, un aspirateur de prix et plusieurs aperçus de messagerie produisent l’essentiel des requêtes. Le risque est une décision SEO faussée par une population qui ne répond pas à la question posée.
Le filtrage naïf par user-agent n’est pas plus sûr. La chaîne se copie facilement, plusieurs clients Google ont des usages différents et un robot interne peut changer de nom sans prévenir. Supprimer toutes les lignes inconnues donne un tableau propre en apparence, mais impossible à contredire.
Une analyse Tech SEO des logs commence par conserver l’événement brut, enrichit plusieurs signaux, attribue un niveau de confiance et compare toujours les vues avant et après filtre. Elle ne transforme pas la classification en mécanisme de sécurité.
Le vrai enjeu est de construire un contrat analytique réversible : le filtrage définit quelles requêtes éclairent une décision, tout en gardant robots tiers et inconnus accessibles. Vous allez comprendre comment nettoyer la vue SEO sans supprimer la preuve nécessaire à l’infrastructure, la sécurité ou de futures analyses.
Définir la population analytique
La première question n’est pas « quel bot faut-il exclure ? », mais « quel phénomène veut-on mesurer ? ». Pour estimer l’exploration Google Search, la population attendue contient les requêtes Googlebot vérifiées et sépare les autres clients Google. Pour dimensionner la capacité serveur, les robots tiers restent au contraire indispensables.
Chaque vue publie son périmètre : hôtes, dates, sources de logs, types de clients, environnement, redirections observées et champs manquants. Une extraction CDN et une extraction applicative peuvent voir des requêtes différentes selon le cache, le routage et les erreurs précoces.
Le dénominateur est affiché avant et après classification. Sans cette comparaison, une courbe peut sembler baisser uniquement parce qu’une règle récente a exclu une famille entière. Le volume non classé reste une série de premier rang, jamais un résidu caché.
Le dictionnaire de sortie décrit chaque colonne, sa source et son usage autorisé. Une équipe peut ainsi réutiliser la vue Googlebot pour le crawl sans supposer qu’elle représente la charge serveur totale ou l’ensemble des clients Google.
Conserver une collecte exploitable
Les champs minimaux comprennent horodatage avec fuseau, hôte, méthode, chemin, requête, statut, octets, durée, IP source, user-agent, référence, couche ayant répondu et identifiant de requête. L’adresse vue par l’application peut être celle d’un proxy ; la chaîne de transfert exige une politique de confiance explicite.
Les données brutes sont immuables, datées et protégées selon leur sensibilité. L’enrichissement ajoute une famille, une règle, une version, une confiance et les preuves utilisées. Une correction de classification crée une nouvelle vue plutôt qu’une réécriture silencieuse de l’historique.
Le coût caché d’une collecte incomplète apparaît au premier incident : les équipes recalculent des exports, débattent de l’adresse réelle et ne peuvent plus reproduire la décision prise le mois précédent. Le stockage de champs utiles coûte souvent moins que cette enquête collective.
La rétention distingue données brutes sensibles et agrégats de long terme. Les adresses sont protégées et supprimées selon la politique applicable, tandis que les volumes et versions de règles restent disponibles pour expliquer les comparaisons historiques.
Vérifier Google sans croire le user-agent
Une chaîne contenant « Googlebot » constitue un indice, pas une preuve. Google documente deux méthodes : vérifier l’adresse contre ses plages publiées ou effectuer une résolution DNS inverse, contrôler le domaine obtenu, puis rejouer une résolution directe vers l’adresse originale.
Les clients Google se répartissent en robots communs, robots spécialisés et récupérateurs déclenchés par un utilisateur. Ils n’ont pas le même comportement face à robots.txt ni la même signification pour Search. Les fusionner sous une étiquette unique fausse l’interprétation même si leur origine est légitime.
Le dossier sur les faux Googlebot et la validation DNS approfondit cette authentification. Cette analyse traite l’étape suivante : séparer les autres robots pour produire une vue adaptée à la décision.
Conserver une preuve datée et rejouable
La vérification est automatisée à l’ingestion, mais son résultat reste daté. Les plages officielles sont mises en cache avec leur version, les contrôles DNS ont une durée de validité et les échecs temporaires passent dans une file de requalification. Une adresse non résolue pendant une panne DNS ne devient donc ni Google certifié, ni bot tiers certain. Elle reste inconnue jusqu’au nouveau contrôle, ce qui protège à la fois le signal SEO et la traçabilité du filtre.
Le pipeline enregistre l’adresse, la famille annoncée, la méthode, la réponse DNS, la plage correspondante et l’instant de validation. Une règle versionnée recalcule ensuite les agrégats touchés lorsqu’un verdict change. Les tableaux historiques ne basculent jamais silencieusement d’une définition à une autre : ils affichent la version du filtre et la couverture d’adresses confirmées.
Le contre-test rejoue la règle sur la donnée brute et réutilise seulement les preuves encore valides. Une réponse DNS arrivée à expiration ou une adresse affectée par l’évolution des plages déclenche une nouvelle vérification ; l’historique conserve le verdict qui était connu à chaque date au lieu de lui appliquer rétroactivement une identité actuelle.
Classer les robots tiers par fonction
Une nomenclature utile distingue moteurs de recherche, outils SEO autorisés, surveillance de disponibilité, prévisualisation sociale, archivage, assistants et collecteurs IA déclarés, agrégateurs, partenaires, automatisations internes, scanners de sécurité, scrapers commerciaux et clients inconnus.
La fonction prévaut sur le nom. Deux user-agents d’un même fournisseur peuvent représenter indexation et aperçu à la demande. Une famille peut également changer de comportement. Le registre conserve documentation officielle, plage d’adresses éventuelle, contact interne, règles robots attendues et date de dernière vérification.
La classification ne décide pas automatiquement du blocage. Un outil de monitoring doit sortir de l’analyse Googlebot mais rester autorisé. Un scraper agressif relève peut-être du WAF ou d’une décision juridique. Mélanger analytics et sécurité conduit à prendre une action de production depuis une preuve conçue pour un autre but.
Contre-intuitivement, le robot le plus volumineux n’est pas toujours celui qu’il faut traiter en premier. Si son identité et son usage sont autorisés, alors la priorité peut rester sur une petite famille contredite qui fausse l’interprétation ou menace la sécurité.
Préserver les inconnus et la confiance
Les états recommandés sont « vérifié », « probable », « ambigu », « inconnu » et « contredit ». « Probable » peut s’appuyer sur une chaîne documentée et un comportement cohérent sans plage officielle. « Contredit » signale par exemple un user-agent Google provenant d’une origine non validée.
La confiance dépend de signaux indépendants : adresse, DNS, signature éventuelle, documentation, fréquence, respect de robots.txt, distribution des routes, cookies, méthode HTTP et régularité temporelle. Aucun seuil unique ne convient à toutes les familles.
La part inconnue possède une alerte de dérive. Une hausse soudaine peut indiquer un nouveau prestataire, un changement d’adresse, un bot émergent ou une perte de champs lors d’un déploiement. L’exclure automatiquement détruirait précisément le signal qui mérite une enquête.
Une file de qualification ordonne les inconnus par volume, croissance, coût, routes visitées et ressemblance avec une identité contredite. Les petits clients stables peuvent attendre ; un nouveau client concentré sur des pages sensibles remonte immédiatement.
Éviter les pièges réseau et proxy
Un CDN, un équilibreur ou un service mesh peut masquer l’adresse source. La liste des proxies de confiance doit être bornée ; croire n’importe quel en-tête transmis permettrait à un client de choisir lui-même son identité analytique.
Les plages évoluent, IPv6 agrandit les formats et les résolutions DNS peuvent échouer temporairement. Le pipeline met en cache les résultats avec une durée maîtrisée, distingue échec technique et résultat négatif, puis rejoue les vérifications selon une fréquence raisonnable.
Le NAT peut regrouper des clients, tandis qu’un robot distribué utilise plusieurs adresses. L’adresse seule ne suffit donc pas à attribuer une intention à un fournisseur non documenté. Elle reste néanmoins déterminante lorsque le propriétaire publie officiellement ses plages.
Valider les règles sur un échantillon
Un échantillon stratifié couvre gros volumes, longues traînes, inconnus, clients Google, statuts rares, méthodes inhabituelles, IPv4, IPv6 et plusieurs hôtes. Deux lecteurs étiquettent une partie commune afin de repérer les règles ambiguës.
La matrice de confusion compare étiquette attendue et étiquette produite. Une erreur qui inclut un scraper dans Googlebot fausse le volume ; une erreur qui exclut de vrais hits Googlebot fausse la distribution. Ces conséquences justifient des seuils de qualité différents selon la classe.
Le test contradictoire cherche activement des lignes qui ressemblent à une famille sans en partager l’origine ou le comportement. Le sampling des logs détaille cette couverture quand le volume rend la lecture exhaustive impraticable.
Résoudre un cas simulé de bruit
Cas simulé : une boutique observe 9,6 millions de requêtes de robots sur trente jours. La vue initiale attribue 44 % des hits aux fiches produit et décide à tort de réduire leur exposition. Après enrichissement, un outil de veille tarifaire autorisé représente une grande partie de ces visites, tandis qu’un monitoring interne interroge les mêmes URL chaque minute.
La vue Googlebot vérifiée ne montre plus un excès global de fiches. Elle révèle en revanche que les nouvelles catégories reçoivent peu de visites et que les anciennes facettes restent très actives. La décision passe donc d’une réduction générale des fiches à une analyse ciblée des liens, sitemaps et facettes.
Un signal faible subsiste : 3 % des requêtes portent un user-agent Googlebot sans correspondre aux plages ou à la validation DNS. La décision est de les isoler dans une famille contredite et de les transmettre à la sécurité. Elles ne rejoignent ni les robots tiers ordinaires, ni la population SEO.
Les volumes sont fictifs. L’arbitrage est réel : conserver l’outil de veille dans la vue de capacité, l’exclure de la vue Google Search, investiguer les identités contredites et ne modifier le crawl interne qu’après avoir analysé la bonne population.
Appliquer le filtre sans perdre la preuve
Chaque tableau expose un sélecteur de population et une comparaison brute, classée et vérifiée. Les indicateurs critiques conservent le volume, les URL uniques, les statuts, la durée, les octets et la distribution par section. Un filtre qui change fortement l’une de ces séries est explicitement signalé.
Les décisions SEO utilisent la vue Googlebot vérifiée pour étudier exploration, sections, statuts et fraîcheur. Les décisions d’infrastructure utilisent toutes les requêtes, car un robot non Google consomme réellement CPU, bande passante et connexions. Les décisions de sécurité utilisent enfin les identités contredites et comportements suspects.
À faire d’abord : fiabiliser l’identité Google et la provenance réseau. À différer : l’enrichissement fin des familles qui ne modifient aucune décision. À refuser : supprimer les lignes brutes ou bloquer un client uniquement parce qu’il gêne un graphique SEO.
Versionner, surveiller et revenir en arrière
Le registre de règles porte identifiant, expression, source, justification, confiance, auteur, date et cas de test. Une modification importante est exécutée en parallèle de la version précédente afin de quantifier les reclassements avant adoption.
Les alertes suivent part inconnue, part contredite, volumes par famille, échecs DNS, taux de lignes sans IP exploitable et variation de classification. Un nouveau robot important ouvre une revue ; il n’est pas ajouté silencieusement depuis une intuition.
Le retour arrière consiste à réappliquer une version antérieure sur la même donnée brute. Ce mécanisme est indispensable lorsque la documentation d’un fournisseur change, qu’une plage devient obsolète ou qu’une règle trop large absorbe plusieurs familles.
Une invalidation du registre ne bloque pas les logs entrants. Le pipeline conserve les événements dans une file, applique la dernière version saine et reprend le classement après validation. Cette séparation protège la collecte contre une panne d’enrichissement.
Plan d’action : mettre le filtre sous contrat
La première entrée rassemble les logs CDN, proxy et application, leur schéma, les proxies de confiance et les plages Google. Les responsabilités séparent collecte, classification, validation SEO et escalade sécurité. Chaque dépendance réseau et chaque champ manquant sont documentés.
Pour éprouver la taxonomie des bots, la QA sélectionne deux cents lignes stratifiées entre Googlebot, tiers connus, inconnus, IPv6, erreurs et méthodes rares. Elle augmente ce volume selon la rareté des classes, le coût d’une erreur et la confiance attendue, sans laisser les gros volumes effacer les cas sensibles. Elle associe route, statut, HTML, canonical, cache, TTFB et version lorsque le bot touche une page rendue en JavaScript ou en SSR. La sortie comprend étiquette attendue, résultat et confiance.
L’instrumentation publie version de règle, preuve d’adresse et famille dans une table dérivée. La journalisation conserve les reclassements ; le monitoring suit inconnus, identités contredites et échecs DNS. Le repli réapplique la version précédente sans modifier la donnée brute.
À titre de seuils locaux illustratifs, si plus de 1 % de la population Googlebot vérifiée change de classe après une mise à jour, alors le déploiement du filtre est suspendu jusqu’à revue. Une hausse de 20 % des inconnus sur deux fenêtres ouvre une analyse, sans bloquer automatiquement le trafic. Ces valeurs sont remplacées par la variabilité saine, la taille des populations et le coût d’une erreur de classement.
- D’abord, conserver : figer la donnée brute et la provenance réelle avant toute exclusion.
- Ensuite, vérifier : authentifier Google et séparer robots communs, spécialisés et récupérateurs déclenchés.
- Puis, classer : attribuer fonction, preuve, confiance et date de révision aux autres familles.
- À refuser : bloquer une requête ou réécrire l’historique uniquement pour stabiliser un tableau SEO.
Éviter les raccourcis de classification
Faire confiance au nom déclaré
Le user-agent reste falsifiable et parfois trop général. Il doit ouvrir une règle de vérification, pas clôturer l’identité à lui seul.
Une chaîne exacte peut provenir d’une adresse contredite, tandis qu’un client légitime peut publier plusieurs chaînes. Adresse, DNS et documentation doivent converger avant l’étiquette vérifiée.
Jeter tous les inconnus
Cette pratique réduit artificiellement le dénominateur et masque les changements de collecte. Les inconnus restent quantifiés, échantillonnés et réévalués.
Une hausse peut signaler un nouveau fournisseur ou la perte d’un en-tête au proxy. La conserver permet de réparer la collecte avant que toutes les analyses dérivées ne dérivent à leur tour.
Utiliser une liste figée pour toujours
Les clients, adresses et produits évoluent. Une règle sans date de vérification ni tests de non-régression devient une source de biais plus dangereuse que le bruit initial.
Une revue trimestrielle peut convenir aux familles stables, mais les plages officielles et la part inconnue se surveillent automatiquement. La fréquence réelle dépend du taux de changement observé.
Approfondir logs, échantillons et crawl
Reprendre la chaîne complète d’analyse
Le dossier Logs SEO : analyser Googlebot couvre collecte, normalisation et rapprochement avec les signaux d’indexation. Le filtrage décrit ici en sécurise le périmètre.
Cette chaîne permet aussi de rapprocher crawl et statut d’indexation sans confondre identité du client et décision de la recherche. Les deux preuves restent consultables séparément.
Automatiser sans figer une erreur
L’automatisation de l’analyse des logs aide à organiser pipeline, alertes et reprises. Elle doit consommer un registre versionné et conserver la capacité de recalcul.
Un test de non-régression compare les volumes avant publication. Il empêche qu’une expression plus large reclasse silencieusement un moteur ou un outil interne.
Étudier ensuite la répartition par section
L’analyse du crawl budget par section utilise la population Googlebot vérifiée pour comparer distribution, fraîcheur et valeur sans être contaminé par les robots tiers.
Elle conserve cependant une vue de capacité avec tous les robots. Cette double lecture évite qu’une amélioration SEO apparente masque une charge serveur toujours présente.
Vérifier les sources officielles
Google explique comment vérifier ses robots et récupérateurs par DNS inverse et direct ou par plages d’adresses publiées. La page distingue aussi robots communs, spécialisés et récupérateurs déclenchés.
La documentation sur les propriétés des clients Google décrit user-agent, IP, DNS, protocoles, charge et cache. Elle confirme qu’une identité combine plusieurs signaux.
La liste des récupérateurs déclenchés par un utilisateur rappelle que leur usage et leur comportement face à robots.txt diffèrent du crawl automatique.
Google publie les plages des robots communs au format JSON. Enfin, la norme RFC 9309 sur le protocole robots.txt fournit la référence primaire du mécanisme, sans authentifier l’identité déclarée d’un client.
Conclusion : nettoyer sans effacer
Un filtre fiable ne cherche pas à rendre le graphique plus calme. Il construit une population adaptée à la question et conserve tout ce qui permet de contredire son classement.
La vérification de Google, les familles fonctionnelles, les inconnus et les niveaux de confiance évitent qu’un nom déclaré devienne une identité certaine. Les vues restent séparées pour le SEO, la capacité et la sécurité.
Le registre versionné transforme enfin le filtrage en composant exploitable : il peut être testé, comparé, surveillé et rejoué sur la donnée brute lorsque le contexte change.
Pour fiabiliser la population analysée, l’équipe Tech SEO Dawap vous accompagne afin d’isoler les robots utiles et convertir leurs écarts en décisions mesurables.
