LLMs et crawl : comment GPTBot, Claude et les bots IA crawlent votre site

Un éditeur de presse français de 28 000 pages a vu son temps de réponse serveur tripler en novembre 2024. Pas de pic de trafic organique. Pas de campagne virale. Dans les logs : GPTBot, ClaudeBot et Bytespider représentaient 47 % des requêtes totales — plus que Googlebot. Le crawl budget Google s'est effondré mécaniquement, et les pages récemment publiées ont mis 11 jours à être indexées au lieu de 2.

Ce scénario se répète sur des centaines de sites depuis 2024. Les crawlers des LLMs sont une nouvelle classe d'agents dont le comportement, les objectifs et l'agressivité n'ont rien à voir avec les search bots traditionnels. Comprendre comment ils fonctionnent est devenu un prérequis technique.

Cartographie des crawlers IA : qui crawle quoi, et pourquoi

Les crawlers IA ne forment pas un bloc monolithique. Chaque acteur a ses propres user-agents, ses propres objectifs, et surtout ses propres niveaux de respect des conventions.

Les crawlers identifiés et documentés

Voici les principaux user-agents actifs en 2026, avec leur documentation officielle :

Bot	Opérateur	User-Agent string	Objectif	Respecte robots.txt
GPTBot	OpenAI	GPTBot/1.0	Entraînement + retrieval	Oui (documenté)
ChatGPT-User	OpenAI	ChatGPT-User	Browsing en temps réel	Oui
OAI-SearchBot	OpenAI	OAI-SearchBot/1.0	SearchGPT	Oui
ClaudeBot	Anthropic	ClaudeBot/1.0	Entraînement	Oui (documenté)
Bytespider	ByteDance	Bytespider	Entraînement (TikTok/Doubao)	Partiellement
Meta-ExternalAgent	Meta	Meta-ExternalAgent/1.0	Entraînement LLaMA	Oui
PerplexityBot	Perplexity	PerplexityBot	RAG en temps réel	Oui
Google-Extended	Google	Google-Extended	Entraînement Gemini	Oui
Applebot-Extended	Apple	Applebot-Extended	Entraînement Apple Intelligence	Oui
cohere-ai	Cohere	cohere-ai	Entraînement	Oui

La distinction critique se situe entre les bots d'entraînement (qui aspirent massivement du contenu pour créer des datasets) et les bots de retrieval (qui récupèrent du contenu à la volée pour répondre à une requête utilisateur). GPTBot sert aux deux. ChatGPT-User ne fait que du retrieval. La différence d'impact sur vos serveurs est considérable.

Les bots non déclarés

Le problème majeur : une partie significative du crawl IA n'est pas identifiable via le user-agent. Certains bots se font passer pour des navigateurs classiques (Chrome headless, par exemple). Les logs révèlent souvent des patterns suspects — des requêtes séquentielles sur l'intégralité d'un sitemap, provenant de plages IP de fournisseurs cloud (AWS, GCP, Azure), avec un user-agent Chrome standard.

Identifier ces crawlers fantômes nécessite une analyse des plages IP et des patterns de crawl, pas seulement du user-agent. Nous y reviendrons.

Anatomie d'un crawl IA : différences fondamentales avec Googlebot

Googlebot crawle votre site avec un objectif précis : construire et maintenir un index de recherche. Son crawl est sélectif — il priorise les pages selon leur PageRank interne, leur fréquence de mise à jour, et les signaux de qualité. Il respecte un crawl rate adaptatif qui évite de surcharger votre serveur.

Les crawlers IA, eux, ont un comportement radicalement différent.

Crawl exhaustif vs. crawl sélectif

GPTBot et ClaudeBot ne cherchent pas à "indexer" au sens classique. Ils cherchent du texte de qualité pour alimenter des datasets d'entraînement. Conséquence : ils crawlent de manière bien plus agressive les pages à fort contenu textuel (articles, documentation, fiches produit détaillées) et ignorent souvent les pages structurelles (catégories, paginations).

