Deux personnes nous ont posé la même question lors de notre événement en direct consacré à l’analyse de la réalité du trafic généré par les robots, et nous n’avons pas eu l’occasion d’y répondre en direct : un fichier llms.txt empêche-t-il réellement l’IA de saturer votre site ?

Nous avons longuement réfléchi à cette question, car la réponse honnête ne se résume pas à un simple « oui » ou « non ». En réalité, le fichier llms.txt n’a jamais été conçu pour remplir aucune des deux fonctions que les gens espéraient lui voir assurer, et une grande partie de ce qui a été publié à ce sujet cette année a discrètement conduit les gens à croire le contraire.

Cette confusion n’est pas un cas isolé. Dans l’ensemble des questions qui nous ont été posées, les fichiers robots.txt et llms.txt, les « robots d’exploration IA » et la protection contre les robots ont sans cesse été évoqués comme s’il s’agissait de quatre réglages d’un même cadran, où le fait d’en modifier un quelconque aboutirait au même résultat. Ce n’est pas le cas. Ils se situent à des points totalement différents du chemin de requête, ils sont appliqués par des mécanismes totalement différents (ou, dans un cas, ne sont pas appliqués du tout), et c’est précisément en les confondant qu’un propriétaire de site finit par tout faire « correctement » tout en subissant des conséquences désastreuses.

Et ce n’est pas seulement une théorie. Dans notre rapport sur le trafic généré par l’IA et les robots, nous avons constaté que le trafic de bots IA sur les sites hébergés par Kinsta est passé de 1 visite sur 200 il y a un an à 1 visite sur 31 aujourd’hui. Une pancarte sur la porte ne sert pas à grand-chose lorsque tant de personnes tentent de tourner la poignée.

TL;DR

  • Le fichier robots.txt est une demande, pas un verrou. Les robots d’exploration IA réputés d’OpenAI, d’Anthropic, de Google et de Perplexity le lisent et le respectent généralement. Certains, dont historiquement le Bytespider de ByteDance, ne l’ont pas fait.
  • Le fichier llms.txt ne contrôle pas l’accès. Il s’agit d’un index de contenu destiné aux outils d’IA qui choisissent de le lire, et non d’un fichier d’autorisations. Son adoption se situe autour de 9 à 10 % des sites, et les principaux robots d’indexation basés sur l’IA ne le récupèrent de toute façon pas pour la plupart.
  • La protection contre les robots est la seule couche qui impose des restrictions. Les fichiers robots.txt et llms.txt fonctionnent en formulant une demande polie. Ce sont la protection contre les robots de Kinsta et l’AI Crawl Control de Cloudflare qui bloquent, remettent en question ou limitent le débit d’un robot d’indexation qui ignore vos préférences.

Quatre couches, quatre fonctions, un seul point de confusion

Couche Ce qu’elle fait réellement Peut-elle empêcher un acteur malveillant d’agir ?
robots.txt Indique vos préférences à tout robot d’indexation qui prend la peine de le lire Non
llms.txt Fournit aux outils d’IA un index propre de votre contenu Non
Robots d’indexation IA Les robots à l’origine des requêtes N/A (il s’agit des éléments que vous gérez, et non d’un contrôle)
Protection contre les robots (Kinsta / Cloudflare) Détecte, classe et traite les requêtes au niveau de l’infrastructure Oui

Une fois que vous voyez les choses présentées ainsi, la plupart des questions posées par les participants trouvent leur réponse d’elles-mêmes. Passons donc en revue chaque couche, en commençant par celle que tout le monde comprend déjà à peu près.

robots.txt

Le fichier robots.txt, formalisé par la norme RFC 9309, indique aux robots d’indexation quelles parties de votre site vous préférez qu’ils ignorent. Il ne s’accompagne d’aucune contrainte technique ; son fonctionnement repose donc uniquement sur le fait que les robots d’indexation qui le lisent ont décidé, par principe, de s’y conformer.

Ce qui est rassurant, c’est que les robots d’indexation qui vous intéressent le plus, comme OpenAI, Anthropic, Google et Perplexity, publient tous des user-agents documentés et respectent les directives standard.

