Chemins sensibles dans robots.txt

Comment fonctionne cette vérification

Scanaris télécharge ton /robots.txt et vérifie d'abord que c'est un vrai robots : il répond 200, n'est pas du HTML et contient au moins une directive (User-agent, Disallow, Allow ou Sitemap). Il parcourt ensuite chaque ligne Disallow: et regarde si le chemin contient l'un de ces indicateurs : wp-admin, phpmyadmin, /admin, backup, .git, .env, /private, /secret, dump, .sql, password ou credential. Si l'un correspond, il ouvre un constat de sévérité faible avec les chemins trouvés. La liste est volontairement courte : des mots comme test, old, tmp ou logs apparaissent dans des robots parfaitement légitimes et produisaient des faux positifs.

Pourquoi c'est important

robots.txt est public par définition : n'importe qui peut le lire, et c'est d'ailleurs l'un des premiers fichiers que consulte un outil de reconnaissance. Quand tu écris Disallow: /backups/ ou Disallow: /ancien-admin/, tu ne caches pas ces chemins ; tu les désignes à celui qui les cherche, avec la garantie supplémentaire qu'ils comptent pour toi. Google ne les explorera pas, mais un attaquant ne lit pas robots pour lui obéir, il le lit pour savoir où aller. C'est un constat de sévérité faible parce que lister un chemin ne le rend pas accessible ; le problème apparaît quand le chemin listé n'est, en plus, pas protégé.

Comment corriger

• Retire de robots.txt les chemins que tu ne veux pas annoncer. Si tu ne veux pas que Google indexe une zone privée, la bonne approche est que cette zone demande une connexion ; ce qui est derrière une authentification n'est pas indexé de toute façon.
• Si tu as besoin qu'une page accessible reste hors des moteurs sans l'annoncer, utilise l'en-tête X-Robots-Tag: noindex ou la meta robots sur cette page. Les moteurs la respectent et rien n'est écrit dans un fichier public.
• Protège vraiment le chemin. Un panneau sur /admin a besoin d'une authentification, pas d'une ligne dans robots. Un dossier /backups/ ne devrait pas du tout être dans le répertoire public ; les vérifications fichiers sensibles et listage de répertoires couvrent ces cas.
• WordPress : le robots virtuel qu'il génère inclut Disallow: /wp-admin/ par défaut. Ce n'est pas grave, parce que wp-admin exige déjà une connexion et envoie noindex ; tu peux le laisser ou remplacer robots par le tien sans cette ligne. L'important est que la connexion ait des mots de passe forts, une limite de tentatives et, si possible, un second facteur.

Un robots.txt sain est généralement court : un User-agent: *, peut-être deux ou trois Disallow pour la recherche interne ou des paramètres, et la ligne Sitemap:. Si le tien a vingt lignes de chemins « privés », il fait le travail d'un système de permissions, et mal.

Vérifie que c'est corrigé

curl -s https://tondomaine.com/robots.txt | grep -iE "^disallow:.*(admin|phpmyadmin|backup|\.git|\.env|private|secret|dump|\.sql|password|credential)"

Rien ne doit sortir. Et pour chaque chemin retiré, vérifie qu'il demande bien une authentification ou renvoie 404 :

curl -s -o /dev/null -w "%{http_code}\n" https://tondomaine.com/admin/

Questions fréquentes

Si je retire /admin de robots.txt, Google va-t-il l'indexer ?

Si /admin demande une connexion, Google ne voit que l'écran d'accès, et cet écran porte normalement noindex. S'il ne demande pas de connexion, le problème n'est pas l'indexation, c'est que ton panneau est ouvert.

Puis-je tout bloquer et ne lister que ce qui est public ?

Pour un site qui veut du trafic organique, non : tout bloquer avec Disallow: / le sort des moteurs. Si ce que tu veux, c'est contrôler l'exploration, la vérification robots et sitemap s'assure que tu ne te bloques pas toi-même.

Et les robots d'IA ?

Bloquer ou autoriser GPTBot, ClaudeBot et compagnie est une décision commerciale distincte et va dans le même fichier. Ça n'a rien à voir avec cette vérification, qui ne regarde que les chemins sensibles.