Fichier robots.txt : bonnes pratiques et erreurs à éviter

Un fichier robots.txt, ça ressemble à rien. Quelques lignes de texte brut, deux mots-clés, des slashs. Et pourtant, une seule ligne mal placée peut vous coûter des semaines de trafic. J'ai vu ça de mes propres yeux : un `Disallow: /` ajouté un vendredi après-midi par un dev pressé, et le lundi matin, le site d'un client avait perdu 60 % de ses visites organiques. Le pire ? Personne ne comprenait pourquoi. Le fichier était là, propre, bien formaté. Il disait juste à Googlebot de partir.

Cet article n'est pas une nième définition du robots.txt. Vous savez déjà ce que c'est. Ce que vous voulez probablement savoir, c'est comment ne pas transformer ce petit fichier en bombe à retardement SEO, et comment le réparer quand c'est déjà arrivé.

Robots.txt : les bonnes pratiques qui évitent 90 % des accidents

Avant de parler d'erreurs, posons ce qui fonctionne. Un robots.txt sain tient sur un principe simple : il autorise par défaut, et il bloque des chemins précis. Pas l'inverse.

Le principe « allow by default »

Vous n'avez pas besoin d'écrire `Allow: /`. Si aucune règle ne s'applique à une URL, elle est explorable. Ça paraît banal, mais ça change tout : chaque ligne que vous ajoutez est une ligne qui peut casser quelque chose. Le fichier le plus sûr est souvent le plus court.

Sur un projet e-commerce de taille moyenne que j'ai accompagné, nous avions un robots.txt de 340 lignes. Résultat : deux règles contradictoires se chevauchaient, et une catégorie entière de produits n'était plus explorée. La réécriture en 22 lignes a réglé le problème. Moins, c'est mieux.

Bloquer le bruit, pas le contenu

Un robots.txt utile cible ce qui n'a aucune valeur en recherche : les pages de recherche interne, les paramètres de tri, les sessions, les URLs de panier. Pas vos articles, pas vos fiches produits, pas vos pages catégories.

Voici une structure réaliste :