Ce qui induit souvent en erreur, c’est de supposer que chaque entreprise exploite un seul « bot IA ». Ce n’est pas le cas. La plupart d’entre elles séparent désormais l’entraînement de la recherche, et cette distinction constitue le levier le plus utile de tout cet article :

  • GPTBot (OpenAI) : entraîne les modèles de base. Interdisez-le et votre contenu ne servira plus à alimenter les futurs cycles d’entraînement.
  • OAI-SearchBot (OpenAI) : indexe les pages en vue de leur citation dans la recherche ChatGPT. Si vous l’interdisez, vous perdrez ces citations, mais l’entraînement n’en sera pas affecté.
  • ClaudeBot (Anthropic) : apprentissage.
  • Claude-SearchBot (Anthropic) : indexation de recherche pour Claude.
  • Google-Extended : régit l’utilisation dans le cadre de l’entraînement de l’IA et des aperçus IA en particulier. Son blocage n’ affecte pas l’indexation habituelle par Googlebot ni vos classements de recherche normaux.
  • PerplexityBot : le robot d’exploration du moteur de réponses de Perplexity.

La véritable décision n’a donc jamais été de « laisser entrer l’IA ou de la tenir à l’écart ». Il s’agit de savoir si vous souhaitez que votre contenu serve à l’entraînement d’un modèle, soit cité dans une réponse générée par l’IA, les deux, ou aucun des deux. Le fichier robots.txt vous permet déjà de répondre à cette question avec précision. La plupart des propriétaires de sites ne se sont tout simplement pas posé la question en ces termes.

Voici à quoi ressemble concrètement cette précision dans un fichier robots.txt. Imaginons que vous souhaitiez vous soustraire totalement à l’entraînement, tout en continuant à apparaître lorsque quelqu’un pose à ChatGPT ou à Claude une question à laquelle votre contenu pourrait répondre :

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

Si vous préférez exclure une section spécifique de tout, qu’il s’agisse de l’entraînement ou de la recherche, vous limitez la règle « disallow » à un chemin d’accès plutôt qu’à l’ensemble du site :

User-agent: GPTBot
Disallow: /premium-reports/

User-agent: ClaudeBot
Disallow: /premium-reports/

Le hic, c’est que le respect de ces règles relève de la courtoisie, et non d’une obligation. Quelques robots d’exploration ont déjà prouvé par le passé qu’ils ignoraient purement et simplement les règles « disallow ». Il existe également une nouvelle complication : lorsqu’un utilisateur demande à ChatGPT ou à un assistant similaire de lire une page spécifique en son nom à un moment donné, cette requête ponctuelle ne se comporte pas toujours comme un exploration, et la logique du fichier robots.txt ne s’y applique pas de manière claire.

llms.txt

De nombreux contenus publiés en 2026 ont décrit le fichier llms.txt comme un outil de contrôle d’accès ou une astuce de référencement. La réponse honnête est plus simple et moins utile que ce que la plupart des articles ont laissé entendre.

llms.txt est un simple fichier Markdown situé dans votre répertoire racine qui fonctionne comme une table des matières pour les outils d’IA, en les orientant vers vos pages les plus importantes afin qu’un modèle n’ait pas à analyser une page entièrement affichée pour comprendre votre activité. C’est là toute la spécification. Elle ne dit rien sur ce qu’un robot d’indexation est autorisé ou non à faire.

Voici à quoi ressemble globalement ce fichier :

# Acme Analytics

> Acme Analytics is a WordPress plugin for tracking site performance and uptime.

