Robots.txt : le guide complet avec exemples

Le fichier robots.txt est un simple fichier texte placé à la racine d’un site qui indique aux robots des moteurs de recherche quelles parties ils peuvent explorer et lesquelles ils doivent laisser de côté. C’est l’un des premiers éléments que Googlebot consulte en arrivant sur votre domaine, et une seule ligne mal écrite peut suffire à rendre invisible un site entier. Ce guide explique à quoi il sert vraiment, comment l’écrire correctement, et surtout quels pièges évitent que votre référencement parte en fumée.

À quoi sert le robots.txt ?

Le robots.txt fait partie d’un standard ancien appelé Robots Exclusion Protocol. Son rôle est de donner des consignes d’exploration (le « crawl ») aux robots qui parcourent le web : Googlebot, Bingbot, mais aussi des dizaines d’autres, des outils SEO aux robots des IA génératives. Quand un robot bien élevé visite votre site, il commence par télécharger votresite.com/robots.txt et lit les règles qui le concernent avant d’explorer quoi que ce soit d’autre.

Il faut bien comprendre ce que le fichier contrôle — et ce qu’il ne contrôle pas. Le robots.txt gère le crawl, c’est-à-dire l’accès des robots à vos URLs. Il ne gère pas directement l’indexation, c’est-à-dire la présence d’une page dans les résultats de recherche. Cette distinction, que nous détaillerons plus loin, est la source de la majorité des erreurs SEO graves liées à ce fichier.

À quoi sert-il concrètement, alors ? Principalement à trois choses :

• Préserver le budget de crawl. Sur un gros site, les robots ne peuvent pas tout explorer à chaque passage. En leur interdisant les zones sans valeur SEO (résultats de recherche interne, panier, pages de filtres infinies), vous concentrez leur attention sur vos pages importantes.
• Garder les robots à l’écart de zones techniques. Espaces d’administration, scripts internes, environnements de test, fichiers temporaires : autant de contenus qui n’ont rien à faire dans un index.
• Indiquer l’emplacement du sitemap. Le robots.txt est l’endroit standard pour pointer vers votre plan de site XML, ce qui aide les moteurs à découvrir vos URLs.

Une nuance importante en 2026 : le robots.txt est aussi devenu un fichier stratégique face aux robots d’IA. De nombreux crawlers (GPTBot, Google-Extended, ClaudeBot, etc.) le consultent avant de collecter du contenu pour entraîner leurs modèles ou alimenter des réponses génératives. Décider qui peut puiser dans vos contenus passe désormais aussi par ce fichier.

Où placer le fichier et comment le créer ?

La règle est stricte : le robots.txt doit se trouver à la racine du domaine, à l’adresse exacte https://votresite.com/robots.txt. Placé ailleurs, dans un sous-dossier par exemple, il est purement et simplement ignoré.

Quelques contraintes techniques à respecter :

• Le fichier doit s’appeler robots.txt, en minuscules, au singulier.
• Il doit être encodé en UTF-8.
• Il doit renvoyer un code HTTP 200 quand un robot le demande.
• Chaque sous-domaine possède son propre robots.txt. Celui de votresite.com ne couvre pas blog.votresite.com ni boutique.votresite.com, qui ont besoin de leur propre fichier.
• Le protocole compte également : le robots.txt de la version HTTPS ne s’applique pas automatiquement à la version HTTP, même si en pratique tout le trafic doit être redirigé vers HTTPS.

Pour le créer, un éditeur de texte brut suffit (Bloc-notes, VS Code…) : on rédige les règles, on enregistre sous robots.txt, et on dépose le fichier à la racine du serveur. Sur WordPress, des extensions comme Yoast ou Rank Math permettent de l’éditer directement depuis l’administration. Beaucoup de CMS génèrent par ailleurs un robots.txt par défaut — qu’il faut toujours vérifier, car les valeurs livrées d’usine sont parfois inadaptées.

La syntaxe : User-agent, Disallow, Allow, Sitemap

