Fichier robots.txt : bonnes pratiques pour un SEO sans erreur

Un client m'appelle un mardi matin, paniqué : « Google a désindexé tout mon blog du jour au lendemain. » Je demande le robots.txt. Il me l'envoie. Deux lignes :

User-agent: *
Disallow: /

Voilà. Toute une après-midi de travail perdue parce qu'un stagiaire avait décommenté une ligne dans un plugin WordPress. Le pire ? Ce fichier traînait là depuis trois semaines avant que qui que ce soit s'en aperçoive. Et c'est exactement le genre d'incident que le fichier robots.txt peut provoquer quand on le traite comme un détail technique plutôt que comme une pièce maîtresse du référencement.

Ce petit fichier texte, à la racine de votre site, dicte aux robots d'exploration ce qu'ils peuvent visiter. Mal configuré, il sabote votre visibilité. Bien utilisé, il oriente le budget de crawl vers les pages qui comptent. La nuance est énorme, et peu de gens la maîtrisent vraiment.

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

Beaucoup imaginent que le robots.txt « cache » des pages à Google. Faux. Ce fichier indique simplement à un crawler : « ici, tu peux passer ; là, évite. » Si le robot décide d'ignorer la consigne — et certains le font —, rien ne l'en empêche techniquement. C'est une politesse, pas un verrou.

Robots.txt, c'est quoi au juste ?

Un fichier texte hébergé à la racine d'un domaine, qui s'adresse aux user-agents (les robots des moteurs) pour leur signaler les zones du site qu'ils peuvent ou non explorer. Il se lit de haut en bas, par blocs. Chaque bloc commence par un User-agent, suivi des directives qui le concernent.

Le fichier doit être accessible à une adresse unique : https://votresite.com/robots.txt. Si votre site existe en http et https, ou en www et sans www, sachez que les robots considèrent chaque variante comme un hôte distinct. J'ai vu un site dont la version https avait un robots.txt correct, tandis que la version http en hébergeait un tout autre — reliquat d'une migration oubliée. Résultat : des incohérences de crawl pendant des mois.

Exploration n'est pas indexation

Bloquer une URL via Disallow n'empêche pas Google de l'afficher dans ses résultats s'il la découvre par un lien externe. Il ne pourra simplement pas en lire le contenu. Une page peut donc apparaître avec un titre vide, ou un extrait bidon.

Pour retirer une page de l'index, il faut soit une balise <meta name="robots" content="noindex">, soit un en-tête HTTP X-Robots-Tag: noindex, soit une protection par mot de passe. Et attention au piège classique : si vous bloquez l'URL dans le robots.txt, le robot ne pourra pas lire le noindex qu'elle contient. Les deux directives se neutralisent.

• Bloquer l'exploration d'une URL et vouloir son déréférencement : incompatible.
• Autoriser l'exploration et poser un noindex : la bonne combinaison.
• Bloquer une zone volumineuse sans valeur (paramètres de tri, paniers, recherche interne) : excellent usage du robots.txt.
• Bloquer des ressources CSS ou JS utiles au rendu : Google rend moins bien la page et votre SEO en pâtit.

Les bonnes pratiques d'un robots.txt qui ne vous trahit pas

Un robots.txt propre tient en quelques règles simples. Le problème, c'est que la plupart des sites que j'audite en contiennent au moins une erreur. Souvent invisible jusqu'au jour où elle coûte cher.

Un exemple de fichier robots txt propre, copiable tel quel

