Comment vérifier robots.txt pour des pages bloquées

Où robots.txt doit se trouver

Il doit se trouver à la racine de l'hôte, sous /robots.txt, en texte UTF-8 brut. Il s'applique à exactement un schéma, un hôte et un port, donc https://example.com/robots.txt ne régit rien sur https://shop.example.com ni rien sur la version http du même hôte. Chaque sous-domaine que vous voulez contrôler a besoin de son propre fichier.

Le code de statut que renvoie le fichier compte autant que son contenu. Un 404 est lu comme « aucune restriction, tout explorer », ce qui est un état parfaitement valide. Un 5xx répété est lu comme un échec temporaire et Google peut suspendre l'exploration de l'hôte plutôt que de supposer qu'il est autorisé à continuer. Un 403 se comporte comme une erreur serveur à cette fin. Si robots.txt n'est pas fiable, l'exploration devient peu fiable avec lui.

La syntaxe, en cinq lignes

User-agent: *
Disallow: /admin/
Allow: /admin/public-page.html
Disallow: /*?sessionid=
Sitemap: https://example.com/sitemap.xml

User-agent ouvre un groupe. Disallow bloque un préfixe de chemin, Allow découpe une exception dans un blocage, * correspond à n'importe quelle suite de caractères et $ ancre la fin d'une URL. Sitemap est indépendant de tout groupe et prend une URL absolue. Le format est standardisé sous la RFC 9309, donc le comportement décrit ici n'est pas propre à un fournisseur.

Deux règles de résolution décident ce qui se passe réellement. Un robot d'exploration n'utilise que le groupe le plus spécifique qui le nomme, et ignore entièrement le groupe * dès qu'un groupe le nomme directement. Au sein de ce groupe, la règle correspondante la plus longue l'emporte, et une égalité va à Allow.

Les erreurs qui bloquent tout un site

• Disallow: / resté d'un déploiement de préproduction. Un seul caractère, tout le site bloqué. Cela se déploie exactement de la même façon qu'un noindex de préproduction se déploie : un fichier de configuration promu avec une version.
• Bloquer le CSS et le JavaScript. Google rend les pages, donc un répertoire de ressources bloqué peut faire paraître une page cassée pour le robot d'exploration alors qu'elle vous paraît normale.
• S'attendre à ce que robots.txt retire une page de la recherche. Il ne le peut pas. Une URL bloquée peut quand même être listée à partir de liens externes, généralement sans extrait, et comme le robot d'exploration ne peut pas la récupérer, un noindex sur cette page n'est jamais vu. Pour retirer une page, autorisez l'exploration et servez un noindex.
• Utiliser noindex: comme directive à l'intérieur de robots.txt. Cela n'a jamais fait partie du standard et Google a cessé de l'honorer le 1er septembre 2019. C'est aujourd'hui ignoré silencieusement.
• Ajouter un groupe pour un robot nommé en s'attendant à ce que les règles génériques s'appliquent encore. Ce n'est pas le cas. Dès que User-agent: Googlebot existe, Googlebot lit ce groupe et rien d'autre, donc chaque règle partagée doit y être répétée.
• Une ligne vide à l'intérieur d'un groupe. Une ligne vide termine le groupe, donc les règles qui suivent n'appartiennent à rien jusqu'à la prochaine ligne User-agent.
• Lister des chemins privés. Le fichier est public. Y nommer /internal-admin/ publie l'emplacement de ce que vous essayez de cacher.

Comment tester un chemin précis

Récupérez le fichier et lisez d'abord le groupe qui s'applique à vous :

curl -s https://example.com/robots.txt

Puis appliquez à la main la règle de correspondance la plus longue au chemin en question. Avec Disallow: /blog/ et Allow: /blog/public/, l'URL /blog/public/post est autorisée parce que la règle Allow correspondante est plus longue. Pour une propriété que vous possédez, le rapport robots.txt dans Search Console montre le fichier récupéré, quand il a été récupéré pour la dernière fois et toute erreur d'analyse, ce qui est le moyen le plus rapide de confirmer que le robot d'exploration lit ce que vous pensez qu'il lit.

Confirmez qu'il est joignable depuis partout

Un robots.txt qui se charge depuis votre bureau peut quand même échouer pour un robot d'exploration. Les règles de protection contre les bots, les limites de fréquence et les blocages géographiques renvoient couramment un 403 aux plages d'adresses de centres de données tout en servant normalement les visiteurs résidentiels, et le résultat est un hôte que Google ralentit ou cesse d'explorer pour des raisons que rien dans vos journaux n'appelle une erreur.

La façon de le voir est de demander le fichier depuis un endroit qui n'est pas votre bureau. Pointez l'outil gratuit de vérification HTTP vers https://example.com/robots.txt et lisez le code de statut renvoyé depuis des points de contrôle dans différents pays. Un 200 partout est la réponse saine ; un 200 chez vous et un 403 depuis trois régions est la découverte. Pour tester si les règles bloquent une page précise, l'testeur de robots.txt gratuit vérifie une URL par rapport au groupe pour tous les robots d'exploration et indique si elle figure dans le sitemap. Robots.txt existe en dehors de la page, donc l'option Indexability d'un moniteur HTTP HostTracker ne le lit pas : elle surveille les balises noindex et canonique sur la page elle-même, tandis que le crawl planifié, en bêta, vérifie de manière croisée chaque page explorée par rapport au robots.txt. Le monitoring SEO explique ce que chacun couvre.