La structure d’un robots.txt repose sur des groupes de règles. Chaque groupe commence par une ligne User-agent qui désigne le ou les robots concernés, suivie d’une ou plusieurs directives qui s’appliquent à eux. Une ligne valide se compose d’un champ, d’un deux-points et d’une valeur (par exemple Disallow: /panier/).

Voici les quatre directives qui couvrent à elles seules l’immense majorité des besoins.

User-agent

User-agent identifie le robot auquel le groupe de règles s’adresse. C’est toujours la première ligne d’un groupe. L’astérisque * désigne tous les robots.

User-agent: *

On peut aussi cibler un robot précis par son nom :

User-agent: Googlebot

Le nom du champ (User-agent) n’est pas sensible à la casse, mais le nom du robot l’est. À noter : User-agent: * s’applique à tous les robots sauf certains crawlers publicitaires comme AdsBot de Google, qui doivent être nommés explicitement pour être concernés.

Disallow

Disallow indique un chemin que le robot ne doit pas explorer. La valeur est relative à la racine du site et sensible à la casse.

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

Quelques cas particuliers très utiles :

# Tout bloquer (à manier avec une extrême prudence)
User-agent: *
Disallow: /

# Ne rien bloquer (autoriser tout le crawl)
User-agent: *
Disallow:

Une ligne Disallow: / interdit l’exploration de tout le site : c’est exactement ce qu’on retrouve, par accident, sur des sites entiers tombés de l’index. À l’inverse, un Disallow: vide n’interdit rien.

Allow

Allow autorise explicitement un chemin, et sert surtout à créer une exception à l’intérieur d’un dossier interdit. C’est très pratique pour bloquer un répertoire tout en laissant accessible une page précise qu’il contient.

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

Ici, tout le dossier /wp-admin/ est interdit, sauf le fichier admin-ajax.php dont WordPress a besoin pour fonctionner correctement. En cas de conflit entre une règle Allow et une règle Disallow, Google applique la règle la plus spécifique (celle dont le chemin est le plus long) ; à spécificité égale, c’est la règle la moins restrictive qui l’emporte.

Sitemap

La directive Sitemap indique l’adresse de votre plan de site XML. Contrairement aux autres, elle n’est rattachée à aucun User-agent : on la place généralement en haut ou en bas du fichier, et elle vaut pour tous les robots.

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

L’URL doit être complète (avec le protocole et le domaine) : Google ne devine pas les variantes http/https ou www/non-www. On peut déclarer plusieurs sitemaps en répétant la ligne. Pour comprendre comment construire et soumettre ce fichier, consultez notre guide dédié au sitemap, qui complète idéalement le robots.txt dans la stratégie de crawl.

Les jokers : * et $

Google reconnaît deux caractères spéciaux dans les chemins, qui rendent les règles bien plus puissantes :

• * remplace n’importe quelle suite de caractères.
• $ marque la fin de l’URL.

