Pourquoi un robots.txt mal configuré peut-il tuer votre indexation Google ?

Qu'est-ce que le robots.txt et pourquoi Google insiste-t-il encore dessus ?

Le fichier robots.txt reste l'un des leviers les plus puissants pour contrôler l'accès de Googlebot à votre site. Placé à la racine de votre domaine, il dicte quelles URLs peuvent être crawlées et lesquelles doivent être ignorées. Google réaffirme ce principe de base parce que les erreurs de configuration restent une cause fréquente de désindexation involontaire.

La subtilité réside dans le fait qu'un blocage dans robots.txt ne se limite pas aux pages HTML. Si vous interdisez l'accès aux fichiers CSS, JavaScript ou images, Google ne pourra pas évaluer correctement le rendu de vos pages. Ce qui était acceptable il y a dix ans ne l'est plus aujourd'hui, avec l'indexation JavaScript et les Core Web Vitals.

Comment Googlebot interprète-t-il réellement les directives Disallow ?

Googlebot respecte le robots.txt à la lettre. Une directive Disallow: /admin/ bloquera tout ce qui commence par ce chemin, y compris les sous-répertoires. Le bot ne passera pas outre cette instruction, même si des liens internes ou externes pointent vers ces URLs.

Ce qui surprend encore certains praticiens : un blocage dans robots.txt n'empêche pas une URL d'apparaître dans les résultats. Google peut indexer une page sans la crawler si elle reçoit suffisamment de backlinks. Vous verrez alors une entrée dans la SERP avec un snippet générique du type "Aucune information disponible". Ce n'est pas un bug, c'est le comportement documenté de Google.

Quelle est la relation entre robots.txt et le test de compatibilité mobile ?

Google teste la compatibilité mobile en rendant complètement vos pages, ce qui nécessite l'accès aux ressources CSS et JS. Si votre robots.txt bloque ces fichiers, le bot voit une page cassée ou mal formatée, et votre site échoue aux tests Mobile-Friendly.

Cette vérification impacte directement le Mobile-First Index. Un site bloquant les ressources essentielles sera pénalisé dans le classement mobile, qui est désormais le classement par défaut pour tous les sites. Le problème touche particulièrement les configurations héritées où on bloquait historiquement /wp-content/themes/ ou /assets/ pour "économiser le crawl budget".

• Googlebot respecte robots.txt sans exception : aucune URL bloquée ne sera crawlée, même si elle est techniquement accessible.
• Bloquer CSS/JS casse les tests mobile : le rendu incomplet fait échouer les validations de compatibilité.
• Robots.txt n'empêche pas l'indexation : une URL peut apparaître dans les résultats même si elle est Disallow, mais sans snippet exploitable.
• La directive Disallow est récursive : elle s'applique à tous les chemins enfants sauf règle Allow explicite.
• Le fichier doit être en UTF-8 : les encodages exotiques provoquent des erreurs d'interprétation silencieuses.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Totalement. Les audits SEO révèlent encore des dizaines de sites bloquant involontairement des sections critiques via robots.txt. Le cas classique : un staging environment migré en production avec un Disallow: / laissé par erreur. Le site reste accessible via navigateur, mais Google ne crawle rien. Les équipes mettent parfois des semaines à identifier le problème.

L'autre scénario récurrent concerne les ressources tierces hébergées sur un CDN. Certains configurent un robots.txt sur le sous-domaine CDN qui bloque tout, cassant le rendu des pages principales. Google Search Console signale ces erreurs, mais beaucoup ignorent les alertes jusqu'à ce qu'une chute de trafic brutale les réveille.

Quelles nuances faut-il apporter à cette directive officielle ?

Google simplifie volontairement son message. En réalité, bloquer certaines sections via robots.txt peut être stratégiquement pertinent. Les zones à faible valeur ajoutée (facettes de filtres infinis, pages de tags non curées, résultats de recherche interne) méritent parfois un Disallow pour concentrer le crawl budget sur le contenu premium.

