Lire le robots.txt d'un site
Saisissez une adresse et l'outil récupère le fichier robots.txt du domaine, puis en
affiche le contenu et les règles qu'il contient : les groupes User-agent, les
directives Disallow et Allow, et la déclaration éventuelle du sitemap.
Le fichier se trouve toujours à la racine du domaine, à l'adresse
https://exemple.fr/robots.txt. Il n'existe qu'un seul emplacement valable : un
fichier placé dans un sous-répertoire n'est jamais lu.
Ce que le robots.txt contrôle réellement
Ce fichier indique aux robots d'exploration quelles parties du site ils ne doivent pas parcourir. C'est une consigne d'exploration, et uniquement cela.
La distinction est capitale : bloquer l'exploration n'empêche pas l'indexation. Si d'autres sites pointent vers une page bloquée, Google peut l'afficher dans ses résultats — sans description, puisqu'il n'a pas eu le droit de la lire, mais elle apparaîtra.
Pour retirer réellement une page des résultats, il faut une balise noindex ou un
en-tête X-Robots-Tag. Et pour que le moteur voie cette instruction, il doit pouvoir
lire la page : la bloquer dans le robots.txt l'empêche justement de découvrir le noindex. Les deux
mesures combinées produisent l'inverse de l'effet recherché.
Les erreurs qui coûtent le plus cher
Le blocage total oublié. Un Disallow: / dans un groupe
User-agent: * interdit l'exploration du site entier. C'est le réglage d'un site en
préproduction, et il est régulièrement mis en ligne avec la version définitive. Si le trafic d'un
site neuf ne décolle pas, c'est la première chose à vérifier.
Le blocage des ressources d'affichage. Interdire les répertoires contenant les feuilles de style et les scripts empêche le moteur de restituer la page telle qu'un visiteur la voit. Il évalue alors une version dégradée, souvent jugée inadaptée au mobile.
La casse. Les chemins sont sensibles à la casse : /Admin/ et
/admin/ sont deux règles différentes.
Croire que c'est une protection. Le fichier est public et consultable par n'importe qui. Y lister ses répertoires sensibles revient à en publier la carte. Ce qui doit rester privé se protège par mot de passe, jamais par une ligne de robots.txt.
Comment les règles s'appliquent
Les directives sont groupées par User-agent. Un robot lit le groupe qui le désigne
nommément ; s'il n'en trouve aucun, il lit le groupe générique *. Il n'applique
que ce groupe : les autres sont ignorés, y compris le générique.
C'est une source d'erreur classique. Un groupe spécifique à Googlebot qui ne reprend pas les interdictions du groupe générique laisse Google explorer tout ce que les autres robots ne peuvent pas voir.
Entre deux règles qui s'appliquent à une même adresse, la plus longue l'emporte. Un
Allow: /blog/public/ prend donc le pas sur un Disallow: /blog/.
Y déclarer son sitemap
Une ligne Sitemap: suivie de l'adresse complète du fichier signale son emplacement à
tous les moteurs, sans passer par un outil propriétaire. Elle se place n'importe où dans le
fichier et ne dépend d'aucun groupe User-agent.
C'est un ajout gratuit et utile, absent de beaucoup de sites : l'outil vous dira si le vôtre le contient.
Un robots.txt absent n'est pas un problème
Si le fichier n'existe pas, le serveur renvoie une erreur 404 et les robots explorent tout. Pour un petit site sans zone à masquer, c'est un comportement parfaitement acceptable.
En revanche, une erreur serveur de type 500 sur ce fichier est bien plus ennuyeuse : Google interprète cette réponse comme une incertitude et peut suspendre l'exploration en attendant de savoir à quoi s'en tenir. Un fichier manquant vaut mieux qu'un fichier qui renvoie une erreur.