Robots.txt : créer, tester et corriger le fichier

Le fichier robots.txt indique aux robots d’exploration les chemins auxquels ils peuvent accéder sur un hôte. Il sert principalement à gérer l’exploration, pas à garantir l’indexation, protéger des informations confidentielles ou supprimer une URL des résultats de recherche.

Une mauvaise règle peut empêcher Google de charger une page, une image ou une ressource nécessaire au rendu. À l’inverse, une URL bloquée peut encore apparaître dans les résultats si Google la découvre par des liens. La première décision n’est donc pas « que faut-il bloquer ? », mais « quel résultat cherche-t-on réellement ? ».

Ce guide suit une méthode en neuf étapes : définir le besoin, inventorier les chemins, vérifier la portée du fichier, écrire des groupes simples, comprendre les correspondances, préserver le rendu, déclarer le sitemap, tester la version publiée puis surveiller les changements.

Robots.txt, noindex, accès privé et canonical : choisir le bon mécanisme

Objectif	Mécanisme adapté	Ce que robots.txt ne garantit pas
Limiter l’exploration de chemins sans intérêt	Règle Disallow ciblée	La disparition de l’URL des résultats
Retirer une page publique des résultats	noindex dans le HTML ou l’en-tête HTTP	Google doit pouvoir explorer la page pour lire la directive
Protéger un contenu confidentiel	Authentification et contrôle d’accès	Le fichier est public et les robots malveillants peuvent l’ignorer
Regrouper des doublons accessibles	Canonical cohérente, liens et sitemap alignés	Le blocage empêche l’examen des signaux de la variante
Remplacer définitivement une ancienne URL	Redirection permanente vers un équivalent réel	Une règle ne transporte ni visiteurs ni signaux
Supprimer une ressource sans remplaçant	Réponse 404 ou 410	Bloquer l’exploration masque le statut à vérifier

Google précise dans sa présentation de robots.txt qu’une page interdite d’exploration peut encore être indexée sans contenu si d’autres pages pointent vers elle. Pour diagnostiquer une adresse précise, utilisez le guide page non indexée sur Google.

La méthode robots.txt en neuf étapes

Étape	Question	Résultat attendu
1. Objectif	Faut-il gérer l’exploration, l’indexation ou l’accès ?	Mécanisme correctement choisi
2. Inventaire	Quelles familles d’URL existent réellement ?	Liste de chemins et fonction de chacun
3. Portée	Quel protocole, hôte et port le fichier couvre-t-il ?	Un fichier à la bonne racine
4. Groupes	Quels robots reçoivent quelles règles ?	Groupes simples et non contradictoires
5. Motifs	Quelles URL correspondent à chaque chemin ?	Règles précises, testées sur des exemples
6. Rendu	CSS, JavaScript et médias essentiels restent-ils accessibles ?	Pages interprétables par le robot
7. Sitemap	L’adresse absolue du sitemap est-elle déclarée ?	Inventaire canonique facile à retrouver
8. Test	Que renvoie le fichier public et quelles URL autorise-t-il ?	Contrôle avant et après publication
9. Suivi	Google récupère-t-il le fichier sans erreur ?	Changements documentés et surveillés

1. Définir le résultat attendu avant d’écrire une règle

Commencez par une phrase vérifiable : « éviter l’exploration de résultats de recherche internes infinis », « laisser Google charger les ressources de rendu » ou « réduire les variantes générées par un filtre ». Une formule vague comme « améliorer le SEO » ne permet pas de savoir si une règle est adaptée.

Besoin observé	Question de contrôle	Décision possible
Paramètres de tri très nombreux	Modifient-ils seulement l’ordre des mêmes éléments ?	Liens propres, canonical et éventuelle restriction ciblée
Recherche interne	Les résultats créent-ils des combinaisons sans valeur autonome ?	Limiter leur exploration, sans les traiter comme contenu privé
Page de connexion	Une authentification bloque-t-elle déjà l’accès ?	Conserver la sécurité ; robots.txt n’est pas la protection
Page publique à retirer de Google	Le robot peut-il encore la visiter ?	Utiliser noindex, pas seulement Disallow
Ancienne URL	Existe-t-il un remplacement véritablement équivalent ?	Rediriger ou renvoyer 404/410
Zone de test	Est-elle publiquement accessible ?	Protéger par authentification ou restriction réseau