Un pattern typique observé dans les logs :

# Extrait de logs d'accès — GPTBot sur un site e-commerce (15 000 produits)
# 2026-03-15 — 6h de crawl

66.249.xx.xx - - [15/Mar/2026:02:14:33] "GET /produit/chaussure-running-nike-pegasus-41 HTTP/2" 200 48291 "-" "GPTBot/1.0 (+https://openai.com/gptbot)"
66.249.xx.xx - - [15/Mar/2026:02:14:34] "GET /produit/chaussure-trail-salomon-ultra-glide HTTP/2" 200 52103 "-" "GPTBot/1.0 (+https://openai.com/gptbot)"
66.249.xx.xx - - [15/Mar/2026:02:14:34] "GET /produit/chaussure-running-asics-gel-nimbus-26 HTTP/2" 200 45887 "-" "GPTBot/1.0 (+https://openai.com/gptbot)"
# ... 800 requêtes/minute sur les fiches produit uniquement
# Aucune requête sur /categorie/ ou /marque/

800 requêtes par minute. Googlebot, sur le même site, tournait à 40-60 requêtes par minute. Un facteur 15x.

Pas de gestion du crawl budget côté IA

Googlebot a un mécanisme intégré de crawl rate limiting : si votre serveur ralentit, il réduit sa cadence. Vous pouvez ajuster ça dans Search Console. Les crawlers IA n'ont pour la plupart aucun mécanisme d'adaptation dynamique documenté. GPTBot respecte le Crawl-delay dans robots.txt selon la documentation d'OpenAI, mais ce n'est pas un standard universel. Bytespider, historiquement, l'ignore largement.

Le risque concret : un crawl IA agressif consomme les ressources serveur, augmente le TTFB, et Googlebot — qui lui adapte sa cadence — réduit mécaniquement son crawl. Vos pages mettent plus longtemps à être découvertes et indexées. C'est exactement le scénario de l'éditeur de presse évoqué en introduction.

Pour suivre ce type de dégradation, les rapports d'exploration de la Search Console sont votre premier signal d'alerte : une chute du nombre de pages crawlées par jour par Googlebot, corrélée à une hausse du temps de réponse moyen, indique presque toujours une surcharge causée par un tiers.

Contrôler l'accès via robots.txt : ce qui fonctionne, ce qui ne fonctionne pas

Le robots.txt reste le mécanisme standard pour communiquer vos préférences aux crawlers IA. Tous les opérateurs majeurs (OpenAI, Anthropic, Google, Meta, Apple) se sont engagés publiquement à le respecter. Mais les nuances sont essentielles.

Configuration robots.txt complète pour les bots IA

Voici une configuration robots.txt qui couvre les principaux crawlers IA actuels, avec des stratégies différenciées :

# robots.txt — Stratégie différenciée pour les bots IA
# Dernière mise à jour : 2026-04-10

# === SEARCH ENGINES (accès complet) ===
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

# === BOTS IA — ENTRAÎNEMENT (blocage total) ===
# On refuse l'utilisation du contenu pour l'entraînement de modèles

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: cohere-ai
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Omgili
Disallow: /

User-agent: Diffbot
Disallow: /

# === BOTS IA — RETRIEVAL (accès autorisé, contenu limité) ===
# On autorise les bots qui citent/linkent nos pages en temps réel

User-agent: ChatGPT-User
Allow: /blog/
Allow: /guide/
Disallow: /

User-agent: PerplexityBot
Allow: /blog/
Allow: /guide/
Disallow: /

User-agent: OAI-SearchBot
Allow: /blog/
Allow: /guide/
Disallow: /

La logique derrière cette configuration : bloquer les bots d'entraînement (qui prennent votre contenu sans rien donner en retour) tout en autorisant les bots de retrieval sur les sections où vous souhaitez de la visibilité dans les réponses des LLMs. ChatGPT-User et PerplexityBot, lorsqu'ils citent votre contenu, génèrent du trafic référent mesurable.

