Comment écrire un robots.txt : directives, correspondance, et ce qu'il ne peut pas cacher

Une instruction d'exploration, pas une serrure ni une gomme

Google le dit sans détour : robots.txt n'est pas un mécanisme pour tenir une page hors de Google, et une page interdite dans robots.txt peut toujours être indexée si d'autres sites y renvoient. Le mécanisme est simple une fois énoncé. Disallow demande à un robot bien élevé de ne pas charger l'URL. Il ne dit rien sur la présence de l'adresse dans un index, et un lien venu d'un autre site fournit assez — l'URL elle-même, plus le texte d'ancrage qui la vise — pour référencer la page sans jamais la télécharger. Le résultat est le résultat de recherche bien connu, avec une URL nue, sans titre issu de la page ni description, exactement là où le propriétaire du site croyait l'avoir retirée.

Les bons outils dépendent de ce que tu veux vraiment. Pour tenir une page hors des résultats, sers un noindex — soit une balise meta robots dans l'en-tête du document, soit un en-tête de réponse X-Robots-Tag, qui fonctionne aussi pour les fichiers sans en-tête HTML, comme les PDF. Pour soustraire un contenu à tout le monde, mets-le derrière une authentification ; rien de déclaratif dans un fichier texte public n'a jamais restreint l'accès, et la RFC 9309 le dit franchement en qualifiant le protocole de non-substitut à de véritables mesures de sécurité. Et il y a un piège d'ordonnancement pour qui combine les deux : si tu interdises une URL, le robot ne la chargera jamais, ne verra donc jamais le noindex que tu y as ajouté, et la page peut rester indéfiniment dans l'index. Laisse-la explorable jusqu'à sa disparition, puis interdis-la si tu y tiens encore.

Comment fonctionne la correspondance : préfixes, deux jokers, et la règle la plus longue

Chaque valeur de Disallow et d'Allow est comparée comme préfixe du chemin de l'URL : Disallow: /admin bloque donc aussi bien /admin, /admin/, /administrator que /admin-tools. Ajouter une barre finale restreint au répertoire. Deux caractères spéciaux affinent cela : * représente zéro caractère ou plus, et $ ancre la fin de l'URL — ainsi Disallow: /*.pdf$ bloque toute URL se terminant par .pdf tout en laissant /report.pdf?download=1 accessible, la chaîne de requête venant après l'ancre. Un joker en fin de valeur n'ajoute rien : /* est la même règle que /. Les chemins sont sensibles à la casse, /Admin et /admin sont donc deux règles distinctes, alors que les noms de directives, eux, ne le sont pas.

Quand plusieurs règles correspondent à une URL, c'est la plus spécifique qui gagne, et la spécificité ne signifie ici rien de plus sophistiqué que la longueur du chemin de la règle en octets. Disallow: /reports/ et Allow: /reports/public/ correspondent tous deux à /reports/public/q3.html ; l'Allow est plus long, le fichier est donc explorable. Inverse les longueurs et le Disallow l'emporte. Si deux règles correspondantes ont exactement la même longueur, l'égalité profite à la moins restrictive, c'est-à-dire à l'Allow. L'ordre dans le fichier est sans effet — un Disallow écrit après un Allow ne l'annule pas, et ce seul point explique une bonne part des robots.txt qui ne se comportent pas comme leur auteur les lit. Deux autres limites à connaître : Google lit au plus 500 kibioctets et ignore tout ce qui suit, et une valeur Disallow vide signifie que rien n'est bloqué — c'est la façon idiomatique d'écrire un groupe qui autorise tout.

Où vit le fichier, et pourquoi il annonce ce que tu voulais cacher

