Fichier robots.txt : bonnes pratiques et erreurs à éviter pour un SEO au top

Un fichier robots.txt vide, deux lignes, et un site entier qui disparaît de Google pendant onze jours. C'est la mésaventure qu'un client m'a racontée un lundi matin, paniqué, après qu'un prestataire ait « nettoyé » son fichier en y laissant un Disallow: / malencontreux. Le trafic organique s'est effondré de 68 % en une semaine. Le diagnostic a pris vingt minutes. La réparation, cinq secondes. La reprise, presque deux semaines.

Le fichier robots.txt a cette particularité agaçante : il est invisible pour vos visiteurs, souvent oublié pendant des mois, mais la moindre virgule mal placée peut coûter très cher. Et paradoxalement, beaucoup de ceux qui le modifient n'ont jamais ouvert la documentation officielle. Je vais vous montrer comment je procède aujourd'hui, ce que j'ai appris à la dure, et les erreurs que je vois revenir sans cesse dans les audits.

Fichier robots.txt : ce qu'il contrôle vraiment (et ce qu'on croit à tort)

La confusion la plus répandue — je la rencontre dans environ un audit sur deux sur des sites de taille moyenne — consiste à croire qu'un Disallow retire une URL des résultats de recherche. Faux. Si une page est bloquée au crawl mais qu'un lien externe pointe vers elle, Google peut parfaitement l'indexer sans en connaître le contenu. Résultat : une page sans description, sans image, avec un titre brut. Aïe.

Exploration vs indexation : deux mécanismes distincts

Le robots.txt indique aux robots ce qu'ils sont autorisés à parcourir. L'indexation, elle, dépend d'une balise <meta name="robots" content="noindex">, d'un en-tête HTTP X-Robots-Tag ou d'une protection par mot de passe. Pour retirer réellement une page des résultats, c'est noindex qu'il faut poser, pas Disallow.

Et là, piège classique : si vous bloquez la page en robots.txt et mettez du noindex, le robot ne lira jamais la balise. La page reste indexée. J'ai vu cette configuration rester en place plus d'un an sur un blog à 400 articles, parce que personne ne vérifiait.

À quoi sert le fichier, concrètement

• Éviter de gaspiller le budget de crawl sur des URL sans intérêt (filtres, paniers, paramètres de tri).
• Protéger des zones sensibles au crawl massif (recherche interne, sessions).
• Pointer vers les plans de site avec la directive Sitemap:.

C'est un outil de pilotage du crawl. Pas un outil SEO au sens strict. Google le précise depuis longtemps : il ne consacre pas de budget spécifique à un fichier fourni, et son absence (ou sa présence) ne change pas le classement.

Les erreurs robots.txt les plus coûteuses (et comment les corriger)

Parlons concret. Voici les sept erreurs que je retrouve en boucle, avec la ligne fautive et sa version corrigée. Je les ai toutes commises au moins une fois — la deuxième dans la liste m'a personnellement coûté deux semaines de trafic.

Erreur n°1 : le Disallow global oublié

Une ligne Disallow: / bloque l'intégralité du domaine. C'est souvent un reste de phase de développement ou d'une mise en maintenance rapide.

Correction : après toute intervention, testez dans l'outil d'inspection d'URL de la Search Console la directive « Tester le fichier robots.txt ». Vérifiez que vos pages principales sont bien « explorables ».

Erreur n°2 : bloquer les ressources de rendu