## Docs
- [Getting Started](https://example.com/docs/getting-started): Install and configure the plugin
- [API Reference](https://example.com/docs/api): Full REST API documentation

## Pricing
- [Plans](https://example.com/pricing): Current plans and feature comparison

Remarquez qu’il n’y a ni Allow, ni Disallow, ni ciblage par user-agent, rien qui indique à un robot d’indexation ce qu’il peut ou ne peut pas faire.

Voici ce que révèlent les données actuelles :

  • Son adoption reste très limitée. Environ 9 à 10 % des sites en disposent, même parmi les plus grands domaines du Web, alors que cela fait bien plus d’un an que l’on se recommande mutuellement de l’ajouter.
  • La plupart des robots qui comptent ne le consultent pas. L’analyse du trafic sur des centaines de millions de requêtes d’IA montre que GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot et Google-Extended ignorent massivement ce fichier et passent directement à l’exploration du code HTML.
  • Google a officiellement déclaré que non. Les responsables de la recherche chez Google ont affirmé sans ambages que le fichier llms.txt n’était pas utilisé comme signal de classement ou d’exploration, et l’ont comparé, de manière défavorable, à la balise méta « keywords », tombée en désuétude depuis longtemps.
  • Aucun grand laboratoire d’IA ne s’est engagé à le traiter comme un signal d’accès, que ce soit pour l’entraînement ou pour la recherche.

Son utilité réside plutôt dans son rôle de carte pour les agents de codage et les outils de développement, tels que Claude Code ou Cursor, qui tirent parti d’un index propre et structuré d’un site de documentation.

Ainsi, le fichier llms.txt n’empêchera pas votre site d’être exploré à plusieurs reprises. Il s’agit d’une aide à la découverte, et non d’un limiteur de fréquence ni d’une barrière.

Les robots d’IA

Le terme « robot d’IA » est utilisé comme un fourre-tout pour désigner au moins trois comportements distincts, et c’est en les confondant que naissent de nombreuses mauvaises décisions :

  1. Les robots d’apprentissage qui collectent périodiquement du contenu pour l’ensemble d’entraînement d’un modèle : GPTBot, ClaudeBot, Google-Extended, Bytespider, CCBot.
  2. Les robots de recherche et de réponse qui construisent l’index à partir duquel un moteur de réponse IA puise effectivement ses informations : OAI-SearchBot, Claude-SearchBot, PerplexityBot.
  3. Les requêtes d’agents en temps réel, où une personne demande à un assistant d’aller consulter une page spécifique immédiatement, ce qu’il fait sur-le-champ.

Les deux premiers se comportent comme des robots d’indexation classiques et s’identifient généralement à l’aide d’un user-agent documenté, ce qui est précisément ce qui rend possible, en premier lieu, le contrôle basé sur le fichier robots.txt. Le troisième ressemble beaucoup plus à une personne cliquant sur un lien qu’à un robot d’exploration, ce qui explique en partie pourquoi certains outils de navigation basés sur l’IA apparaissent désormais dans les journaux de serveur de manière impossible à distinguer des visiteurs ordinaires, et pourquoi les systèmes de blocage des robots trop rigides interceptent parfois des activités légitimes menées par des humains dans le même filet.

C’est également ce qu’a souligné Daniel Pataki lors du webinaire : la majeure partie du trafic généré par les robots d’exploration basés sur l’IA n’est aujourd’hui pas malveillante, elle est simplement incessante. Il suit tous les liens qu’il trouve, y compris toutes les variantes d’URL redondantes qu’une page WordPress ou WooCommerce dynamique peut générer, et finit par effectuer une boucle qui ressemble à une attaque, mais qui n’est en réalité qu’un robot qui ignore qu’il a déjà consulté cette page neuf mille fois.

Nous approfondissons les raisons précises pour lesquelles cela met particulièrement à mal l’infrastructure WooCommerce dans la section intitulée « Pourquoi les sites WooCommerce sont-ils particulièrement vulnérables au trafic de robots ? ».

La couche qui fait vraiment la différence : la protection contre les robots

Une fois que vous avez accepté que le fichier robots.txt est facultatif et que le fichier llms.txt ne constitue en rien un moyen de contrôle, il ne reste plus qu’une seule couche capable d’agir sur un robot d’indexation qui refuse de coopérer : la protection contre les robots, qu’il s’agisse de la protection Kinsta Bot Protection, des outils de Cloudflare ou d’une toute autre solution.

Du côté de Cloudflare, les choses ont évolué rapidement, mais chez Kinsta, nous adoptons une approche plus ciblée, spécifique à WordPress pour aborder ce même problème : un bouton dédié « Bloquer les robots d’indexation IA » qui bloque les robots d’indexation IA, y compris ceux qui sont vérifiés, sans affecter Googlebot ni Bing, ainsi qu’une classification des robots d’indexation IA à débit excessif qui détecte un robot techniquement vérifié mais qui sollicite votre site bien plus intensément qu’une exploration normale ne le ferait jamais.

Outil de protection contre les bots Kinsta
L’outil de protection contre les robots de Kinsta

Laszlo Farkas, notre directeur de l’ingénierie, a présenté ainsi le compromis sous-jacent lorsque nous lui avons demandé de comparer un outil géré à la création de vos propres règles à partir de zéro :

Si vous disposez de l’expertise et du temps nécessaires pour affiner vous-même ces réglages, c’est probablement le meilleur choix pour vous. Si ce n’est pas le cas, je pense qu’il vaut mieux utiliser l’outil de Kinsta, car il est géré, optimisé pour WordPress et entretenu à votre place.

Pour une comparaison plus complète des avantages respectifs de l’outil de Kinsta et de celui de Cloudflare, consultez notre guide comparatif « Protection robots de Kinsta  vs Cloudflare ».

Les questions qui nous ont été posées, avec des réponses directes

« Nous souhaitons accepter les robots d’indexation LLM tout en évitant les abus. Existe-t-il un moyen fiable d’y parvenir ? » Oui, il s’agit de la distinction entre « apprentissage » et « recherche », appliquée de manière délibérée. Autorisez les robots d’indexation chargés de la recherche et des réponses si vous souhaitez que votre site soit repérable et cité. Utilisez le fichier robots.txt pour exclure spécifiquement les robots d’entraînement, si c’est cette partie qui vous pose problème. Laissez ensuite la protection anti-robots détecter les abus liés au volume, qu’ils soient vérifiés ou non, provenant de tout ce qui effectue un crawling plus intensif qu’il ne le devrait.

« Nous ne souhaitons pas bloquer le trafic, car nous voulons que l’IA mette notre entreprise en avant. Que devons-nous faire concrètement ? » Même réponse, formulation différente. Être visible dans les réponses générées par l’IA et contrôler la pression sur les ressources ne sont pas incompatibles, car des robots distincts se chargent de chaque tâche. Contrez ou bloquez les robots d’entraînement et ceux à fort volume si tel est votre souci, et laissez explicitement l’accès ouvert aux robots de recherche et de réponse.

« Les murs de paiement empêchent-elles les robots d’IA d’extraire ce contenu ? » En partie, et uniquement à l’encontre des robots d’indexation qui se comportent comme tels. Une page de connexion bloque un robot qui respecte la structure normale de la page et ne dispose pas d’identifiants valides, tout comme elle bloque tout utilisateur humain anonyme. Cela n’a aucun effet contre les outils d’IA qui naviguent davantage comme un véritable utilisateur non connecté, ou qui accèdent au même contenu via une copie mise en cache, un flux RSS ou une autre « porte dérobée » qui ne touche absolument pas à la logique du mur de paiement. C’est une mesure utile et complémentaire, mais qui ne remplace pas la protection contre les robots.

« Peut-on empêcher les robots d’indexation basés sur l’IA de parcourir en boucle les filtres de notre boutique WooCommerce ? » Il s’agit d’un problème de mise en cache et de structure d’URL déguisé en problème de protection contre les robots. Les robots d’indexation suivent tous les liens qu’ils rencontrent, et les paramètres dynamiques de filtrage et de tri génèrent un nombre quasi infini d’URL distinctes pour ce qui est, pour un humain, la même page. Bloquer ces modèles de paramètres dans le fichier robots.txt est une première mesure judicieuse :

User-agent: *
Disallow: /*?*filter_
Disallow: /*?*orderby=

Lorsqu’un robot d’indexation l’ignore de toute façon, ce que certains feront, ce sont les règles basées sur le débit dans la protection contre les bots qui permettent réellement de briser la boucle.

Où cela vous mène-t-il ?

Cessez de considérer ces quatre éléments comme des options concurrentes et commencez à les traiter comme une pile, appliquée dans l’ordre :

  1. Le fichier robots.txt énonce votre intention, en distinguant les robots d’apprentissage des robots de recherche et de réponse en fonction de ce que vous attendez réellement de chacun.
  2. Le fichier llms.txt, si vous prenez la peine de le créer, est une marque de courtoisie envers les outils qui le lisent, et non un levier permettant de réduire ou de contrôler le volume d’exploration.
  3. Les « robots IA » englobent les robots d’entraînement, les robots de recherche et les requêtes des agents en direct, et chacun d’entre eux peut mériter une réponse différente.
  4. C’est au niveau de la protection contre les robots que s’exerce réellement le contrôle, car c’est la seule couche ici capable d’intervenir sur une requête qui ignore tout ce que vous avez demandé.

Si votre question porte moins sur « comment contrôler cela » que sur « comment être trouvé par ce système », nos guides consacrés à l’AEO pour WordPress et à la comparaison entre GEO, AEO et SEO prennent le relais là où celui-ci s’arrête. Pour découvrir les contrôles abordés ici, consultez la section Protection contre les robots de Kinsta.

Joel Olawanle Kinsta

Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.