Robots.txt : guide pratique pour contrôler le crawl Google

Le fichier robots.txt est un fichier texte placé à la racine d’un site, qui indique aux robots d’exploration les zones qu’ils peuvent ou ne peuvent pas parcourir. Pour trouver celui d’un site, il suffit d’ajouter /robots.txt après le nom de domaine. Bien utilisé, il concentre l’exploration de Googlebot sur les pages utiles. Mal utilisé, il peut rendre invisibles des sections entières d’un site, ou au contraire laisser dans l’index des pages que vous pensiez bloquées. Ce guide couvre la syntaxe, les directives qui fonctionnent vraiment avec Google, les cas d’usage, les robots d’IA, les erreurs fréquentes et une méthode de test avant chaque mise en production.

01Robots.txt : définition et rôle réel dans le SEO

Le robots.txt repose sur le protocole d’exclusion des robots, imaginé en 1994 et normalisé par l’IETF dans la RFC 9309 publiée en septembre 2022. Le fichier doit se trouver à la racine de l’hôte (https://www.exemple.fr/robots.txt), être encodé en UTF-8 et s’applique uniquement au protocole, à l’hôte et au port sur lesquels il est servi. Un sous-domaine a donc besoin de son propre fichier. Selon la documentation de Google sur son interprétation du robots.txt, la taille du fichier est limitée à 500 Kio : le contenu au-delà est ignoré. Si votre site répond à la fois en HTTP et en HTTPS, ou avec et sans www, chaque variante lit son propre fichier : les redirections vers la version principale évitent des comportements différents selon l’adresse explorée.

Ce que le fichier contrôle : l’exploration

Le robots.txt dit à un robot s’il a le droit de demander une URL. C’est un outil de gestion de l’exploration : éviter que Googlebot passe son temps sur des URL sans valeur (recherche interne, combinaisons de filtres, paramètres de tri), protéger un serveur fragile d’un crawl trop intense, ou empêcher l’exploration de zones techniques. Sur les gros sites, il fait partie des leviers d’optimisation présentés dans notre article sur l’optimisation du crawl budget pour les gros sites.

Ce qu’il ne contrôle pas : l’indexation

C’est la confusion la plus coûteuse. Une URL bloquée dans le robots.txt peut quand même être indexée si d’autres pages font un lien vers elle : Google l’affiche alors sans description, et la Search Console la classe en « Indexée, bien que bloquée par le fichier robots.txt ». Pour empêcher l’indexation, il faut une balise meta robots noindex ou un en-tête HTTP X-Robots-Tag, et laisser la page explorable pour que Google puisse lire cette consigne. Bloquer et désindexer en même temps est donc contradictoire.

02Syntaxe et directives utiles

Le fichier est composé de groupes. Chaque groupe commence par une ou plusieurs lignes User-agent, suivies de règles Allow et Disallow. Les chemins sont sensibles à la casse et commencent par une barre oblique.

User-agent, Disallow et Allow

User-agent: *
Disallow: /recherche/
Disallow: /panier/
Allow: /recherche/guide-des-tailles/
User-agent: Googlebot-Image
Disallow: /medias/internes/
Sitemap: https://www.exemple.fr/sitemap_index.xml

• User-agent désigne le robot concerné. L’astérisque vise tous les robots qui n’ont pas de groupe dédié. Un robot applique uniquement le groupe le plus spécifique qui le concerne, et ignore les autres.
• Disallow interdit l’exploration des URL qui commencent par le chemin indiqué. Un Disallow vide n’interdit rien.
• Allow autorise explicitement un chemin à l’intérieur d’une zone bloquée.

Les lignes qui commencent par le caractère dièse sont des commentaires : utilisez-les pour documenter la raison de chaque règle et la date de son ajout. Dans six mois, personne ne saura pourquoi /catalogue-v2/ est bloqué si ce n’est pas écrit. L’ordre des groupes dans le fichier n’a pas d’importance pour Google : seul compte le groupe dont le user-agent correspond le mieux au robot.

Caractères génériques et règle la plus spécifique

Google reconnaît deux caractères spéciaux : l’astérisque, qui remplace n’importe quelle suite de caractères, et le dollar, qui marque la fin de l’URL.

User-agent: *
Disallow: /*?tri=
Disallow: /*.pdf$
Allow: /produits/*?couleur=

Quand plusieurs règles s’appliquent à une URL, Google retient la plus spécifique, c’est-à-dire celle dont le chemin est le plus long. En cas d’égalité, la règle la moins restrictive (Allow) l’emporte. Testez toujours les cas limites : une règle trop large, comme Disallow: /p, bloque aussi /produits/ et /promotions/.

Directive Sitemap et directives ignorées par Google

La ligne Sitemap indique l’URL absolue d’un sitemap ou d’un index de sitemaps. Elle est indépendante des groupes et peut être répétée. C’est un complément utile à la déclaration dans la Search Console, détaillée dans notre guide sur la structure et l’automatisation des sitemaps XML.

Google ignore en revanche plusieurs directives encore fréquentes dans les fichiers : Crawl-delay n’est pas pris en compte par Googlebot, et Noindex dans le robots.txt n’est plus supporté depuis septembre 2019. D’autres moteurs peuvent interpréter Crawl-delay, ce qui explique sa présence, mais il n’a aucun effet sur Google.

03Quoi bloquer, quoi laisser ouvert : cas d’usage

Un robots.txt efficace est généralement court. Voici ce qu’il est souvent pertinent de bloquer :

• les pages de résultats de recherche interne, qui génèrent une infinité d’URL sans valeur propre ;
• les paramètres de tri, d’affichage et de session qui dupliquent des pages existantes ;
• les combinaisons de facettes sans demande de recherche, quand elles ne sont pas gérées autrement ;
• les parcours de compte, de panier et de commande ;
• les environnements de test accessibles publiquement (même si une authentification reste la vraie solution).

Et ce qu’il ne faut jamais bloquer :

• les fichiers CSS et JavaScript nécessaires au rendu : sans eux, Google ne voit pas la page comme un utilisateur ;
• les images et médias que vous voulez voir apparaître dans Google Images ou Discover ;
• les pages que vous voulez désindexer avec un noindex, puisque Google doit pouvoir les explorer pour lire la balise ;
• les URL de pagination qui donnent accès à des produits ou articles profonds.

Exemple de fichier pour un site e-commerce qui gère ses facettes indexables par ailleurs :

# Recherche interne et parcours client
User-agent: *
Disallow: /recherche?
Disallow: /panier/
Disallow: /mon-compte/
Disallow: /commande/
# Paramètres de tri et d'affichage
Disallow: /*?*tri=
Disallow: /*?*affichage=
Disallow: /*?*sessionid=
Sitemap: https://www.exemple.fr/sitemap_index.xml

Ce fichier reste lisible, chaque règle a une justification, et aucune ressource de rendu n’est bloquée. Les facettes à fort potentiel restent explorables et indexables ; les autres sont traitées par des liens non explorables ou des balises adaptées plutôt que par une longue liste de règles.

Sur WordPress, le fichier virtuel généré par défaut bloque /wp-admin/ tout en autorisant admin-ajax.php, ce qui convient à la plupart des sites. Les extensions SEO permettent de le compléter ; vérifiez qu’un fichier physique à la racine ne vient pas écraser leurs réglages.

04Robots.txt et robots d’IA : Google-Extended, GPTBot et les autres

Le robots.txt sert aussi à exprimer ses choix vis-à-vis des robots d’IA. Les éditeurs publient des user-agents distincts selon l’usage :

• Google-Extended : jeton de contrôle, sans robot distinct, qui permet de refuser que vos contenus servent à l’entraînement des futurs modèles Gemini et à l’ancrage (grounding) dans les applications Gemini et Vertex AI. D’après la liste des robots courants de Google, il n’a pas d’effet sur l’inclusion dans la recherche Google et n’est pas utilisé comme signal de classement.
• GPTBot et OAI-SearchBot chez OpenAI : le premier concerne l’entraînement des modèles, le second l’affichage dans les résultats de recherche de ChatGPT. Selon la documentation d’OpenAI sur ses robots, les deux réglages sont indépendants. Un troisième agent, ChatGPT-User, visite des pages à la demande d’un utilisateur : OpenAI précise que les règles du robots.txt peuvent alors ne pas s’appliquer.
• ClaudeBot, PerplexityBot, CCBot (Common Crawl) et d’autres, chacun documenté par son éditeur.

Point important pour Google : les AI Overviews et AI Mode font partie de la recherche et s’appuient sur Googlebot. Bloquer Google-Extended ne vous en retire pas. Pour limiter l’usage de vos contenus dans ces fonctionnalités, Google renvoie aux directives de snippet (nosnippet, max-snippet), et la Search Console propose un contrôle au niveau de la propriété, ouvert à tous les sites depuis le 31 août 2026, pour exclure le site des AI Overviews, d’AI Mode et des fonctionnalités d’IA de Discover ; un site exclu n’y reçoit plus aucune impression ni aucun trafic. Les éditeurs ajoutent ou renomment régulièrement leurs robots : relisez la documentation de chacun avant de modifier votre fichier.

Exemple d’une politique qui refuse l’entraînement des modèles tout en restant visible dans les moteurs de réponse :

# Refus de l'entraînement des modèles
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
# Recherche dans les assistants : autorisée
User-agent: OAI-SearchBot
Allow: /

Ce type de configuration ne vaut que pour les robots qui respectent le protocole. Vérifiez ensuite dans vos logs serveur que les user-agents concernés suivent bien vos règles, et que leurs adresses IP correspondent à celles publiées par les éditeurs.

La décision doit être business avant d’être technique : un site qui vit de la visibilité et des citations dans les assistants n’a pas intérêt à bloquer les robots de recherche des IA, alors qu’un éditeur dont le contenu est le produit peut légitimement refuser l’entraînement.

05Erreurs fréquentes qui bloquent des zones stratégiques

1. Le Disallow: / hérité de la préproduction : copié lors d’une mise en ligne, il bloque tout le site. C’est l’erreur la plus grave et l’une des plus fréquentes lors des refontes.
2. Bloquer une page pour la désindexer : la page reste dans l’index, sans description, et Google ne voit jamais le noindex.
3. Bloquer les ressources de rendu : des répertoires de thème ou de scripts bloqués empêchent Google d’afficher correctement la page.
4. Une règle trop large : Disallow: /cat bloque aussi /catalogue/ et /categories/. Terminez les répertoires par une barre oblique.
5. Un groupe dédié à Googlebot incomplet : dès qu’un groupe cible Googlebot, celui-ci ignore le groupe général. Les règles communes doivent donc être répétées.
6. Un fichier inaccessible : si le serveur renvoie une erreur 5xx sur le robots.txt, Google arrête d’explorer le site pendant les 12 premières heures, puis utilise la dernière version valide pendant 30 jours tout en réessayant. Une erreur 4xx (sauf 429), elle, est interprétée comme une absence de restriction : un fichier supprimé par erreur ouvre tout le site.
7. Bloquer des URL déjà indexées en espérant les faire disparaître : elles restent visibles plus longtemps. Traitez d’abord l’indexation, puis bloquez si nécessaire. Notre article sur les raisons pour lesquelles vos pages ne sont pas indexées aide à distinguer ces cas.

06Tester, déployer et surveiller son robots.txt

Une modification du robots.txt doit suivre le même circuit qu’une mise en production de code.

1. Listez les URL à tester : au moins une URL par type de page stratégique (accueil, catégorie, fiche produit, article, pagination, image) et une URL par zone que vous voulez bloquer.
2. Testez hors ligne : utilisez un analyseur conforme aux règles de Google, par exemple la bibliothèque open source robots.txt publiée par Google, ou la fonction de test de votre crawler.
3. Crawlez en simulation : lancez un crawl du site en appliquant le nouveau fichier en mode personnalisé, et comparez le nombre d’URL accessibles avant et après.
4. Déployez et contrôlez dans la Search Console : le rapport robots.txt, dans les paramètres, affiche les fichiers trouvés pour les 20 principaux hôtes du site, leur date de récupération, les erreurs et les versions récupérées sur les 30 derniers jours. Il permet de demander une nouvelle récupération après une modification urgente. Google met généralement en cache le fichier jusqu’à 24 heures.
5. Vérifiez avec l’inspection d’URL sur les pages stratégiques.
6. Contrôlez les logs serveur dans les jours qui suivent : les hits de Googlebot sur les répertoires bloqués doivent disparaître, et ceux sur les pages stratégiques rester stables ou augmenter. Les statistiques d’exploration de la Search Console donnent une tendance, les logs donnent le détail par URL.

La surveillance, enfin, s’automatise simplement. Un workflow n8n peut récupérer le fichier chaque jour, calculer son empreinte, comparer avec la version précédente et envoyer une alerte avec le différentiel en cas de changement. Il peut aussi alerter si une ligne Disallow: / apparaît dans le groupe général, ou si le fichier renvoie autre chose qu’un code 200. Ce contrôle de quelques minutes à mettre en place évite l’incident le plus classique des refontes. Pour situer le robots.txt parmi les autres leviers techniques, notre page dédiée au référencement naturel présente l’ensemble des chantiers.