User-agent: *
# Bloque toutes les URLs contenant un point d'interrogation (paramètres)
Disallow: /*?
# Bloque tous les fichiers PDF
Disallow: /*.pdf$

La première règle interdit toutes les URLs avec paramètres (souvent des pages de filtres ou de tri sans valeur SEO) ; la seconde cible précisément les fichiers se terminant par .pdf.

Des exemples concrets de robots.txt

Rien ne vaut des fichiers complets pour comprendre. Voici trois modèles courants.

Un site vitrine classique, qui laisse tout explorer et signale son sitemap :

User-agent: *
Disallow:

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

Un site WordPress standard, qui protège l’administration tout en gardant le fichier AJAX accessible :

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

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

Une boutique e-commerce, qui écarte les pages sans valeur SEO pour économiser le budget de crawl :

User-agent: *
Disallow: /panier/
Disallow: /commande/
Disallow: /mon-compte/
Disallow: /*?orderby=
Disallow: /*?filter=
Allow: /

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

On peut aussi définir des règles différentes selon le robot. L’exemple ci-dessous interdit tout un site à un crawler d’IA donné, tout en laissant les moteurs de recherche travailler normalement :

User-agent: GPTBot
Disallow: /

User-agent: *
Disallow: /panier/

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

Les lignes commençant par # sont des commentaires : elles sont ignorées par les robots et servent uniquement à documenter le fichier pour les humains. N’hésitez pas à en mettre pour expliquer vos choix.

Le piège n°1 : crawl n’est pas indexation

C’est l’erreur la plus coûteuse, et elle mérite sa propre section. Beaucoup pensent qu’en ajoutant un Disallow sur une page, on la retire de Google. C’est faux.

Le robots.txt empêche un robot de lire le contenu d’une page. Il n’empêche pas Google de connaître l’existence de l’URL et de l’afficher dans ses résultats si d’autres sites pointent vers elle. Le résultat est un statut bien connu dans la Search Console : « Indexée malgré le blocage par le fichier robots.txt ». La page apparaît alors dans Google, souvent sans description (« Aucune information n’est disponible pour cette page »), parce que le robot n’a pas pu en lire le contenu.

Pire : si vous voulez désindexer une page avec une balise noindex, mais que cette même page est bloquée dans le robots.txt, le piège se referme. Googlebot ne peut pas accéder à la page, donc il ne voit jamais la balise noindex, et la page reste indexée indéfiniment.

La règle à retenir :

• Pour empêcher l’exploration (économiser le budget de crawl, masquer une zone technique) → Disallow dans le robots.txt.
• Pour empêcher l’apparition dans les résultats → balise <meta name="robots" content="noindex"> dans le <head> de la page, et surtout ne pas bloquer cette page dans le robots.txt, sinon la balise ne sera jamais lue.

Cette confusion entre crawl et indexation est un classique des audits techniques. Si vous voulez un cadre méthodique pour traquer ce genre de problème, notre audit SEO détaille la marche à suivre point par point.

Les erreurs courantes qui bloquent l’indexation

Au-delà de la confusion crawl/indexation, plusieurs maladresses de syntaxe ou de configuration peuvent saboter un site. Voici les plus fréquentes et comment les éviter.

Erreur	Conséquence	Correction
Disallow: / resté en production	Tout le site est bloqué au crawl	Vérifier le robots.txt après chaque mise en ligne ou migration
Mauvaise casse (/Folder au lieu de /folder)	La règle ne s’applique pas au bon dossier	Respecter exactement la casse des URLs réelles
Bloquer le CSS et le JavaScript	Google ne peut plus afficher la page correctement	Ne jamais bloquer les ressources nécessaires au rendu
Bloquer une page qu’on veut désindexer	La balise noindex n’est jamais lue, la page reste indexée	Laisser la page crawlable et utiliser noindex
Slash final incohérent (/contact vs /contact/)	Le blocage ne couvre pas la variante attendue	Vérifier la forme exacte de l’URL à bloquer
Crawl-delay pour Googlebot	Ligne ignorée, aucun effet	Régler la vitesse de crawl dans la Search Console
Robots.txt placé dans un sous-dossier	Fichier totalement ignoré	Le placer à la racine du domaine
Bloquer une URL pour cacher des données sensibles	L’URL reste publiquement listée dans le robots.txt	Protéger par authentification, jamais par robots.txt

Deux points méritent d’être soulignés. D’abord, le robots.txt est un fichier public : n’importe qui peut lire votresite.com/robots.txt. Y lister vos dossiers « secrets » revient à dresser une carte de vos zones sensibles. Pour protéger réellement un contenu, il faut une authentification, pas un Disallow.

Ensuite, méfiez-vous des règles trop larges. Un Disallow: /blog (sans slash final) peut bloquer non seulement /blog/ mais aussi /blog-actualites/ ou toute URL commençant par ces lettres. Soyez toujours le plus spécifique possible, et testez vos règles plutôt que de vous fier à votre intuition.

Tester et valider son robots.txt

Ne mettez jamais un robots.txt en production sans le tester. Une erreur ici se paie en trafic perdu, parfois pendant des semaines avant qu’on s’en aperçoive.

Quelques réflexes simples :

• Le test de l’URL dans la Search Console. L’outil d’inspection d’URL de Google indique si une page précise est bloquée ou non par le robots.txt, et par quelle règle. C’est la source de vérité.
• La lecture directe. Ouvrez simplement votresite.com/robots.txt dans un navigateur pour vérifier que le bon fichier est servi et qu’il renvoie bien un code 200.
• Le rapport d’indexation. Surveillez dans la Search Console les statuts « Bloquée par le fichier robots.txt » et « Indexée malgré le blocage » : ils révèlent les conflits entre vos intentions et la réalité.
• Les validateurs en ligne. De nombreux outils SEO proposent un testeur de robots.txt qui simule le comportement des robots sur vos règles.

Pensez aussi à revérifier le fichier après chaque événement majeur : refonte, changement de CMS, migration de domaine, passage en HTTPS. C’est précisément lors de ces transitions qu’un Disallow: / de l’environnement de préproduction se retrouve, par mégarde, copié en production.

Une fois le crawl maîtrisé, place au contenu

Maîtriser le robots.txt, c’est s’assurer que Google peut accéder à vos bonnes pages et ignorer les mauvaises. Mais ce n’est qu’une condition d’accès : un crawl parfaitement réglé ne garantit pas le moindre positionnement. Une fois la mécanique d’exploration et d’indexation sous contrôle, le vrai travail commence — celui du contenu. Une page accessible mais pauvre plafonnera toujours.

C’est exactement là qu’un outil d’optimisation sémantique entre en jeu. Une fois vos pages clés correctement crawlées et indexées, l’étape suivante consiste à les rendre réellement compétitives sur leurs requêtes cibles : couvrir le champ lexical attendu par Google, structurer le contenu autour de la bonne intention de recherche, combler les manques par rapport aux pages déjà bien classées. NeuronWriter est précisément conçu pour ça : il analyse les pages en tête des résultats sur votre mot-clé et vous indique, terme par terme, ce qu’il manque à votre contenu pour rivaliser.

Optimiser mes pages clés avec NeuronWriter →

L’idée n’est pas de bourrer vos textes de mots-clés, mais de vérifier objectivement que vous traitez un sujet aussi complètement que les meilleurs résultats. Sur les pages stratégiques que vous venez justement de rendre accessibles aux robots, ce gain de pertinence sémantique fait souvent la différence entre la deuxième page et le top 3. Le crawl ouvre la porte ; le contenu décide de votre place.

Cette logique s’inscrit dans une démarche plus large : la technique (robots.txt, sitemap, indexation) et l’éditorial sont les deux jambes du référencement. Pour replacer l’ensemble dans une stratégie cohérente, notre guide sur le référencement naturel montre comment ces leviers s’articulent. Et si vous voulez voir concrètement comment l’optimisation sémantique se traduit en gains de positions, vous pouvez tester l’approche par vous-même.

Découvrir NeuronWriter et tester l’optimisation sémantique →

En résumé

Le robots.txt est un fichier minuscule au pouvoir disproportionné. Bien réglé, il oriente les robots vers vos pages importantes et préserve votre budget de crawl. Mal réglé, il peut faire disparaître un site entier des résultats. Retenez les points essentiels :

• Il se place à la racine du domaine, en UTF-8, et chaque sous-domaine a le sien.
• Quatre directives suffisent dans 90 % des cas : User-agent, Disallow, Allow, Sitemap.
• Il contrôle le crawl, pas l’indexation : pour désindexer une page, utilisez noindex et laissez-la crawlable.
• Ne bloquez jamais le CSS, le JavaScript, ni des données que vous croyez « cacher » — le fichier est public.
• Testez toujours vos règles, et revérifiez le fichier après chaque migration.

Une fois cette base technique solide, concentrez votre énergie là où elle paie vraiment : la qualité et la complétude de vos contenus sur les pages qui comptent.