Un Disallow: /*.css ou Disallow: /js/ empêche le robot de charger la mise en page. Il analyse alors une version dégradée de votre contenu, sans menus, sans fonctionnalités, parfois sans texte utile dans la partie visible.

Un site de e-commerce que j'ai audité perdait manifestement du trafic sur ses fiches produits : les prix étaient injectés en JavaScript, et le script était bloqué. Le robot voyait une fiche sans prix. Correction : n'interdisez jamais l'accès aux fichiers CSS, JS et aux polices nécessaires à l'affichage.

Erreur n°3 : wildcards et symboles mal placés

Les jokers et $ sont puissants mais piégeux. Disallow: /? bloque toutes les URL avec paramètres — utile pour filtrer les tris. Disallow: /.pdf$ cible les PDF en fin d'URL. En revanche, Disallow: seul est invalide ; les robots ignorent la directive sans prévenir.

Erreur n°4 : conflits Allow / Disallow

Si vous écrivez Allow: /produits/ puis Disallow: /produits/, c'est la règle la plus longue (la plus spécifique) qui s'applique, pas la plus permissive. Sur des URL paramétrées, cette subtilité change tout. Je documente désormais chaque ligne par un commentaire pour éviter les surprises lors d'une reprise par un autre intervenant.

Erreur n°5 : oublier la directive Sitemap

Ajouter Sitemap: https://votresite.fr/sitemap.xml en fin de fichier coûte trois secondes et aide les robots à découvrir vos URL récentes plus vite. Beaucoup l'oublient, ce qui n'est pas dramatique mais représente une optimisation gratuite.

Erreur n°6 : syntaxe invalide

Un fichier robots.txt est très simple, mais il se casse facilement : caractère UTF-8 mal encodé (un BOM invisible), deux-points manquant après User-agent, casse non respectée (le nom du robot est sensible à la casse), ligne commençant par un espace. Le robot considère alors la ligne comme un commentaire. Il ne bloque rien, mais il ne bloque pas non plus ce que vous vouliez bloquer.

Erreur n°7 : fichier mal placé

Le fichier doit être accessible à l'adresse https://votredomaine.fr/robots.txt, à la racine. Un fichier placé dans /sous-dossier/robots.txt n'est pas lu. Idem si le fichier est protégé par une authentification ou renvoyé en erreur 500 : les robots considèrent alors qu'il n'existe pas et explorent sans restriction — l'inverse du but recherché.

Voici un récapitulatif comparatif des pratiques :

Pratique	Effet	Recommandation
Disallow: /	Bloque tout le site	Uniquement en maintenance temporaire
Disallow: /*.css	Casse le rendu visuel	À éviter absolument
Disallow: /recherche/	Économise du budget de crawl	Bonne pratique
Disallow + noindex	Le noindex n'est jamais lu	Choisir l'un ou l'autre, jamais les deux
Sitemap:	Découverte accélérée	À ajouter systématiquement

Comment vérifier un robots.txt pas à pas

La procédure que j'applique systématiquement après chaque modification, et que j'impose à mes équipes.

1. Ouvrez l'URL racine votredomaine.fr/robots.txt dans un navigateur en navigation privée : le fichier doit s'afficher en clair, sans mot de passe.
2. Dans la Search Console, ouvrez l'outil d'inspection d'URL sur trois pages types : la page d'accueil, une page catégorie, une fiche produit. Vérifiez que le statut indique « Explorable ».
3. Utilisez le rapport dédié aux fichiers robots.txt de la Search Console : il signale les erreurs de syntaxe et les blocages détectés.
4. Testez une version de test sur un environnement de préproduction (sous-domaine) avant de pousser en production. C'est une habitude qui m'a évité deux incidents sérieux cette année.
5. Conservez une copie du fichier précédent avant chaque déploiement. Un simple fichier texte horodaté suffit.

Astuce d'audit : faites un test avec l'outil de rendu de page de la Search Console. Il vous montre exactement ce que le robot voit. Si votre page apparaît vide de contenu utile, vous savez qu'une ressource est bloquée.

Faut-il un robots.txt par sous-domaine ?

Oui. Chaque sous-domaine (blog.exemple.fr, boutique.exemple.fr) est traité comme un site distinct. Il lui faut son propre fichier à sa propre racine. Une erreur courante : croire qu'un fichier sur le domaine principal s'applique automatiquement aux sous-domaines. Ce n'est pas le cas.

Le robots.txt peut-il aider au référencement ?

Non, pas directement. Aucun moteur ne le mentionne comme facteur de classement. Son bénéfice est indirect : il évite le gaspillage de budget de crawl et oriente les robots vers les pages stratégiques. Sur un gros site (plus de 50 000 URL), cet effet est mesurable — j'ai vu un site passer de 12 000 pages explorées à 30 000 en deux mois, simplement en bloquant les URL de filtres inutiles.

Ce que j'ai fini par adopter

Après plusieurs années à jongler entre fichiers, je me suis fixé une règle simple : traiter le robots.txt comme du code, pas comme un fichier de configuration jetable. Cela signifie versionner le fichier dans le dépôt du site, interdire sa modification hors processus de déploiement, et exiger un test de validation avant mise en ligne.

Le déclic est venu d'une erreur bête : sur un projet, j'avais ajouté un Disallow: /*? pour bloquer les paramètres de tri produits. Sauf que ce joker bloquait aussi les paramètres de pagination, et Google a arrêté d'explorer les pages 2 et 3 des catégories. Trois semaines avant de m'en apercevoir. Depuis, chaque règle de wildcard est testée sur une dizaine d'URL réelles avant déploiement. Une demi-heure de vérification, contre trois semaines d'angles morts.

Le fichier robots.txt n'est pas un acteur du classement, mais c'est un point de défaillance majeur, silencieux, et souvent entre les mains de la personne la moins formée de l'équipe. Le traiter comme un fichier critique, c'est simplement admettre que l'invisible compte aussi.

Et si vous voulez un test rapide : ouvrez votre robots.txt là, maintenant, dans un nouvel onglet. Regardez chaque ligne. Demandez-vous, pour chacune, si vous seriez capable d'expliquer pourquoi elle est là. Si la réponse est « je ne sais pas », vous venez de trouver la prochaine chose à corriger.