Ne bloquez pas une page simplement parce qu’elle est faible. Si elle est publique et doit rester dans la recherche, améliorez sa fonction, son contenu et son maillage. Si elle ne doit pas être indexée, choisissez une directive que le robot peut lire.

2. Inventorier les familles d’URL et leurs sources

Un fichier utile repose sur l’architecture réelle du site. Recensez la navigation, les formulaires, les filtres, les paramètres, les routes techniques, les espaces de compte, les médias et les sous-domaines. Ajoutez les URL repérées dans les journaux, les rapports d’exploration, Search Console et votre outil de crawl.

Famille	Exemple générique	Point à vérifier
Pages publiques	/guides/, /produits/	Doivent-elles être explorées et indexées ?
Recherche interne	/recherche?q=...	Combien de combinaisons sont accessibles par liens ?
Filtres et tris	?couleur=bleu, ?tri=prix	Créent-ils un contenu autonome ou une variante ?
Compte et paiement	/compte/, /paiement/	L’accès est-il réellement protégé ?
Administration	/admin/	L’authentification fonctionne-t-elle indépendamment des robots ?
Ressources	/assets/, /scripts/	Sont-elles nécessaires au rendu ou à la compréhension ?
Fichiers	PDF, images, flux	Faut-il contrôler l’exploration ou l’indexation du fichier ?

Reliez chaque règle prévue à une famille documentée. Cette discipline évite les blocages globaux ajoutés pour résoudre une seule URL. Elle permet aussi de supprimer une règle devenue inutile après une refonte.

3. Placer robots.txt à la bonne racine et comprendre sa portée

Le fichier doit être accessible sous le nom exact robots.txt, à la racine de l’hôte concerné, par exemple https://www.example.com/robots.txt. Il s’agit d’un fichier texte en UTF-8. Un fichier placé dans /dossier/robots.txt ne contrôle pas le site entier.

Fichier publié	Portée	Hors portée
https://example.com/robots.txt	Chemins de https://example.com/	http://example.com/ et sous-domaines
https://www.example.com/robots.txt	Chemins de l’hôte www	Domaine sans www
https://shop.example.com/robots.txt	Sous-domaine shop	Domaine principal et autres sous-domaines
https://example.com:8443/robots.txt	Hôte sur ce port	Port HTTPS standard

La documentation officielle sur la création d’un fichier robots.txt rappelle cette portée par protocole, hôte et port. Après une migration, contrôlez donc chaque variante encore accessible et ses redirections plutôt que de supposer qu’un fichier unique s’applique partout.

4. Écrire des groupes simples avec User-agent, Allow et Disallow

Un groupe commence par une ou plusieurs lignes User-agent, suivies des règles applicables. Disallow interdit l’exploration d’un chemin ; Allow peut autoriser une exception plus précise. Pour un site qui n’a rien à bloquer, autoriser l’ensemble et déclarer le sitemap suffit souvent.

User-agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

Pour interdire un répertoire technique tout en autorisant une ressource publique précise :

User-agent: *
Disallow: /espace-technique/
Allow: /espace-technique/aide-publique

Sitemap: https://www.example.com/sitemap.xml

Directive	Rôle	Erreur fréquente
User-agent	Désigner le robot ou le groupe de robots	Inventer un nom qui ne correspond pas au robot
Disallow	Interdire l’exploration d’un chemin	L’utiliser pour garantir la désindexation
Allow	Autoriser une exception plus précise	Ajouter des exceptions sans tester la règle concurrente
Sitemap	Indiquer l’URL absolue d’un sitemap	Fournir un chemin relatif ou une URL redirigée
#	Commencer un commentaire	Placer une information indispensable uniquement en commentaire

Évitez les longues listes copiées d’un autre site. Une boutique, un média et une application ne génèrent pas les mêmes chemins. Gardez chaque règle justifiable par un besoin observé.

