Vitesse, TTFB et budget d'exploration des robots IA.

Un robot de recherche IA a moins de patience que Googlebot, et moins de raisons d'attendre

Deux situations très différentes se cachent derrière l'expression « passage d'un robot IA ». Dans la première, un robot d'index comme OAI-SearchBot, Claude-SearchBot ou PerplexityBot parcourt votre site à son rythme, pour alimenter un index consulté plus tard. Dans la seconde, un agent à la demande comme ChatGPT-User, Claude-User ou Perplexity-User lit votre page pendant qu'un utilisateur attend, et la réponse doit être assemblée en quelques secondes. Dans les deux cas, la lenteur coûte, mais elle ne coûte pas la même chose.

Pour le robot d'index, une réponse lente réduit le nombre de pages lues par visite : c'est la logique du budget d'exploration, que Google documente pour Googlebot et qui s'applique, par construction, à tout robot qui doit répartir une capacité limitée entre des millions de sites. Pour l'agent à la demande, une réponse lente peut exclure la page de la réponse en cours, parce que le moteur ne dispose que d'une fenêtre courte pour réunir ses sources. La page n'est pas pénalisée ; elle est simplement absente.

Aucun éditeur de moteur génératif ne publie de délai maximal, ni de nombre de pages par visite. Le seul repère documenté vient de Google, dont la documentation sur le budget d'exploration indique que la capacité accordée à un site augmente lorsqu'il répond vite et de manière stable, et diminue lorsqu'il ralentit ou renvoie des erreurs serveur. Faute de chiffres pour les autres, la règle raisonnable est de traiter chaque robot de recherche IA comme un visiteur pressé, et de mesurer ce qu'il subit réellement plutôt que ce qu'un outil de performance affiche pour un navigateur. C'est la première des quatre conditions d'une citation, l'accessibilité, prise sous l'angle du temps.

Ce que le TTFB mesure, et ce qui le fait grimper

Le temps jusqu'au premier octet (TTFB) est le délai entre l'envoi d'une requête et la réception du premier octet de la réponse. C'est la mesure qui compte pour un robot, parce qu'il ne charge ni les images, ni les polices, ni les scripts qui font la note d'un outil de performance : il attend le HTML, et le TTFB dit combien de temps il attend avant que quoi que ce soit n'arrive. Un TTFB élevé se décompose toujours en quatre parts, et c'est en les séparant que l'on trouve la cause.

La mesure se fait en ligne de commande, en se présentant sous l'identité d'un robot. Ce détail n'est pas anecdotique : un CDN ou un pare-feu peut appliquer aux agents IA un traitement différent de celui des navigateurs, et c'est précisément ce traitement qu'il faut mesurer.

# Décomposition du délai, en se présentant comme OAI-SearchBot
curl -o /dev/null -s -A "OAI-SearchBot" \
  -w "DNS %{time_namelookup}s | TCP %{time_connect}s | TLS %{time_appconnect}s | premier octet %{time_starttransfer}s | total %{time_total}s | code %{http_code}\n" \
  https://www.exemple.fr/guides/robots-ia

# Même mesure sans identité de robot, pour comparer
curl -o /dev/null -s -w "premier octet %{time_starttransfer}s | code %{http_code}\n" https://www.exemple.fr/guides/robots-ia

Répétez la mesure à plusieurs heures de la journée et sur vos dix pages les plus importantes. Un écart net entre la mesure « robot » et la mesure « navigateur », ou entre les heures creuses et les heures pleines, désigne respectivement une règle d'accès et un problème de capacité, deux chantiers distincts.

Délais tolérés : ce qui est documenté, et ce qui ne l'est pas

Sur les délais, la documentation publique se limite à Google. Elle établit que la vitesse de réponse module la capacité d'exploration, que les codes 429 et 503 sont interprétés comme une demande de ralentir, qu'une indisponibilité prolongée conduit au retrait des URL de l'index, et que Googlebot suit au plus dix redirections successives avant d'abandonner. OpenAI, Anthropic et Perplexity ne publient rien d'équivalent pour leurs agents. Il faut donc raisonner à partir du fonctionnement d'une réponse générative, décrit ci-dessous, plutôt qu'à partir de seuils.

Cette mécanique explique pourquoi un site peut être correctement indexé et rarement cité en conversation : l'index a été alimenté par un robot patient, mais la page ne revient pas à temps lorsqu'un agent la demande en direct. Elle explique aussi pourquoi les pages statiques ou servies depuis un cache sont surreprésentées dans les réponses par rapport aux pages générées à la volée. À notre connaissance, aucun éditeur n'a confirmé ni infirmé ce mécanisme dans le détail ; il découle de la contrainte de temps d'une réponse conversationnelle, et il se vérifie dans les journaux.

Les pages abandonnées : les reconnaître dans les journaux

Une page abandonnée par un robot pressé laisse des traces, à condition de savoir les lire. Sur Nginx, le code 499 indique que le client a fermé la connexion avant que le serveur ne réponde : c'est le signe le plus direct. Sur Apache, on observe des réponses de taille nulle ou incomplète. Dans les deux cas, les codes 429, 503 et 5xx en général racontent la même histoire depuis l'autre côté : le serveur n'a pas pu servir. Le tableau ci-dessous résume l'effet de chaque code sur l'exploration.

