Points clés à retenir
- Le fichier robots.txt se place toujours à la racine du domaine, pas dans un sous-dossier.
- Pour cibler un sous-dossier, on utilise une directive Disallow suivie du chemin exact :
Disallow: /mon-dossier/. - Les règles se lisent de haut en bas ; en cas de conflit entre Allow et Disallow pour le même chemin, c'est la règle la plus spécifique (le chemin le plus long) qui l'emporte.
- Un sous-domaine nécessite son propre fichier robots.txt indépendant.
- Le fichier robots.txt ne bloque pas l'indexation d'une page, seulement son exploration par les robots.
Je vais être franc : la première fois que j'ai dû configurer un robots.txt pour un sous-dossier, j'ai fait n'importe quoi. J'ai collé le fichier dans le sous-dossier lui-même. Résultat ? Googlebot a continué d'explorer allègrement mes pages privées pendant trois semaines avant que je ne m'en rende compte. Bref, j'ai appris à mes dépens qu'il y a des règles précises à suivre.
Dans cet article, je vais vous montrer exactement comment configurer le fichier robots.txt pour des sous-dossiers, avec des exemples concrets tirés de mon expérience. Et je vais répondre aux questions que tout le monde se pose, notamment celles qui reviennent dans les recherches.
Où placer le fichier robots.txt pour les sous-dossiers ?
Erreur numéro 1 que j'ai commise : croire qu'on pouvait mettre un fichier robots.txt à l'intérieur d'un sous-dossier pour en contrôler l'accès. C'est faux. Le fichier robots.txt doit toujours être placé à la racine du domaine. Toujours.
Pour un site comme mon-site.fr, le fichier doit donc être accessible à l'adresse mon-site.fr/robots.txt. Si vous avez un sous-dossier /blog/ ou /admin/, vous ne créez PAS un deuxième robots.txt dedans. Vous le configurez depuis le fichier racine.
Pourquoi ne peut-on pas le mettre dans le sous-dossier ?
La raison est simple : les robots d'exploration comme Googlebot consultent systématiquement /robots.txt à la racine avant d'explorer une quelconque page. Si le fichier n'est pas là, ils considèrent qu'il n'y a pas de restrictions. Mettre un fichier dans /blog/robots.txt ne servirait à rien : aucun robot ne va le chercher à cet endroit.
J'ai perdu deux jours à tester ça sur un projet perso. Spoiler : ça ne marche pas.
Syntaxe pour bloquer un sous-dossier dans robots.txt
La syntaxe est d'une simplicité déconcertante, mais il faut la connaître précisément. Pour interdire l'exploration d'un sous-dossier, on utilise la directive Disallow :
User-agent: *
Disallow: /mon-dossier-prive/
Ce bloc indique à tous les robots d'exploration (le * signifie "tous") de ne pas explorer les URLs qui commencent par /mon-dossier-prive/.
Attention à la barre oblique finale. Si vous écrivez Disallow: /mon-dossier-prive (sans slash à la fin), cela bloque aussi toute URL qui commence par cette chaîne. Par exemple, /mon-dossier-prive-2/ serait bloqué aussi. Pour être précis, utilisez toujours le slash final.
Exemple concret : configurer plusieurs sous-dossiers
Sur un de mes sites, j'ai trois dossiers à protéger : /admin/, /tmp/ et /backup/. Voici ce que j'ai mis dans mon robots.txt :
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /backup/
Sitemap: https://mon-site.fr/sitemap.xml
Rien de plus. Chaque sous-dossier a sa propre directive Disallow. Et j'ai ajouté la ligne Sitemap pour aider Google à trouver mon plan de site malgré les restrictions.
Autoriser un sous-dossier alors que le dossier parent est bloqué
Là, ça se corse. Imaginons que vous vouliez bloquer tout le dossier /blog/ sauf un sous-dossier /blog/public/. La norme d'exclusion des robots permet de le faire avec la directive Allow :
User-agent: *
Allow: /blog/public/
Disallow: /blog/
L'ordre a de l'importance. Google lit les règles de haut en bas et applique la règle la plus spécifique en cas de conflit. Ici, /blog/public/ est plus long que /blog/, donc Allow l'emporte sur Disallow pour ce sous-chemin.
J'ai utilisé cette technique pour un site e-commerce où je voulais cacher les fiches produits en préparation tout en laissant accessibles les pages déjà publiées dans un sous-dossier.
Le piège du Allow qui ne marche pas
J'ai vu des gens écrire ceci :
User-agent: *
Allow: /blog/
Disallow: /blog/prive/
Ils pensent que Allow va tout autoriser, puis Disallow va bloquer le sous-dossier privé. Mais ça ne fonctionne pas comme ça. La directive Allow n'est interprétée que si elle vient après une Disallow dans le même bloc. Si vous commencez par Allow, les robots ignorent souvent la Disallow qui suit.
La bonne méthode : commencez toujours par Disallow, puis ajoutez Allow pour les exceptions.
Que faire pour les sous-domaines ?
Les sous-domaines (comme blog.mon-site.fr) sont traités comme des sites indépendants par les robots. Chaque sous-domaine doit avoir son propre fichier robots.txt à sa racine.
Par exemple :
mon-site.fr/robots.txtblog.mon-site.fr/robots.txtadmin.mon-site.fr/robots.txt
Si vous voulez bloquer l'exploration du sous-domaine admin, vous ne pouvez pas le faire depuis le fichier racine de mon-site.fr. Vous devez créer un fichier robots.txt à la racine de admin.mon-site.fr.
Je me suis fait avoir là-dessus aussi. J'avais un sous-domaine staging que je voulais cacher de Google. J'ai ajouté Disallow: /staging/ dans le robots.txt principal. Évidemment, Google continuait d'explorer staging.mon-site.fr. Il a fallu que je crée un robots.txt dédié sur le sous-domaine pour que ça marche.
Questions fréquentes sur le fichier robots.txt
Le fichier robots.txt est-il illégal ?
Non, le fichier robots.txt n'est pas illégal. C'est un standard d'exploration (le Robots Exclusion Protocol) qui existe depuis 1994. Il sert à indiquer aux robots d'exploration quelles parties d'un site ils sont autorisés à explorer. Ce n'est pas une loi, mais une convention respectée par la plupart des robots bien élevés. Les scrapers malveillants peuvent l'ignorer sans conséquence légale directe (dans la plupart des juridictions), mais cela peut être considéré comme une violation des conditions d'utilisation du site.
À quoi sert Google Bot ?
Googlebot est le nom générique des robots d'exploration utilisés par la recherche Google. Il en existe deux types : Googlebot Smartphone (qui simule un utilisateur mobile) et Googlebot Desktop (qui simule un utilisateur sur ordinateur). Leur rôle est d'explorer les pages web pour les indexer dans le moteur de recherche. C'est pourquoi configurer correctement votre robots.txt est crucial : vous pouvez décider ce que Googlebot explore ou non.
Qu'est-ce que la norme d'exclusion des robots ?
La norme d'exclusion des robots (Robots Exclusion Protocol) est le standard qui définit comment utiliser le fichier robots.txt. Elle spécifie les directives User-agent, Disallow, Allow et Sitemap. Cette norme, bien que non contraignante légalement, est suivie par la quasi-totalité des robots d'exploration légitimes.
Qu'est-ce qu'un robot d'indexation Google ?
Un robot d'indexation Google est le programme automatisé (appelé crawler ou spider) qui parcourt le web pour découvrir et analyser les pages web. Googlebot en est l'exemple principal. Il suit les liens, télécharge le contenu des pages et le transmet à l'index de Google. C'est lui qui lit votre robots.txt pour savoir où il a le droit d'aller.
Testez votre configuration robots.txt
Avant de publier votre fichier, testez-le. Google propose un outil gratuit dans la Search Console : le testeur de robots.txt. Vous pouvez y entrer une URL de votre site et voir si elle est bloquée ou autorisée.
Voici comment je procède :
- Je vais dans Search Console > Outils et rapports > Testeur de robots.txt.
- Je copie une URL de mon sous-dossier cible.
- Je clique sur "Tester".
- Si le test indique "Autorisé", je vérifie que c'est bien ce que je veux. Si c'est "Bloqué", je corrige.
J'ai rattrapé pas mal d'erreurs grâce à ce test. La dernière en date : j'avais oublié un slash final dans un Allow, ce qui bloquait tout le dossier parent par erreur.
Les limites du fichier robots.txt
Il faut être clair : le fichier robots.txt ne sécurise rien. C'est une indication, pas une barrière. Un robot malveillant peut parfaitement l'ignorer. Si vous avez des données sensibles dans un sous-dossier, utilisez une vraie authentification (mot de passe, IP filtering).
De plus, le robots.txt ne contrôle pas l'indexation, seulement l'exploration. Si une page est déjà indexée avant que vous ne la bloquiez, Google peut continuer de l'afficher dans les résultats. Pour empêcher l'indexation d'une page spécifique, utilisez la balise meta robots noindex ou l'en-tête HTTP X-Robots-Tag.
J'ai appris ça en voyant une page que j'avais bloquée dans robots.txt rester dans les résultats de recherche pendant encore un mois. Depuis, je combine toujours les deux approches : robots.txt pour limiter l'exploration, et balises meta pour contrôler l'indexation.
Exemple complet pour un site avec plusieurs sous-dossiers
| Sous-dossier | Action | Directive |
|---|---|---|
| /admin/ | Bloquer | Disallow: /admin/ |
| /tmp/ | Bloquer | Disallow: /tmp/ |
| /blog/public/ | Autoriser | Allow: /blog/public/ |
| /blog/prive/ | Bloquer | Disallow: /blog/prive/ |
| /images/ | Bloquer (pour économiser le crawl budget) | Disallow: /images/ |
Et le fichier robots.txt correspondant :
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /images/
Allow: /blog/public/
Disallow: /blog/prive/
Sitemap: https://mon-site.fr/sitemap.xml
Notez l'ordre : Disallow pour les gros blocs, puis Allow pour les exceptions, puis une autre Disallow pour les sous-parties à protéger. Google traite ça correctement.
Voilà, vous avez maintenant une base solide pour configurer vos sous-dossiers dans robots.txt. Le plus important, c'est de tester après chaque modification. Et rappelez-vous : ce fichier est un guide, pas un verrou. Pour du contenu vraiment sensible, investissez dans une vraie protection.
Quand je repense à mes premiers tâtonnements, je me dis que j'aurais gagné un temps fou si quelqu'un m'avait simplement expliqué que la racine est la seule place valable. Mais c'est comme ça qu'on apprend, non ?