Les limites du robots.txt

Trois problèmes concrets que le robots.txt ne résout pas :

1. Les bots non identifiés. Un crawler qui se présente avec un user-agent Chrome ne sera pas filtré par robots.txt. Seule l'analyse des plages IP et des patterns de requête permet de les détecter.

2. Le robots.txt est consultatif. Rien n'empêche techniquement un bot de l'ignorer. Les acteurs majeurs le respectent par engagement légal (surtout depuis les procès NYT vs. OpenAI et les régulations européennes). Mais les acteurs plus petits ou les scrapers dérivés ne jouent pas forcément le jeu.

3. Pas de granularité temporelle. Vous ne pouvez pas dire "crawlez-moi 50 pages par jour maximum" via robots.txt. Le Crawl-delay est un hack imparfait et n'est pas supporté par tous les bots.

Défense en profondeur : contrôler le crawl au niveau serveur

Le robots.txt est votre première ligne. La configuration serveur est votre deuxième ligne — et elle est impérative pour les bots qui ne jouent pas le jeu.

Rate limiting par user-agent avec Nginx

# /etc/nginx/conf.d/ai-bots-rate-limit.conf

# Définition d'une map pour identifier les bots IA
map $http_user_agent $is_ai_bot {
    default 0;
    "~*GPTBot"              1;
    "~*ClaudeBot"           1;
    "~*Bytespider"          1;
    "~*ChatGPT-User"        1;
    "~*PerplexityBot"       1;
    "~*Meta-ExternalAgent"  1;
    "~*OAI-SearchBot"       1;
    "~*cohere-ai"           1;
    "~*Diffbot"             1;
    "~*CCBot"               1;
}

# Zone de rate limiting dédiée aux bots IA
# 5 requêtes par seconde max — burst de 10 avec délai
limit_req_zone $binary_remote_addr zone=ai_bot_limit:10m rate=5r/s;

server {
    listen 443 ssl http2;
    server_name www.monsite-ecommerce.fr;

    # Appliquer le rate limit uniquement aux bots IA identifiés
    location / {
        if ($is_ai_bot) {
            set $limit_ai "1";
        }

        limit_req zone=ai_bot_limit burst=10 nodelay;
        # Note : la directive limit_req s'applique ici à tous,
        # mais la zone est dimensionnée pour les bots.
        # Pour un ciblage plus fin, utilisez un location imbriqué
        # ou un module Lua (OpenResty).

        proxy_pass http://backend;
    }

    # Bloc spécifique : retourner 403 pour les bots à bloquer complètement
    # Plus fiable que robots.txt pour les bots non coopératifs
    if ($http_user_agent ~* "(Bytespider|CCBot|Diffbot)") {
        return 403;
    }
}

Cette approche a un avantage clé sur le robots.txt : elle s'exécute réellement. Un return 403 ne laisse pas le choix au bot. Le rate limiting protège vos ressources serveur même si un bot tente un crawl massif.

Pour les architectures utilisant un CDN (Cloudflare, Fastly, Akamai), la logique de filtrage peut être déportée au edge — ce qui est souvent plus performant. Si vous utilisez Cloudflare Workers ou des VCL Fastly pour modifier les réponses HTTP, le même principe s'applique : l'edge SEO permet de filtrer les bots sans toucher à votre infrastructure applicative.

Détection des crawlers non identifiés via les logs

Le vrai défi n'est pas GPTBot — il s'identifie proprement. Le défi, ce sont les crawlers qui ne s'identifient pas. Voici un script bash pour détecter les patterns de crawl suspects dans vos access logs :

#!/bin/bash
# detect-stealth-crawlers.sh
# Détecte les IPs qui crawlent de manière séquentielle avec un UA Chrome
# depuis des plages IP de cloud providers

