Un client m'appelle un mardi matin, panique dans la voix : « On a disparu de Google. Du jour au lendemain. » Je regarde le site. Rien de cassé. Le code est propre, les pages répondent, le sitemap est en place. Je demande l'accès au serveur, j'ouvre le fichier robots.txt... et là, je vois la ligne. Une seule. Disallow: /. Quelqu'un avait voulu bloquer une page de test le vendredi précédent, et avait oublié de retirer le slash. Toute la boutique était invisible pour les robots. Trois jours de trafic en moins, une dizaine de commandes envolées.
Le fichier robots.txt est un peu le videur de votre site. C'est lui qui dit aux robots d'exploration ce qu'ils ont le droit de voir. Et comme tous les videurs, il fait très bien son travail — y compris quand on lui donne de mauvaises instructions. La différence avec un videur humain, c'est qu'il ne vous demandera jamais si vous êtes sûr.
Points clés à retenir
- Le robots.txt contrôle l'exploration (crawl), pas l'indexation. Bloquer une URL ne la retire pas de Google.
- Une erreur d'un seul caractère peut bloquer tout un site. La ligne Disallow: / est la plus dangereuse du fichier.
- Depuis 2023, ce même fichier sert aussi à refuser la collecte par les robots d'IA génératives (GPTBot, CCBot, ClaudeBot, etc.).
- Toujours tester après modification : l'inspection d'URL et l'outil de test de Google sont vos garde-fous.
- Un sitemap déclaré dans le robots.txt n'est pas une garantie d'exploration — c'est une indication.
- Ce fichier est public. N'y mettez jamais d'information sensible.
Fichier robots.txt : à quoi ressemble réellement un bon fichier
La structure est bête comme chou. Une ou plusieurs sections, chacune démarrant par un User-agent, suivie des règles applicables. C'est tout. Le piège, c'est que beaucoup de gens copient un exemple trouvé quelque part sans comprendre ce que chaque ligne fait.
La syntaxe de base, ligne par ligne
Voici un fichier que j'utilise régulièrement sur des sites vitrines ou des blogs :
User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Disallow: /panier/ Disallow: /*?s= Sitemap: https://exemple.fr/sitemap.xml
Trois choses à comprendre ici. D'abord, User-agent: * signifie « tous les robots ». Ensuite, les directives Disallow fonctionnent par préfixe : Disallow: /panier/ bloque tout ce qui commence par /panier/, y compris /panier/checkout et /panier/merci. Enfin, l'ordre compte : Allow et Disallow s'appliquent selon la règle la plus spécifique, pas selon leur position dans le fichier — mais la lisibilité humaine, elle, dépend de l'ordre. Je place toujours les Allow après les Disallow concernés.
Un détail que j'ai mis des années à vraiment intégrer : les caractères génériques (* et $) ne sont pas supportés par tous les robots. Google les gère, Bing aussi, mais des crawlers plus obscurs peuvent les ignorer complètement. Si une règle est critique, n'utilisez pas de joker.
Robots.txt, c'est quoi exactement ?
C'est un fichier texte, à la racine de votre domaine, qui indique aux robots d'exploration quelles parties de votre site ils peuvent parcourir et lesquelles ils doivent éviter. Il doit être accessible à l'adresse https://votresite.fr/robots.txt — ni dans un sous-dossier, ni renommé. Un seul fichier par domaine. Si vous avez des sous-domaines, chacun a le sien.
Le fichier est apparu en 1994, inventé par Martijn Koster sur une liste de discussion dédiée aux serveurs web. Il a fallu attendre 2022 pour qu'un véritable standard IETF (RFC 9309) le normalise. Pendant presque trente ans, on a donc fonctionné sur une convention tacite. Ça explique une partie du bazar actuel.
Les erreurs qui coûtent cher (et comment je les ai vues se produire)
Sur les audits que j'ai menés ces dernières années, je trouve en moyenne un problème sérieux dans le robots.txt sur cinq sites. Ce n'est pas un chiffre précis, c'est l'ordre de grandeur que je constate. Voici les fautes qui reviennent.
Erreur n°1 : bloquer tout le site par accident
Le classique. Une ligne Disallow: / qui traîne, ou un User-agent mal orthographié qui fait que la règle s'applique au mauvais robot. J'ai aussi vu le cas inverse : un développeur voulait bloquer les robots sur un environnement de préproduction, a déployé le fichier, et oublié de le retirer à la mise en ligne. Résultat, l'environnement de prod se comportait comme un bac à sable.
La vérification est simple. Vous tapez l'URL dans un navigateur, vous regardez la première ligne. Si vous voyez un Disallow: / sans Allow compensatoire, vous avez un problème.
Erreur n°2 : croire que bloquer, c'est désindexer
C'est l'erreur conceptuelle la plus répandue. Bloquer une page dans le robots.txt empêche Google de la lire. Ça ne l'empêche pas de l'indexer. Si d'autres sites pointent vers cette URL avec un texte de lien explicite, Google peut parfaitement afficher cette URL dans ses résultats, avec un extrait vide ou un message du type « Aucune information n'est disponible pour cette page ».
Pour retirer véritablement une page de l'index, il faut une balise noindex. Et là, il y a un piège dans le piège : si la page est bloquée par le robots.txt, le robot ne peut pas lire la balise noindex. Il faut donc d'abord laisser la page accessible, laisser le noindex être lu, puis seulement bloquer l'exploration — ou ne jamais bloquer.
Erreur n°3 : ignorer les robots d'IA
Depuis 2023, une nouvelle catégorie d'agents est arrivée : GPTBot, CCBot, ClaudeBot, PerplexityBot, Google-Extended, et d'autres. Ces robots collectent le contenu pour entraîner ou alimenter des modèles. Par défaut, la plupart se présentent comme des agents génériques — donc un User-agent: * les autorise.
Si vous voulez les exclure, il faut les lister explicitement :
User-agent: GPTBot Disallow: / User-agent: CCBot Disallow: / User-agent: ClaudeBot Disallow: /
Attention : ces robots ne sont pas tous obligés de respecter le fichier. Certains l'annoncent, d'autres pas. Le robots.txt reste ici une déclaration d'intention, pas une serrure. Si vous voulez vraiment empêcher la collecte, il faut coupler avec des solutions côté serveur (pare-feu applicatif, blocage par plage d'IP).
Les bonnes pratiques que j'applique systématiquement
Après quelques années à rédiger et corriger ces fichiers, j'ai fini par adopter une méthode. Elle tient en cinq points.
- Partez du principe que tout est autorisé. Un robots.txt vide ou absent laisse les robots faire ce qu'ils veulent. C'est souvent suffisant.
- Ne bloquez que ce qui a une raison claire : pages de recherche interne, paniers, pages de filtres générant du contenu dupliqué, sections d'administration.
- Déclarez toujours votre sitemap en dernière ligne. L'ordre logique veut qu'il soit à la fin, après les règles.
- Testez avant de déployer. L'inspection d'URL dans la Search Console permet de vérifier qu'une URL donnée est bien explorable.
- Versionnez le fichier. Un robots.txt modifié sans trace, c'est un incident de production en puissance. Je le mets dans le dépôt Git avec le reste du code.
Un mot sur la ligne Disallow: /*?s= qu'on voit souvent. Elle est censée bloquer les pages de recherche interne. Elle fonctionne sur Google, mais elle génère parfois des effets de bord sur d'autres robots. Je préfère bloquer par répertoire quand c'est possible.
Comment tester et vérifier un robots.txt
Vous avez deux outils principaux, et ils ne font pas la même chose.
| Outil | Ce qu'il vérifie | Quand l'utiliser |
|---|---|---|
| Inspecteur d'URL (Search Console) | Si Googlebot peut explorer une URL spécifique, avec la règle bloquante affichée | Après chaque modification du fichier, avant mise en ligne |
| Validateur de syntaxe tiers | Les erreurs de format, les directives non reconnues, les conflits | Quand vous héritez d'un fichier que vous n'avez pas écrit |
| Test manuel dans un navigateur | Que le fichier est accessible et qu'il contient ce que vous attendez | Toujours, en premier |
Comment trouver le fichier robots.txt d'un site quel qu'il soit ? Vous ajoutez simplement /robots.txt à la fin du nom de domaine. Si le fichier affiche une page 404, il n'existe pas — et c'est rarement un problème en soi, sauf si vous avez besoin de règles spécifiques. Si vous voyez une page HTML d'erreur personnalisée à la place du texte brut, c'est un bug de configuration serveur : un vrai robots.txt renvoie un Content-Type en text/plain.
Pour créer un fichier robots.txt, aucun outil sophistiqué n'est nécessaire. Un éditeur de texte, un respect strict de la syntaxe, et un upload à la racine du domaine. Le piège n'est pas la création, c'est la relecture. Relisez toujours à froid, le lendemain, avant publication.
Un robots.txt peut-il contenir des commentaires ?
Oui. Tout ce qui suit un dièse (#) est ignoré. Je m'en sers systématiquement pour documenter la raison de chaque règle, avec une date. Quand on revient six mois plus tard, ça change la vie.
Que se passe-t-il si le fichier contient une erreur de syntaxe ?
La règle fautive est généralement ignorée, ou son interprétation devient imprévisible. Le risque n'est pas qu'elle soit rejetée en bloc — c'est qu'elle soit interprétée d'une façon que vous n'avez pas prévue. Un User-agent: * suivi d'une instruction invalide peut amener certains robots à considérer que tout le site est bloqué.
Ce que je retiens après des années à jouer avec ce fichier
Un robots.txt bien écrit, c'est souvent un robots.txt court. Les fichiers de trente lignes que je vois circuler sont généralement des copy-paste de tutoriels, avec des règles qui se contredisent ou qui bloquent des choses sans raison. Franchement, dans 80 % des cas que je croise, un fichier de cinq lignes bien senties fait mieux qu'un roman.
La vraie question à se poser avant d'ajouter une règle : est-ce que je sais précisément quel robot cette ligne affecte, et pourquoi ? Si la réponse est floue, retirez-la. Un fichier vide n'a jamais fait de mal. Un fichier mal écrit, si. Et si vous vous demandez aujourd'hui si votre robots.txt actuel est correct, tapez son URL dans un navigateur et lisez-le vraiment. Pas en diagonale. Ligne par ligne. C'est dix minutes qui peuvent vous éviter le coup de fil du mardi matin.