La règle d'emplacement est absolue et ne se configure pas. La RFC 9309 exige que les règles soient accessibles dans un fichier nommé /robots.txt, tout en minuscules, à la racine du service, et Google ajoute qu'elles ne s'appliquent qu'à l'hôte, au protocole et au port où le fichier est hébergé. Lis-le attentivement, car les conséquences font trébucher en permanence. Un fichier à https://example.com/robots.txt ne gouverne rien sur http://example.com, rien sur https://shop.example.com et rien sur https://example.com:8443 — chacune de ces adresses est une origine distincte qui a besoin de son propre fichier. Un fichier placé dans un sous-répertoire n'est pas lu du tout. Et un site derrière un CDN ou un proxy inverse ne vaut que ce que vaut son routage : si la plateforme sert son propre robots.txt à la racine, le vôtre côté application ne s'exécute jamais.

Passons au franc-parler. Le fichier est servi à quiconque le demande, sans authentification, et c'est de loin la première chose que lit un scanner automatisé. Écrire Disallow: /internal/backup-2019/ ne cache pas ce répertoire — cela publie son existence, son chemin exact et le fait que tu l'aies jugé digne d'être caché, dans un document que tu invites l'internet entier à lire. Tous les outils de reconnaissance jamais écrits commencent là, précisément pour cette raison. Si un chemin ne doit pas être atteint, mets-le derrière une authentification ou sors-le de l'hôte public ; s'il doit seulement ne pas être exploré, interdis un préfixe parent large plutôt que de nommer la feuille sensible. Et traite le fichier comme du code : garde-le en gestion de versions, relis les modifications comme n'importe quel déploiement, et vérifie-le après chaque migration de plateforme, car un Disallow: / égaré parti en production est le moyen le plus rapide de retirer un site entier de la recherche, et l'un des plus lents dont on se remet.

Questions fréquentes

Puis-je utiliser robots.txt pour tenir une page privée hors de Google ?

Non, sur les deux plans. Google dit franchement que robots.txt n'est pas un mécanisme pour tenir une page hors de Google, et une URL interdite mais liée depuis n'importe quel autre site peut encore être référencée avec le seul lien et son texte d'ancrage. La page n'est pas non plus privée en un sens réel : robots.txt n'est qu'une demande, respectée par les moteurs de recherche et ignorée par tout ce qui a intérêt à l'ignorer, et le fichier lui-même diffuse le chemin. Pour la visibilité dans la recherche, utilise un noindex, servi via une balise meta robots ou un en-tête X-Robots-Tag. Pour une vraie confidentialité, utilise une authentification. Ce sont deux problèmes distincts et robots.txt ne résout ni l'un ni l'autre.

Les sous-domaines et http contre https partagent-ils un seul robots.txt ?

Non. Les règles ne s'appliquent qu'à l'hôte, au protocole et au port exacts qui ont servi le fichier : https://example.com, http://example.com, https://www.example.com et https://api.example.com sont donc quatre portées distinctes nécessitant quatre fichiers distincts — même si elles pointent vers le même serveur et la même racine documentaire. C'est la deuxième erreur de configuration la plus fréquente, après le placement du fichier dans un sous-répertoire, où il n'est jamais lu. Conséquence pratique : si tu rediriges http vers https, le robot suit la redirection pour charger le fichier, la copie https gouverne donc les deux de fait ; si tu ne rediriges pas, l'origine http n'a aucune règle et est explorée librement.

J'ai interdit une page mais elle est toujours dans les résultats. Et maintenant ?

C'est le comportement attendu, et la correction consiste à inverser l'ordre des opérations. Retire le Disallow pour rendre la page à nouveau explorable, ajoute un noindex — balise meta robots ou en-tête X-Robots-Tag — et attends que la page soit réexplorée puis retirée. Si l'approche initiale a échoué, c'est par circularité : tant que l'URL est interdite, le robot ne la charge jamais, ne voit donc jamais le noindex que tu y as posé, et le résultat bâti sur les liens entrants persiste indéfiniment. Une fois la page sortie de l'index, tu peux rétablir le Disallow pour économiser du budget d'exploration, même si à ce stade cela ne rapporte généralement pas grand-chose.