Le fichier robots.txt est un petit document texte posé à la racine d’un site, que les robots d’exploration consultent avant de parcourir la moindre page. Il indique ce qu’ils peuvent visiter, ce qu’ils doivent éviter et où se trouve le sitemap. Mal compris, il fait pourtant plus de dégâts que bien des lignes de code : une règle trop large peut fermer un site entier, et une règle mal choisie ne retire aucune page de l’index. Ce guide pose le rôle réel du fichier, détaille sa syntaxe, recense les erreurs les plus fréquentes, puis explique comment le tester, le déployer et le surveiller sans mauvaise surprise.
Le fichier robots.txt : ce qu’il contrôle vraiment, et ce qu’il ne garantit pas
Avant de visiter un site, un robot sérieux demande toujours la même chose : son fichier robots.txt. Ce document, accessible depuis la racine du domaine, énonce des consignes d’exploration que Google et la plupart des moteurs lisent avant de suivre le moindre lien. Son périmètre est étroit, et c’est précisément ce qui le rend efficace : il règle la circulation des robots sur les pages, pas leur présence dans les résultats. Bien le tenir suppose de comprendre où il s’arrête, et cette précision sert de fil conducteur à tous les tutoriels SEO pas à pas consacrés à l’indexation. Les sections suivantes avancent dans l’ordre : rôle, syntaxe, pièges, contrôle.
Exploration et indexation : deux étapes à ne pas confondre
Un moteur traite une adresse en deux temps. Il commence par l’exploration : le robot télécharge la page et en lit le contenu. Vient ensuite l’indexation : le moteur décide s’il enregistre la page et pour quelles requêtes elle peut répondre. Le fichier robots.txt n’intervient qu’au premier temps, avant le téléchargement. Une adresse interdite peut donc rester connue du moteur, par exemple parce que d’autres pages y renvoient, et s’afficher dans les résultats sans description exploitable. Pour retirer une page de l’index, la bonne méthode est la balise meta robots noindex ou l’en-tête X-Robots-Tag, à condition que la page reste accessible au robot, sans quoi il ne lira jamais la consigne.
Un fichier public qui repose sur la bonne foi des robots
Le fichier est lisible par n’importe qui : il suffit de saisir son adresse dans un navigateur. Lister un répertoire sensible dans une ligne Disallow revient donc à le signaler sur une pancarte. Les robots des grands moteurs respectent ces consignes ; un robot malveillant ou un script de copie s’en dispense. Le constat vaut aussi pour les robots d’IA : certains éditeurs publient des identifiants que l’on peut cibler, mais l’efficacité dépend du respect volontaire du robot. Protéger réellement un contenu exige une authentification par mot de passe ou un contrôle d’accès côté serveur, jamais une simple règle d’exploration, aussi bien rédigée soit-elle.
Une adresse unique, propre à chaque hôte
Le fichier doit se trouver à la racine du domaine, à l’adresse /robots.txt ; rangé dans un sous-dossier, il est ignoré. Ses règles s’appliquent uniquement à l’hôte, au protocole et au port où il est publié : un sous-domaine réclame son propre fichier. Le serveur doit le renvoyer en texte brut, encodé en UTF-8 ; un simple test dans le navigateur permet de vérifier qu’il répond bien. S’il est introuvable (erreur 404), les robots considèrent que tout est explorable. Une erreur serveur persistante, en revanche, peut conduire Google à suspendre l’exploration par précaution (documentation Google Search Central), ce qui justifie une surveillance régulière du fichier.
La syntaxe de robots.txt : user-agent, Disallow, Allow et Sitemap
Un fichier robots.txt se compose de groupes de lignes. Chaque groupe s’ouvre par un user-agent, le nom du robot visé, puis enchaîne les règles qui le concernent. Quatre directives couvrent la quasi-totalité des besoins ; le tableau ci-dessous les résume avant leur détail. Le format est volontairement rudimentaire : une instruction par ligne, des commentaires introduits par un dièse, des noms de directives insensibles à la casse. Les chemins, eux, sont sensibles aux majuscules : /Blog/ et /blog/ désignent deux répertoires distincts. Cette sobriété explique qu’un caractère mal placé suffise à changer le sens d’une règle, d’où l’intérêt de relire chaque ligne.
| Élément | Ce qu’il fait |
|---|---|
| User-agent | Nomme le robot visé par le groupe ; l’astérisque désigne tous les robots. |
| Disallow | Interdit l’exploration d’un chemin ; laissé vide, il n’interdit rien. |
| Allow | Rouvre un chemin précis à l’intérieur d’un répertoire interdit. |
| Sitemap | Donne l’adresse complète d’un sitemap, en dehors de tout groupe. |
| * et $ | L’astérisque remplace une suite de caractères, le dollar marque la fin d’une adresse. |
| # | Ouvre un commentaire que les robots ignorent. |
User-agent : à quel robot s’adresse chaque groupe
Un robot lit le fichier, repère le groupe qui le désigne le plus précisément et n’applique que celui-là. Un groupe nommé Googlebot l’emporte sur le groupe générique marqué d’un astérisque, et les règles des deux ne s’additionnent pas : un groupe créé pour un robot particulier doit donc répéter les interdictions communes. Chaque moteur publie le nom de ses robots dans sa documentation. S’y ajoutent des jetons de contrôle, comme Google-Extended, qui encadre l’usage des contenus par certains produits d’IA de Google avec aucun effet sur l’indexation dans Search. D’autres éditeurs d’IA publient leurs propres identifiants, dont le respect reste volontaire.
Disallow et Allow : la règle la plus précise l’emporte
Plusieurs règles peuvent viser la même adresse. Google retient la plus spécifique, celle dont le chemin compte le plus de caractères ; en cas d’égalité, la moins restrictive, donc Allow, s’applique (documentation Google Search Central). Avec Disallow: /recherche/ et Allow: /recherche/aide/, la page d’aide reste explorable alors que le reste du répertoire est fermé. Une ligne Disallow vide n’interdit rien, tandis qu’un simple Disallow: / ferme l’ensemble du site : c’est le caractère le plus dangereux du fichier, celui qu’il faut chercher en premier lors d’une relecture. Les chemins commencent par une barre oblique et portent sur le début de l’adresse, pas sur son milieu.
Jokers, fin d’adresse et ligne Sitemap
Deux caractères spéciaux suffisent à écrire des motifs utiles. L’astérisque remplace n’importe quelle suite de caractères, et le dollar ancre la règle à la fin de l’adresse : Disallow: /*?tri= ferme les adresses contenant un paramètre de tri, Disallow: /*.pdf$ celles qui se terminent par .pdf. Il ne s’agit pas d’expressions régulières complètes, et chaque motif gagne à être vérifié sur des adresses réelles avant publication, surtout lorsqu’ils cumulent plusieurs jokers. La ligne Sitemap: indique l’adresse absolue d’un plan du site ; elle ne dépend d’aucun groupe et peut figurer plusieurs fois. Le sitemap facilite la découverte, sans constituer un facteur de classement.
Les erreurs courantes dans un fichier robots.txt
Les incidents liés à robots.txt sont rarement spectaculaires : le site continue de s’afficher, les pages se chargent, et le problème n’apparaît que dans les rapports d’exploration de la Search Console, parfois des semaines plus tard. La plupart relèvent de l’héritage : une règle ajoutée pour un besoin ancien, jamais retirée ensuite. Un audit SEO sérieux commence d’ailleurs par ouvrir ce fichier avant tout autre contrôle. Le tableau suivant recense les erreurs les plus fréquentes avec la correction à appliquer ; les paragraphes qui suivent reviennent sur celles qui coûtent le plus cher, en rappelant ce que dit la documentation officielle de Google.
| Erreur | Conséquence et correction |
|---|---|
| Disallow: / oublié après une préproduction | Tout le site devient inexplorable ; retirer la règle dès la mise en ligne. |
| CSS et JavaScript bloqués | Le robot ne rend plus la page comme un visiteur ; rouvrir ces ressources. |
| Noindex écrit dans le fichier | Consigne ignorée par Google ; utiliser meta robots ou X-Robots-Tag. |
| Page bloquée puis passée en noindex | La balise n’est jamais lue ; laisser la page explorable. |
| Crawl-delay pris pour un frein | Google n’en tient pas compte ; agir sur le serveur ou la structure. |
| Fichier très volumineux | Au-delà d’environ 500 Kio, le reste est ignoré ; regrouper les motifs. |
Bloquer les fichiers CSS et JavaScript
Beaucoup de fichiers anciens interdisent les dossiers de scripts et de feuilles de style, par réflexe d’économie d’exploration. Or Google affiche les pages à la manière d’un navigateur : privé de ces ressources, il voit une page sans mise en forme, parfois sans le contenu injecté par JavaScript, et son jugement sur l’affichage mobile s’en ressent. La règle de prudence consiste à laisser accessibles les ressources nécessaires au rendu et à réserver Disallow aux zones qui n’apportent rien au moteur : administration, panier, recherche interne, identifiants de session. L’inspection d’URL de la Search Console montre la page telle que Google la reconstitue.
Noindex dans robots.txt : une consigne qui n’existe plus
Pendant longtemps, certains sites ont écrit des lignes Noindex dans robots.txt, et quelques outils les ont tolérées. Depuis 2019, Google ne prend plus en charge cette directive : elle reste sans effet sur l’index. L’erreur voisine consiste à bloquer une page avec Disallow, puis à lui ajouter une balise noindex pour doubler la sécurité. Comme le robot n’ouvre pas la page, il ne voit jamais la balise, et l’adresse peut rester connue du moteur. Le choix tient en une alternative : on autorise l’exploration et l’on pose noindex dans la page ou dans l’en-tête X-Robots-Tag, ou bien on bloque en acceptant que l’adresse reste visible.
Crawl-delay et taille du fichier : deux limites à connaître
La directive crawl-delay, qui demande au robot de patienter entre deux requêtes, est comprise par certains moteurs, mais Google ne l’applique pas. Compter dessus pour ralentir Googlebot est donc inutile : si l’exploration met réellement un serveur en difficulté, c’est sa capacité et la structure du site qu’il faut traiter. Autre limite : Google ne lit qu’environ les 500 premiers Kio du fichier et ignore le reste. Un fichier qui énumère des milliers d’adresses une par une approche ce plafond sans raison valable ; mieux vaut regrouper les règles par motifs, avec des jokers, et supprimer celles qui visent des pages disparues depuis longtemps du site.
Tester, déployer et surveiller son fichier robots.txt
Écrire des règles justes ne suffit pas : le fichier vit sur un site qui change, et c’est lors des mises en production que les accidents arrivent. La méthode tient en trois temps, qui forment un cycle plus qu’une liste de tâches : tester avant de publier, déployer proprement, puis surveiller ce que Google a réellement compris. Le schéma ci-dessous donne un repère simple pour trancher le sort de chaque chemin avant d’ouvrir le fichier, et les paragraphes suivants montrent où contrôler, quand relire et comment éviter la dérive silencieuse. Ce contrôle prend peu de temps lorsqu’il est intégré à la routine de livraison.
Le rapport robots.txt de la Search Console
La Search Console propose un rapport robots.txt dédié. Il liste les fichiers que Google a trouvés pour chaque hôte du site, indique leur dernière exploration et leur état, puis signale erreurs et avertissements ; une nouvelle exploration peut y être demandée après une correction. Pour une adresse précise, l’inspection d’URL dit si l’exploration est autorisée, et le rapport d’indexation des pages affiche le statut des adresses bloquées par le fichier. Ces écrans se complètent : le premier valide la lecture du fichier, le deuxième contrôle une page, le troisième mesure l’ampleur d’un blocage sur l’ensemble du site, sans quitter la Search Console.
- Rédiger en préproductionÉcrire les règles dans un fichier de travail, relu par une seconde personne.
- Tester les adresses clésVérifier qu’une page stratégique reste autorisée et qu’une page à exclure est bien bloquée.
- Déployer à la racinePublier le fichier à l’adresse /robots.txt et contrôler la réponse du serveur.
- Surveiller dans la Search ConsoleOuvrir le rapport robots.txt, puis demander une nouvelle exploration au besoin.
Une relecture à chaque mise en production
Les pires accidents viennent d’un transfert involontaire : le fichier de préproduction, qui interdit tout pour protéger un site de test, est copié en production lors d’une livraison. Pour l’éviter, traitez le fichier comme du code : versionner le fichier dans le dépôt du projet, comparer l’ancienne et la nouvelle version à chaque livraison, inscrire sa vérification dans la liste de contrôle de mise en ligne de l’équipe. Une refonte, une migration de domaine ou la création d’un sous-domaine imposent de le revoir, hôte par hôte. Cette discipline coûte quelques minutes et épargne souvent des semaines de pages absentes des résultats de recherche.
Surveiller dans la durée sans se disperser
Une fois le fichier en place, la surveillance reste légère. Il suffit de consulter à intervalles réguliers le rapport robots.txt et le rapport d’indexation, en cherchant deux signaux : une page importante classée comme bloquée, ou une hausse soudaine du nombre d’adresses exclues. Les journaux du serveur, quand ils sont accessibles, montrent ce que les robots demandent réellement. En cas d’alerte, la correction suit toujours le même ordre : retirer la règle fautive, republier, demander une nouvelle exploration, vérifier quelques adresses. Un suivi du code de réponse du fichier complète ce contrôle. Le quiz ci-dessous remet en jeu quatre idées reçues rencontrées dans ce guide.
Vrai ou faux ?
Une page interdite par robots.txt disparaît toujours des résultats.
Le fichier gère l’exploration, pas l’index : une adresse interdite mais citée par d’autres pages peut rester affichée, sans description. Pour sortir de l’index, utilisez noindex sur une page explorable.
Google ignore la directive crawl-delay.
Certains moteurs la lisent, pas Google. Pour alléger la charge d’un serveur, agissez sur ses capacités plutôt que sur cette ligne.
Un noindex écrit dans robots.txt suffit à désindexer une page.
Google ne prend plus en charge cette directive depuis 2019. La consigne doit figurer dans la page (meta robots) ou dans l’en-tête X-Robots-Tag.
Une page doit rester explorable pour que Google lise son noindex.
Si robots.txt bloque la page, le robot ne l’ouvre pas et ne voit jamais la balise : la consigne reste lettre morte.
Faut-il déclarer son sitemap dans robots.txt ?
Ce n’est pas obligatoire, mais c’est pratique. Une ligne Sitemap avec l’adresse complète du fichier permet à tous les robots qui lisent robots.txt de le trouver, en plus de la soumission dans la Search Console. Le sitemap aide à la découverte des pages ; il n’influence pas le classement.
Que se passe-t-il si le site n’a pas de fichier robots.txt ?
Si le serveur répond par une erreur 404, les robots en déduisent que rien n’est interdit et explorent librement, sans pénalité. Un fichier minimal reste pourtant utile pour déclarer le sitemap et marquer les zones à éviter, à condition que le serveur ne renvoie pas d’erreur persistante.
Peut-on bloquer les robots d’IA avec robots.txt ?
Oui, en visant leurs identifiants dans un groupe user-agent, quand l’éditeur en publie. Le contrôle repose sur le respect volontaire du robot : ce n’est pas une barrière technique. Le jeton Google-Extended encadre l’usage des contenus par certains produits d’IA de Google, sans effet sur l’indexation dans Search.
À lire aussi dans la même rubrique
Comment améliorer ses Core Web Vitals sans se tromper de priorité ?
Core Web Vitals : ce que mesurent le LCP, l’INP et le CLS, comment lire les données de terrain et dans quel ordre corrig…
Comment poser des données structurées utiles sur son site ?
Données structurées : quels balisages schema.org poser, comment les écrire en JSON-LD, les tester et éviter les erreurs…
Comment bâtir un maillage interne réellement utile ?
Maillage interne : logique de silo, ancres, profondeur de clic et pages orphelines. La méthode pour cartographier ses li…