Une ligne mal placée dans un fichier robots.txt peut faire perdre du temps à Googlebot, bloquer des ressources utiles au rendu, ou pire, couper l’exploration d’une section rentable. Le sujet paraît minuscule. Franchement, il ne l’est pas. Le robots txt standard est une règle de circulation pour les crawlers : utile quand elle est sobre, dangereuse quand elle devient une rustine SEO écrite dans la panique.
Je le traite comme un fichier de production, pas comme un bout de texte oublié à la racine. Avant de modifier quoi que ce soit, il faut comprendre ce que le standard contrôle vraiment, ce qu’il ne contrôle pas, puis tester. Pas après. Avant.
À quoi sert le standard robots.txt ?
Le fichier robots.txt est un fichier texte placé à la racine d’un site, par exemple https://exemple.fr/robots.txt. Les robots d’exploration volontaires le consultent avant de crawler les URL du domaine. Son rôle : donner des consignes d’accès au crawl, pas gérer toute la visibilité SEO à lui seul.
Le protocole existe depuis longtemps sous le nom de Robots Exclusion Protocol. Il a été formalisé en 2022 par la RFC 9309, ce qui donne un cadre plus clair aux notions de groupes, de règles, d’accès au fichier et de comportement attendu des robots.
En pratique, robots.txt sert surtout à éviter l’exploration de zones sans intérêt SEO : résultats de recherche interne, facettes infinies, URLs de tri, répertoires techniques, endpoints inutiles. Sur un petit site vitrine, le meilleur fichier est souvent presque vide. Oui, c’est frustrant pour ceux qui aiment tout optimiser. Mais une règle inutile est déjà une dette technique.
Ce que robots.txt contrôle vraiment, et ce qu’il ne contrôle pas
robots.txt contrôle le crawl. Pas l’indexation garantie. Cette nuance évite beaucoup de dégâts.
Si vous bloquez une URL avec Disallow, Google peut ne pas la crawler. Mais si cette URL est découverte ailleurs, par un lien externe ou un ancien maillage interne, elle peut encore apparaître dans les résultats avec peu d’informations. Le fichier a empêché Google de lire la page, il n’a pas forcément demandé sa suppression.
Pour désindexer une page, il faut choisir un autre levier selon le cas : balise meta robots noindex sur une page accessible au crawl, en-tête HTTP X-Robots-Tag pour certains fichiers, suppression temporaire dans Search Console, redirection 301, code 410, ou nettoyage du maillage. Bloquer dans robots.txt une page que vous voulez faire désindexer est souvent une mauvaise idée. Google ne peut plus lire le noindex. Le serpent se mord la queue, et personne n’est content.
Attention : robots.txt est public
Le fichier n’est pas non plus une barrière de sécurité. C’est une consigne. Les robots légitimes la respectent généralement, les robots douteux peuvent l’ignorer. Si une préproduction contient des données client, le robots.txt arrive beaucoup trop tard dans la discussion.
La syntaxe standard : User-agent, Disallow, Allow et Sitemap
La syntaxe tient en peu de mots. C’est justement pour ça qu’elle est piégeuse : une seule ligne large peut couvrir plus d’URL que prévu.
| Directive | Rôle | Exemple | Risque SEO |
|---|---|---|---|
| User-agent | Cible un robot ou un groupe de robots | User-agent: Googlebot | Créer des règles divergentes difficiles à maintenir |
| Disallow | Interdit le crawl d’un chemin | Disallow: /recherche/ | Bloquer une zone stratégique par règle trop large |
| Allow | Autorise une exception dans une zone bloquée | Allow: /wp-admin/admin-ajax.php | Croire que l’exception corrige une règle mal pensée |
| Sitemap | Indique l’emplacement du sitemap XML | Sitemap: https://exemple.fr/sitemap_index.xml | Penser que cette ligne compense un sitemap sale |
Un groupe commence par User-agent, puis contient des règles Allow ou Disallow. L’astérisque cible tous les robots : User-agent: *. Une directive Disallow: vide signifie que tout est autorisé pour ce groupe. À l’inverse, Disallow: / bloque tout le site au crawl. C’est la ligne qui fait transpirer pendant une migration.
Le chemin compte. Le fichier doit s’appeler robots.txt, en minuscules, à la racine du host concerné. Un sous-domaine a son propre fichier. https://blog.exemple.fr/robots.txt ne règle pas https://www.exemple.fr/robots.txt. Ça paraît évident. En audit, c’est pourtant une source classique de surprises.
User-agent: *
Disallow: /recherche/
Disallow: /*?tri=
Allow: /wp-admin/admin-ajax.php
Sitemap: https://www.exemple.fr/sitemap_index.xmlCet exemple est volontairement sobre. Il bloque une recherche interne, limite un paramètre de tri et déclare le sitemap. Rien de spectaculaire. Tant mieux.
Exemples de fichiers robots.txt selon les cas SEO
Bon, passons au concret. Je préfère un robots.txt court, lisible, commenté dans le dépôt interne si besoin, plutôt qu’un fichier de 80 lignes hérité de trois refontes. Les fichiers interminables vieillissent mal. Très mal.
Site vitrine ou blog simple
User-agent: *
Disallow:
Sitemap: https://www.exemple.fr/sitemap_index.xmlPour un site sans facettes, sans recherche interne indexable et sans piège de crawl, cette base suffit souvent. Ne bloquez pas des répertoires juste pour faire sérieux. Si Google peut lire les pages utiles, les ressources CSS et JS, et le sitemap, vous avez déjà gagné l’essentiel.
WordPress propre, sans casser le rendu
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://www.exemple.fr/sitemap_index.xmlLe vieux réflexe qui consistait à bloquer tout /wp-content/ est mauvais. Google doit parfois accéder aux CSS, JS, images ou fichiers nécessaires pour comprendre le rendu. Bloquer ces ressources peut brouiller l’analyse de la page, notamment quand on surveille les Core Web Vitals et la qualité d’expérience.
E-commerce avec filtres et paramètres
User-agent: *
Disallow: /*?tri=
Disallow: /*?couleur=
Disallow: /panier/
Disallow: /compte/
Sitemap: https://www.exemple.fr/sitemap_index.xmlLà, le fichier devient utile. Les filtres, tris et paramètres peuvent créer des milliers d’URL faibles. Mais attention aux règles trop brutales. Bloquer tous les paramètres peut aussi couper des pages de catégories filtrées réellement utiles, par exemple une landing SEO bien construite. Il faut regarder les logs, la Search Console et le maillage. Pas deviner.
Préproduction : le mauvais outil utilisé au mauvais endroit
Pour une préproduction, robots.txt peut compléter le dispositif, mais il ne doit jamais être la protection principale. La bonne approche reste une authentification, une restriction IP ou un contrôle serveur. Un Disallow: / sur staging rassure, puis quelqu’un oublie de le retirer au moment de passer en production. Classique. Et pénible.
Impact SEO : crawl budget, indexation et visibilité
Le robots txt standard agit surtout sur l’allocation du crawl. Sur un site de 30 pages, parler de crawl budget est souvent du théâtre. Sur un e-commerce, un média ou un site avec facettes, c’est autre chose : Googlebot peut perdre du temps dans des URL de tri, des paramètres, des pages internes sans valeur, pendant que des pages business attendent d’être revisitées.
L’objectif n’est pas de faire un site fermé. L’objectif est d’éviter le gaspillage. Moins d’URL inutiles explorées, moins de charge serveur, plus de signaux concentrés sur les pages qui doivent vraiment être découvertes et rafraîchies. C’est aussi une logique de sobriété technique : un crawler qui tourne dans une boucle de paramètres consomme des ressources pour rien. Petit sujet, vrai impact.
En revanche, ne bloquez pas les ressources nécessaires au rendu. Google documente le rôle de robots.txt dans l’exploration sur Search Central, et le point terrain est simple : si le robot ne peut pas charger ce qui structure la page, votre diagnostic SEO devient flou.
J’ajoute un point souvent oublié : robots.txt ne répare pas une architecture sale. Si votre maillage envoie Google vers des filtres inutiles, corrigez le maillage. Si votre sitemap contient des URL non canoniques, nettoyez le sitemap. Si vos pages génèrent des paramètres sans fin, traitez la cause. Le fichier robots.txt est un garde-fou, pas une benne à ordures.
Méthode d’audit avant de modifier un robots.txt
Avant de toucher au fichier, faites l’inventaire. Pas besoin d’un cérémonial de trois jours, mais il faut au moins savoir ce que vous êtes en train de couper.
- Listez les zones du site : pages business, blog, catégories, facettes, recherche interne, compte client, panier, API, fichiers médias, préproduction.
- Classez chaque zone : à crawler, à indexer, à désindexer, à sécuriser, ou à ignorer.
- Vérifiez les données réelles : rapport d’indexation Search Console, statistiques de crawl, logs serveur si disponibles.
- Repérez les règles existantes et leur historique. Une règle ajoutée pendant une migration peut survivre des années.
- Testez les chemins critiques avec l’outil d’inspection d’URL et un validateur robots.txt.
- Préparez un rollback. Oui, même pour trois lignes.
Ce découpage évite une confusion fréquente : une URL à désindexer ne se traite pas comme une URL à ne plus crawler. Une URL privée ne se traite pas comme une URL faible. Et une facette utile ne se traite pas comme un paramètre parasite.
Ma règle de décision
Dans une démarche de budget de performance web, ce fichier fait partie du ménage technique. Il ne remplace pas l’optimisation front, mais il évite de demander aux robots et au serveur de travailler sur du bruit.
Erreurs fréquentes à éviter
La pire erreur reste Disallow: / laissé en production. Ça arrive après une mise en ligne, une copie de fichier staging, une règle temporaire jamais retirée. Le résultat ? Découverte ralentie, exploration coupée, signaux SEO qui partent dans le brouillard.
Autres pièges que je vois trop souvent :
- Bloquer CSS, JS ou images nécessaires au rendu.
- Utiliser robots.txt pour cacher des URL sensibles.
- Confondre
Disallowetnoindex. - Écrire des règles sur les paramètres sans vérifier les pages qui génèrent du trafic.
- Oublier qu’un sous-domaine a son propre fichier.
- Modifier le fichier sans suivi Search Console après déploiement.
Un autre classique : copier le robots.txt d’un concurrent. Mauvaise idée. Son CMS, ses filtres, ses priorités SEO, son historique d’indexation et ses problèmes techniques ne sont pas les vôtres. Copier une règle sans son contexte, c’est importer une panne potentielle.
La documentation MDN rappelle aussi le point sécurité : une configuration robots.txt ne doit pas servir à protéger des informations confidentielles. C’est une consigne de crawl, pas un verrou. Si ce rappel vous semble basique, tant mieux. C’est justement le genre de base qui coûte cher quand elle est oubliée.
Checklist robots.txt avant mise en ligne
- Le fichier répond en 200 à l’URL exacte
/robots.txt. - Aucune règle
Disallow: /globale ne traîne en production. - Les pages et ressources nécessaires au rendu restent crawlables.
- Le sitemap XML canonique est déclaré.
- Les règles sur paramètres, filtres et répertoires ont été testées sur des URL réelles.
- Les pages à désindexer utilisent un levier adapté, pas un simple blocage crawl.
- Les environnements de test sont protégés par accès, pas seulement par robots.txt.
- Un contrôle Search Console est prévu après mise en ligne.
Gardez cette checklist courte. Si elle devient un roman, votre configuration est probablement trop complexe.
FAQ courte sur robots txt standard
robots.txt est-il obligatoire ?
Non. Un site peut fonctionner sans fichier robots.txt. Mais en SEO technique, il est recommandé d’en avoir un propre, même minimal, surtout pour déclarer le sitemap et éviter les règles héritées non maîtrisées.
robots.txt empêche-t-il l’indexation ?
Pas de façon garantie. robots.txt bloque le crawl, mais une URL peut rester indexée si Google la connaît par d’autres signaux. Pour demander une désindexation, utilisez plutôt noindex sur une page accessible, X-Robots-Tag, redirection, 410 ou outils Search Console selon le cas.
Où placer le fichier robots.txt ?
À la racine du host concerné, avec le nom exact robots.txt. Exemple : https://www.exemple.fr/robots.txt. Chaque sous-domaine doit avoir son propre fichier si vous voulez le contrôler.
Quelle différence entre robots.txt et noindex ?
robots.txt donne une consigne de crawl avant l’exploration. noindex donne une consigne d’indexation lue sur la page ou dans l’en-tête HTTP. Si la page est bloquée au crawl, Google peut ne pas voir le noindex.
Le standard robots.txt est-il respecté par tous les bots ?
Les grands robots légitimes le respectent généralement, mais le fichier repose sur la coopération. Des bots malveillants ou mal configurés peuvent l’ignorer. Il ne faut donc jamais l’utiliser comme mesure de sécurité.
Le bon robots.txt n’est pas celui qui contient le plus de règles. C’est celui qui dit clairement aux crawlers quoi éviter, sans bloquer ce qui nourrit votre visibilité. Si votre site a des filtres, une migration, une refonte ou un doute d’indexation, un conseil technique avant mise en production coûte moins cher qu’un mois de crawl cassé.
