Fichier robots.txt : rôle, syntaxe et erreurs à éviter

Le fichier robots.txt indique aux robots d’exploration quelles zones d’un site ils peuvent parcourir. Il vit à la racine de l’hôte, s’écrit en texte brut, et gouverne l’exploration sans jamais gouverner l’indexation. Une seule ligne mal posée coupe un site entier de la découverte par les moteurs.

Le protocole a plus de trente ans. Martijn Koster l’a proposé en 1994 comme une convention informelle entre webmasters et robots. Sa normalisation a pris du temps : septembre 2022 et la publication de la RFC 9309 par l’IETF, signée Martijn Koster, Gary Illyes, Henner Zeller et Lizzi Sassman, avec un vocabulaire défini, une gestion des erreurs et des règles de cache.

Ce que le fichier commande, et ce qu’il ne commande pas

Un fichier robots.txt gouverne une seule chose : l’accès des robots aux URL d’un hôte. Il ne chiffre rien, ne masque rien, ne supprime rien. Un navigateur, un aspirateur de site mal élevé ou un script maison passent outre sans difficulté, puisque le respect des règles relève de la bonne volonté du client qui les lit.

Google documente cette frontière dans son centre d’aide destiné aux développeurs : le robots.txt sert à gérer le trafic des robots sur un serveur, pas à tenir une page hors de Google. La confusion entre ces deux fonctions produit la majorité des accidents relevés en audit technique.

Bloquer l’exploration ne retire pas une page de l’index

Le scénario se répète. Vous interdisez /promotions/ dans le fichier. Un site externe pointe vers /promotions/soldes-hiver/. Google découvre l’URL par ce lien, ne peut pas la lire, et l’indexe quand même à partir du contexte extérieur, sans description ni extrait sous le titre.

Le remède demande le mouvement inverse : rendre la page explorable, puis poser une balise noindex dans son en-tête HTML, ou l’équivalent en en-tête HTTP avec X-Robots-Tag. Un robot doit lire une instruction pour l’appliquer. Interdire l’accès à une page dont vous voulez la disparition revient à placer le mot de désinscription derrière une porte fermée à clé.

Un robots.txt par hôte, à la racine, en texte brut

L’emplacement ne se négocie pas : https://example.com/robots.txt, et rien d’autre. Un fichier rangé dans un sous-dossier ne sera jamais lu, quelle que soit sa qualité.

La règle porte sur le triplet protocole, hôte, port. Trois conséquences concrètes :

• https://example.com et https://blog.example.com forment deux hôtes distincts, chacun avec son propre fichier
• La version HTTP et la version HTTPS ne partagent pas leurs règles, même derrière une redirection généralisée
• Un environnement de recette exposé sur un sous-domaine réclame son fichier à lui

Le format reste volontairement pauvre : du texte encodé en UTF-8, une directive par ligne, le croisillon pour les commentaires. Google applique une limite de lecture de 500 kibioctets et ignore tout ce qui dépasse ce seuil, tandis que la RFC 9309 demande aux robots d’analyser au moins cette quantité. Un fichier qui approche ce plafond trahit presque toujours une liste de blocage devenue incontrôlable.

La syntaxe, groupe par groupe

Un robots.txt s’organise en groupes. Chaque groupe s’ouvre sur une ou plusieurs lignes User-agent, suivies des règles qui s’appliquent à ces robots.

Choisir le bon User-agent

Un robot ne lit pas tout le fichier. Il cherche le groupe qui le nomme le plus précisément, applique celui-là, et laisse tomber les autres. Googlebot qui trouve un groupe User-agent: Googlebot cesse de tenir compte du groupe User-agent: *, y compris pour les règles absentes de son propre groupe.

Ce détail explique un accident classique. Un fichier bloque proprement plusieurs répertoires dans le groupe générique, ajoute ensuite un groupe nominatif pour Googlebot afin d’y traiter un cas particulier, et annule pour Googlebot toutes les protections écrites plus haut.

Google fait circuler plusieurs agents distincts, dont Googlebot pour la recherche, Googlebot-Image pour les images et Google-Extended pour ses usages liés à l’intelligence artificielle générative. Les éditeurs de modèles de langage publient les leurs, ce qui fait du robots.txt le point de contrôle standard pour l’accès des robots d’entraînement.

Allow, Disallow et le chemin le plus long

Deux directives suffisent. Disallow interdit un chemin, Allow en réautorise une portion. Les valeurs se comparent en respectant la casse : /Media/ et /media/ désignent deux chemins différents pour le robot.

Deux caractères spéciaux complètent le jeu. L’astérisque remplace n’importe quelle suite de caractères, le dollar ancre la fin de l’URL.

