Les 5 erreurs les plus fréquentes dans un robots.txt et comment les corriger
Un fichier robots.txt est d'une simplicité trompeuse. Quelques lignes de texte brut, aucun langage de programmation, aucune étape de compilation. Et pourtant, la majorité des sites WordPress livrent un robots.txt qui en fait trop peu, en fait trop, ou travaille activement contre leurs propres objectifs SEO.
Après avoir examiné des centaines de fichiers robots.txt sur des installations WordPress de toutes tailles, cinq erreurs reviennent systématiquement. Chacune est facile à commettre et étonnamment coûteuse à laisser en place.
1. Utiliser le robots.txt par défaut de WordPress sans modification
WordPress génère automatiquement un robots.txt minimal. Il contient typiquement deux lignes : une directive User-agent: * et un Disallow: /wp-admin/. C'est mieux que rien, mais ce n'est pas une politique de crawl. C'est un bouche-trou.
Le fichier par défaut ne dit rien sur les robots IA, rien sur les robots d'archivage, rien sur les outils SEO qui scrapent, et rien sur les dizaines de chemins internes WordPress qui génèrent du contenu dupliqué ou sans valeur. Laisser ce défaut en place, c'est comme laisser la porte d'entrée déverrouillée en partant du principe que seuls les amis entreront.
La correction : Remplacer le défaut par un robots.txt intentionnel qui reflète les besoins réels du site. Les presets de Better Robots.txt existent précisément pour ça : ils fournissent une politique fonctionnelle en quelques secondes, pas un point de départ vide.
2. Bloquer les fichiers CSS et JavaScript
Cette erreur a connu son apogée vers 2015, mais on la rencontre encore. Certains propriétaires de sites ajoutent Disallow: /wp-content/themes/ ou Disallow: /wp-includes/ en pensant cacher des ressources internes aux robots.
Le problème, c'est que Googlebot fait du rendu de page. Il charge le CSS et le JavaScript pour comprendre la mise en page, la hiérarchie du contenu et les signaux d'expérience utilisateur. Quand ces fichiers sont bloqués, Google ne peut pas afficher la page correctement. Le résultat : une indexation dégradée et, souvent, une baisse de positionnement.
La correction : Ne jamais bloquer les répertoires CSS ou JavaScript sauf en cas de raison spécifique et documentée. En cas de doute, utiliser l'outil d'inspection d'URL de Google Search Console pour voir ce que Google perçoit réellement.
3. Interdire des pages qu'on veut pourtant indexées
Ça semble évident, mais ça arrive plus souvent qu'on ne le croit. Un scénario classique : quelqu'un ajoute /category/ à sa liste d'interdictions parce qu'un article de blogue parlait de contenu mince. Six mois plus tard, il se demande pourquoi ses pages de catégories ont disparu des résultats de recherche.
Un autre cas fréquent : bloquer /page/ pour empêcher le crawl des archives paginées, sans réaliser que certains thèmes utilisent /page/ dans des chemins importants.
La correction : Avant d'ajouter toute règle Disallow, vérifier quelles URL correspondent au patron. Utiliser un outil de crawl ou simplement chercher site:votredomaine.com inurl:/category/ pour voir ce qui serait retiré. Un Disallow n'est pas une suggestion. C'est une instruction que les robots bien élevés suivent immédiatement.
4. Oublier la directive Sitemap
La directive Sitemap: dans le robots.txt indique aux robots où trouver le plan de site XML. Ce n'est pas techniquement une règle robots.txt — c'est une extension que tous les grands moteurs de recherche supportent. Et pourtant, un nombre surprenant de sites l'omettent.
Sans cette ligne, les robots découvrent le sitemap par Search Console, Bing Webmaster Tools, ou en devinant /sitemap.xml. Mais compter sur la découverte indirecte est fragile. La directive Sitemap: est le seul endroit dans le robots.txt où l'on dirige activement les robots vers du contenu au lieu de les en éloigner.
La correction : Ajouter une ligne Sitemap: en bas du robots.txt pointant vers l'URL principale du plan de site. Si le plugin SEO génère un index de sitemaps, pointer vers l'index, pas vers les sitemaps enfants individuels.
5. Traiter tous les robots de la même manière
C'est l'erreur la plus lourde de conséquences en 2026, et la moins abordée dans les guides SEO traditionnels.
Un seul bloc User-agent: * applique les mêmes règles à Googlebot, GPTBot, CCBot, Bytespider, AhrefsBot et tous les autres robots qui lisent le fichier. Mais ces robots ont des objectifs fondamentalement différents. Google indexe les pages pour la recherche. GPTBot peut utiliser le contenu pour l'entrainement ou la récupération. Les robots d'archivage prennent des instantanés. Les outils SEO scrapent des données concurrentielles. Les traiter tous de manière identique signifie qu'on ne peut pas fixer de limites différentes pour des usages différents.
La correction : Utiliser des blocs User-agent spécifiques pour les catégories qui comptent. Au minimum, séparer les moteurs de recherche, les robots IA et les mauvais robots connus en groupes distincts avec des règles distinctes. C'est le principe fondateur du système de presets de Better Robots.txt : chaque catégorie de robot reçoit une politique adaptée à son comportement et à votre intention.
Le patron derrière ces erreurs
Les cinq erreurs partagent une racine commune : elles traitent le robots.txt comme un fichier qu'on configure une fois et qu'on oublie, au lieu d'une politique active. Le site évolue. L'écosystème des robots évolue. Les attentes autour de l'utilisation IA, de l'archivage et de l'extraction de données évoluent. Un robots.txt qui était adéquat il y a deux ans peut être activement nuisible aujourd'hui.
La bonne pratique est de réviser son robots.txt au moins chaque trimestre, idéalement avec un outil qui montre ce que chaque règle fait avant sa mise en ligne. C'est exactement ce que l'étape de révision de Better Robots.txt permet : on voit la sortie finale, ligne par ligne, avant que quoi que ce soit ne change sur le site.