Pourquoi Google a-t-il supprimé la découverte des ressources bloquées dans Search Console ?

Qu'est-ce que la découverte des ressources bloquées ?

L'ancienne version de Google Search Console proposait un rapport permettant d'identifier les fichiers bloqués via robots.txt — typiquement CSS, JavaScript, images — que Googlebot tentait d'accéder pour rendre une page correctement. Ce rapport était crucial à l'époque du mobile-first indexing, quand bloquer des ressources critiques pouvait empêcher Google de comprendre qu'un site était réellement mobile-friendly.

La disparition de cet outil s'inscrit dans une simplification progressive de Search Console. Google justifie cette décision par une baisse des problèmes d'accessibilité mobile liés aux blocages robots.txt. Concrètement, moins de sites commettent l'erreur de bloquer des fichiers essentiels au rendu mobile.

Pourquoi Google considère-t-il ce problème comme résolu ?

Depuis le déploiement complet du mobile-first indexing, la plupart des CMS et frameworks modernes ont adapté leurs configurations par défaut. Les thèmes WordPress, Shopify, et autres solutions grand public ne bloquent plus systématiquement les CSS/JS comme c'était courant il y a quelques années.

Google observe donc moins de signalements de pages considérées comme non-mobile-friendly à cause de ressources inaccessibles. Cette baisse statistique a motivé la suppression d'un outil devenu — selon leur analyse — peu utilisé pour sa fonction première. Mais cette logique ne prend pas en compte tous les cas d'usage.

Quelles sont les limites de cette décision ?

Le fait que les problèmes mobiles aient diminué ne signifie pas que le blocage de ressources est sans conséquence. Des fichiers bloqués peuvent encore ralentir l'exploration, compliquer le rendu côté serveur, ou empêcher Google de détecter certains contenus injectés en JavaScript.

La suppression de cet outil prive les SEO d'une visibilité directe sur ce que Googlebot tente réellement de charger et ce qui lui est refusé. John Mueller reconnaît implicitement ce point en mentionnant que la fonctionnalité est « demandée » — signe que le besoin terrain persiste, même si Google considère le problème comme marginal.

• La détection des ressources bloquées permettait d'identifier des erreurs de configuration robots.txt invisibles autrement
• Le mobile-first indexing a réduit mais pas éliminé les blocages problématiques, notamment sur des sites legacy ou custom
• L'absence d'outil natif oblige désormais à recourir à des audits manuels ou des outils tiers pour vérifier l'accessibilité des ressources
• Google privilégie la simplicité de Search Console au détriment de fonctionnalités jugées peu utilisées, même si elles restent pertinentes pour certains cas
• Les demandes de retour de cette fonctionnalité suggèrent un décalage entre la vision de Google et les besoins de certains praticiens SEO

Cette suppression est-elle vraiment justifiée par les données terrain ?

Google affirme que « les sites ont moins de problèmes mobiles liés aux ressources bloquées » — mais cette affirmation manque de données chiffrées publiques pour être vérifiée. [À vérifier] : s'agit-il d'une baisse de 90 %, 50 %, ou simplement d'une tendance observée sur un échantillon non représentatif ? Sans métrique précise, difficile de juger si la suppression est proportionnée.

Sur le terrain, les audits SEO révèlent encore régulièrement des blocages involontaires — notamment sur des sites e-commerce custom, des plateformes legacy, ou des configurations serveur mal migrées. Le fait que ces cas soient « moins fréquents » ne les rend pas négligeables, surtout quand ils impactent directement le crawl budget ou la compréhension du contenu par Google.

Quelles conséquences pratiques pour l'audit SEO ?

Perdre ce rapport dans Search Console complique le diagnostic rapide. Avant, un coup d'œil suffisait pour repérer qu'un fichier CSS critique était bloqué. Désormais, il faut passer par l'outil d'inspection d'URL, analyser les logs serveur, ou utiliser des crawlers tiers pour détecter ces blocages — autant de manipulations qui allongent le temps d'audit.