User-agent: *
Disallow: /panier/
Allow: /panier/guide-des-tailles/
Disallow: /*?tri=
Disallow: /*.pdf$

Sitemap: https://example.com/sitemap.xml

Quand plusieurs règles correspondent à une même URL, Google retient celle dont le chemin déclaré est le plus long. À longueur égale, l’autorisation l’emporte sur l’interdiction. Dans cet exemple, le guide des tailles reste explorable malgré l’interdiction qui pèse sur le panier, parce que son plus long chemin correspondant est la ligne Allow.

La ligne Sitemap, hors des groupes

La directive Sitemap ne dépend d’aucun User-agent. Elle se place où vous voulez dans le fichier, prend une URL absolue, et se répète autant de fois qu’il existe de fichiers d’index. C’est le seul mécanisme de déclaration qui vaut pour tous les moteurs à la fois, sans compte à créer ni propriété à valider.

Ce qui mérite un Disallow, et ce qui n’en a pas besoin

Google précise dans sa documentation consacrée au budget d’exploration qu’un site de moins de quelques milliers d’URL n’a pas de sujet à ce niveau : le robot passe partout sans peiner. Le budget d’exploration devient un paramètre réel au-delà, sur les catalogues, les annuaires et les applications qui fabriquent des URL à la volée.

Les candidats légitimes au blocage se ressemblent d’un site à l’autre :

• Les URL de filtres et de tri, qui multiplient les combinaisons d’une même liste de produits
• Les pages de résultats de recherche interne, sans valeur pour un visiteur venu d’un moteur
• Les espaces de compte, paniers et tunnels de commande
• Les exports lourds, archives et fichiers temporaires générés par l’application

Trois cas ressemblent à des candidats sans en être. Une page en double se traite par une balise canonique, jamais par une interdiction d’accès. Une page obsolète se retire avec un noindex, puis un code 410 une fois désindexée. Une page confidentielle se ferme par authentification, seule barrière que personne ne contourne. Le tri se fait donc en deux temps : la question « ce contenu doit-il exister dans l’index ? » ne se règle jamais dans le robots.txt, seule la question « ce contenu mérite-t-il d’être exploré ? » y trouve sa réponse.

Les directives que Google ignore dans un robots.txt

Le nombre de fichiers contenant des lignes sans le moindre effet reste élevé. Google a publié en juillet 2019 une note sur les règles non prises en charge, et a cessé d’obéir à la directive noindex écrite dans le robots.txt à partir du 1er septembre 2019.

Sont ignorées côté Google :

• noindex et nofollow, à écrire dans la page ou dans l’en-tête HTTP
• La directive crawl-delay, que Bing lit encore et que Google n’a jamais appliquée
• host, request-rate et visit-time, vestiges d’autres robots

Pour freiner l’exploration, Google renvoie vers les signaux serveur, un code 429 ou 503 retourné au robot, et vers les réglages de la Search Console. La cadence se pilote côté hébergement, pas côté fichier texte.

Ce que Google fait quand le fichier répond mal

Le comportement en cas d’erreur figure dans la spécification publiée par Google et dans la RFC 9309.

Deux enseignements pratiques. Un hébergement qui répond 503 pendant une maintenance très longue finit par se faire explorer comme si aucune règle n’existait. Et une correction n’agit pas dans la minute : Google conserve généralement le fichier en cache jusqu’à vingt-quatre heures, durée que la RFC 9309 fixe comme plafond pour tous les robots conformes.

Les erreurs qui coûtent des positions

Quelques fautes reviennent dans presque tous les audits techniques.

Le Disallow: / oublié après une mise en production arrive en tête du classement. La ligne protégeait l’environnement de recette, elle part en ligne avec le reste des fichiers, et le site s’efface des résultats en quelques jours. Ce contrôle appartient à la recette d’une migration de site web, au même titre que le plan de redirections.

Le blocage des ressources d’affichage vient juste après. Interdire /css/, /js/ ou un répertoire d’images empêche Google de rendre la page telle que la voit un visiteur, et sa documentation demande explicitement de laisser ces fichiers accessibles au robot.

Le troisième réflexe fautif consiste à traiter le robots.txt comme une mesure de protection. Le fichier est public par nature : n’importe qui le lit en tapant son adresse dans un navigateur. Y déclarer /admin-prive/ revient à publier la liste des portes à essayer. Les répertoires sensibles se ferment par authentification, logique détaillée dans nos conseils pour sécuriser un poste contre les cyberattaques.

Restent trois négligences plus discrètes :

• Un sous-domaine oublié, qui laisse une préproduction complète ouverte à l’indexation
• Une ligne Sitemap pointant vers une ancienne adresse après un changement de nom de domaine
• Un fichier généré par une extension du CMS, réécrit à chaque mise à jour sans que personne ne le remarque

Contrôler le fichier après chaque mise en ligne

La Search Console propose depuis fin 2023 un rapport robots.txt, arrivé en remplacement de l’ancien testeur. Il liste les fichiers trouvés pour les vingt principaux hôtes d’une propriété, la date du dernier passage du robot, ainsi que les avertissements et erreurs rencontrés. Une demande de nouvelle lecture s’y déclenche en un clic quand une correction presse.

Un crawler de bureau complète le tableau. Il montre quelles URL du site sont réellement bloquées par le fichier en vigueur, ce qu’aucune relecture manuelle ne révèle sur un site de plusieurs milliers de pages. Nos outils d’analyse de performance d’un site web couvrent cette famille de logiciels et leur usage en audit.

Une routine tient en quatre points, à dérouler après chaque mise en production :

1. Ouvrir l’URL du fichier dans un navigateur et vérifier qu’elle répond bien en 200
2. Relire la première ligne de chaque groupe, la casse comprise
3. Tester deux URL sensibles, une censée être bloquée, une censée rester ouverte
4. Confirmer que la ligne Sitemap renvoie vers un fichier valide

Prochaine étape : ouvrez le robots.txt de votre site, comptez ses lignes, et supprimez celles que Google ignore. Un fichier de dix lignes lisibles protège mieux qu’une liste de blocage empilée sur cinq ans. Les fondamentaux du référencement naturel replacent ce réglage dans l’ensemble du travail technique.