Un « Disallow: / » collé dans le mauvais bloc, et votre trafic organique peut tomber à zéro en quelques heures. Ça paraît dramatique dit comme ça. C'est pourtant l'une des erreurs les plus banales du SEO technique, et je l'ai vue arriver sur un site que je suivais : une mise en production un vendredi soir, un fichier de préproduction poussé par erreur, et le lundi matin Google avait retiré la quasi-totalité des pages du site de ses résultats. Deux jours et demi de travail pour récupérer la situation.
La bonne nouvelle : le robots.txt est un fichier d'une simplicité désarmante. Une dizaine de lignes suffisent largement. Le problème n'est jamais la complexité du format, c'est la rigueur avec laquelle on le maintient. Voici comment gérer ce fichier sans se tirer une balle dans le pied.
Points clés à retenir
- Le robots.txt se place à la racine du domaine, jamais dans un sous-dossier.
- Une erreur de syntaxe silencieuse est plus dangereuse qu'une erreur visible : elle ne casse rien, elle laisse juste passer ce qu'il fallait bloquer.
- Un code 5xx sur le fichier bloque temporairement l'exploration ; un 404 revient à dire « tout est autorisé ».
- Bloquer une URL dans le robots.txt n'empêche pas son indexation : utilisez noindex si le but est de la retirer des résultats.
- Testez chaque modification dans la Search Console avant de la déployer en production.
Gérer un fichier robots.txt sans erreur : la grammaire avant tout
La syntaxe tient en cinq directives. User-agent désigne le robot visé, Disallow les chemins à ne pas explorer, Allow les exceptions, Sitemap l'adresse du plan de site, et Crawl-delay un délai entre deux requêtes (que Google ignore, mais que d'autres robots respectent). C'est tout. Si votre fichier contient autre chose, c'est probablement du bruit.
User-agent et regroupements
Une règle de base à ne jamais perdre de vue : chaque bloc User-agent ouvre un groupe, et toutes les directives qui suivent ne concernent que ce bloc. Un groupe se termine dès qu'un nouveau User-agent apparaît. Sur un fichier que j'ai audité récemment, l'administrateur avait empilé trois blocs sans ligne vide entre eux en pensant que Google lirait les règles comme un empilement logique. Résultat : la moitié des directives s'appliquaient au mauvais robot, et personne ne s'en était aperçu pendant huit mois.
Le cas de l'astérisque mérite un mot. User-agent: * s'applique à tous les robots qui n'ont pas de bloc dédié. Si vous ajoutez plus bas un bloc User-agent: Googlebot, c'est bien ce dernier qui primera pour Google, et le bloc générique deviendra sans effet pour lui.
Disallow, Allow et l'ordre des lignes
La règle la plus longue l'emporte. Ce n'est pas l'ordre des lignes qui décide, mais la longueur du chemin. Donc :
Disallow: /blog/bloque tout le blogAllow: /blog/public/réautorise ce sous-dossier précis, car le chemin est plus longDisallow: /*.pdf$bloque tous les PDF (le$indique la fin d'URL)- Le caractère
*remplace n'importe quelle suite de caractères
Attention aux jokers mal placés. Disallow: /? bloque toutes les URL contenant un point d'interrogation, ce qui est souvent l'intention. Mais Disallow: / bloque absolument tout, y compris la page d'accueil, et c'est exactement le scénario du vendredi soir dont je parlais plus haut.
Les commentaires commencent par #. Ils ne coûtent rien, servez-vous-en. Une ligne du type # bloc ajouté le 12/03, à revoir après migration vous sauvera un jour.
L'emplacement et le code HTTP comptent autant que le contenu
Un robots.txt qui répond correctement mais qui se trouve au mauvais endroit ne sert à rien. Le fichier doit être servi sur https://votredomaine.com/robots.txt, en texte brut, sans redirection. Pas dans /public/, pas dans /assets/. À la racine, point. Et un sous-domaine a son propre fichier : blog.monsite.com/robots.txt est distinct de monsite.com/robots.txt.
Que se passe-t-il en cas d'erreur 4xx ou 5xx ?
C'est le point que presque personne ne vérifie, et il est capital.
- 200 : le fichier est lu normalement.
- 404 ou 410 : le robot considère qu'aucune restriction n'existe et explore tout. Vous perdez le bénéfice de vos règles, mais rien ne casse.
- 5xx : le robot considère qu'il y a un problème temporaire et suspend l'exploration du site pendant un moment. Un serveur mal configuré qui renvoie une 500 sur ce fichier peut donc geler le crawl sans que vous compreniez pourquoi.
- Redirection 301 : Google suit les redirections, mais d'autres robots ne le font pas. À éviter absolument sur ce fichier.
J'ai perdu une semaine sur ce diagnostic l'an dernier, sur un site dont le fichier répondait en 503 uniquement quand le cache était vidé. Le crawl baissait de 40 % sans raison apparente. Franchement, je cherchais ailleurs.
Les erreurs fréquentes qui coûtent cher
Bloquer dans le robots.txt ne désindexe pas
C'est la confusion la plus répandue. Une URL bloquée par Disallow peut tout à fait apparaître dans les résultats de recherche si des liens externes pointent vers elle — Google en affichera alors une description vide, faute de pouvoir explorer le contenu. Pour retirer réellement une page des résultats, il faut une balise meta robots noindex ou un en-tête X-Robots-Tag. La bonne séquence : autoriser l'exploration, laisser Google lire le noindex, puis seulement après, bloquer si l'on veut économiser du budget de crawl.
Faut-il bloquer les paramètres d'URL dans le robots.txt ?
Généralement non. Mieux vaut déclarer les paramètres inutiles dans la Search Console ou utiliser une balise canonique. Le robots.txt est un outil grossier pour un problème de finesse.
Casse, casse, casse
Les chemins sont sensibles à la casse. Disallow: /Images/ ne bloque pas /images/. Sur un site en Linux, c'est cohérent avec le serveur. Sur un site dont les URL contiennent des majuscules, cela devient un piège silencieux.
Bon, et il y a les cas particuliers de robots. AdsBot-Google, qui vérifie la qualité des pages de destination pour Google Ads, n'obéit pas aux règles du User-agent: * : il faut un bloc dédié si vous voulez le bloquer. Même logique pour certains robots d'IA génératives, qui ont leurs propres user-agents et qui n'appliquent pas toujours ce que vous croyez.
| Directive | Effet | Piège classique |
|---|---|---|
| User-agent: * | Cible tous les robots sans bloc dédié | Croit qu'il prime sur les blocs nommés |
| Disallow: / | Bloque tout le site | Poussé par erreur depuis la préprod |
| Allow: /dossier/ | Exception dans une zone bloquée | Doit être plus long que le Disallow |
| Sitemap: … | Indique le plan de site | URL absolue obligatoire |
La procédure pour ne plus jamais casser votre fichier
Voilà comment je procède aujourd'hui, après avoir commis à peu près toutes les erreurs du tableau ci-dessus. Rien de compliqué, juste de la discipline.
- Conserver le fichier dans un dépôt Git, avec un diff visible à chaque modification.
- Avoir un robots.txt distinct en préproduction :
Disallow: /y est non seulement acceptable, mais souhaitable, pour éviter que Google indexe des versions de test. - Vérifier que le fichier n'est pas écrasé par le pipeline de déploiement (le cas typique : le fichier de préprod qui remonte en prod).
- Tester la syntaxe avec le rapport sur les fichiers robots.txt de la Search Console, puis avec l'inspection d'URL sur deux ou trois pages sensibles.
- Surveiller, la semaine suivante, la courbe de pages explorées : une chute brutale est le premier signal d'alerte.
Un fichier minimal et bien tenu vaut mieux qu'un fichier savant. Voici la version que je déploie par défaut, à ajuster selon les besoins :
User-agent: *
Disallow: /admin/
Disallow: /panier/
Allow: /panier/validation/
Sitemap: https://exemple.com/sitemap.xml
Comment vérifier un fichier robots.txt en production ?
Trois vérifications suffisent, dans cet ordre. D'abord, saisir l'adresse du fichier dans un navigateur en navigation privée : vous devez voir le texte brut, sans page d'erreur ni redirection. Ensuite, passer par le rapport dédié de la Search Console, qui signale les lignes non reconnues. Enfin, inspecter une URL que vous croyez bloquée : l'outil vous indique explicitement si l'exploration est empêchée par ce fichier, et par quelle directive.
Un robots.txt par domaine ou partagé ?
Un fichier par domaine et par sous-domaine. Pas de mutualisation possible, pas d'héritage. Si votre site est décliné sur plusieurs domaines (versions localisées, par exemple), chaque domaine doit avoir son propre fichier, cohérent avec son contenu.
Ce qui reste quand on a tout bien réglé
Le robots.txt n'est pas un outil de sécurité. Il n'empêche pas un concurrent curieux de lire vos pages, et il ne protège rien : les robots malveillants l'ignorent. Tout au plus freine-t-il les robots polis.
Et c'est peut-être là le vrai piège : on passe du temps à écrire des règles dans ce fichier, alors que la plupart des problèmes qu'on cherche à résoudre se règlent ailleurs. Une page à retirer des résultats ? noindex. Un budget de crawl gaspillé ? Canoniques et maillage interne. Un contenu dupliqué ? Redirections.
Le robots.txt reste ce qu'il a toujours été : un panneau indicateur, pas une barrière. Le jour où vous l'aurez compris, vous arrêterez d'y mettre des règles au cas où — et vous mettrez enfin des règles qui servent.