ACCESS_LOG="/var/log/nginx/access.log"
THRESHOLD=200  # Nombre de requêtes par IP sur les dernières 24h

echo "=== IPs suspectes (>$THRESHOLD requêtes/24h, UA Chrome, pas de JS/CSS/images) ==="

# Filtrer les requêtes des dernières 24h, UA contenant Chrome,
# uniquement des pages HTML (pas de ressources statiques)
awk -v threshold="$THRESHOLD" '
/Chrome\// && !/\.(js|css|png|jpg|jpeg|webp|svg|woff2|ico)/ {
    ip = $1
    count[ip]++
}
END {
    for (ip in count) {
        if (count[ip] > threshold) {
            printf "%s\t%d requêtes\n", ip, count[ip]
        }
    }
}' "$ACCESS_LOG" | sort -t$'\t' -k2 -rn | head -20

echo ""
echo "=== Vérification des plages IP (whois) ==="
# Pour chaque IP suspecte, vérifier si elle appartient à un cloud provider
awk -v threshold="$THRESHOLD" '
/Chrome\// && !/\.(js|css|png|jpg|jpeg|webp|svg|woff2|ico)/ {
    count[$1]++
}
END {
    for (ip in count) {
        if (count[ip] > threshold) print ip
    }
}' "$ACCESS_LOG" | while read ip; do
    org=$(whois "$ip" 2>/dev/null | grep -i "org-name\|OrgName\|netname" | head -1)
    echo "$ip => $org"
done

Un vrai navigateur Chrome charge des CSS, des images, du JavaScript. Un crawler headless qui se fait passer pour Chrome ne charge généralement que le HTML. Ce pattern (beaucoup de requêtes HTML, zéro ressource statique, IP cloud) est le signal le plus fiable pour identifier un scraper IA non déclaré.

L'intégration de ce type de détection dans un pipeline CI/CD est parfaitement faisable. Si vous automatisez déjà vos checks SEO dans le CI/CD, ajouter une vérification des patterns de crawl suspects est un prolongement naturel.

Impact réel sur le SEO : un scénario documenté

Reprenons le cas de l'éditeur de presse mentionné en introduction, avec des chiffres concrets.

Contexte

• Site de presse francophone, 28 000 pages indexées
• Stack : Next.js avec SSR, hébergé sur Kubernetes (3 pods, auto-scaling à 8)
• Trafic organique : 1,2 million de sessions/mois
• Crawl Googlebot moyen : 18 000 pages/jour

Chronologie de la dégradation

Semaine 1 (baseline) : TTFB moyen 180 ms. Googlebot crawle 18 000 pages/jour. Les articles publiés le matin apparaissent dans Google News sous 2h.

Semaine 2 : GPTBot et ClaudeBot commencent un crawl intensif. Les logs montrent 45 000 requêtes/jour pour GPTBot seul, ciblant exclusivement les articles éditoriaux. Le TTFB passe à 420 ms. L'auto-scaling fait monter les pods à 6/8 en permanence — la facture cloud augmente de 40 %.

Semaine 3 : Bytespider rejoint la fête. 62 000 requêtes/jour combinées pour les trois bots IA. Le TTFB atteint 580 ms. Le rapport d'exploration de Search Console montre que Googlebot a réduit son crawl à 7 200 pages/jour — une chute de 60 %. Les nouveaux articles mettent 8 à 11 jours à apparaître dans l'index.

Semaine 4 (intervention) : Mise en place du blocage robots.txt + rate limiting Nginx. En 72h, le TTFB redescend à 210 ms. Le crawl Googlebot remonte progressivement à 15 000 pages/jour sur les deux semaines suivantes.

Ce que ça coûte réellement

La perte directe : 11 jours de délai d'indexation sur un site de presse, c'est une perte de trafic Google News et Discover estimée à 15-20 % du trafic organique sur la période. Pour un site à 1,2 million de sessions/mois, ça représente environ 180 000 sessions perdues sur un mois.

