Fichier robots txt et exploration web

Quelques lignes de texte à la racine de votre site décident de ce que les robots ont le droit de visiter. Mal écrites, elles peuvent rendre tout votre travail invisible.

Chaque crawler qui visite votre site web demande d’abord un fichier précis, placé à la racine du domaine : le robots txt. Parmi tous les fichiers hébergés sur votre serveur, celui-ci occupe une place à part. Ce fichier texte indique aux moteurs de recherche les zones qu’ils peuvent explorer et celles qui leur sont fermées. Bien rédigé, il concentre l’exploration sur vos pages utiles et écarte les adresses techniques sans valeur. Mal rédigé, il peut couper un site entier de Google sans qu’aucune alerte visible ne se déclenche.

Le protocole d’exclusion des robots, un standard devenu norme

Le fichier robots.txt applique le protocole d’exclusion des robots, une convention née en 1994 et normalisée par l’IETF dans la RFC 9309, publiée en septembre 2022. Le principe tient en une phrase : avant d’explorer un site, un crawler lit le fichier placé à l’adresse votredomaine.fr/robots.txt et respecte les consignes qui le concernent. Chaque crawler s’identifie par un user agent, la chaîne qu’il déclare à chaque requête adressée au serveur web.

Concrètement, il s’agit d’un simple document texte, encodé en UTF-8, accessible publiquement. Il en existe un par combinaison de protocole et de sous-domaine : le robots.txt de www.exemple.fr ne s’applique pas à blog.exemple.fr, qui doit posséder le sien.

Une précision qui change tout : ces directives relèvent de la convention, pas de la contrainte. Googlebot, Bingbot et les robots des moteurs de recherche sérieux les respectent scrupuleusement. Un robot malveillant, un scraper ou un aspirateur de contenu les ignore sans conséquence. Le robots.txt n’est donc jamais un outil de sécurité ; des données confidentielles se protègent par mot de passe, pas par une directive Disallow.

Un robots.txt ne cache rien : il demande poliment aux robots de ne pas regarder.

La syntaxe du fichier robots txt

Un fichier robots.txt se construit avec quatre directives principales, regroupées en blocs. Chaque bloc s’ouvre sur une ligne User-agent qui désigne l’agent concerné, puis liste les règles qui s’appliquent à lui.

User-agent: *
Disallow: /panier/
Disallow: /recherche-interne/
Allow: /panier/aide/

Sitemap: https://www.exemple.fr/sitemap.xml

Le détail de chaque directive :

• User-agent : identifie le robot visé par le bloc. L’astérisque cible tous les robots ; un nom précis (Googlebot, Bingbot) cible un seul agent et prend le pas sur le bloc générique.
• Disallow : interdit l’exploration d’un chemin. La règle Disallow: /panier/ bloque toutes les URL commençant par ce préfixe ; un Disallow: / seul ferme le site entier.
• Allow : rouvre une exception dans un répertoire bloqué. La directive Allow n’existait pas dans le protocole d’origine, mais les principaux moteurs la gèrent depuis longtemps et la RFC 9309 l’a officialisée.
• Sitemap : indique l’adresse du plan de site XML, en URL absolue. Elle vaut pour tous les robots, indépendamment des blocs.

Deux pièges de syntaxe reviennent régulièrement dans mes audits SEO. Les chemins sont sensibles à la casse : /Panier/ et /panier/ sont deux règles différentes. Une taille plafond s’applique aussi : d’après la documentation officielle, tout contenu au-delà de 500 kibioctets est simplement ignoré.

Bloquer l’exploration n’empêche pas l’indexation

C’est le malentendu SEO le plus coûteux autour de ce fichier et je le retrouve dans une bonne partie des sites que j’audite. Une URL bloquée par Disallow n’est pas explorée, mais elle peut quand même apparaître dans les résultats de recherche. Si des liens externes pointent vers elle, Google l’indexe sur la seule foi de ces liens, avec un extrait vide ou la mention « Aucune information n’est disponible pour cette page ». Le rapport de couverture de Google Search Console regroupe ces informations sous le libellé « Indexée malgré le blocage par le fichier robots.txt ».

Pour retirer une page des résultats de recherche, le bon outil est la balise meta noindex, posée dans le code HTML. Le paradoxe mérite d’être souligné : cette balise ne fonctionne que si le robot peut lire la page. Bloquer une adresse dans le robots.txt tout en lui ajoutant un noindex revient à fermer la porte au facteur qui devait lire votre consigne.

La répartition des rôles est donc nette. Le fichier robots.txt gère l’exploration, c’est-à-dire le passage des robots et la consommation du crawl budget. Les balises meta et les en-têtes HTTP gèrent l’indexation, c’est-à-dire la présence dans l’index du moteur de recherche. Confondre les deux produit des pages fantômes qui traînent des mois dans les SERP.

