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

Un client m'appelle un mardi matin, paniqué. Son trafic organique a chuté de 62 % en dix jours. Pas de pénalité manuelle dans la Search Console, aucune alerte, rien. Juste une courbe qui s'effondre. On passe deux heures à fouiller : balises, contenu dupliqué, maillage interne. Et puis je jette un œil à son fichier robots.txt. Une ligne. Une seule.

Disallow: /

Un développeur avait poussé ça sur l'environnement de production au lieu du staging, un vendredi soir, pour "éviter que Google indexe les pages de test". Trois semaines plus tard, Googlebot ne crawle plus rien. Le fichier robots.txt est ce genre d'objet : invisible quand il fonctionne, catastrophique quand il est mal écrit. Et contrairement à ce qu'on croit souvent, il ne fait pas du tout ce que la plupart des gens imaginent.

Points clés à retenir

Le robots.txt contrôle le crawl, pas l'indexation : une page bloquée peut quand même apparaître dans les résultats si d'autres sites la lient.
Il doit être accessible à la racine exacte du domaine (/robots.txt), sans redirection ni erreur 5xx.
Un Disallow sur une page contenant une balise noindex est une erreur classique : Google ne verra jamais le noindex puisqu'il ne crawle pas la page.
La casse compte : user-agent en minuscules n'est pas reconnu par tous les robots.
Un robots.txt trop permissif expose des URL techniques au crawl et dilue le budget d'exploration sur les grosses structures.
En cas de doute, commentez la règle suspecte plutôt que de tout bloquer : un fichier neutre ne casse jamais un site.

Fichier robots.txt : ce qu'il fait vraiment (et ce qu'on lui prête à tort)

Vous avez déjà vu passer cette phrase dans un audit : "il faut ajouter la page dans le robots.txt pour qu'elle disparaisse de Google". C'est faux, et c'est un des contresens les plus répandus.

Robots.txt, c'est quoi au juste ?

Un fichier texte à la racine d'un domaine qui s'adresse aux robots d'exploration. Il leur dit : "tu peux aller ici, tu ne peux pas aller là". C'est un panneau de signalisation, rien de plus. Googlebot lit le fichier avant de crawler une URL ; si la règle lui interdit l'accès, il passe son chemin. Point.

La conséquence logique fait mal : si Googlebot ne crawle pas une page, il ne peut pas lire son contenu. Or c'est le contenu qui détermine l'indexation. Une URL bloquée par Disallow peut malgré tout atterrir dans l'index si suffisamment de liens externes pointent vers elle — Google indexera alors une page vide, sans snippet utile. J'ai vu plusieurs sites de e-commerce se retrouver avec des dizaines d'URL "fantômes" dans les résultats à cause de ça. Le diagnostic est pénible, la correction l'est encore plus.

La distinction crawl / indexation qui change tout

Il faut la garder en tête à chaque ligne du fichier :

Objectif	Bon outil	Mauvais outil
Empêcher un crawl inutile	robots.txt	—
Retirer une page des résultats Google	Balise `noindex` (page crawlable)	robots.txt
Protéger un dossier privé	Authentification serveur	robots.txt
Signaler une zone de test	Environnement staging séparé	robots.txt poussé en prod
Déclarer le sitemap	Ligne `Sitemap:` dans le robots.txt	—

Le point sur la protection mérite qu'on s'y arrête. Un robots.txt n'est pas une sécurité. N'importe qui peut lire le fichier, et un robot malveillant l'ignorera complètement. J'ai déjà retrouvé une liste d'URL d'administration exposée fièrement dans un Disallow — c'était en réalité une carte au trésor pour qui voulait explorer. Si le dossier doit être privé, c'est mot de passe ou restriction IP.

Bonnes pratiques de rédaction : la syntaxe qui ne pardonne pas

La structure de base tient en quatre lignes : un User-agent, puis des directives Disallow et Allow, la casse exacte, et un saut de ligne entre chaque bloc. Rien de sorcier. Et pourtant, quand je reprends un robots.txt inconnu, je trouve une erreur de syntaxe dans environ un fichier sur deux. Voici celles qui reviennent le plus.

Exemple de fichier robots.txt correct

