Un fichier de trois lignes. C'est tout ce qu'il faut pour faire disparaître un site entier de Google pendant huit jours. Je l'ai vécu sur un e-commerce client, il y a un peu plus de deux ans : une mise en production un vendredi soir, un Disallow: / laissé en place depuis un test de staging, et le lundi matin, le patron m'appelle parce que les commandes ont chuté de 60 %. Le fichier robots.txt, c'est la pièce la plus banale et la plus dangereuse d'un site web.
Points clés à retenir
- Le robots.txt gère le crawl, jamais l'indexation. Pour retirer une page des résultats, il faut une balise
noindex. - Une erreur de syntaxe peut bloquer des pages publiques sans que personne ne s'en aperçoive pendant des semaines.
- Le piège numéro un reste le
Disallow: /oublié après un test. - Un
robots.txtet unnoindexsur la même page ne fonctionnent pas ensemble : si le bot est bloqué, il ne lit jamais la balise. - Le diagnostic prend dix minutes dans la Search Console. La réindexation, elle, peut prendre des semaines.
Le fichier robots.txt : ce qu'il fait vraiment (et ce qu'on lui prête à tort)
Le robots.txt est un fichier texte placé à la racine d'un domaine, dont le rôle est d'indiquer aux robots d'exploration quelles URL ils peuvent parcourir. C'est le standard historique du web, aujourd'hui formalisé par la RFC 9309, qui fixe enfin noir sur blanc les règles du jeu : ordre de lecture, jokers, sensibilité à la casse. Pendant vingt ans, chaque moteur faisait un peu ce qu'il voulait. Ce n'est plus le cas.
Voilà la nuance que la plupart des articles ratent : ce fichier n'empêche pas l'indexation. Il empêche le crawl. Nuance capitale, et c'est exactement le genre de détail qui coûte cher.
Robots.txt ou noindex : il faut choisir
La confusion la plus fréquente que je rencontre chez mes clients : « J'ai mis la page en Disallow, elle va disparaître de Google ? » Non. Une URL bloquée au crawl peut toujours apparaître dans les résultats, avec un extrait vide ou un titre générique. Google l'a découverte ailleurs — un lien externe, un sitemap orphelin, un partage sur un réseau — et il l'affiche quand même. Pour sortir une page des résultats, il faut la laisser crawlable et y poser une balise noindex. Les deux mécanismes ne se cumulent pas.
C'est même un piège vicieux : si vous bloquez une page en Disallow et que vous y ajoutez un noindex, le robot n'atteindra jamais la page pour lire la balise. Le noindex devient invisible. J'ai vu un site garder des pages de test dans les résultats pendant onze mois à cause de ce montage.
Syntaxe : les directives qui comptent, et dans quel ordre
Un robots.txt correct tient en quelques lignes. Les directives principales sont au nombre de quatre, et une cinquième circule encore alors qu'elle n'est respectée par aucun moteur majeur.
User-agent: à qui s'adresse la règle.*pour tout le monde, ou un nom précis commeGooglebot.Disallow: ce qu'on interdit.Allow: ce qu'on autorise, utile pour rouvrir une exception dans un dossier bloqué.Sitemap: l'URL absolue de votre plan de site. Simple, ignoré par une majorité de sites, et pourtant bien pratique.Crawl-delay: à oublier. Google ne le lit plus depuis des années, la cadence se gère dans la Search Console.
Les jokers * et $ changent tout
La RFC 9309 a clarifié deux caractères que peu de gens maîtrisent. L'astérisque * remplace n'importe quelle séquence de caractères. Le dollar $ marque la fin d'une URL.
Concrètement, Disallow: /*.pdf$ bloque tous les PDF du site, mais pas mon-fichier.pdf.html. Sans le $, la règle serait trop large. Et attention à la casse : les chemins d'URL sont sensibles à la casse, contrairement aux noms de user-agent.
Autre point que j'ai mis du temps à intégrer : la règle la plus spécifique l'emporte. Si vous avez un Disallow: /dossier/ et un Allow: /dossier/page-publique, cette page reste explorable. L'ordre dans le fichier n'a pas d'importance, c'est la longueur du chemin qui décide. Ça m'a coûté une demi-journée de test la première fois.
Les erreurs que je vois le plus souvent (et celle que j'ai commise)
Le Disallow: / oublié après un test. C'est l'erreur numéro un, et celle dont on se rend compte trop tard. Un staging bloqué à la racine, un fichier copié tel quel en production, et tout le site sort du crawl. Chez Google, la disparition n'est pas immédiate — comptez quelques jours avant que le trafic ne s'effondre. La détection, elle, peut prendre une semaine.
Le slash manquant est le cousin de cette erreur. Disallow: admin ne bloque pas /admin/. Il bloque toutes les URL contenant « admin » à cet endroit précis, ce qui donne des résultats absurdes. Un seul caractère, un comportement complètement différent.
Et puis il y a le cas que j'ai vécu : un fichier valide en apparence, mais avec un User-agent en majuscules mal orthographié. Le robot n'a pas matché la règle, l'a ignorée, et a exploré des pages qu'on voulait cacher. Pas de catastrophe, mais un vrai nettoyage de printemps quelques semaines plus tard.
Un robots.txt invalide, ça ressemble à quoi ?
Lighthouse remonte deux avertissements distincts : « robots.txt non valide » et « robots.txt bloque l'exploration ». Le premier signale une syntaxe cassée — un deux-points manquant, un espace dans une URL, une directive inconnue. Le second est plus grave : il détecte qu'une ressource critique pour le rendu est bloquée.
Le fichier est tolérant. Une ligne incomprise est ignorée, pas le reste du fichier. C'est précisément ce qui rend les erreurs silencieuses : le site continue de fonctionner, l'exploration continue, mais pas comme prévu.
Diagnostiquer et réparer : la procédure qui marche
La Search Console propose un rapport dédié et un test en direct. Le test en direct est l'outil le plus utile que je connaisse : il teste une URL contre votre fichier actuel, sans toucher à l'index.
- Ouvrez le rapport robots.txt dans la Search Console. S'il affiche une erreur de récupération, le fichier est inaccessible ou mal renvoyé (code 500, redirection).
- Utilisez le test en direct sur une URL critique. La réponse vous dit quelle règle s'applique, et laquelle.
- Si vous avez bloqué par erreur, corrigez le fichier et republiez. Google recrawle le robots.txt sous quelques heures en général.
- Pour accélérer la réindexation, soumettez à nouveau votre sitemap et demandez une inspection d'URL sur les pages clés. Ça ne garantit rien, mais ça aide.
Ne comptez pas sur une réindexation en vingt-quatre heures. Sur le site que j'évoquais en ouverture, il a fallu dix-neuf jours pour retrouver le niveau de trafic d'avant. Dix-neuf jours pour trois lignes de texte.
Les bonnes pratiques qui tiennent dans le temps
Un fichier robots.txt, ça se documente. J'ai pris l'habitude de commenter chaque bloc avec une date et une raison, dans le fichier lui-même : le # est là pour ça. Six mois plus tard, personne ne se souvient pourquoi telle règle existe.
| Pratique | Pourquoi ça compte |
|---|---|
| Un robots.txt par environnement | Éviter la copie staging → production, la source de l'erreur numéro un |
| Un test automatisé avant mise en production | Détecter un Disallow: / avant qu'il ne fasse des dégâts |
| Le sitemap déclaré dans le fichier | Aide les moteurs à découvrir les pages récentes |
| Les commentaires datés | Savoir dans six mois pourquoi une règle existe |
| Une revue annuelle | Nettoyer les règles obsolètes, vérifier les nouvelles pages sensibles |
Et un point que je répète à chaque audit : ne bloquez jamais un dossier entier « au cas où ». Chaque règle doit répondre à un besoin identifié. Les robots.txt les plus dangereux sont les plus longs. Trois lignes bien pensées battent cinquante lignes héritées d'un ancien prestataire.
Ce fichier n'a pas vocation à protéger quoi que ce soit. Il demande poliment. Un robot mal intentionné l'ignorera sans scrupule, et un concurrent curieux aussi. Pour la confidentialité, la vraie, c'est mot de passe, en-têtes HTTP ou pare-feu applicatif. Le robots.txt, lui, reste ce qu'il a toujours été : une convention de courtoisie entre un site et des robots.
La prochaine fois que vous ouvrirez ce fichier pour y toucher, relisez-le deux fois. Trois lignes suffisent à faire tomber un chiffre d'affaires.
