Bloquer les bots scrapers IA (GPTBot, crawlers LLM) sans casser son SEO : règles WAF OWASP CRS

Un matin, les métriques d'hébergement montrent un pic de bande passante inexpliqué. Pas d'attaque, pas de campagne marketing en cours, juste un trafic qui grimpe régulièrement depuis plusieurs semaines. En creusant les logs, le motif apparaît : des dizaines de milliers de requêtes par jour depuis des User-Agents comme GPTBot, CCBot ou Bytespider, qui parcourent chaque page, chaque fiche produit, chaque article de blog. Ce n'est pas un incident de sécurité au sens classique, mais un problème bien réel de coût, de charge serveur et de propriété du contenu.

La réaction instinctive, bloquer tout ce qui ressemble à un robot, est la pire des solutions : elle prend aussi Googlebot dans le filet, et le référencement s'effondre en quelques jours. Cet article détaille comment cibler précisément les crawlers d'entraînement IA sans toucher aux moteurs de recherche légitimes.

Le problème concret : des crawlers qui aspirent tout, gratuitement

Depuis 2024, plusieurs éditeurs de modèles de langage font tourner des robots d'indexation dédiés à la collecte de contenu pour l'entraînement de leurs modèles :

• GPTBot (OpenAI)
• ClaudeBot (Anthropic)
• CCBot (Common Crawl, souvent réutilisé en amont par des entraîneurs de modèles)
• Bytespider (ByteDance)
• Google-Extended (distinct de Googlebot, dédié à l'entraînement Gemini)

Ces robots n'ont, pour un site e-commerce ou une PME de services, aucun bénéfice direct : ils ne génèrent pas de clic, pas de conversion, pas de visibilité mesurable. Ils consomment en revanche de la bande passante sortante, sollicitent le serveur d'origine (souvent sans passer par le cache CDN, car ils ignorent parfois les en-têtes de cache classiques) et aspirent l'intégralité du contenu, y compris des pages qu'un site préférerait ne jamais voir republiées telles quelles ailleurs.

Sur un catalogue produit de plusieurs milliers de références, l'addition en requêtes et en CPU serveur devient significative, sans qu'aucune ligne du chiffre d'affaires ne s'en trouve améliorée.

Le piège du blocage trop large

Face à ce constat, le réflexe le plus courant est de bloquer par mots-clés larges dans le User-Agent, du type "bot", "crawl" ou "spider". C'est exactement l'erreur à ne pas commettre.

Googlebot, Bingbot et les crawlers des réseaux sociaux (utiles pour les aperçus de partage) contiennent eux aussi ces termes. Un blocage trop générique fait disparaître le site des résultats de recherche en quelques jours, avec un délai de récupération qui se compte ensuite en semaines une fois l'erreur corrigée.

La bonne méthode distingue deux familles bien différentes :

Le troisième cas est le plus sournois : rien n'empêche un scraper malveillant de déclarer un User-Agent Googlebot pour contourner un blocage naïf basé uniquement sur la chaîne déclarée.

Règle WAF ciblée par User-Agent, avec vérification reverse DNS

La bonne pratique associe deux couches de contrôle. La première identifie le User-Agent revendiqué ; la deuxième vérifie que l'IP source correspond bien à l'infrastructure de l'éditeur qu'il prétend représenter.

Un exemple de règle ModSecurity (compatible OWASP CRS) qui cible spécifiquement les crawlers d'entraînement IA connus :

SecRule REQUEST_HEADERS:User-Agent "@rx (?i)(GPTBot|ClaudeBot|CCBot|Bytespider|Google-Extended|Amazonbot|Applebot-Extended)" \
    "id:9001001,\
    phase:1,\
    deny,\
    status:403,\
    log,\
    msg:'Blocked known AI training crawler by User-Agent',\
    tag:'ai-scraper-block',\
    chain"
    SecRule REQUEST_HEADERS:User-Agent "!@rx (?i)googlebot|bingbot" "t:none"

Pour le cas des User-Agents usurpés qui se prétendent être un moteur de recherche légitime, la vérification passe par une résolution DNS inverse suivie d'une résolution directe (double vérification, la méthode recommandée par Google elle-même pour valider Googlebot) :

#!/bin/bash
# verify_crawler.sh : confirme qu'une IP prétendant être Googlebot
# appartient bien à l'infrastructure Google
IP="$1"
HOSTNAME=$(dig +short -x "$IP" | sed 's/\.$//')
 
if [[ "$HOSTNAME" != *".googlebot.com" && "$HOSTNAME" != *".google.com" ]]; then
    echo "SUSPECT: $IP ne résout pas vers un domaine Google"
    exit 1
fi
 
FORWARD_IP=$(dig +short "$HOSTNAME" | tail -n1)
if [[ "$FORWARD_IP" != "$IP" ]]; then
    echo "SUSPECT: résolution directe ne correspond pas ($FORWARD_IP != $IP)"
    exit 1
fi
 
echo "OK: $IP est un vrai crawler Google ($HOSTNAME)"

Cette vérification, exécutée en tâche périodique ou intégrée en amont du WAF, permet de traiter différemment un vrai Googlebot et un scraper qui usurpe son identité.

Pourquoi robots.txt seul ne suffit pas

La première réaction, ajouter une directive dans robots.txt, est nécessaire mais très insuffisante seule :

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

Le problème : robots.txt est une convention déclarative, pas un mécanisme d'application. Rien n'oblige un robot à la respecter, et plusieurs crawlers d'entraînement IA ont déjà été documentés en train de l'ignorer purement et simplement, ou de changer d'infrastructure pour continuer à collecter malgré l'interdiction. robots.txt reste une bonne pratique de premier niveau (certains éditeurs la respectent effectivement), mais la seule protection réellement effective est celle qui s'applique au niveau du WAF, où la requête peut être bloquée avant même d'atteindre l'application.

Rate-limiting et anomaly scoring plutôt que blocage binaire

Bloquer entièrement n'est pas toujours le bon choix, en particulier lorsque l'identification du crawler reste incertaine ou lorsque le site souhaite conserver une politique plus permissive vis-à-vis de certains agents. Une approche graduée, cohérente avec le modèle d'anomaly scoring d'OWASP CRS, consiste à faire monter un score de comportement plutôt que de trancher en tout ou rien :

SecRule REQUEST_HEADERS:User-Agent "@rx (?i)(GPTBot|CCBot|Bytespider)" \
    "id:9001002,\
    phase:1,\
    pass,\
    setvar:'tx.anomaly_score_pl1=+15',\
    msg:'AI crawler detected, scoring applied'"
 
SecRule IP:REQCOUNT "@gt 60" \
    "id:9001003,\
    phase:1,\
    deny,\
    status:429,\
    msg:'AI crawler rate limit exceeded (60 req/min)',\
    expirevar:IP.REQCOUNT=60"

Cette logique dégrade le trafic excessif (limitation à N requêtes par minute, renvoi de 429) sans bannir catégoriquement l'IP dès la première requête suspecte. Elle laisse une marge pour les cas ambigus (un vrai moteur de recherche mal identifié, un partenaire légitime) sans pour autant laisser filer un aspirateur de contenu à plein débit.

Avant / après : ce qu'il faut surveiller

Deux séries de métriques permettent de juger l'efficacité réelle du dispositif, et surtout d'éviter l'effet de bord redouté (une chute du trafic organique) :

Avant la mise en place :

• Bande passante bot mensuelle (souvent identifiable via les logs d'accès filtrés par User-Agent connu)
• Part du trafic serveur attribuable aux crawlers IA (fréquemment entre 10 et 30 % du trafic total non-humain sur un site de contenu)
• Taux d'indexation Google inchangé (Search Console, couverture)

Après la mise en place :

• Chute de la bande passante consommée par les crawlers bloqués
• Taux de faux blocages sur trafic légitime : à surveiller de près pendant deux à trois semaines via les logs 403/429, en cherchant spécifiquement les hits provenant d'IP Google, Bing ou de partenaires connus
• Stabilité du trafic organique et de l'indexation dans les outils webmaster, semaine après semaine

Un déploiement réussi montre une bande passante bot en forte baisse et un taux de faux blocage proche de zéro sur le trafic Googlebot vérifié. Si ce dernier chiffre bouge, c'est le signal qu'une règle est trop large et qu'il faut resserrer la condition avant qu'elle n'impacte le classement.

Le pack de règles anti-scraping IA

Écrire et maintenir ces règles à la main, en suivant l'évolution constante des User-Agents et des plages IP des nouveaux crawlers d'entraînement, demande une veille continue que peu de PME peuvent tenir dans la durée. Un jeu de règles pré-tunées, validé sur trafic réel et régulièrement mis à jour à mesure que de nouveaux crawlers apparaissent, évite l'écueil du blocage trop large tout en fermant réellement le robinet de bande passante inutile.

Le pack de règles WAF anti-scraping IA de ThreatClaw couvre les crawlers connus, intègre la logique de vérification reverse DNS et le rate-limiting gradué, prêt à s'intégrer sans casser le trafic légitime ni le référencement.