Fichier robots.txt : les bonnes pratiques pour bien le configurer

Un client m'appelle un mardi matin, paniqué. Son site de e-commerce a disparu de Google. Pas pénalisé, non. Disparu. Plus une seule page dans l'index depuis trois semaines. On passe une heure au téléphone à chercher la cause — balises noindex, balises canonical, redirections… rien. Puis je demande à voir son fichier robots.txt. Et là, en deuxième ligne : Disallow: /. Son stagiaire, un vendredi après-midi, avait voulu "bloquer les robots" en attendant la mise en production. Il avait oublié de l'enlever. Trois semaines de chiffre d'affaires à zéro pour une barre oblique.

Voilà pourquoi je considère le fichier robots.txt comme le document le plus dangereux d'un site web. Cinq lignes suffisent à tuer un référencement. Cinq lignes suffisent aussi à économiser des gigas de bande passante. Tout dépend de la façon dont vous l'écrivez — et des bonnes pratiques que vous respectez ou non.

Robots.txt, c'est quoi au juste — et pourquoi ce n'est pas un outil d'indexation

Un fichier robots.txt est un fichier texte brut, hébergé à la racine de votre domaine, qui indique aux robots d'exploration quelles parties de votre site ils peuvent parcourir. C'est un peu comme un panneau "sens interdit" planté à l'entrée d'un parking. Le robot Googlebot arrive, lit le panneau, et décide s'il entre ou pas.

Ce qui surprend la plupart des gens que je forme : ce panneau s'adresse aux véhicules, pas au service de voirie. Autrement dit, empêcher un robot de crawler une URL ne l'empêche pas de l'indexer si un lien externe pointe vers elle. Google peut parfaitement afficher une page dans ses résultats avec un titre générique et un extrait vide, faute d'avoir pu lire le contenu.

Exploration et indexation : deux mécanismes distincts

J'ai vu des dizaines de webmasters confondre les deux. Ils bloquent une page de test avec Disallow, puis s'étonnent de la retrouver dans les SERP. La règle est pourtant simple :

• Robots.txt → contrôle ce que le robot peut lire.
• Balise meta robots noindex → contrôle ce que le moteur peut afficher.
• Pour retirer une page de l'index, il faut combiner les deux dans le bon ordre : laisser le robot lire la page d'abord, puis appliquer le noindex.

Si vous bloquez l'exploration avant de poser le noindex, Googlebot ne verra jamais la balise, et la page restera coincée dans un état bizarre : présente dans l'index, mais sans contenu lisible. Une purge qui prend des mois.

Exemple de fichier robots.txt : à quoi ressemble un fichier propre

Le fichier le plus courant tient en trois lignes. Voici celui que je déploie sur la majorité des sites vitrines que je gère :

User-agent: *
Disallow: /admin/
Disallow: /panier/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://exemple.com/sitemap.xml

Concrètement, chaque directive a une fonction précise :

• User-agent: * cible tous les robots. Une étoile = "tout le monde".
• Disallow: /admin/ bloque les URL commençant par /admin/. Pas besoin d'être exhaustif sur les sous-dossiers : la règle s'applique en préfixe.
• Allow autorise une exception dans une zone bloquée. Utile pour rouvrir un fichier précis, comme l'endpoint AJAX de WordPress.
• Sitemap pointe vers le plan du site. Google recommande explicitement de le déclarer ici.

Un détail que j'ai mis du temps à comprendre : l'ordre des directives Allow et Disallow n'a pas d'importance. C'est la longueur du chemin qui décide. En cas de conflit, la règle la plus spécifique gagne. J'ai perdu une demi-journée à réordonner des lignes avant de tomber sur cette règle. Totalement inutile, donc.

Comment tester un fichier robots.txt avant de le mettre en ligne

Toujours tester avant publication. Le principe : ouvrir votresite.com/robots.txt dans un onglet privé, puis coller une URL du site dans le rapport de couverture d'un outil de validation. Ceux qui n'ont pas d'accès à Search Console peuvent utiliser un validateur en ligne — j'en utilise un vieux qui traîne depuis des années et qui fonctionne toujours.

Ma règle personnelle : jamais de modification directe sur la production. Je teste sur un environnement de staging, je copie le fichier validé, et je le pousse une fois qu'il ne reste plus aucune erreur. Cela m'a évité plusieurs incendies.

Les erreurs que je vois le plus souvent (et comment les repérer)

Sur les 40 derniers audits que j'ai réalisés, deux sites sur trois avaient au moins un problème dans leur robots.txt. Voici le top des conneries, classées par gravité.