La nuance critique : distinguer ce qui doit être non-crawlé de ce qui doit être non-indexé. Pour empêcher l'indexation tout en autorisant le crawl (utile pour le passage de PageRank), utilisez une meta robots noindex, pas un Disallow. Inversement, pour cacher une page sensible aux bots mais pas aux utilisateurs, robots.txt est la bonne méthode. [A vérifier] : Google affirme que les pages Disallow ne transmettent pas de PageRank, mais des tests empiriques suggèrent que des liens pointant vers des URLs bloquées peuvent quand même distribuer une fraction de jus, ce qui reste débattu.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Les bots tiers ne respectent pas toujours robots.txt. Les scrapers malveillants et certains crawlers SEO ignorent purement et simplement ce fichier. Si votre objectif est de protéger du contenu sensible, robots.txt ne suffit pas : il faut un firewall applicatif ou une authentification.

Autre exception : Googlebot Images et Googlebot News ont des comportements légèrement différents de Googlebot classique. Un Disallow ciblant uniquement User-agent: Googlebot n'affectera pas l'indexation des images si Googlebot-Image n'est pas explicitement bloqué. Cette granularité est rarement exploitée, mais elle existe.

Que faut-il vérifier concrètement dans votre robots.txt aujourd'hui ?

Commencez par auditer les directives Disallow actives. Ouvrez votre fichier robots.txt (accessible via votredomaine.com/robots.txt) et listez chaque ligne Disallow. Pour chacune, demandez-vous : cette section contient-elle du contenu que je veux voir indexé ? Si oui, supprimez la directive ou ajoutez une règle Allow pour créer une exception.

Vérifiez ensuite que vos ressources critiques sont accessibles. Testez explicitement les chemins /wp-content/, /assets/, /css/, /js/ et tout répertoire hébergeant du code frontend. Utilisez l'outil de test robots.txt dans Google Search Console : collez une URL de fichier CSS ou JS et vérifiez que le statut est "Autorisé".

Comment éviter les pièges classiques qui cassent l'indexation ?

Le piège numéro un : laisser un Disallow: / en production. Cela arrive après une mise en ligne bâclée où on oublie de retirer la protection du staging. Mettez en place un monitoring qui alerte si cette directive apparaît sur votre domaine principal.

Deuxième erreur fréquente : bloquer les paramètres d'URL avec des wildcards trop larges. Un Disallow: /*?* bloquera toutes les URLs avec query strings, y compris celles nécessaires au tracking ou à la pagination. Préférez des règles ciblées comme Disallow: /*?sort= si vous voulez seulement bloquer les tris.

Quels outils utiliser pour valider votre configuration ?

Google Search Console reste l'outil de référence. La section "Testeur de robots.txt" vous permet de simuler le comportement de Googlebot sur n'importe quelle URL. Collez votre fichier, entrez une URL, et vous verrez instantanément si elle est bloquée ou autorisée.

Complétez avec Screaming Frog ou Botify pour crawler votre site comme le ferait Googlebot. Ces outils respectent robots.txt et vous montreront exactement quelles pages sont inaccessibles. Comparez le nombre d'URLs crawlées avec le nombre d'URLs que vous attendez : un écart significatif révèle souvent un problème de Disallow.

• Ouvrir votredomaine.com/robots.txt et vérifier l'absence de Disallow: / en production
• Tester l'accès aux répertoires CSS et JS via l'outil Search Console
• Crawler le site avec Screaming Frog en mode "respecter robots.txt" et comparer le volume crawlé avec l'inventaire attendu
• Configurer une alerte monitoring qui notifie toute modification du fichier robots.txt
• Documenter chaque directive Disallow avec un commentaire expliquant sa raison d'être
• Vérifier que les URLs stratégiques (pages catégories, produits phares, articles piliers) ne sont pas bloquées