Un fichier robots.txt mal écrit peut coûter très cher. Je le dis sans détour parce que je l'ai vécu : une ligne Disallow: / ajoutée en urgence un vendredi soir sur un site e-commerce que je gérais, et le lundi matin, la moitié du catalogue avait disparu des pages de résultats. Trois semaines pour revenir à la normale. Pour un fichier de six lignes.
C'est la drôle de nature de ce fichier : tout le monde sait qu'il existe, presque personne ne le relit, et il concentre une bonne partie des erreurs techniques les plus coûteuses en référencement naturel. Un robots.txt bien réglé orchestre le travail des moteurs de recherche sur votre site. Un robots.txt approximatif les fait travailler à l'aveugle, ou pire, les empêche d'accéder à ce qui compte. Voici ce que j'ai appris à force de casser des choses, et les bonnes pratiques qui évitent de recommencer.
Points clés à retenir
- Le robots.txt sert à piloter l'exploration, pas à bloquer une page dans les résultats : pour ça, c'est la balise
noindexou un mot de passe. - Il doit vivre à la racine du domaine, en texte brut, et rester accessible en HTTP 200.
- Un blocage des ressources CSS et JS nuit au rendu des pages par les robots.
- Les wildcards (
*) et le caractère$permettent des règles fines, mais leur ordre et leur portée se jouent au détail près. - Un fichier invalide déclenche des alertes d'audit et perturbe le crawl sans prévenir.
- Ce levier n'améliore pas le classement en soi : il évite de le dégrader.
Le robots.txt : un panneau indicateur, pas un cadenas
Le fichier robots.txt est un fichier texte déposé à la racine d'un site (par exemple https://votre-site.fr/robots.txt) qui indique aux robots d'exploration quelles URL ils sont autorisés à parcourir et lesquelles ils doivent ignorer. C'est un protocole d'usage, respecté par les principaux crawlеurs, mais ce n'est pas une barrière de sécurité : rien n'empêche techniquement un robot mal intentionné de l'ignorer.
Ce qu'il fait vraiment (et ce qu'il ne fait pas)
Sa fonction principale, c'est la gestion du budget de crawl. Sur un site qui génère des milliers de pages de recherche interne, de filtres à facettes ou de paramètres d'URL sans fin, orienter le robot vers les pages utiles évite qu'il s'épuise sur de la pagination stérile. Un de mes clients avait 40 000 URL d'archives de blog crawlées chaque mois pour 300 pages réellement stratégiques. Après un robots.txt correctement ciblé, la proportion s'est inversée en quelques semaines.
Mais attention à la confusion la plus répandue : le robots.txt ne retire pas une page des résultats de recherche. Il empêche seulement son exploration. Une page bloquée au crawl reste potentiellement indexable, et il arrive qu'elle apparaisse dans les résultats avec un simple titre, sans description. La bonne approche pour retirer une page de l'index, c'est la balise noindex (qui exige elle-même que la page soit explorée) ou la protection par mot de passe.
Syntaxe : les bonnes pratiques qui tiennent dans la durée
La syntaxe du robots.txt est simple, mais les pièges sont dans les détails. Voici un fichier de base propre, avec les directives les plus courantes.
User-agent: cible un robot précis (Googlebot,Bingbot) ou tous avec*.Allow: autorise explicitement une URL (utile pour isoler une exception).Disallow: interdit une URL ou un répertoire.Sitemap: déclare l'emplacement du plan de site, bonne pratique quasi systématique.Crawl-delay: ralentit la cadence — utile surtout pour les petits sites, moins pour les grands crawlеurs qui gèrent souvent le débit autrement.- Les commentaires démarrent par
#et n'influencent rien.
Wildcards et priorité des règles
Deux symboles font tout le sel du fichier : remplace n'importe quelle suite de caractères, et $ marque une fin d'URL. Par exemple, Disallow: /.pdf$ bloque tous les PDF du site. C'est puissant, et c'est exactement pour ça qu'il faut le rédiger avec soin.
Quand plusieurs règles se contredisent, les robots appliquent généralement la règle la plus spécifique, et en cas d'égalité de longueur, la plus restrictive l'emporte souvent. Mais les comportements varient d'un robot à l'autre sur les cas limites. Le conseil que je donne toujours : testez vos règles dans l'outil de vérification de la Search Console avant publication, et ne partez jamais du principe que tous les robots interprètent les wildcards de la même façon.
| Besoin | Le robots.txt doit-il être utilisé ? | Bonne alternative |
|---|---|---|
| Empêcher le crawl d'une URL | Oui | — |
| Retirer une page de l'index | Non | Balise noindex |
| Protéger du contenu privé | Non | Authentification / mot de passe |
| Signaler un plan de site | Oui | — |
| Ralentir la cadence de crawl | Partiellement | Réglages côté Search Console |
Les erreurs que je vois le plus souvent (et que j'ai commises)
Avouons-le : la plupart des problèmes de robots.txt ne viennent pas d'une syntaxe exotique. Ils viennent d'un fichier bâclé qu'on oublie de relire pendant des mois. Voici les cas que j'ai rencontrés, avec leurs symptômes concrets.
L'erreur n°1 : le Disallow: / accidentel
Un seul slash après Disallow bloque tout le site. C'est l'erreur la plus destructrice, et la plus facile à commettre lors d'une migration ou d'une mise en maintenance rapide. Le symptôme : les pages disparaissent progressivement des résultats, sans message d'erreur explicite. La correction : un déploiement rapide, et une vérification systématique dans la Search Console après coup.
Le blocage des ressources CSS et JavaScript
Beaucoup de robots.txt bloquent les répertoires /css/ ou /js/ par réflexe, pour « économiser » du crawl. Sauf que les moteurs de recherche modernes ont besoin d'explorer ces ressources pour rendre correctement les pages. Résultat : des pages jugées vides ou incomplètes, un rendu dégradé, et parfois une perte de visibilité sur des contenus qui fonctionnaient très bien. J'ai corrigé exactement ce problème sur un site dont les images étaient servies depuis un répertoire bloqué. Les pages n'affichaient plus leurs visuels côté robots, et le trafic organique avait baissé d'environ un quart sans aucune autre cause identifiable.
Fichier invalide, page HTML déguisée
Un robots.txt qui renvoie une page 200 remplie de HTML (typique d'une erreur de configuration) ou une erreur 5xx volontaire peut casser le crawl entièrement. Les outils d'audit remontent souvent un avertissement « robots.txt non valide », mais l'alerte passe inaperçue. La règle est simple : le fichier doit être en texte brut, sans balises, accessible en HTTP 200, et disponible à la racine du domaine — pas dans un sous-répertoire.
Checklist de démarrage propre
Sans refaire toute la théorie, un fichier solide se joue sur quelques réflexes.
- Valider la syntaxe avant publication avec un outil de test dédié.
- Faire un diff entre l'ancien et le nouveau fichier à chaque modification : une ligne suffit à déclencher un incident.
- Étudier l'impact sur le budget de crawl avant de bloquer un répertoire.
- Ne jamais bloquer les ressources de rendu (CSS, JS, images nécessaires).
- Déclarer systématiquement le
Sitemap. - Documenter les règles avec des commentaires : le fichier doit être lisible par un autre humain, pas seulement par un robot.
- Revoir le fichier à chaque refonte ou ajout majeur de section du site.
Eh bien, vous l'aurez compris : le robots.txt n'est pas un levier de classement. Personne n'a jamais gagné une position grâce à lui. Mais il peut en faire perdre beaucoup, et c'est ce qui en fait un fichier à traiter avec sérieux. Un fichier valide ne vous rendra pas plus visible ; un fichier cassé peut vous rendre invisible. La bonne question à se poser avant chaque modification : « Est-ce que je veux vraiment que ce contenu ne soit jamais exploré ? » Si la réponse n'est pas un oui catégorique, la ligne n'a probablement pas sa place dans le fichier.
