Comment Google hiérarchise-t-il vraiment les directives robots.txt ?

Que signifie vraiment « spécificité » dans un robots.txt ?

La spécificité d'une directive se mesure à la longueur et à la précision du chemin qu'elle cible. Une règle qui pointe vers /dossier/sous-dossier/page.html est plus spécifique qu'une règle visant simplement /dossier/. Google analyse chaque URL crawlée et applique la directive la plus précise qui matche cette URL, point final.

Cette logique emprunte aux principes CSS : quand plusieurs règles entrent en conflit, c'est la plus ciblée qui l'emporte. Si vous avez Disallow: /admin/ et Allow: /admin/public/stats.php, Google crawlera stats.php parce que la seconde directive désigne un fichier exact dans un sous-répertoire, donc plus spécifique que le bloc générique sur /admin/.

Pourquoi l'ordre des lignes ne compte-t-il pas ?

Beaucoup de praticiens SEO ont longtemps cru que Google lisait le robots.txt de haut en bas, appliquant la première directive rencontrée. C'est faux. Google parse l'intégralité du fichier, identifie toutes les directives qui matchent l'URL en question, puis sélectionne celle dont le pattern est le plus long.

Résultat : vous pouvez placer votre Allow: /blog/article-important.html en ligne 50 et votre Disallow: /blog/ en ligne 2, Google crawlera quand même l'article parce que sa directive est plus granulaire. L'ordre séquentiel est un mythe hérité d'autres parsers, pas de celui de Google.

Quelles implications pour la gestion du crawl budget ?

Cette règle de spécificité change la donne quand vous voulez bloquer des sections entières tout en autorisant quelques exceptions stratégiques. Vous n'avez plus à jongler avec l'ordre des lignes ni à multiplier les fichiers robots.txt personnalisés par bot.

Par contre, elle exige une rigueur absolue dans la rédaction : une faute de frappe dans le chemin spécifique, et c'est la directive générique qui s'applique. Pas de filet de sécurité séquentiel pour rattraper l'erreur. Les audits robots.txt deviennent donc encore plus critiques, surtout sur les sites avec des arborescences profondes ou des URLs paramétrées.

• La spécificité prime : une directive ciblant /a/b/c.html écrase celle visant /a/
• L'ordre d'écriture est ignoré : Google analyse toutes les lignes simultanément
• Les exceptions autorisées doivent être plus précises que les blocs génériques
• Les wildcards (*) et symboles ($) influent sur la spécificité selon leur placement
• Testez avec Google Search Console : l'outil de test robots.txt simule cette logique en temps réel

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

Oui, et c'est d'ailleurs l'un des rares points où le discours officiel de Google matche parfaitement la réalité technique. Les tests avec l'outil Search Console confirment systématiquement cette hiérarchie par spécificité. On peut inverser l'ordre des lignes dans un robots.txt, le résultat reste identique.

Cependant, la nuance importante que Mueller ne mentionne pas ici : les wildcards et les ancres ($) modifient le calcul de spécificité. Une directive Disallow: /*.pdf$ (tout PDF) est moins spécifique que Allow: /documents/rapport-annuel.pdf (un fichier précis), mais plus spécifique que Disallow: /documents/ (un répertoire entier). Le diable est dans ces détails syntaxiques.

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

Premier piège classique : empiler des Disallow génériques en pensant qu'un Allow placé plus haut dans le fichier les court-circuitera. Faux. Si votre Allow cible un pattern moins spécifique ou mal formé, c'est le Disallow qui gagne. J'ai vu des sites perdre 30% de leur crawl sur des catégories entières à cause de cette incompréhension.

Deuxième erreur : négliger les slash de fin. Disallow: /admin (sans slash) matche /admin ET /admintools ET /administration. Disallow: /admin/ (avec slash) ne matche que le répertoire /admin/ et son contenu. La différence semble minime, mais la spécificité diverge : le pattern sans slash est techniquement plus large, donc moins spécifique pour un fichier donné dans /admin/.

Dans quels cas cette logique peut-elle coincer ?

Sur les sites avec des URLs dynamiques à paramètres multiples, déterminer quelle directive est « la plus spécifique » devient vite un casse-tête. Exemple : Disallow: /produit?id= vs Allow: /produit?id=123&ref=promo. Techniquement, la seconde est plus longue, donc plus spécifique, mais si vous avez aussi Disallow: *?ref=promo, laquelle gagne ? [A verifier] Google ne documente pas exhaustivement ces cas limites.

Autre zone grise : les sous-domaines et les chemins racine. Un Disallow: / sur le domaine principal bloque tout, mais si vous avez un Allow spécifique plus bas, théoriquement il devrait prévaloir. Dans la pratique, certains crawlers tiers (pas Googlebot) traitent Disallow: / comme absolu et ignorent les exceptions. Prudence si vous syndique du contenu ou travaillez avec des agrégateurs.

Comment auditer un robots.txt pour détecter les conflits de spécificité ?

Première étape : lister toutes vos directives Disallow et Allow dans un tableur, avec la longueur en caractères de chaque pattern. Triez par longueur décroissante. Ça vous donne immédiatement une vue sur la hiérarchie que Google appliquera. Toute anomalie saute aux yeux : un Allow court censé débloquer une zone couverte par un Disallow long ne fonctionnera pas.

Ensuite, utilisez l'outil de test robots.txt dans Search Console. Testez vos URLs critiques une par une. L'outil vous dit quelle directive s'applique et pourquoi. C'est le seul moyen fiable de valider la logique de Google sans attendre que Googlebot passe. Ne vous fiez pas aux validateurs tiers, beaucoup implémentent encore la logique séquentielle obsolète.

Quelles règles d'écriture adopter pour éviter les ambiguïtés ?

Privilégiez toujours la spécificité explicite. Si vous voulez bloquer /blog/ sauf /blog/best-practices/, écrivez les deux directives avec leurs chemins complets, pas de raccourcis. Utilisez des commentaires inline (#) pour documenter l'intention de chaque bloc, surtout dans les fichiers multi-sections.

Évitez les wildcards imbriqués complexes sauf si vous maîtrisez parfaitement leur portée. Un pattern comme Disallow: /*?*sort=*&* peut sembler précis, mais sa spécificité réelle dépend de l'URL testée. Préférez des blocs distincts avec des chemins fixes quand c'est possible. Et testez, testez, testez : chaque modification doit passer par Search Console avant déploiement.

Que faire si votre robots.txt actuel contient des incohérences ?

Commencez par identifier les sections à risque : répertoires bloqués en masse avec des exceptions autorisées. Vérifiez que chaque exception est effectivement plus spécifique que le bloc. Sinon, réécrivez les patterns pour éliminer toute ambiguïté. Documentez les changements dans un changelog versionnée, parce qu'un rollback rapide peut sauver votre indexation en cas de déploiement raté.

Si vous gérez un site multilingue ou multi-pays avec des robots.txt différenciés par ccTLD, synchronisez la logique de spécificité entre tous les fichiers. Une incohérence entre robots.txt sur .fr et .com crée des disparités d'indexation que Google ne signale pas explicitement. Automatisez les tests post-déploiement avec un script qui interroge Search Console API pour valider les URLs stratégiques.

• Auditer le robots.txt ligne par ligne en calculant la longueur des patterns
• Tester chaque URL critique avec l'outil Search Console avant tout changement
• Documenter chaque directive avec un commentaire expliquant son intention
• Éliminer les wildcards ambigus et privilégier les chemins explicites
• Versionner le fichier robots.txt et maintenir un changelog des modifications
• Configurer des alertes Search Console sur les erreurs de crawl liées aux blocages robots.txt