Réponse courte
Le robots.txt est un fichier texte placé à la racine du site qui indique aux robots d’exploration les chemins qu’ils peuvent parcourir. Il pilote le crawl, jamais l’indexation : une page bloquée peut rester dans les résultats si d’autres sites la citent. Il ne s’adresse qu’aux robots, jamais aux visiteurs.
Ce guide couvre la création, la syntaxe, les tests et les pièges. Pour la définition seule, voir la fiche Robots.txt du lexique.
/robots.txt
la seule adresse où le fichier est lu, à la racine du domaine, encodé en UTF-8.
4
directives suffisent : User-agent, Disallow, Allow et Sitemap.
0
page désindexée par ce fichier : bloquer l’exploration n’a jamais retiré une URL de l’index.
À quoi sert un fichier robots.txt ?
À dire aux robots d’exploration où ils peuvent aller. Le fichier applique le protocole d’exclusion des robots, normalisé en 2022 par la RFC 9309, et il est consulté avant l’exploration des pages.
Trois conséquences pratiques découlent de ce fonctionnement. Le fichier ne protège rien : il n’empêche personne d’ouvrir une page dans un navigateur. Il repose sur la bonne volonté du robot : la norme décrit un protocole, elle ne le fait pas respecter. Et un fichier absent ou vide n’interdit rien du tout, les robots explorent alors ce qu’ils trouvent.
Son intérêt est ailleurs : orienter l’effort d’exploration vers les pages qui comptent, et tenir les robots à l’écart des zones qui n’ont rien à faire dans un index, espaces d’administration, recherche interne, paramètres d’URL qui fabriquent des doublons.
Comment créer le fichier et où le placer ?
Dans un éditeur de texte, enregistré en UTF-8 sous le nom exact robots.txt, déposé à la racine du domaine. Aucun autre emplacement n’est lu.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://votresite.fr/sitemap.xmlLe contrôle se fait en une requête : ouvrez votresite.fr/robots.txt dans un navigateur. Si le fichier ne s’affiche pas, il n’existe pas pour les robots non plus.
Sous WordPress, un fichier virtuel est généré par défaut et reste minimal. Deux façons de le remplacer : déposer un vrai fichier à la racine, qui prend le dessus, ou passer par l’éditeur d’une extension SEO. Dans les deux cas, relisez ensuite l’URL servie plutôt que l’écran de réglage : c’est elle que les robots lisent.
Quelles directives écrire, et avec quelle syntaxe ?
Quatre directives couvrent l’essentiel. Chacune s’écrit sur une ligne : un mot-clé, deux points, une valeur.
| Directive | Rôle | Exemple |
|---|---|---|
| User-agent | Désigne le robot visé par le bloc de règles | User-agent: Googlebot |
| Disallow | Refuse l’exploration d’un chemin | Disallow: /admin/ |
| Allow | Rouvre une exception dans une zone bloquée | Allow: /admin/public/ |
| Sitemap | Déclare le plan de site, en adresse absolue | Sitemap: https://…/sitemap.xml |
Un bloc commence par un User-agent. L’astérisque vise tous les robots, un nom précis n’en vise qu’un. Empiler plusieurs blocs permet des consignes différentes selon le robot.
User-agent: *
Disallow: /panier/
User-agent: Googlebot
Allow: /panier/apercu/Disallow: / bloque tout le site, une valeur vide n’interdit rien. Entre une interdiction et une autorisation qui se recouvrent, Google applique la règle la plus spécifique, pas la première écrite.
Deux caractères affinent les motifs : l’astérisque remplace n’importe quelle suite de caractères, le dollar marque la fin exacte d’une URL.
Disallow: /*?tri= # toute URL contenant ?tri=
Disallow: /*.pdf$ # toute URL se terminant par .pdfLe raccourci à éviter. Bloquer les fichiers CSS et JavaScript pour « économiser du crawl ». Googlebot en a besoin pour afficher la page comme un visiteur : sans eux, il évalue une page qu’il ne voit pas correctement.
Sur votre site
Votre robots.txt bloque-t-il ce que vous croyez ?
Je relève ce que Googlebot demande réellement dans vos journaux, ce qu’il reçoit, et les règles qui ne servent à rien. Réponse sous 24 heures ouvrées.
Robots.txt, meta robots ou X-Robots-Tag : lequel employer ?
Les trois ne font pas le même travail. Le fichier autorise ou refuse l’exploration ; la balise et l’en-tête décident de l’indexation.
- robots.txt : refuse un chemin aux robots. Sans garantie de désindexation, et sans effet sur une URL déjà connue par des liens externes.
- Balise meta robots : posée dans le
headde la page, elle retire l’URL des résultats avec noindex. - En-tête X-Robots-Tag : même consigne, envoyée par le serveur. C’est la seule option pour un PDF ou une image.
La règle d’or. Ne bloquez jamais dans le robots.txt une page que vous voulez désindexer. Le robot n’ira pas la lire, donc il ne verra jamais votre noindex, et l’URL restera dans l’index sans son contenu.
Les robots des services d’IA générative se traitent comme les autres, par leur nom d’agent. C’est une consigne déclarative : elle vaut pour ceux qui respectent le protocole, pas pour les autres.
User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /Le détail des agents et de ce qu’ils collectent est dans les fiches GPTBot et Crawlers IA.
Comment orienter le budget de crawl ?
En écartant de l’exploration ce qui ne rapporte rien, pour laisser la place aux pages qui portent le trafic. Le budget de crawl ne devient un sujet que sur les sites volumineux ou à forte production d’URL.
Sur un site de quelques centaines de pages, ce plafond n’est jamais atteint et le fichier n’a pas à servir d’outil d’optimisation. Sur un catalogue à facettes, chaque combinaison de filtres explorée est du temps qui n’ira pas aux fiches produits. Les candidats habituels au refus : recherche interne, tri et pagination combinatoire, scripts internes, environnements de test laissés en ligne.
Les fautes qui coûtent le plus cher, dans l’ordre où je les rencontre en audit :
- Bloquer le CSS et le JavaScript nécessaires au rendu.
- Interdire l’exploration d’une page qu’on voulait seulement désindexer.
- Écrire une règle trop large qui emporte des pages stratégiques.
- Oublier de rouvrir un chemin fermé pendant une phase de développement.
- Compter sur ce fichier pour masquer un contenu sensible, au lieu d’une vraie protection serveur.
Quels modèles selon le type de site ?
Les zones à écarter dépendent de la structure. Trois profils courants, à adapter à vos vraies URL avant toute mise en ligne.
# Boutique en ligne
Disallow: /panier/
Disallow: /commande/
Disallow: /compte/
Disallow: /*?couleur=
Disallow: /*?tri=
Disallow: /recherche/
Sitemap: https://votresite.fr/sitemap.xml# Blog ou site de contenu
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?s=
Disallow: /tag/
Disallow: /author/
Sitemap: https://votresite.fr/sitemap.xml# Zones privées et techniques
Disallow: /staging/
Disallow: /merci/
Disallow: /telechargements-prives/
Disallow: /api/Ces modèles sont un point de départ, pas une configuration à recopier. Une règle qui vise un chemin inexistant ne fait rien, une règle qui vise un chemin réel mal orthographié bloque autre chose que prévu.
Comment tester et dépanner le fichier ?
Avant de publier, et après chaque modification. Trois outils suffisent, et ils ne disent pas la même chose.
- 01Le rapport robots.txt de la Search Console. Il montre la version que Google a récupérée, la date de lecture et les erreurs de syntaxe détectées. C’est la seule source qui dit ce que Google lit, par opposition à ce que vous avez écrit.
- 02L’inspection d’URL. Vous saisissez une adresse précise et vous voyez si Googlebot peut l’explorer. À faire sur trois ou quatre pages stratégiques après chaque changement.
- 03La requête directe. Ouvrir le fichier dans un navigateur, sans paramètre. C’est ce que le serveur sert réellement, cache compris.
| Symptôme | Correction |
|---|---|
| Des pages importantes ne sont plus explorées | Retirer la règle trop large, puis retester chaque URL |
| Le fichier renvoie une erreur 404 | Vérifier qu’il est bien à la racine, et servi en texte brut |
| Une règle ne produit aucun effet | Contrôler les espaces, les majuscules et l’orthographe de la directive |
| Les pages s’affichent mal dans l’inspection d’URL | Rouvrir l’accès aux fichiers CSS et JavaScript |
La vérification ne s’arrête pas à l’outil. Les journaux du serveur montrent ce que les robots ont réellement demandé, et ce qu’ils ont reçu. Une adresse censée être bloquée mais visitée chaque jour signale une règle mal formulée, et cela ne se voit nulle part ailleurs.
Migration, multilingue, sous-domaines : ce qui change
Trois situations produisent la quasi-totalité des accidents que je vois en audit.
La mise en ligne après refonte. Le fichier de préproduction contient un Disallow: / destiné à tenir les robots à l’écart. Repris tel quel en production, il bloque le site entier. C’est la première ligne à relire le jour de la bascule, avant même de regarder les redirections. Et une redirection doit rester explorable, sinon le moteur ne suivra jamais l’ancienne URL vers la nouvelle.
Le multilingue. Quand les langues vivent en sous-répertoires, un seul fichier gouverne tout le domaine. Quand elles vivent en sous-domaines, chacun porte le sien, servi à sa propre racine : le fichier de blog.votresite.fr ne s’applique jamais à votresite.fr, et chacun déclare son propre sitemap.
Les grandes structures à facettes. Viser les segments à faible valeur, paramètres de tri et identifiants de session, plutôt qu’un blocage large qui emporterait des pages utiles au passage.
À retenir
- 01À la racine du domaine, en UTF-8, sous le nom exact robots.txt. Ailleurs, il n’existe pas.
- 02Il pilote l’exploration, pas l’indexation : pour retirer une URL des résultats, il faut noindex ou X-Robots-Tag.
- 03Ne jamais bloquer une page qu’on veut désindexer, ni les ressources CSS et JavaScript.
- 04Après chaque changement, relire l’URL servie et croiser avec les journaux du serveur.
Questions fréquentes
Où doit-on placer le fichier robots.txt ?
À la racine du domaine, accessible à une adresse du type votresite.fr/robots.txt. Placé dans un sous-dossier, il n’est jamais lu.
Le robots.txt empêche-t-il l’indexation ?
Non, et c’est le malentendu le plus courant. Une page bloquée peut rester indexée si d’autres sites pointent vers elle. Pour la retirer des résultats, laissez-la explorable et posez un noindex.
Comment savoir ce que Google lit vraiment ?
Par le rapport robots.txt de la Search Console : il affiche la version récupérée par Googlebot, sa date de lecture et les erreurs de syntaxe.
Faut-il déclarer son sitemap dans le fichier ?
Oui, c’est une ligne qui ne coûte rien. Elle aide les robots à trouver la liste de vos URL, même sans soumission dans la Search Console.
Un fichier vide ou absent pose-t-il problème ?
Non. Sans fichier, ou avec un fichier vide, les moteurs considèrent que tout le site est explorable. Aucune restriction n’est appliquée.
Peut-on bloquer les fichiers CSS et JavaScript ?
C’est déconseillé. Google en a besoin pour afficher la page comme un visiteur. Les bloquer fausse l’évaluation du rendu.
Sources
- 1Google Search Central : Introduction au fichier robots.txt et Créer et envoyer un fichier robots.txt
- 2Google Search Central : Bloquer l’indexation avec noindex, qui explique pourquoi une page bloquée au crawl ne peut pas être désindexée
- 3IETF : RFC 9309, Robots Exclusion Protocol, la norme publiée du protocole
- 4Search Console : Rapport robots.txt
- 5Définition courte et contexte dans la fiche Robots.txt du lexique
