Le fichier robots.txt est court, public et capable de provoquer des erreurs très larges.
Une seule règle peut interdire l’exploration d’un répertoire entier. À l’inverse, supprimer une directive ne signifie pas qu’une page sera immédiatement indexée.
Pour bien l’utiliser, il faut commencer par distinguer crawl, indexation et contrôle d’accès.
Où se trouve robots.txt ?
Pour un site :
https://example.com/le fichier se trouve généralement à la racine :
https://example.com/robots.txtIl est volontairement public. Toute personne peut le consulter.
Cela suffit à comprendre pourquoi on ne doit jamais y inscrire une liste de dossiers « secrets » en pensant les protéger.
Structure minimale
Un exemple simple :
User-agent: *
Disallow: /admin-temporaire/User-agent désigne le robot concerné. * représente ici tous les robots qui appliquent ces règles.
Disallow indique un chemin que l’on demande de ne pas explorer.
On peut aussi déclarer :
Sitemap: https://example.com/sitemap.xmlLe Générateur robots.txt aide à produire une syntaxe propre, mais il faut d’abord comprendre ce que l’on souhaite réellement bloquer.
Bloquer le crawl n’est pas demander noindex
C’est la distinction essentielle.
Si un robot n’explore pas une page, il ne peut pas forcément lire les directives présentes dans cette page.
Une URL bloquée dans robots.txt peut malgré tout être connue grâce à des liens externes ou internes. Selon le contexte, elle peut encore apparaître sous une forme limitée dans un index.
Si votre objectif est qu’une page accessible soit explorée mais ne soit pas indexée, la stratégie appropriée est généralement différente, par exemple une directive noindex lisible par le robot.
Il ne faut donc pas mélanger :
robots.txt → contrôler l’exploration
noindex → demander de ne pas indexer une page accessible au robotrobots.txt n’est pas un mécanisme de sécurité
Si /factures-privees/ contient des données sensibles, écrire :
Disallow: /factures-privees/ne protège rien.
L’URL peut toujours être ouverte par un navigateur si le serveur l’autorise.
Pour protéger un contenu, utilisez :
- authentification ;
- autorisation côté serveur ;
- contrôle d’accès ;
- réseau privé si nécessaire ;
- mécanismes adaptés à la sensibilité des données.
Le SEO et la sécurité répondent ici à deux problèmes différents.
Attention aux règles trop larges
Exemple dangereux :
User-agent: *
Disallow: /Le / représente la racine. Cette règle demande donc de ne rien explorer sur le site.
Elle peut être pertinente sur un environnement temporaire dans certains contextes, mais constitue une erreur grave si elle arrive en production sans intention.
Avant publication, relisez les règles comme si vous étiez le robot : quel chemin exact correspond à cette directive ?
Ne bloquez pas les ressources utiles au rendu sans raison
Les moteurs modernes peuvent avoir besoin de CSS, JavaScript et images pour interpréter correctement certaines pages.
Bloquer systématiquement :
/assets/
/scripts/
/styles/peut donc être contre-productif si ces fichiers sont nécessaires au rendu.
L’objectif n’est pas de réduire le nombre de fichiers visités à tout prix, mais d’éviter l’exploration inutile tout en laissant le contenu principal interprétable.