Robots.txt : syntaxe, pièges et bonnes pratiques SEO

Il n’existe pas beaucoup de fichiers où trois caractères de trop coûtent aussi cher. Un Disallow: / oublié après une mise en production, et le site disparaît progressivement des résultats. À l’inverse, un robots.txt trop permissif laisse les robots consommer leur temps sur des pages sans intérêt. Voyons comment l’écrire correctement, ce que Google en fait réellement, et où sont les pièges — un sujet qui s’articule avec l’ensemble des fondamentaux techniques du référencement.

Une barrière d’exploration, pas un verrou d’indexation

C’est le malentendu central, et il vaut la peine d’y insister. Quand vous interdisez un chemin, vous demandez au robot de ne pas demander la page au serveur. Vous ne lui dites pas de l’oublier. Si un lien externe pointe vers cette adresse, le moteur sait qu’elle existe et peut la faire figurer dans ses résultats, sans description, avec une mention indiquant qu’aucune information n’a pu être récupérée.

Deuxième conséquence, plus ennuyeuse : une page bloquée ne peut pas transmettre le contenu de ses propres directives. Si vous voulez retirer une URL de l’index, il faut au contraire laisser le robot y accéder pour qu’il lise la consigne de non-indexation. Bloquer et désindexer sont deux opérations opposées.

Enfin, le fichier n’a aucune valeur de sécurité. Il est public, lisible par tous, et lister vos répertoires sensibles revient à en publier la carte. Ce qui doit rester privé se protège par une authentification, jamais par une ligne de texte.

Où le fichier doit se trouver

Le fichier doit être accessible à l’adresse /robots.txt, à la racine de l’hôte, en réponse à une requête HTTP normale. Trois précisions comptent :

• Un fichier par hôte. boutique.exemple.fr et www.exemple.fr sont deux hôtes distincts, avec chacun son propre fichier. Celui du domaine principal ne couvre pas les sous-domaines.
• Le protocole compte. La version chiffrée et la version en clair sont techniquement deux origines différentes.
• Il doit être un vrai fichier texte, servi en UTF-8, avec un code de réponse 200. Un robots.txt qui renvoie une page d’erreur HTML est ignoré ou mal interprété.

Si le fichier est absent, le comportement est celui d’une autorisation totale : c’est parfaitement acceptable pour un petit site qui n’a rien à cacher aux robots.

La syntaxe, ligne par ligne

Le fichier s’organise en groupes. Chaque groupe commence par une ou plusieurs lignes User-agent, suivies des règles qui s’appliquent à ce robot :

# Regles generales
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /panier/
Disallow: /recherche

# Un robot particulier
User-agent: Googlebot-Image
Disallow: /images-privees/

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

Points à retenir : Disallow fonctionne par préfixe de chemin — /recherche bloque aussi /recherche-avancee, ce qui n’est pas toujours voulu. Les chemins sont sensibles à la casse. Un Disallow: vide signifie « rien n’est interdit ». Les commentaires commencent par un dièse et sont ignorés.

La ligne Sitemap est indépendante des groupes : elle vaut pour tout le fichier, doit contenir une URL absolue, et peut être répétée. C’est le moyen le plus universel de déclarer votre fichier de sitemap XML à tous les moteurs à la fois, sans passer par leurs interfaces respectives.

Les jokers et la fin de chaîne

Google prend en charge deux caractères spéciaux dans les chemins. L’astérisque remplace n’importe quelle suite de caractères, le dollar marque la fin de l’URL :

User-agent: *
Disallow: /*?tri=
Disallow: /*.pdf$
Allow: /guides/*.pdf$

La première règle neutralise toutes les URL contenant un paramètre de tri, cause fréquente de duplication sur les catalogues. La deuxième interdit les fichiers PDF, la troisième réautorise ceux d’un répertoire précis. Attention toutefois : ces jokers ne font pas partie de la norme historique et ne sont pas interprétés par tous les robots.

Qui gagne quand deux règles se contredisent

Deux principes, dans cet ordre. D’abord, un robot n’applique qu’un seul groupe : celui dont le nom d’agent lui correspond le plus précisément. Si un groupe Googlebot existe, Googlebot ignore entièrement le groupe *, même si ce dernier contient des règles utiles. Les groupes ne se cumulent pas — c’est une erreur de raisonnement très répandue.

Ensuite, à l’intérieur d’un groupe, la règle dont le chemin est le plus long l’emporte, qu’elle soit permissive ou restrictive. En cas d’égalité stricte de longueur, c’est la règle la moins restrictive qui s’applique. D’où l’utilité d’un Allow précis pour ménager une exception dans un répertoire globalement interdit.

Ce que Google ne prend pas en charge

Plusieurs directives circulent encore dans des modèles de fichiers copiés-collés depuis des années :

• Noindex: — plus interprétée par Google depuis le 1^er septembre 2019. Elle n’a jamais été normalisée. Utilisez la balise meta robots ou l’en-tête HTTP correspondant.
• Crawl-delay: — ignorée par Google, qui ajuste seul son rythme d’exploration. D’autres moteurs la respectent.
• Nofollow: — sans effet dans ce fichier ; l’attribut de lien porte le même nom mais n’a rien à voir.
• Les règles par pays ou par IP — le format ne prévoit rien de tel.

Laisser ces lignes ne casse rien, mais entretient l’illusion d’une protection qui n’existe pas.

Ce qu’il ne faut surtout pas bloquer

Le réflexe de « nettoyer » l’exploration se retourne souvent contre son auteur. Trois catégories à laisser accessibles :

1. Les feuilles de style et les scripts nécessaires à l’affichage. Un robot qui ne peut pas charger le CSS voit une page brute, mal structurée, parfois illisible sur mobile. Cela fausse aussi l’évaluation de la vitesse de chargement et des Core Web Vitals, puisque le rendu ne peut pas être reconstitué correctement.
2. Les images de contenu, si vous souhaitez apparaître dans la recherche visuelle.
3. Les pages que vous voulez désindexer, pour les raisons expliquées plus haut.

À l’inverse, sont de bons candidats au blocage : les espaces d’administration, les URL de panier et de tunnel de commande, les résultats de recherche interne, les pages de filtres combinatoires qui génèrent des milliers de variantes sans valeur.

Tester avant de publier, surveiller ensuite

Un fichier robots.txt se teste. Les outils d’inspection des moteurs indiquent, pour une URL donnée, si elle est autorisée et quelle règle s’applique. Faites ce test sur cinq ou six adresses représentatives — page d’accueil, page produit, fichier CSS, page paginée, PDF — plutôt que sur la seule page d’accueil.

Surveillez aussi la disponibilité du fichier. Des erreurs serveur répétées sur cette URL peuvent conduire un moteur à suspendre temporairement l’exploration du site, par prudence. Un robots.txt qui répond correctement, même vide, vaut mieux qu’un robots.txt intermittent.

Un dernier conseil d’hygiène : conservez ce fichier dans votre gestion de versions, au même titre que le code. Beaucoup d’accidents viennent d’une modification manuelle en production dont personne ne se souvient.

Questions fréquentes

Sources

• RFC 9309 — Robots Exclusion Protocol, spécification normalisée du format.
• Google Search Central — Documentation robots.txt : syntaxe, règles prises en charge et ordre de priorité.
• Google Search Central — Annonce de fin de prise en charge des règles non documentées (2019).

Article informatif. Le SEO évolue et aucun résultat n’est garanti : privilégiez toujours des pratiques conformes aux consignes de Google.