Maîtriser le fichier robots.txt : le guide complet pour bien l'utiliser

Vous avez probablement déjà ouvert le fichier robots.txt d'un site web par curiosité. Vous avez peut-être vu des lignes comme User-agent: * et Disallow: /admin/. Et puis… vous êtes passé à autre chose. C'est une erreur. Ce petit fichier texte, que Google appelle un "protocole d'exclusion", est l'un des leviers les plus sous-estimés de la technique SEO. Mal utilisé, il peut faire disparaître des pages entières des résultats. Bien configuré, il protège les ressources de votre serveur et guide les robots précisément là où il faut. Franchement, après des années à auditer des sites, je peux vous dire que la plupart des erreurs que je croise viennent d'une méconnaissance de ce fichier. Pas d'une malveillance. Juste de l'ignorance. Et c'est réparable.

Pourquoi le robots.txt est si mal compris

La confusion vient d'une phrase que l'on retrouve partout : "Le fichier robots.txt empêche les moteurs de recherche d'accéder à vos pages." C'est faux. Enfin, c'est une demi-vérité. Il indique aux robots d'exploration les URL auxquelles ils peuvent accéder, oui. Mais son objectif principal, selon la documentation officielle de Google, est d'éviter de surcharger votre site de demandes. C'est un outil de gestion du crawl, pas un outil de référencement au sens strict.

Un jour, un client m'a demandé pourquoi sa page "Contact" n'apparaissait plus dans Google. J'ai ouvert son robots.txt et j'ai vu : Disallow: /. Il avait bloqué tout le site pour "faire une maintenance" et avait oublié de retirer la ligne. Résultat : plus aucune page en cache, plus de trafic. Une seule ligne a suffi. Et le pire, c'est que pendant des semaines, personne n'avait remarqué.

Ce que je veux que vous compreniez, c'est que ce fichier agit comme un portier. Il ne dit pas "cette page est interdite au public". Il dit "ce couloir est réservé au personnel, ne perdez pas votre temps". La nuance est capitale.

La différence entre explorer et indexer, ou l'erreur n°1

Quand vous bloquez une page avec Disallow, Googlebot ne la visite pas. Mais si un autre site pointe vers elle, Google peut quand même la mettre dans son index, sans l'explorer, en utilisant le texte d'ancrage et le contenu environnant. C'est ce qu'on appelle un indexation "sans contenu". La page peut alors apparaître dans les résultats avec un titre tronqué et un extrait vide. C'est moche, mais c'est possible.

Pour empêcher une page de figurer dans les résultats de Google, la documentation est très claire : il faut utiliser la balise noindex ou protéger la page par mot de passe. Pas le robots.txt. Je l'ai appris à mes dépens sur un site e-commerce, où j'avais bloqué l'exploration des pages de filtres pour éviter le contenu dupliqué. Les filtres ont disparu du crawl, mais ils sont restés dans l'index pendant des mois, avec des extraits pauvres. Le jour où j'ai ajouté noindex sur ces pages, elles ont fini par disparaître. Mais j'ai perdu trois mois à cause de cette erreur.

Comment créer un bon fichier robots.txt, pas juste un fichier

Un fichier robots.txt se résume à des groupes de directives. Chaque groupe commence par un User-agent qui cible un robot ou un groupe de robots. Par exemple, User-agent: Googlebot pour le robot de Google, ou User-agent: * pour tous les autres. En dessous, vous ajoutez des règles Disallow et Allow.

Mais attention, il existe une règle subtile, spécifique à Google : pour Googlebot, si une URL correspond à la fois à une règle Disallow et à une règle Allow, c'est la règle Allow la plus spécifique qui l'emporte. C'est une exception au comportement par défaut des autres moteurs. Concrètement, vous pouvez bloquer un dossier entier mais autoriser un fichier précis dedans. Ça peut sembler anecdotique, mais c'est très pratique pour laisser passer un fichier CSS ou une image dans un répertoire protégé.

Prenons un exemple concret, tiré d'un projet récent. Le site avait un dossier /assets/ avec des images optimisées et des fichiers de polices. Le propriétaire ne voulait pas que les moteurs explorent ce dossier, mais il voulait que le fichier logo.png reste accessible pour l'affichage dans les résultats riches. Voici la configuration que j'avais proposée :

User-agent: Googlebot
Disallow: /assets/
Allow: /assets/logo.png

Le fichier logo.png reste explorable, le reste du dossier est bloqué. Simple, efficace, et ça marche.

Syntaxe, emplacement : les bases que tout le monde oublie

Le fichier doit être placé à la racine du domaine. Pour https://example.com/robots.txt, le fichier s'appelle robots.txt (en minuscules, sans accent). Il ne doit pas contenir d'espace avant le nom. La syntaxe de base est simple, mais les erreurs sont courantes : oublier le deux-points après User-agent, écrire Disallow: suivi d'un espace avant l'URL, ou utiliser des caractères accentués dans les chemins. Certains serveurs sont stricts, d'autres non. La plupart du temps, un fichier avec une erreur de syntaxe sera ignoré en totalité, et le robot explorera tout. C'est d'ailleurs une "erreur" que certains webmasters utilisent volontairement : ils laissent un fichier vide ou mal formé pour que le crawl soit autorisé partout.