La perte indirecte : les coûts d'infrastructure (auto-scaling) ont augmenté de 40 % sans aucun trafic utile supplémentaire. Du pur gaspillage.

L'article sur le trafic des bots IA en hausse de 300 % qui frappe les éditeurs en priorité décrit exactement ce phénomène à l'échelle industrielle.

Stratégie de visibilité dans les réponses LLM

Bloquer tous les bots IA n'est pas nécessairement la bonne stratégie. La question est plus nuancée : quels bots, sur quelles sections, pour quel bénéfice ?

Le calcul coût-bénéfice

Il existe désormais un trafic référent mesurable depuis les interfaces des LLMs. Quand ChatGPT cite votre article avec un lien, quand Perplexity affiche votre contenu en source, ça génère des visites. Ce trafic est encore modeste comparé au SEO traditionnel (typiquement 1-3 % du trafic organique pour les sites qui en bénéficient), mais il croît rapidement.

La stratégie optimale pour la plupart des sites :

• Bloquer les bots d'entraînement (GPTBot, ClaudeBot, Google-Extended, Meta-ExternalAgent) : votre contenu sert à entraîner des modèles qui peuvent ensuite répondre à vos utilisateurs sans jamais les envoyer chez vous
• Autoriser les bots de retrieval (ChatGPT-User, OAI-SearchBot, PerplexityBot) sur vos sections à forte valeur éditoriale : blog, guides, documentation

C'est exactement la logique du robots.txt différencié présenté plus haut.

Optimiser le contenu pour le retrieval IA

Les bots de retrieval des LLMs fonctionnent différemment de Googlebot dans leur extraction de contenu. Ils privilégient :

• Les paragraphes auto-suffisants (qui répondent à une question sans nécessiter le contexte de la page entière)
• Les données structurées, en particulier les FAQ et les HowTo
• Les informations factuelles datées (les LLMs cherchent à fournir des informations à jour)

L'approche est compatible avec le SEO classique : un contenu bien structuré, avec des H2/H3 clairs et des paragraphes qui répondent chacun à une question spécifique, performe bien à la fois pour Google et pour le retrieval IA.

Pour approfondir comment les modèles IA interprètent (et parfois déforment) votre contenu, l'article sur comment l'IA décide ce que signifie votre contenu détaille les mécanismes internes de compréhension sémantique.

Monitoring et détection en continu

La difficulté avec les crawlers IA, c'est leur imprévisibilité. Un nouveau bot peut apparaître du jour au lendemain. Un bot existant peut changer de comportement. Vous ne pouvez pas configurer votre robots.txt une fois et oublier.

Ce qu'il faut monitorer

1. La part de trafic bot IA dans vos logs. Si elle dépasse 20-25 % de vos requêtes totales, vous avez un problème de ressources.

2. Le crawl rate Googlebot. Disponible dans le rapport d'exploration de Search Console et via l'API Search Console. Une chute soudaine corrélée à une hausse du TTFB est le signe classique d'une cannibalisation des ressources par les bots IA.

3. Les nouveaux user-agents inconnus. Un monitoring automatisé des user-agents dans vos logs, avec une alerte sur tout nouvel agent non répertorié dépassant un seuil de requêtes, est indispensable.

4. Le trafic référent depuis les LLMs. Dans Google Analytics 4, les sources chat.openai.com, perplexity.ai, claude.ai doivent être trackées séparément pour mesurer le ROI de l'accès accordé aux bots de retrieval.

Un outil de monitoring SEO technique comme Seogard détecte automatiquement les variations anormales de crawl et de temps de réponse qui signalent ce type de problème, sans attendre que vous pensiez à vérifier vos logs.

Automatiser la surveillance avec un cron

Pour les équipes qui préfèrent un monitoring maison, un cron quotidien qui parse les logs et envoie un rapport Slack est un minimum :