Pour les équipes SEO qui gèrent des dizaines de sites, cette suppression représente une perte de productivité. Le fait que Google considère le problème comme marginal ne change rien à la réalité : quand une ressource bloquée empêche le rendu correct d'une page stratégique, l'impact business est réel, même si le cas est statistiquement rare.

Pourquoi Google retire-t-il des fonctionnalités encore demandées ?

Cette décision s'inscrit dans une logique de simplification de Search Console, visant à rendre l'outil plus accessible aux non-experts. Google préfère un nombre réduit de fonctionnalités bien comprises qu'une multitude d'options peu utilisées. Mais cette approche peut frustrer les praticiens avancés qui ont besoin de granularité.

Le fait que John Mueller mentionne explicitement les demandes de retour suggère que Google a conscience du décalage. Reste à voir si ces retours suffiront à faire réintégrer la fonctionnalité — ou si Google estime que les outils tiers peuvent prendre le relais. Soyons honnêtes : compter sur des solutions externes pour une donnée que Google possède nativement, c'est un recul en termes de transparence.

Comment détecter les ressources bloquées sans l'outil Search Console ?

Première option : utiliser l'outil d'inspection d'URL dans Search Console, qui affiche encore les ressources chargées ou bloquées pour une page donnée. Mais cette approche nécessite de tester URL par URL, ce qui devient vite impraticable sur un gros site. C'est un palliatif, pas une vraie solution d'audit à l'échelle.

Deuxième méthode : analyser vos logs serveur pour identifier les requêtes Googlebot qui reçoivent un code 403 ou sont bloquées par robots.txt. Cela demande un accès aux logs, un outil de parsing (Screaming Frog Log Analyzer, OnCrawl, Botify), et une capacité d'interprétation technique — pas donné à tout le monde.

Quelles erreurs éviter dans la configuration robots.txt ?

La principale erreur reste de bloquer des répertoires entiers sans vérifier leur contenu. Bloquer /wp-content/ peut sembler logique pour éviter le crawl de médias inutiles, mais si vos CSS/JS critiques y sont stockés, vous cassez le rendu. Toujours tester l'impact d'une règle Disallow avant de la pousser en production.

Autre piège : les règles trop permissives ou mal ordonnées dans robots.txt. Une directive mal placée peut involontairement bloquer des ressources que vous pensiez autoriser. Et contrairement à ce que Google affirme, certains moteurs de recherche secondaires ou crawlers spécialisés respectent encore strictement robots.txt — y compris pour des ressources que Googlebot ignorerait.

Faut-il continuer à surveiller les blocages de ressources ?

Oui, surtout si vous gérez des sites complexes avec des architectures custom, des migrations en cours, ou des configurations serveur spécifiques. Le fait que Google ait retiré l'outil ne signifie pas que le risque a disparu — juste qu'il est devenu moins visible dans leur interface.

Intégrez cette vérification dans vos audits SEO réguliers : un contrôle trimestriel via Screaming Frog ou un crawler équivalent permet de détecter les blocages avant qu'ils n'impactent vos performances. Et si vous détectez un problème, documentez-le : les équipes techniques ne voient pas toujours l'impact SEO d'un blocage robots.txt.

• Vérifier régulièrement les règles Disallow dans robots.txt et leur impact sur les ressources critiques (CSS, JS, fonts)
• Utiliser l'outil d'inspection d'URL pour tester le rendu des pages stratégiques et identifier les ressources bloquées
• Analyser les logs serveur pour repérer les requêtes Googlebot bloquées par robots.txt, notamment sur les nouvelles sections du site
• Crawler le site avec un outil tiers en mode Googlebot pour simuler ce que le bot voit réellement
• Tester toute modification de robots.txt en staging avant déploiement, surtout sur des sites e-commerce ou riches en JavaScript
• Documenter les blocages détectés et leur résolution pour éviter les régressions lors des mises à jour CMS ou thème