Tableau : faites défiler horizontalement.

La méthode consiste à filtrer les journaux sur les agents IA, puis à compter les codes autres que 200 et 304, page par page. Les commandes sont détaillées dans l'article sur la détection des robots IA dans les journaux serveur. Si les codes 429 dominent, la cause est une limitation de débit appliquée aux robots par le CDN ou le pare-feu, traitée dans l'article sur les blocages involontaires ; si ce sont les 499 et les 503, la cause est chez vous, dans la capacité ou dans le temps de génération.

Priorisation des URL : où dépenser un budget d'exploration réduit

Les robots d'index de recherche IA lisent beaucoup moins de pages que Googlebot, et vous ne choisissez pas lesquelles. Vous pouvez en revanche influencer fortement la liste, parce que ces robots découvrent les URL par les mêmes moyens que les autres : liens internes, liens externes et sitemaps. La documentation de Google décrit trois facteurs de demande d'exploration, la popularité d'une URL, son ancienneté dans l'index et l'inventaire perçu du site ; rien n'indique que les autres éditeurs raisonnent autrement, et nos observations vont dans le même sens.

Le premier levier est l'inventaire lui-même. Un site qui expose des dizaines de milliers d'URL à paramètres, de facettes de filtrage, de pages de pagination profonde ou d'anciennes adresses redirigées dilue un budget déjà faible. Chaque requête consommée sur une URL sans valeur est une requête qui n'est pas consacrée à une page citable. Le second levier est la profondeur : une page atteignable en deux clics depuis l'accueil est lue avant une page enfouie à six niveaux. Le troisième est le sitemap, qui ne doit contenir que des URL canoniques, en code 200, avec une date de modification exacte ; l'article sur les sitemaps et les signaux de fraîcheur en détaille la construction.

Le nettoyage ne demande pas de bloquer les robots IA sur les URL inutiles, ce qui serait risqué ; il consiste à ne plus les leur présenter. Les facettes s'excluent par une règle Disallow ciblée sur les paramètres, les liens internes pointent directement vers les URL finales, et les pages supprimées renvoient un code 410 plutôt qu'une redirection vers l'accueil.

Redirections : chaque saut coûte une requête, et parfois la page

La chaîne de redirection la plus fréquente sur les sites que nous auditons compte trois sauts : de http vers https, puis vers le sous-domaine www, puis vers l'URL avec ou sans barre oblique finale. Chacun est un aller-retour complet, avec sa résolution, sa connexion et son délai serveur ; le TTFB de la page finale s'ajoute au bout. Pour un robot d'index, c'est trois fois plus de requêtes pour une seule page. Pour un agent à la demande, c'est une fenêtre de délai consommée avant même que la page utile ne soit demandée.

# Suivre la chaîne de redirection d'une URL telle qu'elle circule
curl -sIL http://exemple.fr/guides/robots-ia | grep -iE '^(HTTP|location)'

# Résultat typique avant correction : trois sauts
HTTP/1.1 301 Moved Permanently
location: https://exemple.fr/guides/robots-ia
HTTP/2 301
location: https://www.exemple.fr/guides/robots-ia
HTTP/2 301
location: https://www.exemple.fr/guides/robots-ia/
HTTP/2 200

La correction tient en trois règles. Toute URL non canonique redirige en un seul saut vers l'URL finale, quel que soit le point d'entrée. Les liens internes, les sitemaps, les balises canoniques et les annotations de langue pointent tous vers cette URL finale, jamais vers une adresse intermédiaire. Et les URL héritées d'anciennes migrations sont vérifiées une par une, parce qu'une chaîne accumulée au fil de trois refontes peut dépasser la limite de dix sauts documentée par Google, ce qui rend la page inaccessible à tous les robots qui appliquent une limite comparable.

Mettre le cache au service des robots

La manière la plus sûre de répondre vite à un robot est de ne pas générer la page au moment où il la demande. Trois mécanismes y contribuent, et ils se cumulent. Le premier est le cache du HTML en périphérie : servir les pages publiques depuis le CDN, avec une durée de validité distincte pour les navigateurs et pour les caches intermédiaires, et une directive qui autorise à servir une version légèrement périmée pendant qu'elle se régénère. Le deuxième est la réponse conditionnelle : des en-têtes ETag et Last-Modified sincères permettent au robot qui a déjà lu la page de recevoir un code 304 et de passer à la suivante. Le troisième est la priorité à l'origine, c'est-à-dire l'absence de limitation de débit et de défi JavaScript sur les agents authentifiés.

# En-têtes de réponse pour une page publique servie via un CDN
Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=86400
ETag: "a3f9-20260512"
Last-Modified: Tue, 12 May 2026 08:30:00 GMT
Vary: Accept-Encoding

Une précaution : le cache en périphérie ne doit pas masquer un contenu différent selon l'agent. Si le CDN sert aux robots une version allégée, ou une page de défi mise en cache par erreur, le gain de vitesse se paie d'une page vide. Vérifiez, avec la commande curl vue plus haut, que la réponse servie sous une identité de robot contient bien le HTML complet, puis mesurez à nouveau : c'est le seul contrôle qui compte.

Ce qu'il faut retenir