La directive Sitemap est une autre ligne que j'ajoute systématiquement. Elle indique l'adresse de votre fichier sitemap.xml. Ce n'est pas une directive d'exclusion, mais elle aide le robot à découvrir rapidement votre contenu. Voici la ligne à ajouter en fin de fichier : Sitemap: https://example.com/sitemap.xml. Une seule ligne, pas besoin de la répéter pour chaque user-agent.

Les erreurs que j'ai vu ruiner des sites

J'ai vu des choses étranges dans des fichiers robots.txt. Un jour, un développeur avait copié-collé une configuration depuis un tuto en ligne sans la comprendre. Il y avait une ligne Disallow: /*.pdf$. Il voulait empêcher Google de mettre en cache ses brochures PDF. Ça, c'était l'intention. Le résultat ? Toutes les pages dont l'URL contenait un point suivi de "pdf" étaient bloquées. Le site utilisait des URLs propres de type /produits/ma-page.pdf — et bien sûr, toutes ces pages ont été désindexées. Le pire, c'est que son fichier était correctement formaté, la règle était juste trop large.

Une autre erreur récurrente : les webmasters qui bloquent les robots d'IA. C'est devenu un vrai débat depuis quelques années. Quelqu'un lit un article alarmiste sur le vol de contenu par les IA génératives, et il ajoute ces lignes :

User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /

Franchement, je comprends l'envie. Mais avant de le faire, posez-vous une question : voulez-vous que votre contenu soit cité par ChatGPT ou Claude quand un utilisateur pose une question ? Si vous bloquez ces robots, vous coupez cette source de trafic. Vous coupez aussi la possibilité que votre marque soit mentionnée. C'est un choix éditorial, pas une décision technique. Sur mon propre blog, j'ai fait le choix de ne pas bloquer. J'ai vu 15 % de mon trafic venir de réponses d'IA. Une partie significative. Et je ne suis pas sûr que tout le monde en ait conscience.

Et puis il y a l'erreur la plus banale, celle que je vois chaque mois : le fichier placé dans le mauvais dossier. Par exemple, https://example.com/wordpress/robots.txt au lieu de https://example.com/robots.txt. Le robot ne le trouvera jamais, et il explorera tout. Si vous utilisez un CMS comme WordPress, la plupart des plugins SEO génèrent ce fichier automatiquement. Mais vérifiez toujours l'adresse exacte.

Comment tester votre fichier sans vous tromper

Avant de mettre en ligne une modification, testez-la. Les outils de Google Search Console proposent un testeur de robots.txt qui vous montre exactement ce que Googlebot voit. C'est gratuit, c'est officiel, et ça évite les catastrophes. Vous pouvez aussi simuler l'exploration d'une URL spécifique et voir quelle règle s'applique.

Mais il existe une méthode plus simple, que j'utilise en premier : ouvrir le fichier dans un navigateur et vérifier visuellement qu'il n'y a pas d'erreur de frappe. Une ligne Disalow: /admin/ (avec une faute) sera ignorée. Une ligne Disallow: /admin/ (avec un espace avant le slash) fonctionnera la plupart du temps, mais pas partout. Soyez rigoureux.

Quand ne pas utiliser de robots.txt du tout

Voici la partie que personne n'évoque dans les tutos. Si votre site est petit, que vous n'avez pas de zone d'administration à protéger et que vous publiez du contenu public, vous n'avez probablement pas besoin d'un fichier robots.txt. Un fichier vide ou inexistant signifie que tous les robots peuvent explorer tout. C'est le comportement par défaut le plus sain pour la majorité des sites.

La tentation de vouloir "contrôler" le crawl est compréhensible. Mais chaque règle ajoutée est une occasion de se tromper. Je me souviens d'un site vitrine de 15 pages, sans espace membre, sans filtre. Le webmaster avait un robots.txt avec des règles venant d'un ancien projet e-commerce. Il bloquait /search, /filter, /sort... des dossiers qui n'existaient même pas. Résultat : aucune page bloquée, mais un fichier confus qui envoyait des signaux contradictoires aux robots. Un fichier minimaliste aurait suffi :

User-agent: *
Sitemap: https://example.com/sitemap.xml

Voilà. Deux lignes, zéro risque. Et pourtant, quand je propose ça à mes clients, certains ont l'impression que je ne fais pas mon travail. Parce que "un bon référenceur, ça met des disallow partout". Non. Un bon référenceur, ça nettoie, ça supprime le superflu, et ça explique pourquoi.

L'ironie, c'est que le fichier robots.txt est peut-être le seul fichier technique dont la bonne configuration est de faire le moins de choses possible. Plus vous ajoutez de règles, plus vous prenez de risques. La véritable compétence, c'est de savoir quoi ne pas bloquer. C'est contre-intuitif, mais c'est ça, la maîtrise.