Ce que je bloque, ce que je ne bloque jamais

Sur la plupart des sites web, quelques zones méritent un blocage, parce qu’elles consomment du budget de crawl sans rien apporter à votre référencement :

• Les résultats de recherche interne : ces pages générées à la volée créent un volume d’adresses quasi infini et dupliquent le contenu des catégories.
• Les tunnels de commande : panier, étapes de paiement, espace client, autant de zones à interdire aux crawlers.
• Les paramètres de tri et de filtre : quand une même liste de produits existe en dizaines de variantes d’adresses, pagination comprise, bloquer les paramètres concentre l’exploration sur la version canonique.
• Les environnements techniques : dossiers de scripts internes, versions d’impression, flux obsolètes.

À l’inverse, deux blocages font des dégâts directs sur le SEO. Ne bloquez jamais les fichiers CSS et JavaScript : Google affiche les pages comme un navigateur et a besoin de ces ressources pour comprendre la mise en page ; les lui interdire dégrade l’évaluation de la page entière, notamment sur mobile. Ne bloquez pas non plus les images que vous voulez voir remonter dans la recherche visuelle : un Disallow sur le dossier des médias vous sort de Google Images.

Ma règle de lecture est simple : chaque ligne Disallow doit avoir une justification écrite quelque part. Un fichier hérité de trois refontes successives, dont plus personne ne sait expliquer les règles, est un risque dormant.

Robots.txt et WordPress, le cas du fichier virtuel

WordPress illustre bien la façon dont un CMS gère cette ressource. Par défaut, aucun fichier physique n’existe sur le serveur : le CMS génère un robots.txt virtuel à la volée, qui bloque le répertoire /wp-admin/ tout en autorisant admin-ajax.php, nécessaire à certaines fonctions du site.

Pour le personnaliser, deux voies existent. Une extension comme Yoast SEO propose un éditeur intégré qui crée et modifie le fichier depuis l’administration, sans accès serveur. Vous pouvez aussi déposer un fichier robots.txt physique à la racine par FTP ; il prend alors le dessus sur la version virtuelle, définitivement.

Un point de vigilance propre à WordPress : la case « Demander aux moteurs de recherche de ne pas indexer ce site », dans les réglages de lecture. Cochée sur un site de préproduction puis oubliée au lancement, elle maintient le blocage en production et prive le site de tout référencement. Je vérifie cette case sur chaque site WordPress audité ; l’oubli est plus fréquent qu’on ne l’imagine.

GPTBot, ClaudeBot et les nouveaux user agents

Le protocole d’exclusion connaît une seconde vie avec les robots que les acteurs de l’IA envoient sur le web. OpenAI documente publiquement GPTBot, qui collecte des données pour l’entraînement de ses modèles et ChatGPT-User, l’agent que ChatGPT mobilise lors des navigations en direct ; Anthropic et Perplexity publient de même leurs user agents, sur le modèle d’OpenAI. Chaque user agent se pilote par un bloc dédié dans le robots.txt, selon la même logique de blocs.

La question posée aux éditeurs dépasse le SEO : elle est stratégique. Bloquer ces crawlers protège vos contenus de la collecte ; les autoriser rend ces mêmes contenus visibles dans les réponses générées. Lors de ma dernière formation sur la recherche générative, chez Babbar en juin 2026, le point a été posé clairement : un site absent des sources accessibles aux moteurs génératifs ne peut pas être cité dans leurs réponses. Le blocage systématique, réflexe défensif compréhensible, a donc un coût de visibilité qu’il faut assumer en connaissance de cause.

Mon conseil tient en une phrase : décidez crawler par crawler, en séparant les agents d’entraînement des agents de recherche et documentez ce choix comme n’importe quelle autre règle du fichier.

Tester votre fichier avec Google Search Console

Un robots.txt ne se modifie jamais à l’aveugle : une règle mal écrite se propage en quelques jours sur tout le site web. Google Search Console fournit les outils de contrôle nécessaires, via le rapport dédié accessible dans les paramètres de la propriété.

Cette routine prend moins d’une heure et devrait accompagner chaque refonte, chaque migration et chaque changement de CMS. La majorité des accidents d’exploration que je rencontre datent précisément de ces moments-là.

Votre fichier relu règle par règle avant la prochaine mise en production

Affichez le robots.txt de votre site maintenant et demandez-vous, pour chaque ligne Disallow, qui l’a écrite et pourquoi. Si une seule règle reste sans réponse, vous tenez la première étape de votre prochain chantier SEO. Un fichier de dix lignes maîtrisées protège mieux votre crawl que cinquante règles héritées que personne n’ose toucher.

L'AUTEUR

Régis Cuomo

Consultant SEO senior, 8 années de référencement naturel, conférencier (SEO Summit, Bizz & Buzz). Expert netlinking et GEO.

X (Twitter)LinkedInInstagram