#!/bin/bash
# /etc/cron.daily/ai-bot-report.sh
# Rapport quotidien du crawl IA

LOG="/var/log/nginx/access.log"
SLACK_WEBHOOK="https://hooks.slack.com/services/xxx/yyy/zzz"
DATE=$(date -d "yesterday" '+%d/%b/%Y')

# Comptage par bot IA
report=$(awk -v date="$DATE" '
$0 ~ date {
    if ($0 ~ /GPTBot/)              bots["GPTBot"]++
    else if ($0 ~ /ClaudeBot/)      bots["ClaudeBot"]++
    else if ($0 ~ /Bytespider/)     bots["Bytespider"]++
    else if ($0 ~ /ChatGPT-User/)   bots["ChatGPT-User"]++
    else if ($0 ~ /PerplexityBot/)  bots["PerplexityBot"]++
    else if ($0 ~ /OAI-SearchBot/)  bots["OAI-SearchBot"]++
    else if ($0 ~ /Googlebot/)      bots["Googlebot"]++
    total++
}
END {
    printf "📊 Crawl IA — %s\n", date
    printf "Total requêtes : %d\n\n", total
    for (bot in bots) {
        pct = (bots[bot] / total) * 100
        printf "%-20s %8d (%5.1f%%)\n", bot, bots[bot], pct
    }
}' "$LOG")

# Alerte si les bots IA dépassent 30% du crawl total
ai_pct=$(echo "$report" | awk '/GPTBot|ClaudeBot|Bytespider|ChatGPT|Perplexity|OAI-Search/ {sum += $2} /Total/ {total = $4} END {printf "%.0f", (sum/total)*100}')

if [ "$ai_pct" -gt 30 ]; then
    alert="⚠️ ALERTE : les bots IA représentent ${ai_pct}% du crawl total"
    report="$alert\n\n$report"
fi

# Envoi Slack
curl -s -X POST "$SLACK_WEBHOOK" \
    -H 'Content-type: application/json' \
    -d "{\"text\":\"$(echo -e "$report")\"}"

Ce script est basique mais fonctionnel. En production, vous voudrez le compléter avec la corrélation TTFB et le suivi du crawl Googlebot. Les outils comme Chrome DevTools restent utiles pour debugger des problèmes ponctuels de rendu, mais pour le monitoring continu du crawl bot, l'analyse de logs est irremplaçable.

Le cadre légal en évolution

Un point que beaucoup de leads SEO sous-estiment : la dimension juridique du crawl IA évolue rapidement et influence directement la stratégie technique.

L'AI Act européen (en application depuis 2025) impose aux fournisseurs de modèles d'IA générative de documenter les données d'entraînement utilisées et de respecter les opt-outs. Le robots.txt, combiné avec les meta tags noai et noimageai proposés par certains acteurs, commence à avoir une valeur juridique — pas seulement conventionnelle.

Concrètement, cela signifie que votre robots.txt est aussi un document de politique de données. Documentez-le, versionnez-le dans git, et horodatez les changements. Si vous devez un jour prouver que vous aviez bloqué un crawler spécifique avant une certaine date, l'historique git de votre robots.txt sera votre pièce à conviction.

La question de la génération de contenu automatisée et du SEO se pose aussi dans l'autre sens : les LLMs entraînés sur votre contenu peuvent produire du texte qui cannibalise vos pages dans les SERP. Bloquer l'entraînement est une forme de protection de votre avantage compétitif éditorial.

---

Les crawlers IA sont une infrastructure parallèle à celle des moteurs de recherche, avec des volumes comparables et une agressivité souvent supérieure. La gestion de ces bots n'est plus optionnelle : c'est un composant à part entière de la stack SEO technique, au même titre que le sitemap ou le robots.txt pour les search bots. La combinaison robots.txt différencié + rate limiting serveur + monitoring continu des logs est le minimum pour garder le contrôle de vos ressources serveur et protéger votre crawl budget Google.