Se connecter Commencer gratuitement

Vérification des robots dans les logs serveur

N'importe quel client peut envoyer une chaîne user agent Googlebot, et sur la plupart des sites publics une part non négligeable des hits qui s'en réclament sont des aspirateurs de contenu, des outils de surveillance et des robots d'IA qui empruntent le nom. Un travail sur le budget de crawl bâti sur des logs non vérifiés est faux avant même que l'analyse commence, et les règles de pare-feu qui en découlent bloquent les mauvaises cibles. Cela vaut chaque fois que les logs servent de preuve, et systématiquement avant que quiconque bloque un robot au niveau du CDN.

CATÉGORIE
SEO technique
FORMAT
server-log-bot-verification.md
ÉTAPES
7
PRIX
Gratuit — sans compte
QUAND S’EN SERVIR

À utiliser lorsqu'une analyse de crawl, un pic de bande passante ou une proposition de bloquer un robot repose sur des lignes de logs qui annoncent Googlebot, sans que personne n'ait vérifié que c'en était bien un.

Le fichier de compétence

server-log-bot-verification.md
---
name: server-log-bot-verification
description: À utiliser lorsqu'une analyse de crawl, un pic de bande passante ou une proposition de bloquer un robot repose sur des lignes de logs qui annoncent Googlebot, sans que personne n'ait vérifié que c'en était bien un.
---

# Vérification des robots dans les logs serveur

N'importe quel client peut envoyer une chaîne user agent Googlebot, et sur la plupart des sites publics une part non négligeable des hits qui s'en réclament sont des aspirateurs de contenu, des outils de surveillance et des robots d'IA qui empruntent le nom. Un travail sur le budget de crawl bâti sur des logs non vérifiés est faux avant même que l'analyse commence, et les règles de pare-feu qui en découlent bloquent les mauvaises cibles. Cela vaut chaque fois que les logs servent de preuve, et systématiquement avant que quiconque bloque un robot au niveau du CDN.

## Ce qu’il vous faut d’abord

- Des logs d'accès bruts avec IP, user agent, statut, octets et horodatage, sur 14 jours minimum et sans échantillonnage
- La possibilité d'effectuer des résolutions DNS inverses et directes depuis la machine des logs, ou les plages d'IP publiées par les robots qui vous intéressent
- robots.txt ainsi que les règles anti-robots déjà en place sur le CDN ou le WAF
- La liste des robots qui comptent commercialement, en distinguant les moteurs de recherche des assistants IA

## Méthode

1. Regroupez les requêtes par chaîne user agent distincte, avec le nombre de hits et le volume d'octets. C'est le tri par identité revendiquée qui rend l'usurpation visible.
2. Vérifiez chaque hit se réclamant d'un robot de moteur par un DNS inverse sur l'IP, puis résolvez le nom d'hôte obtenu et confirmez qu'il renvoie bien à la même IP. Là où le DNS inverse n'est pas proposé, comparez au fichier de plages d'IP publié par l'opérateur, retéléchargé et non tiré de mémoire.
3. Étiquetez chaque requête comme vérifiée, non vérifiée ou autre, et conservez l'ensemble non vérifié au lieu de le supprimer. C'est votre photographie du scraping et de la charge, et le seul endroit où un usurpateur est visible.
4. Recalculez la fréquence de crawl, la profondeur de crawl et la répartition des statuts sur le seul segment vérifié. Toute conclusion sur le budget de crawl vient de ce segment et d'aucun autre.
5. Chiffrez ce que coûte réellement le trafic non vérifié : temps de réponse de l'origine, taux de 5xx sous charge et bande passante. Appliquez une limitation de débit là où la source peut encore être un outil dont quelqu'un dépend, et réservez le blocage pur et simple aux volumes qui pénalisent l'origine de façon démontrable.
6. Tranchez le cas des robots d'IA et d'entraînement séparément de celui des robots de recherche, et consignez la raison par écrit. Le débat est réel : les autoriser achète une visibilité dans les réponses des assistants qui n'enverra peut-être jamais un clic, les bloquer protège un contenu exploité sans contrepartie, et aucune des deux positions n'est tranchée.
7. Recommencez au bout de 30 jours. Les usurpateurs changent de user agent, les robots légitimes changent de plages d'IP, et une vérification faite une seule fois se dégrade en illusion de logs propres.

## Ce que ça produit

Un segment de logs limité aux robots vérifiés, une décision par robot, autoriser, limiter ou bloquer, avec sa raison explicite, et le trafic non vérifié résiduel chiffré en requêtes et en bande passante.

## Là où ça dérape

- Vérifier sur la seule foi du user agent, ou avec un fichier de plages d'IP téléchargé il y a des mois, si bien qu'un aspirateur reste compté dans votre budget de crawl et échappe à vos limites de débit
- Bloquer au WAF avant d'avoir essayé un Disallow dans robots.txt, ce qui transforme un robot qui aurait respecté la règle en un flot de 403 qu'il faut désormais expliquer
- Échantillonner un jour sur sept, alors que le crawl arrive par rafales : le jour retenu est soit une rafale entière, soit rien du tout
- Prendre une chaîne Googlebot venue d'une plage d'hébergement cloud pour la preuve d'une malveillance, alors que des émulateurs et des outils de test tiers envoient légitimement la même chaîne

