Sur un panel de sites totalisant 24 millions de requêtes de crawl analysées par Vercel et AllIAI, le user-agent ChatGPT-User génère désormais 3,6 fois plus de hits que Googlebot. Ce n'est plus un signal faible — c'est un renversement structurel dans la façon dont les serveurs web sont sollicités. Et la plupart des infrastructures n'y sont pas préparées.
L'étude AllIAI/Vercel : ce que les données montrent vraiment
L'étude publiée par Search Engine Journal repose sur l'analyse de logs serveur agrégés par AllIAI sur des sites hébergés chez Vercel. Le dataset couvre 24 millions de requêtes de crawl sur une période récente. Le constat principal : ChatGPT-User représente le premier poste de requêtes automatisées, devant Googlebot (toutes variantes confondues).
Ce que ça n'est pas
Il faut immédiatement nuancer. Ce ratio 3,6x ne signifie pas que ChatGPT "indexe" 3,6 fois plus de pages que Google. Les deux crawlers n'ont pas la même finalité :
- Googlebot crawle pour indexer, calculer le PageRank, alimenter les SERP. Son crawl est optimisé : il priorise les pages à forte valeur, respecte le crawl budget, et recrawle intelligemment.
- ChatGPT-User crawle en temps réel pour répondre à des requêtes utilisateurs dans l'interface ChatGPT (quand la fonctionnalité "Browse" est activée). Chaque conversation qui déclenche une recherche web génère potentiellement des dizaines de requêtes HTTP vers les sites sources.
Le volume brut de requêtes ne reflète donc pas une "indexation" plus profonde, mais une mécanique fondamentalement différente : un crawl conversationnel, distribué, à haute fréquence et faible profondeur par session.
Pourquoi le volume explose
La raison est arithmétique. Google effectue un crawl planifié et centralisé. ChatGPT effectue un crawl déclenché par chaque requête utilisateur avec Browse activé. Avec des centaines de millions d'utilisateurs actifs sur ChatGPT, chaque question de type "compare les prix de X" ou "quelles sont les meilleures pratiques pour Y" peut générer 10 à 30 requêtes HTTP vers des sites tiers en quelques secondes. Multipliez par le volume de conversations quotidiennes, et le ratio 3,6x devient logique — voire conservateur.
Pour le vérifier dans vos propres logs, voici comment filtrer les requêtes de ChatGPT-User sur un access log Nginx standard :
# Comptage des requêtes par user-agent AI vs Googlebot sur 7 jours
awk -v start="$(date -d '7 days ago' '+%d/%b/%Y')" '
$4 ~ start {
if ($0 ~ /ChatGPT-User/) chatgpt++
if ($0 ~ /Googlebot/) googlebot++
if ($0 ~ /GPTBot/) gptbot++
if ($0 ~ /ClaudeBot/) claude++
if ($0 ~ /Bytespider/) bytespider++
}
END {
print "ChatGPT-User:", chatgpt+0
print "GPTBot:", gptbot+0
print "Googlebot:", googlebot+0
print "ClaudeBot:", claude+0
print "Bytespider:", bytespider+0
}
' /var/log/nginx/access.logSi vous n'avez jamais segmenté vos logs par bot IA, vous allez probablement découvrir que ces crawlers consomment déjà une part significative de votre bande passante. Notre guide sur l'analyse de logs pour le SEO couvre la méthodologie en détail — il est temps de l'étendre aux bots IA.
GPTBot vs ChatGPT-User : deux crawlers, deux stratégies
OpenAI opère deux user-agents distincts, et la confusion entre les deux est un problème courant dans les configurations de blocage.
GPTBot
GPTBot est le crawler d'entraînement. Il parcourt le web pour alimenter les datasets utilisés pour fine-tuner les modèles. Son comportement ressemble à celui d'un crawler classique : il suit les liens, respecte (en principe) le robots.txt, et effectue un crawl en profondeur sur de longues périodes. C'est celui que la plupart des éditeurs ont bloqué en 2024.
ChatGPT-User
ChatGPT-User est le crawler de navigation en temps réel. Il se déclenche quand un utilisateur demande à ChatGPT de "chercher sur le web" ou quand le modèle détermine qu'une recherche live est nécessaire pour répondre. Son comportement est différent : requêtes à faible latence, focus sur le contenu textuel, pas de crawl systématique de la structure.
La distinction est critique pour votre robots.txt :
# robots.txt — stratégie différenciée pour les bots OpenAI
# Bloquer le crawl d'entraînement (pas de contribution aux datasets)
User-agent: GPTBot
Disallow: /
# Autoriser le crawl conversationnel (visibilité dans ChatGPT Browse)
User-agent: ChatGPT-User
Allow: /
Disallow: /admin/
Disallow: /api/
Disallow: /checkout/
Crawl-delay: 2
# Googlebot — aucune restriction sur le contenu public
User-agent: Googlebot
Allow: /Cette configuration permet de refuser que votre contenu serve à entraîner les modèles tout en restant visible quand un utilisateur ChatGPT cherche une information que votre site peut fournir. C'est un trade-off stratégique : bloquer ChatGPT-User signifie disparaître des réponses ChatGPT Browse, ce qui représente un canal de trafic croissant.
Le piège : ChatGPT-User ne respecte pas systématiquement le Crawl-delay. La documentation officielle d'OpenAI sur GPTBot mentionne le respect du robots.txt mais reste floue sur le rate limiting côté serveur. Comptez sur votre infrastructure, pas sur la bonne volonté du bot.
Impact serveur : un scénario concret sur un e-commerce à 18 000 pages
Prenons un cas réaliste. Un e-commerce mode avec 18 000 URLs indexables : 12 000 fiches produit, 3 500 pages catégories/sous-catégories avec navigation à facettes, 2 000 pages de contenu éditorial, 500 pages diverses (CGV, FAQ, landing pages).
Avant la vague IA (mi-2024)
Le site recevait environ 40 000 requêtes de crawl par jour, dont 85% de Googlebot (toutes variantes), 8% de Bingbot, et le reste réparti entre crawlers divers (Yandex, SEMrush, Ahrefs, etc.). La charge crawl représentait environ 3% du trafic HTTP total — négligeable.
Après la montée en puissance des bots IA (début 2026)
Le même site reçoit désormais 150 000+ requêtes de crawl par jour. La répartition a basculé :
- ChatGPT-User : ~65 000 requêtes/jour (43%)
- GPTBot : ~18 000 requêtes/jour (12%)
- Googlebot : ~35 000 requêtes/jour (23%)
- ClaudeBot (Anthropic) : ~12 000 requêtes/jour (8%)
- Bytespider (ByteDance) : ~10 000 requêtes/jour (7%)
- Autres : ~10 000 requêtes/jour (7%)
La charge crawl est passée de 3% à 12% du trafic HTTP total. Sur un site avec SSR (Next.js sur Vercel), chaque requête de crawl déclenche un rendu serveur complet. Le coût en compute a augmenté de 35% — sans qu'un seul utilisateur humain supplémentaire n'ait visité le site.
Le vrai problème : la concurrence sur les ressources serveur
Les bots IA ne crawlent pas "poliment" comme Googlebot. Googlebot espace ses requêtes, détecte la surcharge serveur, et réduit son rythme. ChatGPT-User, déclenché par des conversations utilisateurs concurrentes, peut envoyer des rafales de requêtes simultanées sans throttling coordonné.
Sur un site en SSR, cela signifie que le pool de workers Node.js (ou les fonctions serverless) est partagé entre les vrais utilisateurs et les bots IA. Pendant un pic de crawl IA, le Time to First Byte (TTFB) des utilisateurs humains peut se dégrader — ce qui impacte directement les Core Web Vitals et, par extension, le ranking Google.
C'est le paradoxe : les bots IA dégradent vos performances pour les vrais utilisateurs, ce qui peut faire baisser votre ranking Google, ce qui réduit votre visibilité organique. Si vous exploitez des applications en Single Page Architecture avec SSR, la pression sur le serveur est d'autant plus forte.
Rate limiting et gestion de la charge : configurations concrètes
La solution passe par du rate limiting différencié au niveau du reverse proxy ou du CDN. L'objectif : protéger les ressources serveur sans bloquer complètement les bots IA (pour préserver la visibilité dans ChatGPT Browse).
Nginx : rate limiting par user-agent
# /etc/nginx/conf.d/ai-bot-ratelimit.conf
# Définition d'une zone de rate limiting pour les bots IA
# Clé basée sur l'adresse IP du bot
# 10m de mémoire partagée ≈ ~160 000 adresses IP
map $http_user_agent $is_ai_bot {
default 0;
"~*ChatGPT-User" 1;
"~*GPTBot" 1;
"~*ClaudeBot" 1;
"~*Claude-Web" 1;
"~*Bytespider" 1;
"~*PerplexityBot" 1;
"~*Applebot-Extended" 1;
}
# Zone de rate limiting dédiée aux bots IA
limit_req_zone $binary_remote_addr zone=ai_bots:10m rate=5r/s;
# Zone séparée pour Googlebot (traitement premium)
limit_req_zone $binary_remote_addr zone=googlebot:10m rate=30r/s;
server {
listen 443 ssl http2;
server_name shop.example.fr;
# Appliquer le rate limiting conditionnel
location / {
# Bots IA : max 5 req/s avec burst de 10
if ($is_ai_bot) {
set $limit_ai "1";
}
limit_req zone=ai_bots burst=10 nodelay;
# Servir un cache statique aux bots IA quand possible
# Évite de déclencher un rendu SSR pour chaque requête bot
proxy_cache_bypass $is_ai_bot;
proxy_cache ai_response_cache;
proxy_cache_valid 200 15m;
proxy_cache_use_stale error timeout http_500 http_502 http_503;
proxy_pass http://nextjs_upstream;
}
}Le rate limiting à 5 requêtes/seconde par IP est un bon point de départ pour les bots IA. C'est suffisant pour qu'ils récupèrent le contenu demandé par l'utilisateur ChatGPT, mais ça bloque les rafales qui surchargent le serveur.
Le point clé ici est le proxy_cache : en servant des réponses cachées aux bots IA au lieu de déclencher un rendu SSR à chaque requête, vous divisez le coût compute par un facteur significatif. Un cache de 15 minutes est un bon compromis pour du contenu produit ou éditorial qui ne change pas à la minute. Pour aller plus loin sur cette stratégie, consultez notre article sur le server-side caching et SEO avec Varnish, Redis et CDN.
Cloudflare : règles WAF pour throttler les bots IA
Si votre site est derrière Cloudflare (ce qui est le cas de la majorité des sites à fort trafic), vous pouvez utiliser les règles WAF pour une gestion plus fine. Attention toutefois aux configurations CDN qui peuvent casser le SEO si elles sont mal calibrées.
Dans le dashboard Cloudflare, section Security > WAF > Rate Limiting Rules :
- Rule name :
AI Bot Throttle - Expression :
(http.user_agent contains "ChatGPT-User") or (http.user_agent contains "GPTBot") or (http.user_agent contains "ClaudeBot") or (http.user_agent contains "Bytespider") - Rate : 20 requests per 10 seconds
- Action : Block (avec page challenge comme alternative)
- Duration : 60 seconds
Cette approche est complémentaire au robots.txt — le robots.txt indique ce qui est autorisé, le rate limiting impose comment.
Que signifie ce shift pour le SEO technique en 2026 ?
Le dépassement de Googlebot par les crawlers IA n'est pas un événement ponctuel. C'est une tendance structurelle qui s'accélère, comme l'analyse notre article sur le SEO en 2026. Les implications techniques sont profondes.
Le crawl budget n'est plus un concept mono-moteur
Historiquement, "crawl budget" signifiait "combien de pages Googlebot peut et veut crawler sur votre site". Ce concept doit maintenant s'étendre à l'ensemble des crawlers automatisés. Si les bots IA consomment 60% de votre capacité de crawl serveur, ils réduisent mécaniquement la capacité disponible pour Googlebot — à moins d'une segmentation active.
La métrique à suivre n'est plus seulement "pages crawlées par Googlebot dans la Search Console", mais "requêtes de crawl totales par type de bot" dans vos logs serveur. Si vous ne faites pas de log analysis, vous pilotez à l'aveugle.
Le JavaScript et le rendu deviennent encore plus critiques
ChatGPT-User ne rend pas le JavaScript. Il récupère le HTML brut retourné par le serveur. Si votre contenu dépend d'un rendu côté client (CSR pur, React SPA sans SSR), il est tout simplement invisible pour ChatGPT Browse. Google au moins dispose d'un service de rendu (le Web Rendering Service) qui exécute le JS. Les bots IA ne font pas cette étape.
Cela renforce massivement l'argument en faveur du SSR ou du SSG pour tout contenu que vous voulez rendre accessible aux systèmes IA. Les sites en React sans SSR ou en SPA pure cumulent désormais un double handicap : mauvais crawl Google ET invisibilité totale dans les réponses ChatGPT.
Pour vérifier ce que ChatGPT-User voit réellement de votre site, simulez sa requête :
# Simuler une requête ChatGPT-User et analyser le HTML retourné
curl -s -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot" \
-H "Accept: text/html" \
"https://shop.example.fr/chaussures/running-homme" | \
python3 -c "
import sys
from html.parser import HTMLParser
class ContentExtractor(HTMLParser):
def __init__(self):
super().__init__()
self.in_body = False
self.text_content = []
self.meta_tags = []
self.title = ''
self.in_title = False
def handle_starttag(self, tag, attrs):
attrs_dict = dict(attrs)
if tag == 'meta' and 'name' in attrs_dict:
self.meta_tags.append(attrs_dict)
if tag == 'title':
self.in_title = True
if tag == 'body':
self.in_body = True
def handle_endtag(self, tag):
if tag == 'title':
self.in_title = False
if tag == 'body':
self.in_body = False
def handle_data(self, data):
if self.in_title:
self.title = data.strip()
if self.in_body and data.strip():
self.text_content.append(data.strip())
parser = ContentExtractor()
html = sys.stdin.read()
parser.feed(html)
print(f'Title: {parser.title}')
print(f'Meta tags: {len(parser.meta_tags)}')
print(f'Text blocks in body: {len(parser.text_content)}')
print(f'Total text chars: {sum(len(t) for t in parser.text_content)}')
if len(parser.text_content) < 5:
print('WARNING: Très peu de contenu textuel — probablement du CSR non rendu')
"Si le script retourne "WARNING: Très peu de contenu textuel", votre page est invisible pour ChatGPT-User — et probablement pour tous les bots IA. C'est l'équivalent d'un problème de divergence SSR/CSR, mais avec des conséquences qui s'étendent au-delà de Google.
L'émergence du "AI crawl" comme canal de trafic
Les sites qui apparaissent dans les réponses de ChatGPT Browse reçoivent du trafic via les clics sur les sources citées. Ce trafic apparaît dans vos analytics avec un referrer contenant chatgpt.com ou chat.openai.com. Sur certains sites éditoriaux, ce canal représente déjà 5 à 8% du trafic total — tendance en hausse rapide.
Bloquer ChatGPT-User revient à se couper de ce canal. Mais l'autoriser sans rate limiting revient à subventionner OpenAI en compute serveur sans contrepartie garantie. L'enjeu est de trouver l'équilibre, et il est propre à chaque site.
Pour les marques, un enjeu supplémentaire émerge : Bing, pas Google, influence les recommandations de ChatGPT. Votre stratégie Bing/Microsoft, longtemps négligée, devient soudainement pertinente.
Monitoring : ce qu'il faut surveiller en continu
L'analyse ponctuelle des logs ne suffit plus. Le comportement des bots IA évolue rapidement — de nouveaux user-agents apparaissent, les patterns de crawl changent, les volumes fluctuent avec l'adoption des fonctionnalités Browse/Search.
Les métriques essentielles à tracker
Volume de crawl par bot par jour : un dashboard qui montre les requêtes de Googlebot, ChatGPT-User, GPTBot, ClaudeBot, Bytespider en séries temporelles. Un spike soudain de ChatGPT-User peut indiquer que votre site est devenu une source fréquemment citée (positif) ou qu'un bot mal configuré vous martèle (problème).
Ratio crawl IA / crawl Google : si ce ratio dépasse 5:1 et que votre TTFB augmente, il est temps de renforcer le rate limiting ou d'ajouter une couche de cache.
TTFB segmenté : mesurer le TTFB séparément pour les utilisateurs humains, Googlebot, et les bots IA. Si le TTFB utilisateur dépasse 800ms pendant les pics de crawl IA, vous avez un problème de contention de ressources.
Pages crawlées par les bots IA vs pages indexées par Google : si les bots IA crawlent massivement des pages que Google n'indexe pas (pages filtrées, paginations, variantes produit), c'est du gaspillage de ressources serveur.
Un outil de monitoring SEO continu comme Seogard permet de détecter ces déséquilibres automatiquement et d'alerter quand les seuils critiques sont franchis — avant que le TTFB ne dérape et que les régressions SEO ne s'installent.
L'angle robots.txt et standards émergents
La gestion des bots IA via robots.txt est fragile. Chaque provider IA utilise son propre user-agent, et la liste s'allonge chaque trimestre. Les standards émergents comme MCP, A2A et agents.md tentent de structurer cette interaction, mais aucun ne fait consensus à ce stade.
En attendant, la seule approche fiable reste : logs serveur + rate limiting + cache + monitoring continu.
Ce que ça change pour la stratégie de contenu
Si ChatGPT-User crawle massivement votre site, la question n'est plus seulement "est-ce que Google indexe cette page ?" mais aussi "est-ce que cette page est exploitable par un LLM pour générer une réponse utile ?".
Cela signifie concrètement :
Un contenu structuré et auto-suffisant : les LLM extraient mieux l'information d'une page qui répond clairement à une question, avec des données structurées, des paragraphes courts, et des headings explicites. Notre article sur comment concevoir du contenu que les systèmes IA préfèrent approfondit cet aspect.
Des balises meta irréprochables : ChatGPT-User utilise le <title> et la meta description comme signaux de pertinence pour décider si la page répond à la requête de l'utilisateur. Une page avec un title générique ou une meta description absente a moins de chances d'être sélectionnée comme source.
Un HTML sémantique propre : les bots IA parsent le HTML sans exécuter le JS. Un <article> bien structuré avec des <h2>, <h3>, <p> et des <table> pour les données tabulaires sera mieux exploité qu'une soupe de <div> stylisés en CSS.
Le renversement du rapport de force entre Googlebot et les crawlers IA n'est pas une curiosité statistique — c'est un changement d'infrastructure. Les sites qui traitent les bots IA comme un problème de sécurité à bloquer perdent un canal de distribution. Ceux qui les accueillent sans contrôle paient la facture en performance serveur et en dégradation UX. L'approche qui fonctionne est celle du milieu : autoriser, throttler, cacher, monitorer. Un outil comme Seogard, couplé à une analyse de logs rigoureuse, permet de garder le contrôle sur cette nouvelle réalité du crawl web.