Un fichier propre pour un site classique, avec WordPress ou un CMS équivalent :

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /*?orderby=
Sitemap: https://www.monsite.fr/sitemap.xml

Trois choses à remarquer. D'abord Allow après Disallow sur admin-ajax.php : sans ça, certaines fonctionnalités front du site cassent pour Googlebot. Ensuite l'usage du wildcard dans /?orderby=, qui cible tous les tris de paramètres d'URL. Enfin la ligne Sitemap, qui n'est pas une directive de crawl mais une déclaration utile — elle accepte plusieurs lignes si vous avez plusieurs sitemaps.

Les erreurs de syntaxe qui coûtent cher

La casse : User-agent avec un U majuscule est correct ; user-agent tout en minuscules n'est pas garanti d'être reconnu. De même, les chemins sont sensibles à la casse sur la plupart des serveurs Linux.
Le et le $ : le premier remplace n'importe quelle chaîne, le second ancre la fin de l'URL. Disallow: /.pdf$ bloque les PDF, pas les pages contenant ".pdf" ailleurs dans l'URL. Beaucoup de gens l'ignorent.
L'ordre des règles : quand plusieurs règles s'appliquent, la plus spécifique l'emporte. Un Allow: /dossier/page-a bat un Disallow: /dossier/.
La ligne Sitemap mal placée : elle se met en dehors des blocs User-agent, pas à l'intérieur. Sinon elle est ignorée.
Les commentaires : # en début de ligne fonctionne, mais un commentaire collé après une directive peut être mal interprété par certains robots.

Et un détail qu'on ne répète jamais assez : un Disallow: vide bloque tout. Un Disallow: / aussi. Les deux sont des bombes à retardement à ne jamais laisser traîner dans un fichier de production.

Tester son robots.txt : trois méthodes qui marchent

La question qu'on me pose souvent : "comment trouver le robots.txt d'un site que je ne gère pas ?" Il suffit de taper https://ledomaine.fr/robots.txt dans un navigateur. Si le fichier existe, il s'affiche en texte brut. S'il n'existe pas, vous verrez une erreur 404 — et c'est équivalent à un fichier totalement ouvert, puisque l'absence de règle signifie "tout est crawlable".

Le test en direct, l'outil le plus fiable

Pour un site que vous administrez, le test en direct de la Search Console reste mon outil de prédilection, et de loin. Il permet de coller une URL et de voir exactement quel robot est autorisé ou non sur une page donnée. J'ai résolu plus de cas avec cet outil qu'avec n'importe quel validateur externe.

Les deux autres méthodes utiles :

Le rapport "Fichier robots.txt" dans la Search Console, qui affiche la version lue par Google et signale les erreurs de lecture serveur (redirections, 5xx).
Un test par ligne de commande avec curl -I https://ledomaine.fr/robots.txt, pour vérifier que le code HTTP est bien un 200 et que le Content-Type est du texte brut. Un fichier servi en HTML ou derrière une redirection est traité comme s'il n'existait pas.

Diagnostiquer un robots.txt bloquant

Trois symptômes doivent vous alerter. Une chute brutale des impressions dans la Search Console avec un crawl qui s'effondre au même moment. Un nombre de pages indexées qui stagne ou recule sans raison éditoriale. Et une page qui disparaît des résultats alors qu'elle est toujours en ligne et accessible en navigation privée.

La procédure de correction est simple, mais il faut la jouer proprement :

Identifier la règle fautive dans le fichier.
La commenter avec un # plutôt que de la supprimer, pour garder une trace de ce qui a été tenté.
Publier, puis redemander une indexation des pages principales depuis la Search Console.
Surveiller le rapport de couverture sur deux à trois semaines — le crawl ne redémarre pas instantanément.

Sur un site de taille moyenne, j'ai constaté qu'un retour à la normale après un blocage accidentel prend généralement entre deux et six semaines. Pas deux jours. C'est ce qui rend la prévention tellement plus rentable que le sauvetage.

Le cas WordPress et les pièges qui reviennent

WordPress génère un robots.txt virtuel tout à fait correct par défaut, avec deux lignes : Disallow: /wp-admin/ et un Sitemap vers le fichier natif. Surprenant de constater qu'à chaque audit, je vois des plugins qui écrasent ce fichier par un fichier statique maladroit — un module SEO ancien, un plugin de sécurité zélé, un plugin de cache qui déplace le fichier à la racine avec un contenu approximatif.

Comment modifier son robots.txt sous WordPress

Deux méthodes, à choisir selon le degré de contrôle souhaité.

La plus simple : passer par le hook robots_txt dans le functions.php de votre thème enfant, ou via un plugin dédié. Le fichier reste virtuel et survit aux mises à jour. La plus manuelle : créer un fichier physique à la racine via FTP ou SFTP. Il prendra le dessus sur la version virtuelle, ce qui peut être pratique pour figer les règles. Mais attention, il faudra le maintenir à la main et le versionner, sinon une mise à jour de thème ne le sauvera pas.

Pour un site bilingue ou multilingue, j'ajoute systématiquement une ligne Sitemap: par langue, chacune pointant vers le sitemap correspondant. C'est un détail, mais qui aide Google à découvrir les versions traduites sans passer par le sitemap index principal.

Les erreurs à éviter absolument (et celle que j'ai commise)

Avouons-le, la première fois que j'ai touché à un robots.txt, j'ai fait une erreur grossière. Je voulais retirer une catégorie devenue obsolète des résultats Google. J'ai ajouté Disallow: /categorie-obsolete/. Logique, non ? Sauf que Googlebot ne pouvait plus crawler la page, donc ne voyait jamais la balise noindex que j'avais aussi mise. Résultat : la catégorie est restée indexée pendant des semaines, avec un titre et un snippet obsolètes. La bonne méthode aurait été de la laisser crawlable avec un noindex actif, puis d'attendre que la page disparaisse naturellement des résultats, puis seulement de bloquer le crawl.

Voici celles que je retrouve le plus souvent :

Bloquer une page qu'on veut faire disparaître au lieu d'utiliser noindex — l'erreur qui piège tout le monde au moins une fois.
Pousser le fichier sur le mauvais environnement — mon client du début en sait quelque chose.
Oublier le fichier dans les versions multilingues, et bloquer les sous-dossiers de langue par mégarde.
Ne jamais relire le fichier après une refonte : les URL changent, les règles restent, et l'ancien Disallow bloque les nouvelles pages.
Utiliser un robots.txt pour cacher des choses qu'on ne veut pas voir, alors qu'il s'agit en fait d'une question de contenu et de qualité.

Une habitude que je vous recommande et sur laquelle je ne démordrai pas : garder une version "neutre" du fichier, avec seulement les règles WordPress par défaut et le sitemap. En cas de doute, on revient à cette version. Aucun site bloqué, jamais. Vous perdez quelques minutes, vous gagnez parfois plusieurs semaines de trafic.

La vraie question n'est d'ailleurs pas "que faut-il mettre dans mon robots.txt". C'est plutôt : "qu'est-ce que je veux que Google ne crawle pas, et pourquoi ?" La réponse vous évitera l'essentiel des erreurs décrites ici. Le fichier n'est qu'un panneau ; ce sont les intentions qui le rendent utile ou dangereux.