Le robots.txt est un fichier texte placé à la racine du site qui indique aux robots des moteurs quelles zones ils peuvent explorer et lesquelles ils doivent laisser de côté. Il pilote l'exploration (le crawl), pas l'indexation : ce n'est pas l'outil pour cacher une page des résultats de recherche, et une ligne mal écrite peut rendre un site entier invisible.
Un panneau de signalisation à l'entrée du site
Le robots.txt est un simple fichier texte, posé à la racine du domaine, accessible à l'adresse votre-site.fr/robots.txt. N'importe qui peut l'ouvrir dans son navigateur, y compris vos concurrents. Ce n'est ni un mot de passe, ni un pare-feu.
Son rôle : quand un robot d'exploration (Googlebot, Bingbot, et des dizaines d'autres) arrive sur votre site, il consulte ce fichier en premier, avant toute autre URL. Il y lit les règles que vous avez écrites et décide où il a le droit d'aller. C'est un panneau de signalisation, pas une barrière : les robots sérieux le respectent, les aspirateurs de contenu s'en moquent complètement. Le protocole a une trentaine d'années et il est resté volontairement rudimentaire, quelques lignes de texte suivies par bonne volonté.
Ce qu'il pilote vraiment : l'exploration, pas l'indexation
C'est le point que tout le monde confond, et il vaut le détour parce qu'il change complètement la façon d'utiliser ce fichier.
Google travaille en deux temps distincts. D'abord il explore : le robot télécharge la page pour en lire le contenu. Ensuite il indexe : il décide de stocker cette page dans sa base pour éventuellement l'afficher dans les résultats. Le robots.txt n'agit que sur la première étape.
La conséquence est contre-intuitive. Si vous bloquez une page dans le robots.txt alors que d'autres sites pointent vers elle, Google peut très bien l'afficher quand même dans ses résultats, avec une URL nue et un descriptif du type « aucune information disponible pour cette page ». Il sait qu'elle existe grâce aux liens, mais il n'a pas eu le droit d'aller lire ce qu'il y a dedans. Résultat : le pire des deux mondes, la page apparaît et elle est moche.
Pour empêcher réellement une page de sortir dans les résultats, l'outil correct est la balise meta robots en noindex, ou un en-tête HTTP X-Robots-Tag. Et il y a un piège logique à connaître : une page bloquée dans le robots.txt ne peut pas être lue, donc Google ne verra jamais votre balise noindex. Les deux méthodes se neutralisent l'une l'autre. Pour désindexer une page, on la laisse accessible au crawl et on lui met un noindex, jamais un blocage robots.txt.
La documentation de Google sur le robots.txt insiste d'ailleurs lourdement sur cette distinction, c'est dire si l'erreur est répandue.
La syntaxe utile, en cinq lignes
Pas besoin d'être développeur. Le fichier fonctionne par blocs : on désigne un robot avec User-agent, puis on liste ce qu'on lui interdit avec Disallow, ou ce qu'on lui autorise avec Allow.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://votre-site.fr/sitemap_index.xmlL'étoile signifie « tous les robots ». Le bloc ci-dessus ferme l'administration WordPress tout en laissant passer le fichier technique dont le site a besoin pour fonctionner. La dernière ligne indique l'emplacement du sitemap XML, une habitude à prendre : c'est un des moyens par lesquels les moteurs découvrent l'ensemble de vos URL.
Deux détails qui font tomber beaucoup de monde. Le chemin est sensible à la casse : /Blog/ et /blog/ sont deux règles différentes. Et une ligne Disallow suivie d'une barre oblique seule, donc Disallow: /, bloque la totalité du site. Cette ligne est la cause numéro un des catastrophes de trafic après une mise en ligne, on y revient plus bas.
Vous pouvez aussi cibler un robot précis en remplaçant l'étoile par son nom, par exemple pour laisser Googlebot tranquille et brider un crawler tiers qui tape trop fort sur votre serveur. Le site de référence du protocole, robotstxt.org, recense la syntaxe historique et les noms d'agents les plus courants.
Son intérêt SEO réel : économiser le budget d'exploration
Voilà la vraie raison de s'y intéresser. Google ne crawle pas votre site à l'infini : il alloue à chaque domaine une quantité de ressources d'exploration, proportionnelle à sa taille, à sa popularité et à la santé de son serveur. C'est ce qu'on appelle le budget de crawl.
Sur un site vitrine de quinze pages, ce budget n'est jamais un sujet. Sur un e-commerce avec des filtres à facettes qui génèrent des milliers d'URL combinatoires (couleur, taille, prix, tri par pertinence), ça devient central : le robot passe ses journées sur des variantes sans intérêt pendant que vos nouvelles fiches produit attendent leur tour. Bloquer les paramètres inutiles redirige l'attention du robot vers ce qui compte. Sur une boutique en ligne, c'est un des premiers points que je vérifie, avant même de toucher au contenu.
Autres usages sains : fermer les pages de recherche interne, les paniers, les espaces membres, les fichiers de préproduction. Rien de tout ça n'a vocation à être exploré.
En revanche, si une page traîne à entrer dans l'index, le robots.txt n'est presque jamais le bon levier de correction. Les vrais accélérateurs sont ailleurs, et je les détaille dans mon guide sur la façon de faire indexer une page rapidement par Google.
Les erreurs que je croise le plus souvent en audit
Elles reviennent toujours, quel que soit le CMS.
- Le blocage total oublié après une refonte. Le site est en préproduction avec Disallow: /, il passe en ligne, personne ne retire la ligne. Le trafic organique s'effondre en quelques semaines. Ça arrive à des équipes très compétentes, y compris sur de gros sites.
- Bloquer les fichiers CSS et JavaScript. Google a besoin d'afficher la page comme un vrai visiteur pour juger son rendu et son comportement mobile. Lui interdire ces ressources revient à lui montrer un site cassé.
- Utiliser le robots.txt pour cacher une page confidentielle. Non seulement le fichier est public (vous indiquez donc l'adresse de ce que vous vouliez cacher), mais la page reste accessible à qui connaît l'URL. Un contenu sensible se protège par mot de passe, point.
- Bloquer une URL puis se demander pourquoi la balise noindex ne fait rien. Le cas dont on parlait plus haut.
- Le fichier placé dans un sous-dossier. Il doit être à la racine exacte du domaine, sinon il est purement et simplement ignoré.
Ces vérifications font partie de la routine de base, au même titre que les redirections ou les balises canoniques : j'ai regroupé l'essentiel dans les dix points d'audit technique à contrôler quand on démarre.
Comment le vérifier sans risque
Commencez par le plus simple : tapez votre-site.fr/robots.txt dans un navigateur. Si vous obtenez une erreur 404, ce n'est pas grave en soi (un site sans robots.txt est intégralement explorable, ce qui est souvent le comportement souhaité pour un petit site). Si vous voyez un Disallow: / seul, vous venez de trouver votre problème.
Ensuite, Google Search Console affiche l'état du fichier tel que le moteur l'a lu, avec sa date de dernière récupération et les éventuelles erreurs de syntaxe. L'inspection d'URL vous dit aussi, page par page, si une exploration a été bloquée par le robots.txt. Si vous ne l'utilisez pas encore, j'explique dans un autre article tout ce que cet outil gratuit permet de surveiller.
Un dernier conseil : sur un site qui tourne bien, ne touchez à ce fichier qu'avec une raison précise et une copie de la version précédente sous le coude. Trois caractères mal placés peuvent effacer des années de travail, alors qu'une règle bien pensée fait gagner, au mieux, un peu de confort d'exploration.
