Mettre en place un fichier robots.txt efficace : le guide qui change tout

Un client m'appelle, affolé. Son trafic organique a chuté de 40 % en trois semaines. On regarde la Search Console ensemble, et là, le couperet : « Explorée, actuellement non indexée » sur des dizaines de pages qui, la veille encore, généraient des demandes de devis. La cause ? Une ligne ajoutée dans le robots.txt par un prestataire pressé, qui n'a jamais pris la peine de tester. Une seule ligne. Trois semaines de perte sèche.

C'est l'histoire la plus banale du monde, et c'est précisément pour ça qu'elle mérite un article. Le fichier robots.txt passe pour une formalité technique, un fichier que tout le monde a et que personne ne relit. En réalité, c'est l'un des rares éléments de votre site capable de détruire votre visibilité en une nuit, sans erreur serveur, sans alerte, sans que rien ne clignote en rouge.

Mettre en place un fichier robots.txt efficace ne consiste pas à recopier un modèle trouvé sur un forum. C'est décider, ligne par ligne, de ce que les robots d'exploration ont le droit de voir chez vous. Et cette décision a des conséquences.

À quoi sert vraiment le fichier robots.txt (et pourquoi on lui prête trop de pouvoir)

Un fichier robots.txt, c'est quoi exactement ? Un simple fichier texte, à la racine de votre domaine, qui s'adresse aux robots d'exploration. Il leur dit, en substance : « ici tu peux aller, là tu ne peux pas ». Il repose sur une poignée de directives et rien de plus.

Exploration n'est pas indexation

La confusion la plus répandue tient en une phrase : bloquer une URL dans le robots.txt n'empêche pas son indexation. Elle empêche son exploration. Nuance énorme.

Concrètement : si des liens pointent vers une page bloquée, Google peut la découvrir, la connaître, et l'inscrire dans l'index sans jamais avoir lu son contenu. Résultat visible dans les résultats de recherche : une URL affichée avec un titre vide et aucune description. J'ai vu cette configuration sur le site d'un cabinet d'avocats, persuadé d'avoir « caché » ses pages de tarifs. Elles étaient indexées, juste amputées de leur contenu. L'inverse de ce qu'il cherchait.

Pour empêcher une page d'apparaître, il faut la balise noindex dans le code HTML de la page. Et pour que Google puisse lire cette balise, il doit pouvoir explorer la page. Donc : ne la bloquez surtout pas dans le robots.txt.

Pourquoi optimiser l'exploration change les choses

Les robots disposent d'un volume d'exploration limité par site. Sur un catalogue de 30 000 produits, ce volume part vite. Si vous le gaspillez sur des pages de panier, des résultats de recherche interne ou des paramètres de tri à l'infini, il reste moins de ressources pour les pages qui comptent.

Sur un site e-commerce que j'accompagne, nous avons bloqué les URL de filtres à facettes. En quelques semaines, les pages catégories importantes ont été explorées bien plus régulièrement. Le nombre de produits indexés n'a pas changé d'un pouce, mais leur fraîcheur dans l'index, si. Et sur un catalogue, c'est la fraîcheur qui fait la différence quand un prix change tous les mardis.

Créer un fichier robots.txt : la syntaxe exacte, cas par cas

La syntaxe tient en quelques mots-clés. Le piège n'est pas là. Le piège est de croire qu'on peut improviser.

Le bloc de base, copiable tel quel

Voici le socle minimal que je recommande pour un site classique :

User-agent: *
Disallow:
Sitemap: https://www.votre-domaine.fr/sitemap.xml

Un Disallow: vide signifie « tout est autorisé ». C'est explicite, lisible, et ça évite les surprises. Notez que User-agent s'écrit avec une majuscule à chaque mot et un trait d'union, que chaque directive tient sur une seule ligne, et que les commentaires commencent par un #.

Bloquer des zones précises sans casser le reste

Un exemple très concret pour une boutique en ligne :

User-agent: *
Disallow: /panier/
Disallow: /commande/
Disallow: /recherche
Allow: /recherche/guide-achat
Sitemap: https://www.exemple.fr/sitemap.xml

Le joker remplace n'importe quelle suite de caractères. Le symbole $, lui, marque la fin d'une URL. Donc Disallow: /.pdf$ bloque toutes les URL finissant par .pdf, mais pas /dossier.pdf.html.

Et Crawl-delay ? Je le mentionne pour mémoire, mais sachez que Google l'ignore. Si vous avez un problème de charge serveur, la bonne réponse s'appelle la gestion de la fréquence d'exploration dans votre console de recherche, pas un Crawl-delay.

Où placer le fichier, exactement

Le fichier doit être accessible à cette adresse, et à celle-là uniquement : votre-domaine.fr/robots.txt. Pas dans un sous-dossier, pas dans /public/ si votre serveur ne le sert pas à la racine. Un fichier nommé robot.txt sans le « s » est tout simplement ignoré. J'ai perdu une demi-journée là-dessus au tout début de ma carrière, persuadé que le fichier était mal écrit alors qu'il portait simplement le mauvais nom.

