Pourquoi Google ignore-t-il les fichiers robots.txt placés dans les sous-répertoires ?

Où Google cherche-t-il réellement le fichier robots.txt ?

Google ne consulte qu'un seul emplacement pour le fichier robots.txt : la racine absolue du domaine ou du sous-domaine. Concrètement, si votre site est exemple.com, le moteur ne lira que exemple.com/robots.txt.

Cette règle s'applique de manière stricte. Un fichier placé dans exemple.com/blog/robots.txt ou exemple.com/fr/robots.txt sera totalement ignoré par Googlebot. Le crawler ne descend jamais dans l'arborescence pour chercher d'autres fichiers robots, quelle que soit la structure de votre site.

Cette limitation concerne-t-elle aussi les sous-domaines ?

Chaque sous-domaine est traité comme une entité distincte avec son propre fichier robots.txt. Si vous utilisez blog.exemple.com, vous pouvez placer un robots.txt spécifique à blog.exemple.com/robots.txt.

C'est la seule exception à la règle de la racine unique. Les sous-domaines permettent donc une segmentation des directives de crawl, mais uniquement au niveau du domaine de troisième niveau, jamais au niveau des répertoires.

Quelles erreurs cette règle génère-t-elle fréquemment ?

La confusion vient souvent des sites multilingues ou multi-sections. Certains développeurs placent un robots.txt dans /en/ ou /fr/ en pensant contrôler le crawl par langue. Résultat : zéro effet pratique.

Les migrations partielles posent aussi problème. Quand une section du site déménage vers un nouveau CMS ou une nouvelle infrastructure, l'équipe technique tente parfois de gérer deux fichiers robots distincts. C'est techniquement impossible avec la norme actuelle du protocole.

• Seul le robots.txt à la racine du domaine (ou sous-domaine) est lu par Google
• Les fichiers robots dans les sous-répertoires n'ont aucun effet sur le crawl
• Un sous-domaine peut avoir son propre fichier robots.txt distinct du domaine principal
• Cette limitation est une norme du protocole, pas une spécificité Google
• Vérifiez toujours l'emplacement de votre robots.txt avec un test d'URL directe

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, totalement. C'est une des rares affirmations de Google qui ne laisse aucune place à l'ambiguïté. Sur le terrain, aucun cas documenté ne montre un fichier robots.txt en sous-répertoire ayant un quelconque effet sur le crawl.

La norme RFC 9309 qui définit le protocole robots.txt est explicite là-dessus depuis des années. Google ne fait que confirmer son respect du standard, ce qui est rassurant sur la prévisibilité du comportement du crawler.

Quelles nuances faut-il apporter pour les configurations complexes ?

La vraie limite apparaît sur les architectures multi-domaines ou les sites internationaux complexes. Si vous gérez un site avec 20 versions linguistiques en sous-répertoires, vous n'avez qu'un seul robots.txt pour toutes.

Certains contournent cette limitation en utilisant des sous-domaines (fr.exemple.com, en.exemple.com), mais cela implique d'autres contraintes techniques : dilution potentielle de l'autorité, gestion DNS plus lourde, certificats SSL multiples. Le choix entre sous-domaines et sous-répertoires ne peut pas se faire uniquement sur la base du robots.txt.

Dans quels cas cette contrainte devient-elle réellement bloquante ?

Les plateformes multi-tenants sont les plus impactées. Imaginez un SaaS qui héberge des milliers de clients sur client1.plateforme.com/site/, client2.plateforme.com/site/. Impossible de donner à chaque client un contrôle granulaire du crawl sans créer un sous-domaine dédié.

Les migrations progressives posent aussi souci. Quand vous migrez une section à la fois vers une nouvelle stack technique, vous aimeriez bloquer temporairement le crawl de certaines parties. Mais avec un seul robots.txt global, c'est du tout ou rien par pattern d'URL, ce qui peut générer des règles complexes et fragiles.

Que faut-il vérifier immédiatement sur votre site ?

Testez l'accessibilité de votre robots.txt en tapant votredomaine.com/robots.txt directement dans le navigateur. Si vous voyez un 404 ou un fichier vide, vous avez un problème de configuration de base.

Vérifiez ensuite qu'aucun fichier robots.txt ne traîne dans vos sous-répertoires, surtout après des migrations ou des restructurations. Ces fichiers orphelins créent de la confusion dans les équipes et peuvent faire croire à une protection qui n'existe pas.

Comment centraliser efficacement vos directives de crawl ?

Toutes vos règles doivent être consolidées dans le fichier racine. Utilisez des patterns d'URL précis avec les wildcards * et $ pour cibler des sections spécifiques. Par exemple : Disallow: /admin/* ou Disallow: /temp-*.

Si votre besoin de granularité est vraiment important, basculez sur une architecture à sous-domaines. Chaque sous-domaine aura son propre robots.txt, mais mesurez bien l'impact SEO global avant de fragmenter votre autorité de domaine.

Quelles erreurs éviter absolument dans la gestion du robots.txt ?

Ne multipliez jamais les fichiers robots.txt en pensant créer des zones de contrôle. Seul celui à la racine compte. Ne comptez pas non plus sur des directives en sous-répertoire pour bloquer temporairement une section pendant des travaux.

Évitez les règles trop génériques qui bloqueraient par accident des ressources critiques. Un Disallow: /wp-content/ peut sembler logique, mais si vos CSS et JS sont là-dedans, vous créez un problème de rendu pour Googlebot. Testez toujours avec la Search Console avant de déployer.

• Vérifiez que votre robots.txt est accessible à domaine.com/robots.txt
• Supprimez tous les fichiers robots.txt présents dans les sous-répertoires
• Centralisez toutes vos directives de crawl dans le fichier racine unique
• Utilisez des patterns d'URL précis pour cibler des sections spécifiques
• Testez vos règles avec l'outil de test robots.txt de la Search Console
• Documentez clairement la logique de vos règles pour les équipes futures