Fichier robots.txt : le guide complet pour bien le configurer

Un client m'appelle un mardi matin, panique totale : « On a disparu de Google. Plus rien. Zéro. » Le site avait été refait deux semaines plus tôt. Nouveau design, nouvelles URL, tout propre. J'ouvre leur fichier robots.txt et je tombe sur une ligne, une seule, tapée par un développeur pressé : Disallow: /. Quatre mots (bon, deux) qui interdisaient le crawl de la totalité du site par tous les robots. Le type ne savait pas ce qu'il écrivait. Il croyait « nettoyer » le fichier pour le refaire plus tard.

Résultat : trois semaines de trafic perdues, une remise en indexation qui a pris encore dix jours, et un client qui a failli me remercier par un procès. Voilà pourquoi je considère ce petit fichier texte comme la ligne la plus dangereuse d'un site web. Un caractère mal placé, et vous disparaissez. Un caractère bien placé, et vous gagnez du budget de crawl.

Dans ce guide, je vous montre comment configurer un robots.txt sans vous tirer une balle dans le pied, comment le tester, et les erreurs que je vois le plus souvent quand on m'appelle pour un audit technique.

Robots.txt, c'est quoi exactement ?

Imaginez un standard téléphonique. Le fichier robots.txt, c'est le panneau posé à l'entrée : « Salle de serveurs : accès interdit au public. Cuisine : libre. » Sauf qu'ici, le public, ce sont les robots des moteurs de recherche, et le panneau, c'est un petit fichier texte en clair, lisible par n'importe qui, hébergé à l'adresse votredomaine.com/robots.txt.

Le rôle réel : gérer le crawl, pas le référencement

Voilà le point que 90 % des articles ratent. Le robots.txt ne dit pas à Google « n'affiche pas cette page ». Il dit « ne viens pas lire cette page ». Nuance énorme.

Une URL bloquée au crawl peut quand même apparaître dans les résultats de recherche, avec un titre et une description reconstitués à partir des liens pointant vers elle. Google le fait régulièrement. Si votre objectif est de retirer une page de l'index, le robots.txt est le mauvais outil. Utilisez plutôt une balise <meta name="robots" content="noindex"> ou une protection par mot de passe.

Le pire scénario que je rencontre en audit : un e-commerçant qui bloque ses pages de filtres au crawl et y colle un noindex. Résultat, Googlebot n'entre jamais, ne lit jamais le noindex, et continue d'indexer l'URL sur la base de liens externes. Les deux directives se neutralisent.