5. Comprendre les correspondances et tester les exceptions

Les chemins sont sensibles à la casse et commencent à la racine. Une règle Disallow: /panier/ ne décrit pas automatiquement /Panier/. Google prend en charge * pour une suite de caractères et $ pour marquer la fin de l’URL ; utilisez-les seulement lorsque des exemples prouvent leur nécessité.

Règle	Correspond	Ne correspond pas
Disallow: /prive/	/prive/page	/Prive/page
Disallow: /*?tri=	URL contenant cette séquence après le chemin	Paramètre écrit différemment ou absent
Disallow: /*.pdf$	URL se terminant exactement par .pdf	.pdf?version=2
Disallow: /	Tous les chemins de l’hôte	Aucun chemin de cet hôte n’est autorisé par cette règle seule
Disallow: vide	N’interdit rien	Ne bloque pas l’ensemble du site

Lorsque plusieurs règles Allow et Disallow correspondent à une URL pour Google, la règle la plus spécifique détermine le résultat ; à longueur égale, l’autorisation l’emporte. La spécification interprétée par Google détaille aussi le regroupement des user-agents et le traitement des réponses HTTP.

6. Laisser accessibles les ressources nécessaires au rendu

Une page peut répondre en 200 tout en restant difficile à interpréter si ses feuilles de style, scripts ou données nécessaires sont bloqués. Google recommande de ne pas interdire une ressource lorsque son absence empêche de comprendre correctement la page.

Ressource	Risque du blocage	Contrôle
CSS principal	Mise en page et contenu masqué mal interprétés	Comparer le rendu avec et sans la ressource
JavaScript de rendu	Contenu principal absent du DOM rendu	Inspecter la page testée par Google
API publique de contenu	Page vide ou partielle pour le robot	Vérifier les appels indispensables
Image principale	Image non explorée ou absente de Google Images	Confirmer l’objectif pour la recherche d’images
Police ou élément décoratif	Impact souvent limité sur le contenu	Ne pas multiplier les règles sans bénéfice mesuré

Bloquer tous les répertoires nommés assets, static ou scripts par habitude est risqué. Ouvrez un échantillon de pages importantes et vérifiez ce que le robot reçoit réellement.

7. Déclarer le sitemap sans confondre les deux fichiers

La ligne Sitemap accepte une URL absolue. Elle peut se trouver hors d’un groupe de user-agents et plusieurs sitemaps peuvent être déclarés. Cette indication aide les robots à retrouver l’inventaire, mais elle n’autorise pas une URL bloquée et ne garantit pas son indexation.

Robots.txt	Sitemap XML
Gère l’accès d’exploration par chemins	Liste les URL canoniques que le site souhaite signaler
Peut couvrir des familles entières	Contient des URL absolues individuelles
Ne sert pas à sélectionner les pages à indexer	Ne force ni exploration ni indexation
Doit être placé à la racine de l’hôte pour une portée générale	Peut être déclaré dans robots.txt et Search Console
Règles évaluées selon le robot et le chemin	Doit rester aligné sur les URL finales, indexables et canoniques

Le guide du sitemap XML pour Google détaille la sélection des URL, le format, lastmod et le suivi. Ne placez pas dans le sitemap des variantes que vous interdisez volontairement d’exploration sans avoir documenté cette contradiction.

8. Tester le fichier publié et des URL représentatives

Contrôlez l’adresse publique exacte, son statut HTTP, son type de contenu et son contenu brut. Testez ensuite une URL autorisée et une URL interdite pour chaque règle. Une validation de syntaxe ne prouve pas que la stratégie correspond à l’architecture du site.

Contrôle	Résultat attendu	Erreur à corriger
Adresse	/robots.txt à la racine de chaque hôte concerné	Fichier dans un sous-dossier
Réponse	200 pour un fichier volontairement publié	Boucle, authentification ou erreur serveur
Encodage	Texte UTF-8 lisible	Format de traitement de texte ou caractères inattendus
Groupes	User-agents et règles dans l’ordre prévu	Règles orphelines ou groupe copié inutile
URL permise	Résultat autorisé pour le robot choisi	Blocage global trop large
URL interdite	Résultat bloqué pour le bon chemin	Motif qui ne correspond jamais
Sitemap	URL absolue, finale et accessible	Chemin relatif, mauvais hôte ou redirection

Le rapport robots.txt de Search Console indique les fichiers trouvés par Google pour les principaux hôtes, leur dernière exploration et les erreurs ou avertissements détectés. Pour une URL précise, complétez avec l’inspection et le test en direct.

9. Surveiller les réponses HTTP, le cache et les changements

Le statut renvoyé pour robots.txt modifie la manière dont Google traite le fichier. Une absence avec 404 n’a pas le même effet qu’une erreur serveur ou réseau. Google peut aussi mettre le contenu en cache ; une modification publiée n’est donc pas nécessairement utilisée à la seconde où vous l’envoyez.

Situation	Interprétation générale par Google	Action
200	Le contenu récupéré peut être analysé et mis en cache	Vérifier que les règles servies sont celles attendues
Redirection	Google suit un nombre limité de redirections	Servir si possible le fichier directement sur l’hôte concerné
404 ou autre 4xx hors limitation	Interprété généralement comme absence de restriction	Confirmer que cette ouverture est volontaire
429	Traité comme une erreur serveur	Corriger la limitation qui empêche la récupération
5xx, DNS ou réseau	Google peut suspendre temporairement l’exploration et utiliser une version en cache	Rétablir l’accès et contrôler le rapport
Fichier ancien en cache	Les règles précédentes peuvent rester utilisées un temps	Éviter les changements successifs et noter la date

Documentez chaque modification : motif, chemins affectés, exemples testés, auteur et date. Après une refonte, vérifiez que les anciens blocages ne masquent pas les nouvelles routes. Après une erreur globale, ne changez pas simultanément canonicals, sitemap et maillage : vous perdriez la capacité d’identifier la correction utile.

Exemples de configuration selon le besoin

Site public sans chemin à bloquer

User-agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

Cette configuration explicite l’accès général. Une ligne Disallow: vide aurait un effet d’autorisation équivalent pour les robots qui suivent le protocole.

Recherche interne et espace technique

User-agent: *
Disallow: /recherche
Disallow: /espace-technique/
Allow: /espace-technique/aide-publique

Sitemap: https://www.example.com/sitemap.xml

Avant publication, testez /recherche?q=velo, /espace-technique/rapport et l’exception autorisée. L’espace technique doit rester protégé par authentification s’il contient des données privées.

Environnement de préproduction

Ne comptez pas sur Disallow: / pour garder une préproduction secrète. Protégez l’environnement par authentification ou restriction d’accès. Le fichier robots.txt est publiquement lisible et n’impose rien aux robots qui ne respectent pas le protocole.

Checklist finale du fichier robots.txt

1. L’objectif concerne-t-il réellement l’exploration plutôt que l’indexation ou la confidentialité ?
2. Chaque règle correspond-elle à une famille d’URL qui existe sur le site ?
3. Le fichier se trouve-t-il à la racine exacte du bon protocole, hôte et port ?
4. Le nom, le contenu texte et l’encodage UTF-8 sont-ils corrects ?
5. Chaque groupe possède-t-il un user-agent et des règles simples, sans copie inutile ?
6. Les majuscules, barres obliques, jokers et fins d’URL ont-ils été testés sur des exemples ?
7. Les CSS, scripts, images et API nécessaires au rendu restent-ils accessibles ?
8. Le sitemap déclaré utilise-t-il une URL absolue, finale et accessible ?
9. Le fichier répond-il publiquement sans erreur, redirection excessive ni authentification ?
10. Une URL autorisée et une URL interdite ont-elles été testées pour chaque règle ?
11. Search Console affiche-t-elle le bon fichier, sa date de récupération et aucune erreur critique ?
12. La modification, sa raison et les contrôles effectués sont-ils documentés ?

Un bon robots.txt est généralement court. Il ne cherche pas à piloter le classement ni à cacher le site : il exprime quelques décisions d’exploration précises, compatibles avec l’architecture, les directives d’indexation, les canonicals et le sitemap.