Erreur	Conséquence	Diagnostic
Disallow: / par oubli	Site entièrement désindexé	Recherche site:domaine.com renvoie zéro résultat
Blocage du CSS et JS	Google rend mal la page, chute du classement	Rapport "Ressources bloquées" dans l'outil de validation
Fichier placé dans un sous-dossier	Le robot ne le trouve pas, comportement imprévisible	404 sur domaine.com/robots.txt
Blocage des paramètres d'URL dynamiques	Pages paginées ou filtrées exclues de l'exploration	Chute du nombre de pages indexées
Balisage HTML dans le fichier	Lignes ignorées silencieusement	Onglet Réseau du navigateur montre du texte brut uniquement

Le plus vicieux, c'est le blocage du CSS et du JavaScript. Google veut voir la page comme un utilisateur la voit. Si vous lui interdisez l'accès à /wp-content/themes/, il lit une page nue. Et une page nue, dans son évaluation, ressemble à du spam ou à du contenu pauvre. J'ai récupéré environ 35 % de trafic organique sur un site en réouvrant simplement les dossiers de thème et de plugins.

Comment trouver le fichier robots.txt d'un site

Il suffit de taper l'URL du domaine suivi de /robots.txt dans la barre d'adresse. Par exemple : https://lemonde.fr/robots.txt. Aucun outil, aucune extension. C'est la première chose que je regarde quand j'analyse un concurrent — cela m'apprend souvent où il cache ses sections sensibles, ou s'il laisse ses pages de recherche interne accessibles aux robots.

Fichier robots.txt sur WordPress : ce qui change

WordPress génère automatiquement un robots.txt virtuel. Sur une installation standard, vous ne verrez aucun fichier sur le serveur, mais si vous tapez votresite.com/robots.txt, vous tombez sur une version générée par le CMS. Ce comportement a une conséquence que beaucoup ignorent : si vous créez un fichier physique nommé robots.txt à la racine, il écrase la version virtuelle. Sinon, c'est la version de WordPress qui s'applique.

Deux options pour personnaliser :

1. Créer un fichier physique via FTP ou un gestionnaire de fichiers, en écrasant la génération automatique.
2. Utiliser un plugin SEO qui propose une interface d'édition — c'est plus confortable mais cela introduit une dépendance. Si le plugin est désactivé, la version virtuelle reprend la main et vos règles disparaissent.

Personnellement, je préfère le fichier physique. Rien à voir avec une quelconque supériorité technique : c'est juste que je dors mieux en sachant qu'aucune mise à jour de plugin ne peut modifier mes règles d'exploration. J'ai eu le cas il y a quelques années sur une boutique PrestaShop — un module mal écrit avait réécrit le robots.txt en pleine nuit. Le lendemain, le site était déréférencé. Ça marque.

Robots.txt et robots d'IA : le nouveau terrain de jeu

La question qui revient le plus souvent en formation en ce moment : faut-il bloquer GPTBot, ClaudeBot, PerplexityBot et consorts ? Ma réponse est nuancée. Bloquer ces robots signifie que votre contenu ne sera pas utilisé pour entraîner ou alimenter des modèles. Mais cela signifie aussi que vous disparaissez des réponses générées par ces outils — un canal de visibilité qui pèse de plus en plus lourd.

Pour un média, je comprends la position défensive. Pour une PME qui veut exister, je pense que bloquer est une erreur stratégique. C'est un avis personnel, je le défends.

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

Ce fichier bloque les deux robots nommés. Rien de sorcier. Mais réfléchissez à deux fois avant de l'écrire.

Ce que je retiens après toutes ces années

Un fichier robots.txt bien écrit, c'est trois qualités :

• Court — sous 50 lignes dans 99 % des cas. Un fichier de 400 lignes est un signal d'alarme.
• Testé — jamais publié sans validation préalable.
• Documenté — un commentaire (#) pour expliquer chaque règle inhabituelle. Mon futur moi me remercie à chaque audit.

La directive Crawl-delay mérite un mot : elle n'est pas reconnue par Googlebot. Elle fonctionnait avec Bing et Yandex, mais son usage est aujourd'hui déconseillé au profit du dosage de fréquence côté outil de gestion. Je l'ai longtemps utilisée par réflexe. Erreur.

Et pour clore : le fichier robots.txt n'est pas un dispositif de sécurité. Il repose sur la bonne volonté des robots. Les scrapers malveillants l'ignorent totalement. Si vous voulez protéger une zone sensible, un mot de passe ou une authentification serveur sont vos seuls vrais alliés.

Le fichier que vous écrivez aujourd'hui continuera d'agir pendant des mois. Faites-en sorte qu'il travaille pour vous, pas contre vous. Une barre oblique mal placée ne coûte rien à écrire. Elle peut coûter très cher à oublier.