Voici un squelette que je pose par défaut sur beaucoup de sites clients. À adapter, évidemment :

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /panier/
Disallow: /*?s=
Disallow: /*?orderby=
Disallow: /tmp/

Sitemap: https://votresite.com/sitemap.xml

Trois choses à comprendre dans ce bloc. D'abord, Allow prime sur Disallow quand la règle est plus spécifique : c'est pourquoi la ligne Allow: /wp-admin/admin-ajax.php fonctionne malgré le Disallow général sur /wp-admin/. Ensuite, les jokers * (n'importe quelle chaîne) et $ (fin d'URL) permettent de cibler des motifs sans multiplier les lignes. Enfin, la directive Sitemap évite de devoir déclarer votre plan de site séparément.

Un point que je vois souvent mal compris : l'ordre des lignes dans le fichier n'importe pas. Seule la longueur du motif compte. Une règle Disallow: /blog/ ne bloquera pas /blog/article-test si une règle Allow: /blog/article-test apparaît ailleurs — elle sera plus spécifique, donc gagnante.

Gestion des erreurs et cas limites (le vrai sujet)

Un robots.txt qui renvoie un code 5xx (erreur serveur) est traité par Google comme un signal de blocage temporaire : le crawler cesse de visiter les pages du site pendant un temps. Si le problème dure, l'indexation ralentit, puis s'arrête. Un 404, en revanche, indique que le fichier n'existe pas — Google considère alors que tout est autorisé.

Les redirections sont également piégeuses. Un robots.txt qui redirige vers une autre URL est suivi, dans une certaine limite, mais si la chaîne de redirection est longue ou boucle, le robot abandonne. J'ai déjà vu un site dont le robots.txt redirigeait vers la page d'accueil par une mauvaise règle .htaccess — Google interprétait cela comme une absence de fichier, et explorait frénétiquement des milliers de pages de paramètres inutiles.

Autre limite : la taille. Google lit environ 500 Ko de contenu dans un robots.txt. Au-delà, les directives sont ignorées. Rare, mais existant sur de très gros sites e-commerce.

Comment trouver le robots.txt d'un site

Il suffit de taper l'URL du site suivie de /robots.txt dans la barre d'adresse. Exemple : https://exemple.com/robots.txt. Une page s'affiche avec le contenu brut. Si vous voyez une erreur 404, c'est qu'il n'y a pas de fichier — et donc que tout est explorable, ce qui peut être un problème si vous avez des zones sensibles.

Pour vérifier le rendu côté Google, le plus fiable reste le rapport dédié dans la Search Console. Il indique la dernière date de récupération du fichier, et signale les erreurs de syntaxe éventuelles.

Créer un fichier robots.txt sans se tirer une balle dans le pied

La création est triviale. La sécurisation l'est moins. Sur WordPress, plusieurs options existent, et l'une d'elles est un nid à problèmes.

Robots.txt sur WordPress : la méthode propre

WordPress génère par défaut un robots.txt virtuel. Si vous ne mettez rien, il est fonctionnel pour un blog simple. Mais dès que vous voulez personnaliser, deux voies s'offrent :

1. Via un plugin SEO (Yoast, Rank Math, SEOPress) qui propose un éditeur de fichier. Pratique, mais vos règles survivent-elles à une désactivation du plugin ? Pas toujours.
2. Via un fichier physique à la racine du serveur, créé par FTP. Plus robuste, et détaché du cycle de vie des plugins.

Ma préférence va à la seconde option, pour une raison simple : quand on désactive un plugin SEO pendant une phase de test, il arrive qu'il supprime sa version virtuelle du robots.txt. Si rien ne prend le relais, votre fichier disparaît. Un fichier physique est indépendant.

Tester et valider un robots.txt

Le test le plus utile, à mon sens, est celui de la Search Console : il affiche les éventuelles erreurs, le code de réponse, et permet de tester une URL spécifique pour voir si elle est bloquée. Je le fais systématiquement après chaque modification de structure.

Autre vérification à intégrer dans la routine : consulter le rapport de couverture pour repérer les pages soudainement « exclues par le robots.txt ». Un pic sur ce motif est presque toujours le signe d'une règle trop large.

Erreur fréquente	Conséquence	Correctif
Disallow: / oublié après un test	Désindexation complète du site	Supprimer la ligne immédiatement, resoumettre le sitemap
Blocage de /wp-content/	Images, CSS et JS invisibles pour le crawler	Autoriser au moins /wp-content/uploads/
Règle trop large sur un paramètre	Contenu utile jamais exploré	Restreindre la règle au paramètre précis
Fichier renvoyant un 5xx	Crawl suspendu temporairement	Corriger le serveur, surveiller le rapport robots.txt
Robots.txt absent (404)	Aucune restriction, tout est explorable	Créer un fichier minimal si des zones sensibles existent

La stratégie derrière le fichier, pas seulement la syntaxe

Le robots.txt n'est pas qu'une couche technique. C'est un levier d'orientation. Un site de 40 000 pages produit naturellement des milliers d'URL sans valeur : filtres, tris, paginations, sessions. Chaque URL explorée est une ressource consommée. Les rediriger vers des pages à forte valeur, c'est gagner du temps d'indexation.

Sur un projet e-commerce que je suivais, nous avions bloqué les paramètres de tri et de filtres les plus générateurs d'URL. Le nombre de pages explorées quotidiennement a légèrement baissé, mais le nombre de pages utiles indexées a augmenté. Ce n'est pas une preuve statistique, juste une observation honnête sur plusieurs mois. Et cela m'a convaincu d'un principe : mieux vaut un crawl modeste et ciblé qu'un crawl massif et dispersé.

Trois erreurs que j'ai commises (et que vous pouvez éviter)

La première fois que j'ai touché à un robots.txt en production, j'ai appliqué la modification directement. Sans test. Sans sauvegarde. Le fichier avait une faute de frappe dans le nom du user-agent, ce qui l'a rendu inopérant — je n'ai compris qu'au bout de dix jours, en voyant mes nouvelles pages stagner en exploration.

Deuxième erreur : bloquer /wp-includes/ pour « faire propre ». Sauf que des fichiers JS critiques y logent. Google rendait les pages sans leur script, ce qui a dégradé le rendu mobile perçu. J'ai corrigé en autorisant les fichiers nécessaires.

Troisième : oublier que les sous-domaines ont chacun leur propre robots.txt. Sur un site en blog.exemple.com et www.exemple.com, il faut un fichier par hôte. J'ai perdu une semaine à chercher pourquoi le blog n'était jamais exploré, alors que le fichier bloquait simplement tout.

Ce qui reste quand on a tout compris

Un robots.txt bien fait n'apporte rien de spectaculaire. Il ne fait pas grimper dans les résultats. Il évite juste les catastrophes. C'est un peu comme les freins d'une voiture : on ne les remarque jamais tant qu'ils fonctionnent.

La vraie question, au fond, n'est pas « comment écrire un robots.txt » — c'est « qu'est-ce que je veux que mon site raconte à un crawler ? » Si la réponse tient en une phrase claire, le fichier se déduit presque tout seul. Si elle est floue, aucune syntaxe ne vous sauvera.

Et si vous ne devez retenir qu'une chose : vérifiez votre fichier aujourd'hui, pas demain. La prochaine fois qu'un client m'appellera paniqué, j'aimerais que ce ne soit pas à cause d'une ligne oubliée dans un fichier de la taille d'un SMS.