Robots.txt : ce qu'il bloque, et ce qu'il ne bloque pas

À quoi sert vraiment un fichier robots.txt ?

Son rôle tient en un mot : l'exploration. Il oriente le travail des robots, il ne décide pas de ce qui finit dans les résultats de recherche, et c'est toute la nuance que la suite de cet article détaille.

Ce fichier se place uniquement à la racine du domaine, à l'adresse /robots.txt, jamais dans un sous-dossier : un fichier disposé ailleurs est tout simplement ignoré. Chaque sous-domaine, comme blog.exemple.fr ou boutique.exemple.fr, a besoin de son propre fichier, puisque les règles définies pour un domaine ne s'appliquent pas automatiquement à ses sous-domaines.

Un fichier robots.txt change vraiment quelque chose dans un nombre limité de situations.

• Un site volumineux, où éviter de surcharger inutilement le serveur devient un vrai enjeu
• Des pages sans intérêt réel à faire explorer, comme les résultats de recherche interne du site
• Des fichiers techniques qui n'ont aucun rôle dans le rendu réel des pages, comme certains scripts de build

En dehors de ces cas, un robots.txt reste une bonne pratique par défaut, sans changer la donne à lui seul.

User-agent: *
Disallow: /admin/
Disallow: /panier/
Disallow: /recherche/

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

Le fichier robots.txt empêche-t-il une page d'être indexée dans Google ?

Non. Google ne peut pas explorer le contenu d'une page bloquée par robots.txt. Il peut malgré tout indexer son URL et l'afficher dans les résultats de recherche, sans description, si d'autres pages pointent vers elle avec un texte descriptif. C'est Google lui-même qui le précise dans sa documentation officielle.

Concrètement, Google explore le web en suivant les liens. Quand une page bloquée par robots.txt reçoit des liens externes accompagnés d'un texte d'ancre descriptif, Google peut afficher cette URL dans ses résultats sans description ni extrait, en s'appuyant uniquement sur ce texte d'ancre. C'est la confusion la plus coûteuse en référencement technique : une page que l'on croyait protégée par erreur reste malgré tout visible, sous une forme dégradée, dans les résultats de recherche.

Pour retirer réellement une page des résultats de recherche, robots.txt n'est pas le bon outil : il faut utiliser une balise noindex, une protection par mot de passe, ou la suppression pure et simple de la page. Ces trois méthodes agissent sur l'indexation ; robots.txt, lui, agit uniquement sur l'exploration.

Comment écrire les directives User-agent, Disallow, Allow et Sitemap ?

Google n'accepte que quatre champs dans un fichier robots.txt : User-agent, Disallow, Allow et Sitemap. Le champ crawl-delay, parfois recommandé ailleurs sur le web, n'est pas pris en charge par Google. Chaque règle s'écrit sur une ligne, sous la forme d'un champ, de deux-points, puis d'une valeur.

User-agent cible le ou les robots concernés par les règles qui suivent ; un astérisque seul s'adresse à tous les robots sans distinction. Disallow liste les chemins interdits à l'exploration, une ligne par chemin. Allow crée une exception à l'intérieur d'un chemin par ailleurs interdit. Sitemap indique l'URL complète du fichier sitemap, et rien n'empêche d'en déclarer plusieurs lignes dans le même fichier robots.txt.

Autre nuance à connaître : les noms de champs et la valeur du champ User-agent ne sont pas sensibles à la casse, mais les valeurs de Disallow, Allow et Sitemap le sont. Une majuscule mal placée dans un chemin peut donc laisser une page exposée que l'on croyait bloquée.

La ligne Sitemap se limite ici à sa simple déclaration : un article dédié détaille comment construire, découper et vérifier un sitemap, un fichier qui répond à une question différente de robots.txt.

Comment utiliser les jokers * et $ dans un fichier robots.txt ?

Google reconnaît deux jokers dans les valeurs de chemin d'un fichier robots.txt : l'astérisque représente zéro ou plusieurs caractères, et le symbole dollar marque la fin de l'URL. Combinés, ils permettent de cibler des familles entières d'adresses sans les lister une par une.