Qui respecte le robots.txt (et qui s'en moque)

Googlebot, Bingbot, les crawlers d'Ahrefs ou de Semrush : tous obéissent. C'est un accord tacite, pas une loi.

En revanche, les scrapers de données personnelles, les aspirateurs de contenu et les bots d'IA génératives ne sont pas obligés. Certains sont signataires de conventions, beaucoup ne le sont pas. Je l'ai appris à mes dépens quand un site que je gérais a vu 4 000 pages recopiées sur un domaine miroir. Le robots.txt bloquait Wikipédia-bot mais pas le type qui aurait dû se gêner.

Donc : un robots.txt n'est pas une serrure. C'est un panneau indicateur. Si vous voulez verrouiller l'accès à un dossier (back-office, fichiers de sauvegarde, PDF confidentiels), ce sont des règles d'authentification serveur qu'il faut poser.

Syntaxe : un exemple de fichier robots.txt complet et copiable

Pas besoin d'un doctorat. Le langage tient en cinq directives. Voici un fichier que j'utilise comme base sur la majorité des sites que je configure :

User-agent: *
Disallow: /admin/
Disallow: /panier/
Disallow: /recherche?
Disallow: /*?sort=
Allow: /wp-admin/admin-ajax.php

User-agent: GPTBot
Disallow: /

Sitemap: https://exemple.com/sitemap.xml

Décortiquons ce que vous voyez.

• User-agent: — le signifie « tous les robots non nommés ailleurs ». Si vous déclarez ensuite un agent spécifique, il hérite de ses propres règles et ignore celles du bloc générique.
• Disallow — bloque l'accès. Le chemin est sensible à la casse et s'écrit à partir de la racine du domaine.
• Allow — autorise une exception dans un dossier bloqué. Sur WordPress, admin-ajax.php doit rester accessible, sinon la moitié du site pète. J'ai mis six mois à comprendre pourquoi un formulaire de contact ne fonctionnait plus après un audit : c'était ça.
• Sitemap — la seule ligne non-standard, mais reconnue par tous les grands moteurs. Elle accélère la découverte de vos URL.

Allow contre Disallow : la règle du plus long

Quand deux directives se contredisent, le robot retient la plus spécifique. Plus le chemin est long, plus il gagne. Et à longueur égale, Allow l'emporte sur Disallow.

Directive	Chemin	Résultat
Disallow	/blog/	Dossier entier bloqué
Allow	/blog/public/	Exception rétablie à l'intérieur du dossier bloqué
Disallow	/*.pdf$	Tous les PDF bloqués (le $ marque la fin de l'URL)

Les caractères spéciaux utiles : * (n'importe quelle chaîne) et $ (fin d'URL). Ce sont les deux seuls jokers standardisés. N'en cherchez pas d'autres, ils n'existent pas.

Quand bloquer une URL (et quand ça ne sert à rien)

Le blocage n'est pas un réflexe à avoir partout. J'ai vu des sites bloquer leurs propres images produits au crawl. Cherchez l'erreur.

Les cas où bloquer fait sens

La règle que j'applique depuis quelques années : je bloque tout ce qui génère du crawl sans jamais rien apporter en recherche.

• Pages de résultat de recherche interne (/recherche?) — elles créent des milliers d'URL fantômes.
• Paramètres de tri et de filtre (?sort=, ?color=) — sauf si vous avez une stratégie de landing pages filtrées.
• Zones d'administration et scripts internes.
• Sessions, paniers, tunnels de commande.
• Fichiers de sauvegarde et d'export (le classique Disallow: /*.sql$).

Bonne nouvelle : ce sont rarement les pages qui vous rapportent du trafic organique. Le crawl budget économisé peut être réinvesti sur les pages qui comptent.

Les pièges où bloquer vous nuit

Un site multilingue, par exemple. Le réflexe du développeur consiste à bloquer /en/ parce qu'il ne comprend pas pourquoi il existe. Deux mois plus tard, la version anglaise ne reçoit plus un seul visiteur. Blocage involontaire, conséquence mesurable.

Autre piège classique : le site e-commerce qui bloque toutes ses pages de catégorie après un nettoyage trop zélé. Les fiches produits restent indexées, mais plus aucune hiérarchie ne les structure. Google perd le contexte.

Ma règle personnelle, et je l'assume : je ne bloque que ce que j'ai vérifié dans mes logs serveur comme étant crawlé, inutile, et sans valeur commerciale. Pas de blocage à l'aveugle.

Comment trouver le robots.txt d'un site ?

Vous tapez l'URL du domaine suivi de /robots.txt, rien d'autre. Exemple : https://www.lemonde.fr/robots.txt. Si le fichier s'affiche, il existe. Si vous obtenez une erreur 404, deux possibilités : soit il n'y en a pas (et les robots crawlent tout par défaut), soit il est mal placé. Je le vérifie systématiquement avant tout audit concurrentiel, ça me dit parfois directement comment une marque gère son crawl.

Créer et configurer son robots.txt (cas WordPress inclus)

Trois méthodes, selon votre niveau de contrôle sur le serveur.

Méthode 1 : à la racine du serveur

Vous créez un fichier texte vide, vous le nommez robots.txt (tout en minuscules, sans accent), vous écrivez vos directives, vous l'uploadez dans le dossier racine de votre site. Chemin exact : à côté du index.html ou index.php, jamais dans un sous-dossier.

Méthode 2 : via votre CMS

WordPress génère un robots.txt virtuel par défaut. Un fichier physique placé à la racine écrase cette version. C'est la source de confusion numéro un sur robot txt wordpress.

Deux options : vous éditez le fichier virtuel via une extension SEO (Yoast, Rank Math, SEOPress proposent une interface dédiée), soit vous créez un fichier physique FTP. Je préfère le physique quand je veux un contrôle total. Je l'ai fait sur un site à 12 000 URL : le virtuel devenait illisible.

Attention à un détail que je vois tout le temps sur WordPress : la ligne Disallow: /wp-admin/ ajoutée par défaut. Elle est suivie de Allow: /wp-admin/admin-ajax.php dans la version virtuelle. Si vous créez un fichier physique sans reporter cette exception, vous cassez des fonctionnalités. Je l'ai vécu sur un projet client, un widget de réservation qui ne chargeait plus. Une heure de recherche pour une ligne manquante.

Méthode 3 : via un CDN ou hébergeur

Certains hébergeurs managés (hébergement WordPress premium, plateformes headless) interposent une couche réseau qui sert un robots.txt automatique. Vérifiez toujours la version en ligne, pas celle de votre FTP. J'ai passé une journée à modifier un fichier que le CDN ignorait royalement. Leçon retenue.

Tester et vérifier son robots.txt : la procédure que j'applique

Modifier sans tester, c'est jouer à la roulette russe. Voici ma checklist, dans l'ordre, à chaque déploiement.

1. Test dans Search Console. L'outil « Test de robots.txt » vous permet de coller une URL et de voir si elle est bloquée pour Googlebot. Gratuit, immédiat, indispensable.
2. Vérification manuelle de l'URL. Tapez votredomaine.com/robots.txt dans un onglet privé. Si vous voyez autre chose que vos directives, un cache ou un CDN s'interpose.
3. Test critique sur les pages clés. Trois URL minimum : la page d'accueil, une fiche produit ou un article, une page de catégorie. Les trois doivent passer en « autorisé ».
4. Contrôle du code retour HTTP. Le fichier doit répondre en 200. Une erreur 500 peut être interprétée par certains robots comme un blocage complet. Panne silencieuse, trafic en chute.
5. Surveillance à 48 h. Je regarde dans les logs serveur si Googlebot passe toujours sur les pages stratégiques. C'est le seul moyen fiable de confirmer que rien n'est cassé.

Le test de Search Console est puissant, mais il ne voit pas tout. Il ne simule que Googlebot. Si vous bloquez un chemin pour Bingbot ou pour un crawler d'IA, il faut tester auprès de leurs outils respectifs, quand ils en proposent.

Les erreurs que je vois le plus souvent (et comment les diagnostiquer)

Après une dizaine d'audits techniques, ce sont toujours les mêmes qui reviennent.

Erreur n°1 : le Disallow: / par accident

Un caractère de trop sur une ligne Disallow: /blog transformé en Disallow: /, et c'est tout le site qui disparaît. Cette erreur est plus fréquente qu'on ne le croit, notamment sur les sites en refonte où les développeurs « préparent le terrain ».

Le diagnostic est simple : Search Console > Statistiques de couverture, et vous voyez une chute brutale des URL explorées. Corrigez, puis demandez une réindexation manuelle via le sitemap.

Erreur n°2 : conflit robots.txt et noindex

Déjà évoquée, mais elle mérite sa propre section. Bloquer une URL au crawl empêche la lecture de la balise noindex. Google indexe alors l'URL par déduction. Le remède : autorisez le crawl, laissez le noindex faire son travail, puis attendez le retrait de l'index.

Erreur n°3 : un robots.txt inaccessible

Le fichier renvoie une erreur 404 ou 500. Deux écoles chez les robots : certains considèrent l'absence de fichier comme une autorisation totale, d'autres bloquent prudemment. Google, pour sa part, gère plutôt bien le 404 (il crawle tout) mais peut interpréter un 500 comme un blocage. Ne jouez pas avec ça. Un fichier accessible en 200, point.

Erreur n°4 : oublier le sitemap

Un robots.txt sans ligne sitemap, c'est un panneau indicateur sans flèche. La ligne coûte dix secondes à écrire et accélère la découverte des nouvelles URL. Je l'ajoute systématiquement.

Ce que le robots.txt ne fera jamais pour vous

Ne lui demandez pas ce qu'il ne sait pas faire.

• Il ne gère pas les paramètres d'URL en masse (pas de regex complète, seulement * et $).
• Il ne bloque pas les crawlers qui décident de l'ignorer, notamment les aspirateurs d'IA génératives.
• Il ne remplace pas un noindex, une balise canonique, ou une protection d'accès.
• Il n'empêche pas l'affichage d'une URL dans les résultats, comme expliqué plus haut.
• Il ne doit pas servir à cacher des informations sensibles. La sécurité passe par l'authentification, jamais par ce fichier.

Une règle simple que je répète à mes clients : si la page ne doit pas être vue, protégez-la. Si la page doit simplement être ignorée par les robots, écrivez-la dans le robots.txt.

Ce qui compte vraiment, en une phrase

Le robots.txt est un outil puissant, gratuit, et dangereux dans les mains d'un développeur pressé. Il ne s'agit pas d'un fichier de configuration qu'on écrit une fois pour toutes. C'est un contrat vivant avec les moteurs de recherche, qui évolue avec votre site.

Mon conseil, forgé après plusieurs incidents : à chaque refonte, à chaque nouvelle fonctionnalité, ouvrez le fichier. Relisez-le. Testez-le. Je ne connais pas un técnico qui regrette d'avoir vérifié un Disallow avant de déployer. J'en connais plusieurs qui regrettent le contraire.

Et la prochaine fois que vous taperez /robots.txt sur le site d'un concurrent, regardez bien la première ligne. Elle vous dira souvent tout ce que vous avez besoin de savoir sur la maturité SEO de son équipe.