robots.txt

Comment fonctionne robots.txt et quelle est sa syntaxe de base ?

Le fichier robots.txt est structuré en blocs, chacun commençant par une directive User-agent qui identifie le robot ciblé par les règles suivantes. Le caractère * dans User-agent: * signifie « tous les robots ». Chaque bloc contient des directives Allow (autoriser l'accès à une URL ou un répertoire) et Disallow (interdire l'accès). Une directive Disallow: / interdit à un robot l'accès à l'ensemble du site ; Disallow: /admin/ lui interdit uniquement le répertoire admin. La directive Allow prend la priorité sur Disallow pour les règles plus spécifiques, permettant d'autoriser des sous-sections d'un répertoire globalement bloqué.

robots.txt peut également inclure une directive Sitemap pointant vers l'URL du sitemap XML du site — une pratique recommandée qui signale aux crawlers où trouver la carte complète des URLs indexables. La syntaxe est simple : Sitemap: https://votredomaine.com/sitemap.xml. Cette directive est utile pour tous les robots, pas uniquement pour Googlebot, et facilite la découverte du contenu par les crawlers IA. Le fichier robots.txt est un fichier texte simple qui doit être hébergé à la racine exacte du domaine — pas d'un sous-domaine ou sous-répertoire.

Un point fondamental : robots.txt est une convention reposant sur la bonne volonté des robots, pas un mécanisme de sécurité technique. Un robot qui ne respecte pas le protocole peut ignorer ses directives. En pratique, tous les crawlers légitimes des grands moteurs de recherche et des moteurs IA respectent robots.txt. En revanche, les scrapers malveillants ou les bots non conformes peuvent l'ignorer. Pour les contenus qui doivent être protégés techniquement (données personnelles, contenus propriétaires), l'authentification et le contrôle d'accès côté serveur sont indispensables — robots.txt n'est pas une garantie de confidentialité.

Quels sont les crawlers IA à gérer dans robots.txt ?

Avec la multiplication des moteurs IA génératifs, le nombre de crawlers IA à connaître s'est considérablement élargi. Les principaux User-Agents IA à connaître pour une stratégie AEO sont : GPTBot (OpenAI, pour ChatGPT et ChatGPT Search), OAI-SearchBot (OpenAI, spécifique à la recherche web), ClaudeBot (Anthropic), Google-Extended (Google, distinct de Googlebot — utilisé pour les données d'entraînement IA et potentiellement pour AI Overviews), PerplexityBot (Perplexity), Applebot-Extended (Apple, pour ses fonctionnalités IA) et cohere-ai (Cohere). Ces User-Agents sont documentés par leurs éditeurs respectifs.

La distinction entre Googlebot et Google-Extended est particulièrement importante. Googlebot est le crawler qui alimente l'index de recherche Google classique — le bloquer empêche d'apparaître dans les résultats Google, ce qui est presque toujours indésirable. Google-Extended est un crawler distinct, utilisé pour les produits IA de Google (entraînement de modèles, potentiellement AI Overviews). Un site peut bloquer Google-Extended sans affecter son référencement Google classique — mais les implications sur la visibilité dans les AI Overviews restent incertaines et non officiellement documentées par Google.

Pour une stratégie AEO, la configuration robots.txt par rapport aux crawlers IA repose sur un choix explicite. Autoriser tous les crawlers IA légitimes maximise la crawlabilité du contenu et les chances d'être indexé et cité dans les réponses IA. Bloquer certains crawlers IA spécifiques (notamment ceux utilisés pour l'entraînement de modèles plutôt que pour la récupération en temps réel) est un choix éditorial valide si la marque souhaite contrôler l'utilisation de son contenu. HubSpot permet de configurer le fichier robots.txt de son site via les outils de gestion technique du CMS.

Ressources :

• Configurer le fichier robots.txt sur son site HubSpot

Bloquer ou autoriser les crawlers IA : quelle stratégie adopter ?

La décision de bloquer ou d'autoriser les crawlers IA dans robots.txt dépend des objectifs de visibilité et des considérations éditoriales de chaque organisation. Pour une marque dont la stratégie AEO vise à maximiser la présence dans les réponses des moteurs IA génératifs, autoriser les crawlers IA des principaux moteurs (GPTBot, ClaudeBot, PerplexityBot) est la condition préalable. Un site bloqué dans robots.txt ne peut pas être récupéré et cité par ces moteurs lors de leurs réponses en temps réel — toute stratégie de contenu AEO repose sur cette accessibilité fondamentale.

