Fichier robots.txt : les bonnes pratiques à adopter

Un commercial m'a appelé l'an dernier, paniqué : « On a disparu de Google, tout notre catalogue est introuvable. » J'ai ouvert son site, tapé /robots.txt, et j'ai compris en trois secondes. Son prestataire avait collé un Disallow: / en ligne 4 pour « sécuriser la mise en production ». Le site tournait toujours, les visiteurs achetaient, mais plus aucun robot ne passait. Voilà ce que coûte une mauvaise ligne dans un fichier de 200 octets.

Le fichier robots.txt est probablement le document le plus lu de votre site et le moins bien écrit. On y met trois lignes à la création, on n'y revient plus jamais, et on se demande deux ans plus tard pourquoi Google explore 40 000 URL de tri produits au lieu de vos fiches catégories.

À quoi sert vraiment un fichier robots.txt (et ce qu'il ne fait pas)

Un robot explore votre site en suivant les liens. Chaque visite coûte du temps serveur et remplit une file d'attente. Le robots.txt sert à dire : « Ne perds pas ton temps ici. » C'est tout. C'est un outil de gestion de l'exploration, rien d'autre.

La confusion la plus répandue, je l'entends au moins une fois par mois en audit : croire qu'une URL bloquée dans le robots.txt disparaît de Google. Faux. Si la page est déjà indexée et que vous ajoutez un Disallow, le robot ne passe plus, donc il ne lit plus le noindex posé dans la balise. Résultat : la page reste dans les résultats, avec une description obsolète, parfois pendant des mois. J'ai vu une fiche produit retirée du catalogue traîner en première page pendant huit semaines à cause de ça.

Comment trouver le fichier robots.txt d'un site

Ajoutez simplement /robots.txt à la racine : https://exemple.fr/robots.txt. Pas de sous-dossier, pas de paramètre. Si vous obtenez une erreur 404, il n'y a pas de fichier — et c'est un état valide. Sans robots.txt, tout est explorable par défaut.

Deux exceptions à connaître. Un fichier renvoyant une erreur 5xx (serveur en vrac) peut temporairement suspendre l'exploration côté Google : mieux vaut un 404 franc qu'un 503 qui traîne. Et si vous voyez un fichier qui ressemble à un mur infranchissable, vérifiez l'historique de déploiement du site : c'est presque toujours une erreur de copie depuis un environnement de préproduction.

La syntaxe, avec un exemple qui tient debout

Voici un bloc réaliste pour un site e-commerce. Rien de théorique, c'est la structure que j'utilise par défaut :

User-agent: *
Disallow: /admin/
Disallow: /panier/
Disallow: /checkout/
Disallow: /*?orderby=
Disallow: /*?filter_
Allow: /wp-admin/admin-ajax.php
Allow: /wp-content/uploads/

Sitemap: https://exemple.fr/sitemap_index.xml

User-agent: AhrefsBot
Crawl-delay: 10

Quelques points de lecture. Le User-agent: s'applique à tous les robots non nommés ailleurs. Un groupe nommé spécifiquement prend le dessus sur le générique. Le préfixe /? cible les URL contenant une chaîne de paramètres — en pratique, tous les tris et filtres de catalogue, qui génèrent des milliers de combinaisons.

Allow contre Disallow : qui gagne ?

Le robot compare les règles par longueur de préfixe, pas par ordre d'apparition. La règle la plus longue et la plus spécifique l'emporte. D'où le Allow: /wp-admin/admin-ajax.php placé après le Disallow: /admin/ : il est plus long, il gagne, l'appel Ajax passe. Sans cette exception, certains sites WordPress cassent des fonctionnalités côté front.

Les jokers : remplace n'importe quelle séquence, $ ancre la fin de l'URL. Disallow: /.pdf$ bloque les PDF, et seulement eux.

• Attention aux slashs — une barre oubliée change le périmètre.
• Un Disallow vide (Disallow:) signifie « tout autoriser ».
• Les commentaires commencent par #.
• L'encodage doit être en UTF-8, sans BOM.

Les erreurs que je vois le plus souvent (j'en ai commis la moitié)

La plus coûteuse, de loin, c'est de bloquer le CSS et le JavaScript. Un Disallow: /wp-content/ ou Disallow: /assets/ paraît anodin : on se dit « ce sont des ressources, pas des pages ». Sauf que Google rend la page pour évaluer le contenu. Sans CSS, il voit un mur de texte brut, ne détecte pas le contenu caché, ne mesure pas la lisibilité mobile. Sur un site dont j'ai repris le suivi, la correction de ce seul point a fait bouger la position moyenne de 4,2 places sur les pages catégories en cinq semaines.

Deuxième erreur : le Disallow: / laissé en production. Toujours le même scénario. Une mise en ligne, un copier-coller depuis le staging, et le silence radio.

Troisième : vouloir bloquer les pages de recherche interne. Bonne intention, mauvaise exécution. Si vous bloquez /?s=, le robot n'explore plus ces URL, mais elles peuvent rester indexées si elles ont déjà été découvertes. Le bon réflexe est de les noindex, pas de les bloquer.

Comment gérer le robots.txt sur WordPress ?

WordPress génère un fichier virtuel par défaut. Pour le modifier, deux voies : la page Réglages > Lecture propose un champ d'édition, mais il ne remplace pas toujours le fichier physique. Si un robots.txt existe réellement à la racine de l'hébergement, c'est lui qui est servi, et vos modifications dans l'admin ne servent à rien. J'ai perdu une demi-journée là-dessus la première fois.

La solution fiable : un plugin de SEO qui prend la main, ou un fichier physique écrit à la main via FTP. Le fichier physique reste ma préférence. Il est versionnable, il ne dépend d'aucun plugin, et il survit à une désactivation accidentelle.

Budget de crawl : où le fichier fait vraiment la différence

Sur un site de 50 pages, le robots.txt ne change pas grand-chose. Sur un catalogue de 200 000 références avec tris, filtres et pagination, il devient stratégique. Chaque URL paramétrée consomme du budget d'exploration qui n'ira pas vers vos fiches produits.

Type d'URL	Traitement recommandé	Effet attendu
/admin/, /panier/, /checkout/	Disallow	Aucune valeur SEO, budget préservé
Paramètres de tri et filtres	Disallow via joker	Réduction nette des URL explorées
Recherche interne	noindex (pas Disallow)	Sortie progressive des résultats
Pages de pagination	Laisser explorer	Découverte des fiches profondes
CSS / JS / images de contenu	Laisser explorer	Rendu complet de la page

Le moyen de vérifier l'effet : le rapport d'exploration de la Search Console. Comparez le nombre de requêtes sur les URL paramétrées avant et après. Sur un site que j'ai accompagné l'an dernier, le passage de 62 % à 21 % de requêtes sur les filtres a coïncidé avec une exploration plus rapide des nouvelles fiches — deux jours au lieu de neuf.

Comment tester son fichier avant de le mettre en ligne

Ouvrez-le dans un navigateur, en navigation privée. S'il s'affiche comme du texte brut, il est servi correctement. S'il déclenche un téléchargement ou une page HTML, le serveur renvoie le mauvais type de contenu et le robot peut l'ignorer.

Ensuite : ne déployez jamais un changement de robots.txt sans avoir vérifié l'URL concernée. Créez une page de test, bloquez-la, regardez si elle disparaît de l'exploration. Et gardez une copie de l'ancien fichier sous la main. Un retour arrière en trente secondes vaut mieux qu'une explication à un client mécontent.

Ce que le robots.txt ne contrôle pas

Avouons-le, la partie la moins rassurante : vous n'êtes pas seul décideur. Un moteur peut ignorer une directive, et certains le font. Les robots d'IA, notamment, ne respectent pas toujours les exclusions — si votre enjeu est d'empêcher l'entraînement de modèles sur vos contenus, le robots.txt est une demande, pas un verrou.

Deuxième limite : il n'existe pas de standard unique et contraignant. Les grandes plateformes suivent un consensus de fait, avec des variantes. Le Crawl-delay est reconnu par certains robots et purement ignoré par d'autres. Ne construisez donc pas votre stratégie dessus : préférez une limitation de vitesse côté serveur ou un CDN.

Troisième : le fichier ne protège rien. Une URL listée dans un Disallow reste accessible à qui la tape dans la barre d'adresse. Pour du contenu confidentiel, c'est mot de passe ou suppression.

Questions fréquentes autour du robots.txt

Robots.txt, c'est quoi exactement ?

Un fichier texte à la racine d'un site qui donne des consignes d'exploration aux robots. Il est apparu au milieu des années 1990 et n'a presque pas bougé depuis : quelques directives, une syntaxe minimaliste. Sa simplicité explique à la fois sa robustesse et le nombre d'erreurs qu'on y trouve.

À quoi sert la directive Allow ?

À rouvrir une exception dans une zone bloquée. Comme la règle la plus spécifique gagne, Allow sert à réautoriser un fichier précis au milieu d'un répertoire exclu. C'est indispensable pour les ressources techniques dont le rendu dépend.

Faut-il créer un fichier robots.txt quand on n'en a pas ?

Pas obligatoire, mais recommandé dès que le site dépasse quelques dizaines de pages ou utilise un CMS. Ne serait-ce que pour déclarer le sitemap et éviter les explorations inutiles. Sur un site vitrine de cinq pages, l'absence ne changera rien. Sur un blog avec archives par date, tags et pagination, elle coûte cher.

Un dernier point, et c'est celui sur lequel je serai intraitable : ce fichier se relit à chaque refonte, pas une fois pour toutes. J'ai vu trop de migrations propres, bien pensées, avec un robots.txt recopié tel quel depuis l'ancienne plateforme, pointant vers des chemins qui n'existent plus. Le robot explore dans le vide, les nouvelles pages attendent. Vérifiez-le comme vous vérifiez vos redirections 301 — même combat, même conséquence si on l'oublie.