Les erreurs qui coûtent cher (je les ai vues, plusieurs fois)

Voici le tableau que j'aurais aimé recevoir à mes débuts. Il ne remplace pas la lecture, mais il cadre les risques.

Erreur	Conséquence réelle	Gravité
Disallow: / par accident	Plus aucune page explorée, désindexation progressive	Critique
Bloquer /wp-content/ ou /assets/	CSS et JS non lus, rendu des pages cassé	Élevée
Bloquer une page qu'on veut voir indexée	URL indexée sans contenu, titre vide	Élevée
Fichier dans un sous-dossier	Fichier invisible, règles ignorées	Moyenne
Croire protéger des pages sensibles	Données exposées à qui lit l'URL	Critique (sécurité)

Le Disallow: / qui tue le site

C'est l'erreur numéro un, et elle arrive généralement sur un environnement de préproduction qu'on recopie en production. Une ligne, un déploiement, et le site disparaît des résultats. Le délai de rétablissement n'est pas immédiat : comptez plusieurs jours avant un retour à la normale, parfois davantage sur un gros site.

La parade est simple et je ne m'en passe plus : on annote le fichier. Une ligne # BLOQUANT : à retirer avant mise en production juste au-dessus du Disallow: / de votre environnement de test. Un humain pressé lit un commentaire en majuscules.

Bloquer le CSS et le JavaScript

Google a besoin d'accéder aux ressources de rendu pour comprendre à quoi ressemble votre page. Bloquer un dossier d'assets revient à demander à Google de juger un site qu'il voit sans mise en forme. Les conséquences sont difficiles à diagnostiquer, car rien n'indique explicitement la cause dans votre console. C'est un problème silencieux, et les problèmes silencieux sont les pires.

Le cas WordPress (et les autres CMS)

Depuis l'administration de WordPress, le fichier est virtuel par défaut. Le modifier directement nécessite soit de le faire via FTP ou le gestionnaire de fichiers de votre hébergeur, soit de passer par une extension dédiée si vous voulez une interface. Attention aux extensions de SEO qui réécrivent le fichier à leur manière : si vous éditez le fichier à la main en parallèle, vos changements peuvent disparaître à la première mise à jour de l'extension. J'ai vu un fichier repasser en version par défaut sans prévenir pendant un week-end. Sympa.

Comment tester et valider un fichier robots.txt (la seule étape non négociable)

Un fichier non testé est un fichier qui n'existe pas. Trois vérifications, dans cet ordre.

Le test avant mise en ligne

Ouvrez une page de votre site bloquée par vos nouvelles règles. Dans l'outil d'inspection d'URL de la Search Console, demandez l'analyse de l'URL. Vous verrez immédiatement si elle est explorable ou non, et la cause exacte. Faites-le sur au moins trois URL critiques : une page d'accueil, une page catégorie, un produit.

Le rapport dédié et les logs

La Search Console propose un rapport spécifique qui liste les règles détectées et les erreurs de syntaxe. C'est là que vous verrez si une directive est mal orthographiée. Complétez avec les logs serveur : si des requêtes sur /robots.txt reviennent en 404, votre fichier n'est pas au bon endroit, point final. C'est le test le plus direct et le plus fiable, et paradoxalement le moins utilisé.

Dernier réflexe : testez aussi votre fichier en lecture publique, dans un navigateur en navigation privée, à l'adresse exacte. Si vous voyez votre bloc de texte, le fichier est bien servi. Si vous voyez une page d'erreur ou la page d'accueil de votre site, arrêtez tout.

Ce que le robots.txt ne fera jamais pour vous

Il y a une croyance tenace : le robots.txt protégerait les données sensibles. Non. Le fichier est public, n'importe qui peut le lire, et il ne bloque que les robots bien élevés. Un robot malveillant, un scraper, un concurrent curieux : tous ignorent vos directives sans le moindre scrupule.

Une page de facturation, un export de clients, un dossier d'archives confidentielles : la seule protection acceptable est une authentification côté serveur, un mot de passe, un contrôle d'accès. Le robots.txt n'est pas un cadenas. C'est un panneau indicateur. Et personne n'est obligé de le respecter.

Cela dit, il reste un outil précieux. Bien rédigé, il oriente vos robots vers les pages utiles, il économise votre budget d'exploration, il évite les doublons générés par les paramètres d'URL. C'est un outil d'hygiène, pas de sécurité. Faites-lui confiance pour le premier rôle, jamais pour le second.

Ce que je retiens de toutes ces années, c'est que le robots.txt est le seul fichier de votre site où une ligne de trop peut coûter des semaines de visibilité, et où une ligne oubliée peut laisser traîner des milliers de pages inutiles dans l'index. Deux lettres de différence entre « allons-y » et « stop ». Alors avant de valider, posez-vous une question simple : êtes-vous capable d'expliquer, à voix haute, ce que fait chaque ligne ? Si la réponse est non pour une seule d'entre elles, vous n'avez pas fini le travail.