Prenons un site e-commerce avec des pages de filtre et de tri, générées automatiquement à partir des mêmes pages produits : ce type d'adresse n'a aucun intérêt à être exploré séparément, contrairement aux pages produits et catégories elles-mêmes, qui doivent le rester.

User-agent: *
Disallow: /*?tri=
Disallow: /*?filtre=
Disallow: /*.pdf$

Allow: /produits/
Allow: /categories/

La ligne qui cible le paramètre de tri bloque toute adresse qui le contient, quel que soit le chemin qui précède, grâce à l'astérisque. La ligne qui cible les fichiers PDF ne bloque que les adresses qui se terminent par cette extension, sans toucher une URL qui contiendrait ce texte au milieu du chemin, grâce au symbole dollar. Les deux lignes Allow confirment que les pages produits et catégories restent explorables malgré ces règles plus générales.

Quelle est la taille maximale d'un robots.txt, et que se passe-t-il en cas d'erreur serveur ?

Google applique une limite de taille de 500 kibioctets à un fichier robots.txt : tout contenu qui dépasse cette taille est ignoré. Un fichier qui s'en approche doit être consolidé, pas simplement tronqué, sous peine de perdre des règles sans même s'en apercevoir.

Le comportement de Google face à un fichier robots.txt inaccessible dépend ensuite du code HTTP renvoyé par le serveur. Le tableau ci-dessous résume les quatre cas documentés par Google :

Le cas de l'erreur 5xx est le plus contre-intuitif : Google marque d'abord une pause de 12 heures dans l'exploration du site, plutôt que d'ignorer purement et simplement le fichier robots.txt. Il s'appuie ensuite sur la dernière version valide connue pendant 30 jours, en retentant régulièrement de la récupérer. Si le problème persiste au-delà de ce délai, Google revient à une exploration sans restriction si le site est de nouveau joignable, ou cesse de l'explorer si c'est le site lui-même qui reste indisponible.

Faut-il bloquer GPTBot, ClaudeBot, PerplexityBot ou Google-Extended ?

Ça dépend de l'objectif du site : ces robots ne font pas tous la même chose. Les bloquer n'a pas la même conséquence selon qu'ils servent à entraîner un modèle ou à afficher un site dans une réponse générée. Aucun de ces choix n'est mauvais en soi, encore faut-il savoir ce que chacun implique réellement.

Ces neuf robots se répartissent en trois familles, selon ce qu'ils font réellement. GPTBot, ClaudeBot et Google-Extended collectent du contenu pour entraîner de futurs modèles : les bloquer prive ce modèle de vos pages comme donnée d'entraînement, sans effet sur votre visibilité dans les réponses déjà générées aujourd'hui. OAI-SearchBot, Claude-SearchBot et PerplexityBot indexent le contenu pour les fonctions de recherche de ChatGPT, Claude et Perplexity : les bloquer fait disparaître votre site de ces réponses-là spécifiquement. ChatGPT-User, Claude-User et Perplexity-User, enfin, ne crawlent rien automatiquement : ils se déclenchent seulement quand un utilisateur pose une question précise.

Sur la famille OpenAI, un article dédié détaille déjà GPTBot, OAI-SearchBot et ChatGPT-User plus en profondeur, avec le délai réel de prise en compte d'une modification du robots.txt.

Cette troisième famille réserve d'ailleurs la nuance la plus utile du sujet : être déclenché par un humain n'implique pas le même traitement chez tous les éditeurs. Anthropic indique dans sa documentation que ses trois robots respectent les directives de robots.txt, y compris Claude-User. Un fichier robots.txt s'applique donc bien à lui.

Perplexity a tranché autrement, et l'écart se joue entre ses deux robots. PerplexityBot respecte robots.txt, et l'éditeur recommande explicitement de l'autoriser pour apparaître dans ses résultats. Perplexity-User, à l'inverse, ignore généralement ces règles, puisqu'il est activé par une demande utilisateur directe plutôt que par une exploration planifiée. Même logique chez OpenAI avec ChatGPT-User.

Google-Extended fonctionne encore différemment : ce n'est pas un robot HTTP à part entière, mais un jeton de contrôle qui s'appuie sur les chaînes déjà utilisées par Googlebot. Il permet de choisir si le contenu exploré peut servir à entraîner les futures générations de modèles Gemini et à l'ancrage dans les applications Gemini et Vertex AI. Le bloquer n'a aucune incidence sur l'inclusion d'un site dans Google Search ni sur son classement : c'est écrit noir sur blanc dans la documentation de Google, et c'est ce qui rend ce blocage peu risqué pour un site qui tient à son trafic de recherche.

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Ce choix n'a rien d'automatique. Un éditeur qui vit de son trafic peut vouloir limiter l'entraînement de futurs modèles concurrents tout en restant visible dans leurs réponses. Un autre site peut au contraire chercher la citation la plus large possible et tout autoriser. Aucune de ces deux positions n'est une erreur en soi, à condition de savoir ce que chaque ligne du fichier implique réellement.

Ce fichier robots.txt reste le vrai signal écouté par les robots des IA génératives : le fichier llms.txt, lui, ne joue aucun rôle équivalent. Ce choix s'inscrit plus largement dans la generative engine optimization, la discipline qui travaille la citabilité d'un site par les IA génératives.

À quoi ressemble un fichier robots.txt sur WordPress ?

WordPress génère automatiquement un robots.txt minimal, qui bloque /wp-admin/ tout en laissant une exception pour admin-ajax.php. Ce fichier par défaut se complète en général avec la ligne Sitemap, fournie par l'extension SEO installée sur le site.

Il est tentant d'aller plus loin en bloquant d'autres répertoires WordPress, comme /wp-includes/ ou /wp-content/plugins/ : c'est une pratique aujourd'hui déconseillée, ces dossiers contenant souvent des scripts ou des feuilles de style nécessaires à l'affichage réel des pages. Mieux vaut s'en tenir à ce fichier minimal et laisser les robots explorer librement les ressources qui servent au rendu.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://exemple.fr/sitemap_index.xml

Sur WordPress, le plugin SEO installé permet le plus souvent d'éditer ce fichier directement depuis l'administration, sans toucher au code. Yoast SEO et Rank Math, deux des extensions les plus installées, proposent chacun un éditeur dédié.

Pour un accompagnement complet sur ce type de site, une agence SEO WordPress prend en charge cette configuration technique en plus du travail de contenu et de maillage.

Comment vérifier et tester son fichier robots.txt ?

La méthode la plus simple pour vérifier son fichier robots.txt reste de consulter directement l'adresse /robots.txt du domaine dans un navigateur. Pour un diagnostic plus poussé, Search Console propose un rapport dédié depuis que l'ancien testeur du fichier a été retiré, le 12 décembre 2023.

Ce rapport, accessible dans le menu Paramètres de Search Console, indique la date de dernière lecture du fichier par Google ainsi que les erreurs détectées. Pour vérifier si une URL précise est bloquée, c'est l'outil d'inspection d'URL qui a pris le relais de l'ancien testeur.

Un robots.txt propre ne suffit pas, à lui seul, à garantir que l'exploration et l'indexation d'un site racontent la même histoire. Un sitemap peut pointer vers des pages bloquées, une balise noindex peut contredire une ligne Allow, ou une redirection oubliée peut fausser tout le diagnostic. Un audit SEO vérifie ces éléments ensemble, plutôt qu'un seul fichier isolé.

Quelles sont les erreurs les plus fréquentes avec un robots.txt ?

Quatre erreurs reviennent le plus souvent : un Disallow: / laissé par oubli, des ressources CSS ou JS bloquées à tort, robots.txt pris pour un outil de confidentialité, et une ligne Sitemap oubliée.

Ces quatre erreurs partagent un point commun : elles se corrigent en quelques minutes une fois repérées, mais passent souvent inaperçues pendant des semaines, faute de vérification après une mise en production ou une migration.