• Disallow: /recherche/ — les pages de résultats internes créent du contenu dupliqué à l'infini.
• Disallow: /panier et Disallow: /commande — aucune raison d'indexer un tunnel d'achat.
• Disallow: /*?tri= — toutes les variantes de tri d'une même liste.
• Un Sitemap: en fin de fichier, pour indiquer où trouver votre plan de site.

Quand le robots.txt est le mauvais outil

C'est la confusion la plus fréquente que je rencontre. Bloquer une URL dans le robots.txt n'empêche pas son indexation. Googlebot ne l'explorera pas, mais s'il trouve un lien vers cette page ailleurs, il peut l'inscrire dans l'index sans contenu — une URL nue, sans description.

Si vous voulez empêcher une page d'apparaître dans les résultats, la bonne méthode est la balise <meta name="robots" content="noindex"> ou l'en-tête HTTP X-Robots-Tag: noindex. Le robots.txt bloque l'accès ; le noindex empêche l'affichage. Deux métiers différents.

Attention au piège classique : une page bloquée en exploration et marquée noindex. Googlebot ne lit jamais la balise, donc il ne voit jamais le noindex. La page reste indexable. Il faut d'abord débloquer, laisser passer le crawl, puis appliquer le noindex.

Les erreurs à éviter, classées par gravité

Toutes les erreurs robots.txt ne se valent pas. Certaines font perdre une page, d'autres font perdre un site.

L'erreur n°1 : le Disallow global non commenté

Un site en préproduction, un `Disallow: /` pour empêcher l'indexation pendant la phase de test. Puis la mise en ligne. Et le fichier qui reste. C'est l'accident le plus documenté du SEO technique, et il arrive encore chaque semaine.

La correction est simple sur le papier : supprimer la ligne, redéployer, puis demander une réindexation dans la Search Console. En pratique, il faut aussi vérifier les logs serveur pour confirmer que Googlebot revient explorer. Et compter plusieurs jours avant de retrouver le trafic perdu. Ce n'est pas instantané.

Les erreurs de syntaxe silencieuses

Le robots.txt n'a pas de message d'erreur. Un fichier invalide est simplement ignoré — en tout ou partie. Les fautes que je vois le plus :

1. Un Disallow suivi de deux points espacés (Disallow : /) au lieu de Disallow: /. La règle devient illisible.
2. Des commentaires avec `#` placés au milieu d'une ligne de directive.
3. Un BOM UTF-8 invisible ajouté par l'éditeur de texte, qui casse la première ligne.
4. Une casse incohérente : les noms d'agents sont sensibles à la casse, `user-agent` en minuscules n'est pas reconnu par tous.

Franchement, le BOM m'a coûté une demi-journée. Le fichier semblait parfait dans le navigateur. Il ne l'était pas.

Ignorer les robots spécifiques

Beaucoup de webmasters écrivent un `User-agent: ` et pensent avoir tout couvert. Sauf que les gros robots ne suivent pas tous les règles générales. Googlebot respecte le bloc ``, mais Googlebot-Image, Googlebot-News et AdsBot ont parfois leurs propres blocs. Et depuis quelques années, toute une famille de robots IA (GPTBot, ClaudeBot, PerplexityBot, etc.) vient lire votre fichier avec ses propres règles.

Vous voulez bloquer les robots IA qui aspirent votre contenu ? Il faut les nommer un par un. Le `*` ne suffit pas toujours, selon la façon dont chaque éditeur implémente le respect de la directive.

Tableau comparatif : quel outil pour quel besoin

Voici la distinction que je répète le plus souvent en audit. Trois mécanismes, trois usages.

Mécanisme	Ce qu'il contrôle	Quand l'utiliser
robots.txt	L'exploration (le crawl)	Bloquer des chemins entiers sans valeur : recherche interne, paramètres, paniers
Meta robots noindex	L'indexation	Empêcher une page d'apparaître dans les résultats tout en la laissant accessible
X-Robots-Tag (en-tête HTTP)	L'indexation	Même objectif que noindex, mais pour des fichiers non-HTML : PDF, images, vidéos

La règle à retenir : le robots.txt gère l'accès, les deux autres gèrent l'affichage. Si vous confondez les deux, vous indexez ce que vous vouliez cacher.

Comment diagnostiquer et réparer un robots.txt cassé

Le fichier est en ligne, le trafic chute, et vous suspectez le robots.txt. Voici la marche à suivre, dans l'ordre.

Étape 1 : vérifier le fichier réellement servi

Ne regardez pas le fichier sur votre serveur de fichiers. Regardez celui que Googlebot reçoit. Ouvrez votresite.com/robots.txt dans un navigateur en navigation privée. Un cache, un CDN ou une règle de redirection peut servir une version différente de celle que vous croyez publiée.

Étape 2 : tester une URL en direct

Dans la Search Console, l'inspecteur d'URL permet de tester si une URL précise est bloquée. C'est le moyen le plus rapide de confirmer un `Disallow` fautif. Le rapport dédié au fichier robots.txt vous montre aussi la version que Google a en cache et signale les lignes invalides.

Étape 3 : lire les logs serveur

Si Googlebot ne passe plus du tout, vous le verrez dans les logs : plus aucune requête avec son user-agent. C'est le signal le plus fiable, et paradoxalement celui que le moins de gens consultent.

Étape 4 : corriger puis demander la réindexation

Une fois la ligne fautive retirée et le fichier redéployé, demandez une réindexation des pages prioritaires. Ne vous attendez pas à un retour immédiat : comptez plusieurs jours, parfois deux semaines sur un gros site, pour que le crawl reprenne un rythme normal. Sur le projet dont je parlais en ouverture, il a fallu onze jours pour retrouver le niveau de trafic d'avant.

Ce qu'on retient vraiment

Le robots.txt n'est pas un fichier qu'on écrit une fois et qu'on oublie. C'est une pièce vivante, qui doit être relue à chaque refonte, à chaque changement d'URL, à chaque nouvelle vague de robots. Le vrai danger n'est pas la complexité : c'est la confiance. On croit que le fichier est bon parce qu'il est là.

Si vous ne devez retenir qu'une chose de cet article, c'est celle-ci : testez votre robots.txt comme vous testeriez un formulaire de paiement. Parce qu'un fichier de dix lignes peut faire plus de dégâts qu'un bug dans votre panier. Et la prochaine fois que quelqu'un vous dira « c'est juste le robots.txt », vous saurez exactement ce que ça veut dire.