Configurer robots.txt pour la recherche par IA consiste à ajouter des règles Allow et Disallow par agent qui distinguent les robots de « recherche/citation » (ceux qui alimentent les Google AI Overviews, ChatGPT et les réponses de Perplexity) des robots d'« entraînement de modèles », plutôt que de bloquer ou d'autoriser l'IA en bloc. Robots.txt est un fichier texte volontaire hébergé à la racine du domaine qui signale quels user-agents peuvent accéder à quels chemins. Il n'impose pas l'accès : les robots conformes sont simplement censés le respecter.
Cette distinction est la décision centrale pour la visibilité dans l'IA. Vous voulez que vos pages soient repérables et citables par les moteurs de réponse qui récupèrent, résument et renvoient vers vous, tout en maintenant interdite l'ingestion massive destinée à l'entraînement des modèles de fondation, sauf si vous y consentez délibérément. Concrètement, cela revient à écrire des règles par agent : autoriser les agents axés sur la récupération qui alimentent les citations, interdire les agents axés sur l'entraînement qui nourrissent les poids des modèles, au lieu d'utiliser une seule User-agent: * règle pour toutes les IA.
Parce que le protocole d'exclusion des robots (Robots Exclusion Protocol) repose sur une conformité volontaire, une règle Disallow est une requête publique, pas un pare-feu. Pour un contenu sensible ou à forte valeur, considérez robots.txt comme la première couche et prévoyez de vérifier le comportement et d'appliquer des contrôles plus stricts au niveau du CDN ou du serveur, là où c'est nécessaire. La section suivante indique précisément quels robots relèvent aujourd'hui de chaque catégorie.
Cette distinction compte, car la finalité détermine la valeur. Les robots d'entraînement ingèrent les pages hors ligne pour construire de futurs modèles, sans citation en direct ni renvoi vers vous. Les robots de recherche et de citation explorent pour répondre à une requête sur le moment (ils alimentent les Google AI Overviews, la recherche de ChatGPT, la recherche de Claude et les réponses de Perplexity), et c'est de là que proviennent réellement la découvrabilité et le trafic de référence.
| Éditeur d'IA | Robot de recherche/citation (à autoriser en général) | Robot d'entraînement (à bloquer en général) | Notes de conformité robots.txt |
|---|---|---|---|
| OpenAI | OAI-SearchBot | GPTBot | Respecte les balises robots.txt selon la documentation officielle |
| Anthropic | Claude-SearchBot, Claude-User | ClaudeBot | Respecte robots.txt et Crawl-delay ; blocage IP déconseillé |
| ByteDance | Bytespider | — | Souvent signalé pour son faible respect de robots.txt — à vérifier séparément |
Pour OpenAI, l'éditeur publie OAI-SearchBot et GPTBot comme des balises robots.txt distinctes afin de vous permettre de gérer l'accès. Les éditeurs qui autorisent OAI-SearchBot peuvent suivre le trafic de référence tout en interdisant GPTBot pour exclure des pages d'un éventuel entraînement. Concrètement, cela revient à classer OAI-SearchBot et ChatGPT-User comme recherche/citation, et GPTBot comme entraînement.
Anthropic documente explicitement son cadre : ClaudeBot contribue à améliorer l'utilité et la sécurité en collectant du contenu web susceptible d'alimenter l'entraînement, Claude-User assiste les utilisateurs de Claude AI en accédant aux sites web lorsqu'ils posent des questions, et Claude-SearchBot parcourt le web pour améliorer la qualité des résultats de recherche. Les trois prennent en charge l'extension non standard Crawl-delay, et Anthropic précise que le blocage d'adresses IP peut ne pas fonctionner correctement ou durablement car les robots doivent d'abord lire le fichier robots.txt.
Appliquez le même schéma aux autres éditeurs : vérifiez la chaîne user-agent exacte dans la documentation de l'éditeur avant de l'ajouter. Perplexity publie PerplexityBot / Perplexity-User, Google publie Google-Extended et Googlebot, Apple publie Applebot et Applebot-Extended, et Common Crawl publie CCBot. Bytespider, de ByteDance, est le cas limite classique que les opérateurs signalent pour son faible respect de robots.txt : traitez-le donc comme « à vérifier séparément » et prévoyez une application des règles ci-dessous plutôt que de vous fier au seul robots.txt.
Savoir quels robots cibler n'est utile que si vous savez où ces règles se collent réellement sur votre plateforme.
WordPress génère un robots.txt virtuel si aucun fichier n'existe à la racine du domaine. Vous avez deux possibilités : téléverser un fichier robots.txt statique via SFTP ou le gestionnaire de fichiers de votre hébergeur pour écraser le fichier virtuel, ou le modifier depuis une extension SEO. Yoast SEO et Rank Math exposent tous deux un éditeur de robots.txt dans leurs écrans Tools / File Editor. Si un fichier physique existe sur le disque, WordPress le servira à la place de la version virtuelle : vérifiez donc s'il reste des fichiers résiduels après avoir changé de méthode.
Les sites Webflow n'autorisent pas le téléversement de fichiers arbitraires vers /. Vous gérez le fichier dans Site settings > SEO > Indexing, où une zone de texte vous permet d'ajouter des règles personnalisées et de les publier avec le site Set robots.txt rules. Webflow ajoute automatiquement la référence à votre sitemap, sauf si vous activez Remove sitemap.xml from robots.txt , et il propose également un contrôle distinct de l'en-tête Content-Signal dans le même panneau Indexing. L'éditeur est en texte brut, sans validation par robot : veillez donc à une syntaxe rigoureuse.
robots.txt.liquid à surchargerShopify sert un fichier par défaut géré, adapté à la plupart des boutiques. Pour le personnaliser, vous devez créer un robots.txt.liquid comme modèle dans le thème. Depuis votre interface d'administration, accédez à Online Store > Themes >... > Edit code, puis Add new template > robots et créez-le Editing robots.txt.liquidUtilisez Liquid pour étendre la sortie par défaut plutôt que de la remplacer entièrement par du texte statique, ce que Shopify déconseille car cela empêche l'application des futures protections SEO. Shopify précise également que ces règles sont consultatives et qu'il n'est pas garanti que tous les robots d'exploration les suivent.
Sur les stacks auto-hébergées, modifiez directement le fichier à la racine du document, par exemple /var/www/html/robots.txt, afin que yourdomain.com/robots.txt le renvoie. Si votre CMS verrouille le fichier, utilisez votre couche CDN (une Cloudflare Transform Rule, un Worker ou une règle en périphérie similaire) pour servir un contenu personnalisé à ce chemin.
Modèle prêt à adapter, référençant le répertoire ci-dessus :
# Block training-use crawlers, allow search/citation crawlers
User-agent: [TRAINING-BOT-NAME]
Disallow: /
User-agent: [SEARCH-BOT-NAME]
Allow: /
User-agent: *
Allow: /
Sitemap: https://yourdomain.com/sitemap.xml
Remplacez les espaces réservés entre crochets par les user-agents exacts du répertoire ci-dessus et répétez le bloc autant de fois que nécessaire.
Avertissement : tous les CMS ne permettent pas de contrôler entièrement robots.txt — vérifiez ce que votre plateforme expose réellement et si elle fusionne des valeurs par défaut avant de considérer que vos règles sont actives.
Publier la règle ne représente que la moitié du travail. Les règles ne sont utiles que si elles sont réellement respectées, et robots.txt demeure une convention volontaire : les robots bien élevés le consultent avant de récupérer une page, mais rien dans le protocole n'impose la conformité et une ligne Disallow n'a aucune valeur juridique.
Inspectez les logs du serveur et du CDN. Après avoir publié une nouvelle règle Disallow, recherchez deux événements dans l'ordre chronologique : une récupération de /robots.txt, puis une récupération du chemin que vous avez bloqué. Si vous constatez que le chemin bloqué est récupéré après robots.txt sans que la règle soit respectée, avec un motif de user-agent connu dans le log, il s'agit d'un défaut de conformité. Filtrez par user-agent et par IP d'hôte, et pas seulement par UA, car les chaînes UA sont triviales à falsifier.
Vérifiez l'identité de l'appelant. Pour les principaux robots d'exploration, appuyez-vous sur des vérifications d'infrastructure, et non sur le texte de l'UA. Google documente la méthode canonique : effectuez une résolution DNS inversée sur l'IP à l'origine de l'accès, vérifiez que le nom de domaine est bien googlebot.com, google.com ou googleusercontent.com, puis effectuez une résolution directe sur ce nom d'hôte et confirmez qu'elle renvoie bien vers l'IP d'origine. OpenAI, Anthropic et Common Crawl publient leurs plages d'adresses IP ou leurs motifs de DNS inversé dans leur documentation : vous pouvez donc appliquer la même vérification en deux étapes à GPTBot, ClaudeBot, CCBot et aux opérateurs similaires. La mise en correspondance automatique des IP avec les listes JSON publiées par les éditeurs permet de passer à l'échelle au-delà des vérifications ponctuelles.
Utilisez des analyses tenant compte des robots. Si vous êtes derrière Cloudflare, Fastly, Akamai ou un service similaire, activez les analyses de robots pour regrouper les requêtes par score de robot vérifié ou non, par ASN et par fréquence de requêtes. En exportant une courte fenêtre de logs autour de la modification de robots.txt, vous verrez clairement si un robot IA précis a cessé ou poursuivi son exploration.
Certains robots d'exploration, notamment Bytespider et les boîtes à outils de scraping génériques qui font tourner leurs UA, ont un historique avéré de non-respect de robots.txt. Pour ceux-là, allez au-delà du simple fichier texte :
/blog/* ou /docs/*.Robots.txt n'a aucune force juridique ni technique : considérez-le donc comme un signal et associez-le à un blocage CDN/WAF pour les robots non conformes.
Une fois l'accès correctement contrôlé et vérifié, la dernière couche consiste à s'assurer que le contenu accessible à ces robots mérite réellement d'être cité. robots.txt est le gardien, llms.txt est le guide. Robots.txt indique aux robots ce qu'ils peuvent récupérer ; llms.txt offre aux modèles une carte claire et sélectionnée de ce qui compte vraiment sur votre site : un simple fichier Markdown, à la racine du domaine, qui résume votre expertise et pointe vers vos meilleures pages.
Au-delà des simples mots-clés, les moteurs d'IA privilégient un contenu bien structuré, doté de métadonnées claires, de FAQ et de balisage schema. HarperFlow automatise ces optimisations pour rendre votre contenu hautement repérable et pertinent, réduisant le travail manuel tout en améliorant les performances auprès des moteurs de réponse.
La proposition publiée sur llmstxt.org est volontairement minimale. Elle réside à /llms.txt, utilise Markdown, commence par un titre H1 contenant le nom du projet ou du site — seul élément obligatoire —, ajoute un résumé sous forme de citation (blockquote), puis emploie des titres H2 pour regrouper des listes de fichiers où chaque entrée est un lien Markdown assorti de notes facultatives. Il existe même une section Optional pour les ressources secondaires, que l'on peut ignorer lorsque le contexte est limité. La spécification est conçue pour coexister avec les standards web actuels et compléter robots.txt en fournissant du contexte sur le contenu autorisé, tandis que robots.txt demeure le fichier qui indique aux outils automatisés quel accès est jugé acceptable pour les robots d'indexation de recherche.
Cette répartition explique pourquoi ouvrir l'accès ne suffit presque jamais à obtenir des citations. Les moteurs de recherche et de réponse peuvent récupérer une page mais l'ignorer tout de même si la réponse est noyée dans la navigation, le JavaScript ou une prose vague. Les modèles citent les pages où la réponse est immédiate, autonome et traçable.
Utilisez dès aujourd'hui cette checklist pour boucler la boucle :
Une fois les portes et la carte en place, l'attention se porte sur la structure à grande échelle. HarperFlow est conçu pour cette couche suivante : il transforme le contenu approuvé en pages traçables et orientées réponse, que les moteurs de réponse peuvent analyser et citer sans retouche.
Non, il vaut mieux les traiter séparément. OAI-SearchBot alimente le trafic de référence issu des résultats de recherche de ChatGPT, tandis que GPTBot est l'agent que vous interdisez via Disallow pour exclure vos pages d'un éventuel entraînement. Bloquer le robot de recherche supprime les citations, et non le risque lié à l'entraînement.
Oui. Utilisez des blocs par agent avec un chemin précis, comme Disallow: /private/ sous le User-agent du robot d'entraînement. Le fichier doit toujours se trouver à la racine du site pour être détecté, et vous pouvez combiner Allow et Disallow pour chaque robot. Vérifiez ensuite les journaux du serveur pour confirmer que la règle est respectée.
Vérifiez l'identité à l'aide du DNS inversé et des plages d'adresses publiées par l'éditeur, et pas seulement de la chaîne User-agent. Google décrit la méthode ainsi : effectuer une résolution DNS inversée de l'adresse IP, vérifier le domaine, puis effectuer une résolution directe pour confirmer qu'elle renvoie vers la même IP ; Anthropic publie des recommandations similaires. Anthropic précise également que le blocage d'adresses IP peut ne pas fonctionner correctement ou durablement, car les robots doivent d'abord récupérer le fichier robots.txt.
Cela signifie qu'il ne respecte pas la conformité volontaire. Considérez robots.txt comme une requête publique, et non comme un pare-feu, et appliquez le contrôle en périphérie avec une règle WAF, une limitation de débit ou un défi (challenge). Sur Cloudflare, la fonctionnalité Block AI Bots bloque les robots vérifiés classés comme explorant à des fins d'entraînement de l'IA, ainsi qu'un certain nombre de robots non vérifiés au comportement similaire.
Pas si vous le configurez selon le comportement. Cloudflare répartit le comportement des robots IA en trois catégories — Search, Agent et Training — avec la possibilité de bloquer sur toutes les pages, de bloquer sur les pages comportant des publicités, ou d'autoriser. Vous pouvez bloquer Training tout en laissant Search autorisé afin de préserver les citations et le trafic de référence.
Non, ils remplissent des rôles différents. Robots.txt est le fichier qui indique aux outils automatisés quel accès est jugé acceptable pour les robots d'indexation de recherche, tandis que llms.txt est conçu pour coexister avec lui et le compléter en fournissant du contexte sur le contenu autorisé. L'un contrôle l'accès, l'autre cartographie ce qui mérite d'être cité.
Shopify recommande d'étendre le fichier par défaut à l'aide d'un fichier robots.txt.liquid placé dans le dossier templates de votre thème, plutôt que de le remplacer par du texte statique. Cette méthode préserve les futures protections SEO, et vous pouvez toujours référencer votre sitemap. Shopify précise que ces règles sont indicatives et consultatives, sans garantie d'être suivies par tous les robots d'exploration.
Oui, pour les robots qui la respectent. Anthropic prend en charge l'extension non standard Crawl-delay, vous pouvez donc ajouter Crawl-delay sous son User-agent. Cela réduit la fréquence de récupération sans vous retirer des ensembles de recherche ou d'entraînement.