Tester son robots.txt sans se tromper d’origine
Tester un robots.txt, c’est répondre à deux questions séparées : le fichier est-il servi correctement à la racine de la bonne origine, et une URL donnée est-elle autorisée pour un robot donné. Depuis le retrait du testeur interactif de Search Console en décembre 2023, la réponse fiable vient du test en direct de l’inspection d’URL, du parseur open source de Google, ou d’un parseur local comme Protego.
Deux questions que le test doit séparer
La première question est celle du transport : le fichier existe-t-il, à quelle URL, avec quel code HTTP et quel type de contenu. La seconde est celle de la correspondance : pour un agent utilisateur précis et une URL précise, la règle appliquée est-elle Allow ou Disallow. Un outil qui répond à la première ne répond pas à la seconde, et c’est la source de la plupart des faux diagnostics.
Le fichier est lié à une origine complète, schéma, hôte et port compris. https://exemple.fr/robots.txt ne gouverne que https://exemple.fr/. La version en http://, le port :8443 et le sous-domaine blog.exemple.fr ont chacun besoin de leur propre fichier. Tester la mauvaise origine reste l’erreur la plus fréquente sur les architectures avec CDN ou reverse proxy, où le fichier servi en frontal n’est pas celui du dépôt.
Le nom du fichier est en minuscules. Sur un serveur Linux, /Robots.txt part en 404.
Les outils qui répondent vraiment
Google a retiré le testeur robots.txt historique de Search Console en décembre 2023. Le rapport qui l’a remplacé (Paramètres, puis robots.txt) affiche la dernière version récupérée, son code de statut, la date de récupération et les lignes non comprises, mais il n’a plus de champ pour soumettre une URL. Pour un verdict sur une URL, passez par l’inspection d’URL et le bouton de test en direct : le blocage apparaît alors en clair dans la couverture.
Hors de Search Console, le parseur C++ que Google utilise en production est publié depuis juillet 2019 sous licence Apache 2.0 (dépôt google/robotstxt). Compilé avec Bazel, son binaire prend un fichier, un agent utilisateur et une URL, et répond ALLOWED ou DISALLOWED. C’est la seule façon de reproduire la correspondance officielle sans propriété vérifiée.
Côté Python, prudence avec urllib.robotparser de la bibliothèque standard : sa comparaison de chemins repose sur un simple startswith, sans joker au milieu du chemin ni ancre $. Un `Disallow: /*.pdf$` y est mal interprété. Protego, le parseur par défaut de Scrapy depuis la version 2.0, implémente les jokers et la sélection de groupe, et se teste en trois lignes : `Protego.parse(texte).can_fetch(url, "Googlebot")`.
| Outil | Ce qu’il vérifie | Limite |
|---|---|---|
| Rapport robots.txt (Search Console) | Statut HTTP, date de récupération, erreurs de syntaxe | Aucun champ pour tester une URL précise |
| Inspection d’URL, test en direct | Verdict réel sur une URL de la propriété | Une URL à la fois, propriété vérifiée obligatoire |
| google/robotstxt (C++) | La correspondance exacte utilisée en production | À compiler avec Bazel, aucune interface web |
| Protego (Python) | Jokers * et $, sélection du groupe user-agent | Ne récupère pas le fichier, vous le fournissez |
| curl -sI | Code HTTP, Content-Type, chaîne de redirections | Ne dit rien des règles elles-mêmes |
Le groupe user-agent qui s’applique, et lui seul
Un robot ne cumule pas les groupes. Il retient le groupe dont la ligne User-agent correspond le plus précisément à son nom, et ignore tous les autres, y compris le groupe générique. Ce fichier laisse Googlebot explorer /admin/ librement, alors que l’intention affichée était l’inverse :
User-agent: * Disallow: /admin/ Disallow: /panier/ User-agent: Googlebot Disallow: /panier/
Une fois le groupe choisi, la règle gagnante est la plus longue en nombre de caractères, et en cas d’égalité parfaite c’est Allow qui l’emporte. Cette hiérarchie explique la plupart des résultats contre-intuitifs. La casse du chemin compte aussi, contrairement au nom de l’agent utilisateur qui, lui, est insensible à la casse.
Le RFC 9309, publié en septembre 2022, a figé cette syntaxe (groupes, Allow, Disallow, jokers) après vingt-cinq ans de convention informelle. Les directives hors norme survivent chez certains moteurs : Crawl-delay est pris en compte par Bing, ignoré par Google. La ligne Sitemap, elle, est indépendante des groupes et vaut pour tout le fichier.
| Règles du groupe | URL testée | Résultat |
|---|---|---|
| Disallow: /p et Allow: /p/page | /p/page | Autorisé, la règle la plus longue gagne |
| Disallow: /dossier/ et Allow: /dossier/ | /dossier/fiche | Autorisé, égalité donc Allow l’emporte |
| Disallow: /*.pdf$ | /guide.pdf | Bloqué |
| Disallow: /*.pdf$ | /guide.pdf?v=2 | Autorisé, le $ ancre la fin de l’URL |
| Disallow: /Admin/ | /admin/ | Autorisé, le chemin est sensible à la casse |
Codes HTTP : ce que le robot fait de la réponse
Le contenu du fichier n’est lu que si la réponse le permet. Une 404 sur /robots.txt n’est pas une panne du point de vue du crawler : elle signifie qu’aucune restriction n’existe, et tout le site devient explorable. À l’inverse, une 503 prolongée fige le crawl.
Le cas de panne le plus courant en 2026 vient des applications monopage. Un déploiement avec règle de réécriture attrape-tout renvoie l’index.html en 200 sur /robots.txt : Search Console affiche « récupéré », la première ligne est un doctype HTML, aucune directive n’est reconnue, et les règles ne s’appliquent plus. Deux commandes suffisent à le voir :
curl -sI https://exemple.fr/robots.txt curl -s https://exemple.fr/robots.txt | head -5
Vérifiez que l’en-tête Content-Type annonce text/plain et que le corps commence par User-agent ou un commentaire. Autre garde-fou : Google ne lit que les 500 premiers kibioctets du fichier et coupe le reste, ce qui pénalise les robots.txt générés automatiquement avec des milliers de lignes de Disallow.
| Réponse sur /robots.txt | Comportement de Googlebot |
|---|---|
| 200 avec du texte | Fichier analysé, gardé en cache jusqu’à 24 heures |
| 301 ou 302 | Jusqu’à 5 sauts suivis, au-delà traité comme absent |
| 404, 410, autres 4xx | Aucune restriction, tout le site devient explorable |
| 429, 500, 503 | Crawl suspendu et nouvelles tentatives ; après 30 jours d’échec, dernière copie connue, sinon aucune restriction |
| 200 mais du HTML | Lignes non reconnues ignorées, en pratique aucune règle |
Bloqué ne veut pas dire désindexé
La confusion est permanente et coûte des heures de débogage. Un Disallow empêche la récupération de la page, pas son indexation. Si des liens externes pointent vers l’URL bloquée, Google peut la faire apparaître dans les résultats sans description, avec le statut « Indexée malgré le blocage par le fichier robots.txt » dans le rapport d’indexation.
Pour retirer une page des résultats, il faut au contraire autoriser son exploration et poser une balise `` ou un en-tête `X-Robots-Tag: noindex`. Un robot qui n’a pas le droit de charger la page ne verra jamais l’instruction qu’elle contient. La directive `Noindex:` écrite dans le robots.txt n’est plus honorée par Google depuis le 1er septembre 2019.
Dernière vérification à faire après chaque mise en production : un `Disallow: /` hérité d’un environnement de préproduction. Une seule ligne, deux caractères, et un site entier sort du crawl. Le test en direct de l’inspection d’URL le détecte en dix secondes.
- Empêcher l’exploration et économiser du budget de crawl : robots.txt
- Empêcher l’affichage dans les résultats : noindex sur une page explorable
- Retirer une URL en urgence d’une propriété vérifiée : outil de suppression de Search Console, effet temporaire d’environ six mois
Testez vos connaissances
Le fichier /robots.txt renvoie une 503 depuis plusieurs heures. Que fait Googlebot ?
Score : 0 sur 3
Questions fréquentes
Où est passé le testeur robots.txt de Search Console ?
Il a été retiré en décembre 2023. Le rapport robots.txt, dans Paramètres, montre désormais la version récupérée par Google, son code de statut et les erreurs de syntaxe, mais il ne teste plus d’URL. Pour un verdict par URL, utilisez l’inspection d’URL puis le test en direct.
Combien de temps avant que Google prenne en compte une modification ?
Le fichier est mis en cache jusqu’à 24 heures. Une correction urgente peut être signalée en demandant une nouvelle récupération depuis le rapport robots.txt, mais la propagation vers l’ensemble des systèmes de crawl n’est pas immédiate pour autant.
Mon test local dit « autorisé » et Search Console dit « bloqué ». Pourquoi ?
Trois causes dominent : vous testez une autre origine (http au lieu de https, ou le domaine sans www alors que la redirection change d’hôte), Google utilise encore une version en cache, ou votre parseur local n’implémente pas les jokers. Comparez d’abord le contenu exact affiché dans le rapport robots.txt avec celui que vous avez testé.
Faut-il un robots.txt par sous-domaine ?
Oui. Chaque couple schéma, hôte et port est une origine distincte. Le fichier de exemple.fr ne s’applique pas à blog.exemple.fr ni à la version en http. Un sous-domaine sans robots.txt renvoie une 404 et est donc entièrement explorable.
Peut-on tester le robots.txt d’un site dont on n’est pas propriétaire ?
Pas avec Search Console, qui exige une propriété vérifiée. En revanche, le fichier est public : récupérez-le avec curl et passez-le au parseur google/robotstxt ou à Protego avec l’agent utilisateur de votre choix. C’est la méthode à utiliser pour auditer un concurrent ou un site client avant accès.