---

Extrait de la bibliothèque de compétences QuQi - https://www.quqi.io/fr/skills/server-log-bot-verification
Téléchargement gratuit · sans compte, sans e-mail

Ce qu’il vous faut d’abord

  • Des logs d'accès bruts avec IP, user agent, statut, octets et horodatage, sur 14 jours minimum et sans échantillonnage
  • La possibilité d'effectuer des résolutions DNS inverses et directes depuis la machine des logs, ou les plages d'IP publiées par les robots qui vous intéressent
  • robots.txt ainsi que les règles anti-robots déjà en place sur le CDN ou le WAF
  • La liste des robots qui comptent commercialement, en distinguant les moteurs de recherche des assistants IA

Méthode

  1. 01 Regroupez les requêtes par chaîne user agent distincte, avec le nombre de hits et le volume d'octets. C'est le tri par identité revendiquée qui rend l'usurpation visible.
  2. 02 Vérifiez chaque hit se réclamant d'un robot de moteur par un DNS inverse sur l'IP, puis résolvez le nom d'hôte obtenu et confirmez qu'il renvoie bien à la même IP. Là où le DNS inverse n'est pas proposé, comparez au fichier de plages d'IP publié par l'opérateur, retéléchargé et non tiré de mémoire.
  3. 03 Étiquetez chaque requête comme vérifiée, non vérifiée ou autre, et conservez l'ensemble non vérifié au lieu de le supprimer. C'est votre photographie du scraping et de la charge, et le seul endroit où un usurpateur est visible.
  4. 04 Recalculez la fréquence de crawl, la profondeur de crawl et la répartition des statuts sur le seul segment vérifié. Toute conclusion sur le budget de crawl vient de ce segment et d'aucun autre.
  5. 05 Chiffrez ce que coûte réellement le trafic non vérifié : temps de réponse de l'origine, taux de 5xx sous charge et bande passante. Appliquez une limitation de débit là où la source peut encore être un outil dont quelqu'un dépend, et réservez le blocage pur et simple aux volumes qui pénalisent l'origine de façon démontrable.
  6. 06 Tranchez le cas des robots d'IA et d'entraînement séparément de celui des robots de recherche, et consignez la raison par écrit. Le débat est réel : les autoriser achète une visibilité dans les réponses des assistants qui n'enverra peut-être jamais un clic, les bloquer protège un contenu exploité sans contrepartie, et aucune des deux positions n'est tranchée.
  7. 07 Recommencez au bout de 30 jours. Les usurpateurs changent de user agent, les robots légitimes changent de plages d'IP, et une vérification faite une seule fois se dégrade en illusion de logs propres.

Ce que ça produit

Un segment de logs limité aux robots vérifiés, une décision par robot, autoriser, limiter ou bloquer, avec sa raison explicite, et le trafic non vérifié résiduel chiffré en requêtes et en bande passante.

Là où ça dérape

  • Vérifier sur la seule foi du user agent, ou avec un fichier de plages d'IP téléchargé il y a des mois, si bien qu'un aspirateur reste compté dans votre budget de crawl et échappe à vos limites de débit
  • Bloquer au WAF avant d'avoir essayé un Disallow dans robots.txt, ce qui transforme un robot qui aurait respecté la règle en un flot de 403 qu'il faut désormais expliquer
  • Échantillonner un jour sur sept, alors que le crawl arrive par rafales : le jour retenu est soit une rafale entière, soit rien du tout
  • Prendre une chaîne Googlebot venue d'une plage d'hébergement cloud pour la preuve d'une malveillance, alors que des émulateurs et des outils de test tiers envoient légitimement la même chaîne

Utiliser cette compétence dans votre propre IA

Le fichier téléchargé est un simple markdown dont l'en-tête porte le nom et le déclencheur. Quand un assistant sait charger des compétences tout seul, c'est cet en-tête qu'il lit pour décider que celle-ci s'applique.

Claude Code Enregistrez-le sous ~/.claude/skills/server-log-bot-verification/SKILL.md et Claude le charge tout seul dès que ce que vous faites correspond au déclencheur. Placez-le plutôt dans .claude/skills d'un projet si toute l'équipe doit l'avoir.
Claude Importez le fichier dans la section compétences de vos réglages. Une fois là, il s'applique tout seul dans toute conversation où le déclencheur colle, sans que vous ayez à y penser.
ChatGPT Il n'existe pas de format de compétences où l'installer, alors collez le contenu du fichier dans les instructions d'un Projet ou d'un GPT personnalisé. Il s'applique ensuite à toutes les conversations du projet, pas seulement à celle où vous l'avez collé.
Tout le reste Collez le markdown dans la conversation avant votre question. Cela fonctionne avec n'importe quel assistant, il faut simplement le recoller à chaque fois.

Plus dans SEO technique