Les fichiers robots.txt orientent l’exploration des sites par les moteurs

Chaque fois qu’un moteur de recherche découvre un site, son robot d’exploration cherche d’abord un petit fichier texte placé à la racine : le robots.txt. Ce fichier lui indique quelles parties du site il peut parcourir et lesquelles il doit ignorer. Comprendre ce mécanisme permet de mieux maîtriser la façon dont Google ou Bing lisent vos pages, et d’éviter quelques pièges qui peuvent nuire à votre référencement.

Robots.txt : un filtre d’exploration, pas un verrou de sécurité

Le robots.txt fonctionne comme un panneau d’indication posé à l’entrée d’un bâtiment. Il dit aux visiteurs automatisés (les crawlers) : « Vous pouvez entrer ici, mais pas là. » Le fichier ne bloque rien physiquement. Un robot qui décide de l’ignorer accède tout de même aux pages.

C’est un point souvent mal compris. Bloquer un dossier dans le robots.txt ne protège pas des données sensibles. Le fichier exprime une préférence, pas une interdiction technique. La norme RFC 9309, publiée en septembre 2022, le rappelle explicitement : les règles du fichier ne constituent pas une autorisation d’accès. Pire, inscrire un chemin dans le robots.txt peut le rendre plus facile à repérer pour quiconque consulte le fichier.

Vous stockez des pages d’administration ou des données privées ? Protégez-les par mot de passe ou restriction serveur. Le robots.txt n’est pas l’outil adapté.

Syntaxe du fichier robots.txt : les directives que Google lit vraiment

Le fichier repose sur trois directives principales. Chacune tient en une ligne.

• User-agent désigne le robot concerné. Écrire User-agent: * cible tous les robots. Écrire User-agent: Googlebot cible uniquement le crawler principal de Google.
• Disallow interdit l’exploration d’un chemin. Par exemple, Disallow: /admin/ demande aux robots de ne pas parcourir le dossier admin.
• Allow autorise l’exploration d’un chemin qui serait autrement bloqué par une règle Disallow plus large. Par exemple, autoriser /admin/public/ tout en bloquant /admin/.

Quand une URL correspond à la fois à une règle Allow et à une règle Disallow, la règle dont le chemin est le plus spécifique l’emporte. Cette logique a été formalisée par la RFC 9309. Avant cette norme, chaque moteur interprétait les conflits à sa manière.

Le fichier accepte aussi la directive Sitemap pour indiquer l’URL du plan de site XML. Ce n’est pas une obligation, mais c’est un raccourci utile : le robot découvre le sitemap sans attendre de le croiser dans la Search Console ou au fil de ses explorations.

Pages bloquées mais indexées : le piège classique du robots.txt

Vous avez bloqué une page via Disallow et vous pensez qu’elle ne s’affichera plus dans les résultats de recherche ? C’est une erreur fréquente. Une URL bloquée par le robots.txt peut quand même apparaître dans Google.

Le mécanisme est le suivant. Si d’autres sites font un lien vers cette page, Google découvre l’URL par ces liens externes. Le moteur ne peut pas explorer la page (le robots.txt l’en empêche), mais il peut indexer l’URL elle-même, avec un titre vide ou un extrait très pauvre. L’URL se retrouve dans les résultats, sans que Google ait pu lire une éventuelle balise noindex placée dans le code HTML.

Pour retirer réellement une page de l’index, il faut que le robot puisse d’abord la lire. Laissez-le accéder à la page, ajoutez une balise meta noindex dans le code HTML, puis attendez un recrawl. Bloquer l’exploration empêche Google de voir la directive noindex. C’est contre-intuitif, mais c’est la réalité du fonctionnement actuel.

Portée du fichier robots.txt : protocole, hôte et sous-domaines

Avez-vous remarqué que votre site principal et votre blog sur un sous-domaine ne réagissent pas toujours aux mêmes règles ? C’est normal. Le robots.txt de example.com ne contrôle pas shop.example.com. Chaque combinaison protocole-hôte-port possède son propre fichier.

Concrètement, si votre boutique fonctionne sur un sous-domaine séparé, elle a besoin de son propre robots.txt, hébergé à sa racine. La même logique s’applique si vous utilisez un port non standard ou un protocole différent. Un seul fichier robots.txt ne couvre qu’un seul hôte.

Sur les sites e-commerce, cela implique de vérifier chaque sous-domaine. Les filtres de tri, les facettes de recherche, les pages de compte client : tout ce qui génère des URL dynamiques mérite une attention particulière, zone par zone.

Crawlers IA et robots.txt : une limite à connaître

Depuis l’essor des modèles de langage, de nouveaux robots parcourent le web pour collecter des données d’entraînement. Le robots.txt permet de leur bloquer l’accès, à condition de connaître leur nom d’agent (user-agent). Google propose par exemple le jeton Google-Extended pour contrôler l’accès de ses crawlers liés à l’IA, séparément de Googlebot.

Le fichier indique une préférence d’exploration, pas une restriction sur l’utilisation des données une fois récupérées. Un robot qui a déjà exploré vos pages avant l’ajout d’une règle Disallow a pu stocker le contenu. La frontière entre exploration et exploitation des données reste floue, et le robots.txt n’a pas été conçu pour régler cette question.

Erreurs fréquentes dans un fichier robots.txt

Quelques problèmes reviennent régulièrement lors d’audits techniques.

• Bloquer les fichiers CSS ou JavaScript empêche Google de rendre correctement vos pages. Le moteur voit alors une version dégradée du site et peut mal évaluer l’expérience utilisateur.
• Oublier le slash final dans un chemin change la portée de la règle. Disallow: /admin bloque aussi /administration/, alors que Disallow: /admin/ cible uniquement le dossier admin.
• Placer le fichier ailleurs qu’à la racine du domaine le rend invisible pour les robots. L’URL doit être exactement https://votresite.com/robots.txt.
• Utiliser le robots.txt comme seul outil de désindexation au lieu de combiner avec une balise noindex ou un retrait via la Search Console.

Un fichier robots.txt bien rédigé reste court, lisible en quelques secondes, et ne contient que les règles strictement nécessaires. Chaque ligne ajoutée est une instruction que les moteurs doivent interpréter : moins il y en a, moins il y a de risques de conflit entre les directives.