Un robots.txt bien conçu aide les moteurs à explorer les bonnes zones d’un site. Découvrez comment écrire, tester et maintenir vos règles sans bloquer des pages utiles.
La rédaction SEOMasteryHub
Équipe éditoriale et stratégie
Le fichier robots.txt est un petit fichier texte qui peut avoir de grandes conséquences sur l’exploration d’un site. Une règle trop large suffit parfois à empêcher Googlebot ou un autre robot d’accéder à des pages importantes, à leurs images ou aux fichiers nécessaires à leur affichage. À l’inverse, interdire quelques URLs inutiles peut aider à limiter le crawl de zones qui n’apportent rien à la recherche.
La bonne approche n’est donc pas de bloquer un maximum de répertoires. Il faut d’abord comprendre ce que les robots explorent, puis définir des règles ciblées et les tester avant publication. Ce guide explique comment fonctionne robots.txt en SEO, ce qu’il ne peut pas faire et comment réduire le risque d’une erreur coûteuse, que votre site soit un blog, un site marchand ou une plateforme plus complexe.
robots.txt indique aux robots conformes aux règles du protocole quelles parties d’un site ils peuvent explorer ou non. Il agit comme une consigne de crawl, pas comme un verrou technique. Un robot qui respecte les règles peut choisir de ne pas demander les URL interdites ; le fichier ne supprime toutefois ni la page ni son contenu.
Une règle comme Disallow: /recherche/ peut, par exemple, limiter l’exploration des pages de résultats internes. Elle ne protège pas ces pages contre l’accès des internautes et n’empêche pas nécessairement une URL d’apparaître dans un moteur. Si d’autres pages font un lien vers une URL bloquée, le moteur peut connaître son existence et éventuellement afficher l’adresse sans en avoir exploré le contenu.
Le fichier est particulièrement utile pour éviter l’exploration de zones sans intérêt pour les moteurs, comme certaines combinaisons de filtres ou des espaces de navigation générés en masse. Il peut aussi aider à préserver des ressources de crawl sur les sites très volumineux. Pour un petit site, il n’est pas forcément nécessaire de multiplier les règles : un fichier simple, voire une politique qui autorise tout le site, peut être le choix le plus sûr.
Confondre crawl, indexation et confidentialité est une source fréquente d’erreurs. Les notions sont liées, mais elles ne désignent pas le même processus.
robots.txt peut demander à un robot de ne pas explorer une URL. Il ne garantit pas que celle-ci ne sera pas indexée. Il ne doit jamais servir à protéger des données sensibles, un espace client, un fichier privé ou un environnement de préproduction. Pour ces usages, utilisez une authentification et des contrôles d’accès côté serveur.
Si une page doit rester accessible aux moteurs, mais ne pas figurer dans les résultats, une directive d’indexation telle que noindex peut convenir. Pour que le robot lise cette directive, il doit pouvoir accéder à la page : l’interdire dans robots.txt empêche justement cette lecture. Pour une ressource qui ne doit pas être publique, la bonne solution est de restreindre l’accès, pas de compter sur son absence dans un fichier public.
Le fichier doit se trouver à la racine de l’hôte concerné. Pour https://exemple.com, son adresse habituelle est https://exemple.com/robots.txt. Un fichier placé dans /blog/robots.txt ne définit pas les règles de l’ensemble du domaine.
Les règles s’appliquent à l’origine précise du fichier : protocole, hôte et port. Ainsi, https://exemple.com, http://exemple.com et https://www.exemple.com sont des origines différentes. Un sous-domaine tel que shop.exemple.com a besoin de son propre fichier s’il doit recevoir des consignes particulières. Vérifiez donc chaque version réellement accessible, surtout lors d’une migration ou d’une configuration avec plusieurs sous-domaines.
Le fichier doit être servi à l’adresse attendue, idéalement avec une réponse HTTP 200 et un contenu texte UTF-8. Évitez de le remplacer par une page HTML, une page de consentement ou une redirection complexe. Les moteurs savent gérer certains cas d’erreur et de redirection, mais un accès direct et stable réduit l’ambiguïté. Après une modification, contrôlez la réponse depuis le navigateur ou avec un outil de diagnostic HTTP.
Une règle classique associe un groupe de robots à une ou plusieurs consignes. User-agent désigne le robot visé ; Disallow interdit l’exploration d’un chemin ; Allow, pris en charge par les grands moteurs, permet une exception. Les directives sont généralement écrites une par ligne.
User-agent: *
Disallow: /espace-prive/
Allow: /espace-prive/aide-publique/
Ici, le groupe s’applique à tous les robots qui respectent la consigne. La zone /espace-prive/ est interdite, avec une exception pour le chemin /espace-prive/aide-publique/. Cette règle ne remplace pas un contrôle d’accès : le nom « privé » ne rend pas le contenu confidentiel.
Un fichier vide, ou un groupe comportant Disallow: sans chemin, indique généralement qu’aucun chemin n’est interdit à ce groupe. Pour autoriser explicitement l’exploration générale, on peut écrire :
User-agent: *
Disallow:
Les chemins doivent être choisis avec précision. Une règle visant /panier/ ne devrait pas être remplacée par une interdiction générale de /, qui bloquerait l’ensemble du site. Sur les moteurs qui reconnaissent les caractères génériques, * peut représenter une suite de caractères et $ la fin d’un chemin. Leur interprétation peut dépendre du robot : testez la règle avec le moteur visé plutôt que de supposer que tous les robots la comprennent de la même manière.
Les directives propres à un robot et les directives générales doivent être organisées avec soin. Si vous ajoutez plusieurs groupes, vérifiez à quel groupe chaque ligne appartient. Une règle placée après un nouveau User-agent ne s’applique pas automatiquement au groupe précédent. La syntaxe peut être tolérante, mais un fichier facile à lire est plus simple à auditer et à maintenir.
Vous pouvez également indiquer un plan de site XML avec une ligne Sitemap: et une URL absolue :
Sitemap: https://exemple.com/sitemap.xml
Cette ligne ne donne pas accès aux URL bloquées et ne remplace pas la soumission ou la découverte du sitemap par d’autres moyens. Elle fournit simplement une indication utile aux robots qui la prennent en charge.
Ne partez pas d’une liste trouvée sur un autre site ou d’un modèle généré automatiquement. Deux sites utilisant le même CMS peuvent avoir des structures et des besoins très différents. Commencez par relever les zones qui génèrent des URLs, puis demandez-vous si leur exploration présente un intérêt pour les internautes et les moteurs.
Les recherches internes, les combinaisons de filtres, certains calendriers ou des paramètres de tri peuvent créer de nombreuses variantes d’une même page. Sur un site marchand, plusieurs filtres combinés peuvent aussi produire une quantité importante d’URLs. Il peut être pertinent d’en limiter le crawl lorsque ces pages n’ont pas de valeur de recherche et ne doivent pas être explorées. Mais certaines pages de catégorie filtrées correspondent à une demande réelle et méritent d’être accessibles. Décidez selon leur utilité, leur contenu, leur maillage et leur stratégie d’indexation, pas uniquement selon la présence d’un paramètre dans l’URL.
Ne bloquez pas par réflexe les fichiers CSS, JavaScript ou les images nécessaires au rendu des pages. Les moteurs peuvent s’appuyer sur ces ressources pour comprendre l’affichage et l’expérience d’une page. Si une règle existante les interdit, vérifiez concrètement le rendu dans les outils de diagnostic avant de la conserver.
Les répertoires d’administration sont parfois bloqués par précaution, mais robots.txt est public : n’importe qui peut le consulter. Une consigne qui révèle l’emplacement d’une zone n’en assure pas la sécurité. Dans la mesure où une page d’administration exige déjà une authentification, la règle de crawl est souvent secondaire.
Pour limiter les erreurs, traitez le fichier comme une configuration à auditer, pas comme une formalité de lancement.
robots.txt et notez les règles en place. Comparez-les avec les paramètres du CMS, du serveur et du CDN : plusieurs systèmes peuvent intervenir dans la réponse finale.Cette méthode fonctionne aussi pour une petite mise à jour. Une modification d’une seule ligne peut changer le comportement de robots sur des milliers d’URLs si le chemin est trop large.
Sur un site à facettes, bloquez seulement après avoir séparé les variantes utiles des combinaisons sans valeur. Par exemple, une page filtrée sur une catégorie et une caractéristique recherchée peut apporter une réponse pertinente ; une URL combinant plusieurs dizaines de filtres peut être un cul-de-sac. La règle doit correspondre à la structure réelle des chemins et paramètres. Il faut la tester sur des URL représentatives, car une expression trop générale peut interdire des pages de catégorie importantes.
Pour les paramètres de suivi, commencez par vérifier s’ils créent réellement un problème de crawl ou de duplication. Les moteurs savent souvent traiter des variantes, et d’autres mécanismes du site peuvent préciser la version préférée. Une interdiction indiscriminée de tout chemin contenant un point d’interrogation risque de bloquer des fonctionnalités ou des pages utiles. Évitez les règles complexes tant que vous n’avez pas établi leur effet précis.
Les environnements de préproduction doivent être protégés par une authentification ou une restriction réseau. Ajouter Disallow: / au fichier de test peut fournir une précaution supplémentaire pour les robots conformes, mais ce n’est pas une barrière de sécurité. Lors d’une mise en production, vérifiez que le fichier de test n’a pas été copié tel quel : c’est une cause classique de site entièrement bloqué.
Un contrôle fiable combine plusieurs méthodes. La lecture manuelle permet de repérer une règle générale ; un outil de test aide à vérifier comment un moteur donné interprète un chemin ; l’inspection des URL et des journaux confirme ensuite le comportement observé. Aucun outil ne prouve à lui seul que toutes les versions du site sont correctement configurées.
Dans Google Search Console, inspectez les pages importantes et vérifiez si Google peut les explorer. Examinez aussi les rapports d’indexation et les éventuels avertissements liés au fichier. Pour un diagnostic technique, utilisez un outil de test compatible avec le robot concerné, puis confrontez son résultat aux règles publiées sur le véritable domaine. Un fichier de test local ou une ancienne version ne reflète pas forcément ce que reçoit Googlebot.
Quand une page attendue n’est pas visible dans les résultats, posez les questions dans cet ordre : le serveur répond-il correctement ? Le robot peut-il accéder à l’URL ? La page porte-t-elle une directive noindex ? Le contenu est-il réellement utile et découvrable par des liens ? Les canonicals et les redirections sont-ils cohérents ? robots.txt n’est qu’une piste parmi d’autres.
Surveillez enfin les changements après une mise à jour : les URL importantes restent-elles accessibles, les erreurs de crawl diminuent-elles, de nouvelles familles d’URL apparaissent-elles ? Un blocage ne doit pas être jugé uniquement au nombre de lignes du fichier. Le résultat dépend du site, des robots et de la manière dont les pages sont reliées entre elles.
Disallow: / dans le mauvais groupe peut empêcher l’exploration générale. Vérifiez en priorité cette règle sur chaque hôte.robots.txt pour demander une désindexation. Une page interdite peut rester connue. Utilisez le mécanisme adapté à l’objectif et laissez le robot accéder à la page lorsqu’il doit lire une directive d’indexation.www ne couvre pas automatiquement celle de shop, et un fichier de préproduction peut bloquer le domaine final.Crawl-delay n’est pas une consigne Google. Son comportement dépend du robot ; ne comptez pas dessus sans vérifier la documentation du moteur visé.Avant le déploiement, confirmez que :
Allow sont testées avec les interdictions voisines ;Après publication, vérifiez le fichier public, testez des URL autorisées et interdites, inspectez les pages prioritaires, puis surveillez les journaux et les rapports de crawl. Notez la date, la raison du changement et la personne responsable. Cette petite trace facilite le diagnostic si une page disparaît ou si un robot se comporte différemment de ce qui était prévu.
Non. Un site peut être exploré sans fichier, selon les liens découverts et les autres signaux disponibles. Créer un fichier est utile pour exprimer des consignes ; il n’est pas nécessaire d’y ajouter des interdictions si aucune n’est justifiée.
Oui, c’est possible. Google peut connaître l’URL par des liens ou d’autres indications sans avoir pu en explorer le contenu. Le fichier ne garantit donc pas la désindexation. Si l’objectif est de retirer une page des résultats, choisissez une méthode correspondant à sa situation et vérifiez que le robot peut lire les directives nécessaires.
noindex dans robots.txt ?Non. noindex n’est pas une directive standard de robots.txt reconnue par Google pour contrôler l’indexation. Pour qu’un moteur lise une balise ou un en-tête noindex, il doit pouvoir récupérer la page. En cas de doute, ne combinez pas blocage du crawl et demande de désindexation sans tester le scénario.
Cela dépend de la page et de son fonctionnement. Une page personnelle doit être protégée par une authentification, pas par robots.txt. Une page de panier peut être peu utile dans les résultats, mais vérifiez qu’une règle ne bloque pas aussi des URL ou ressources nécessaires au reste du site. Le blocage ne remplace ni la gestion des accès ni une stratégie d’indexation.
Revoir le fichier lors d’une refonte, d’un changement de CMS, d’une migration de domaine ou d’une évolution importante de l’architecture est une bonne pratique. Pour un site stable, un contrôle périodique et un test après toute modification suffisent souvent. La fréquence dépend du rythme de publication et de la complexité des URLs.
À retenir
robots.txtsert à guider le crawl, pas à sécuriser des données ni à garantir la désindexation. Écrivez des règles ciblées, vérifiez leur effet sur les URL et ressources importantes, testez le fichier réellement publié et contrôlez de nouveau après chaque changement majeur.
À lire aussi
Continuer la lecture
Dans la même catégorie
Les Core Web Vitals aident à repérer des problèmes concrets de chargement, de réactivité et de stabilité visuelle. Découvrez comment les mesurer, prioriser les corrections et vérifier leurs effets sur les visiteurs.
Les données structurées décrivent le contenu d’une page dans un format lisible par les moteurs de recherche. Voici comment choisir, mettre en place et vérifier un balisage utile, sans attendre de lui un gain de classement garanti.
La balise canonical aide les moteurs à identifier la version de référence parmi plusieurs URL proches. Voici quand l’utiliser, comment la configurer et comment vérifier qu’elle envoie un signal cohérent.