La nuance concerne la distinction entre les crawlers de récupération en temps réel (qui alimentent les réponses des moteurs IA sur les requêtes actuelles) et les crawlers d'entraînement de modèles (qui récupèrent du contenu pour entraîner les prochaines versions des modèles). Certains éditeurs choisissent d'autoriser les premiers tout en bloquant les seconds, pour permettre la citation dans les réponses IA actuelles sans contribuer à l'entraînement gratuit des modèles. En pratique, la séparation entre ces deux usages n'est pas toujours clairement documentée par les acteurs IA, ce qui rend cette distinction difficile à implémenter avec certitude.

Pour les marques dont le contenu est une ressource éditoriale propriétaire à haute valeur ajoutée (médias, éditeurs, cabinets de conseil...) le choix de bloquer certains crawlers IA peut être justifié par des considérations de propriété intellectuelle. Pour les marques B2B dont l'objectif est la visibilité et la génération de leads via les moteurs IA, bloquer les crawlers IA revient à se rendre invisible dans un canal de découverte croissant. La configuration optimale est donc spécifique à chaque organisation et doit être revue régulièrement à mesure que l'écosystème des crawlers IA évolue.

robots.txt et crawlabilité AEO : les erreurs courantes à éviter

La première erreur courante est le blocage accidentel des crawlers IA via une directive User-agent: * / Disallow: / ou des règles génériques qui bloquent par inadvertance les User-Agents des moteurs IA. Lors d'une migration de site, d'un changement de CMS ou d'une mise à jour du fichier robots.txt, il est indispensable de vérifier que les crawlers IA des principaux moteurs ne sont pas bloqués globalement. Un audit robots.txt doit faire partie des vérifications techniques de toute migration ou refonte de site dans un contexte AEO.

La seconde erreur est de bloquer dans robots.txt des ressources dont le contenu est nécessaire aux crawlers IA pour comprendre une page — fichiers CSS, images illustratives, contenus chargés dynamiquement. La plupart des crawlers IA ne rendent pas le JavaScript et récupèrent le HTML brut : si le contenu principal d'une page est généré côté client via JavaScript, il ne sera pas accessible au crawler IA même si la page elle-même n'est pas bloquée dans robots.txt. Ce point est indépendant de robots.txt mais souvent confondu avec lui dans les diagnostics de crawlabilité.

La troisième erreur est de traiter robots.txt comme un mécanisme de sécurité pour les contenus sensibles. Les URL bloquées dans robots.txt restent techniquement accessibles à tout browser humain ou bot non conforme — elles ne sont simplement pas supposées être crawlées par les robots respectueux du protocole. Un contenu confidentiel doit être protégé par une authentification côté serveur, pas uniquement par une exclusion robots.txt. Confondre « ne pas indexer » et « rendre inaccessible » est une erreur de sécurité que robots.txt ne peut pas corriger.

Ressources :

• Qu'est-ce que le fichire robots.txt et comment s'en servir ?

Quelle relation entre robots.txt, llms.txt et sitemap.xml dans une stack AEO ?

robots.txt, llms.txt et sitemap.xml sont trois fichiers complémentaires qui adressent des aspects distincts de la découverte et de l'accessibilité du contenu par les robots automatisés. robots.txt est la couche de contrôle d'accès : elle détermine qui peut crawler quoi. sitemap.xml est la couche de découverte exhaustive : elle liste toutes les URLs que le site souhaite voir indexées. llms.txt est la couche de priorisation éditoriale pour les LLM : elle indique les ressources les plus stratégiques parmi celles accessibles. Les trois peuvent coexister sans conflit, mais robots.txt est hiérarchiquement premier : si un crawler est bloqué dans robots.txt, il n'accèdera ni au sitemap ni à llms.txt.

La relation entre robots.txt et llms.txt est particulièrement importante à clarifier. Un fichier llms.txt bien construit n'a d'effet que si les crawlers IA ciblés sont autorisés dans robots.txt à accéder aux pages qu'il référence. Une configuration incohérente — llms.txt qui liste des pages dans des répertoires bloqués pour les crawlers IA dans robots.txt — est contre-productive et peut créer de la confusion dans les logs de crawl. La cohérence entre ces deux fichiers doit être vérifiée lors de chaque mise à jour de l'un ou de l'autre.

Pour une stack AEO technique cohérente, l'ordre de priorité des investissements est le suivant : s'assurer que robots.txt n'est pas un obstacle involontaire à la crawlabilité des crawlers IA légitimes ; s'assurer que le contenu principal des pages est dans le HTML source sans dépendre du JavaScript ; implémenter un sitemap XML à jour ; déployer le Schema Markup sur les pages prioritaires ; éventuellement créer un llms.txt si les fondamentaux précédents sont en place. robots.txt est la première vérification, pas la dernière.

Ressources :

• Faire un sitemap XML