Is it true that Google removed the discovery of blocked resources in Search Console?

What does the discovery of blocked resources entail?

The old version of Google Search Console provided a report to identify files blocked via robots.txt — typically CSS, JavaScript, images — that Googlebot attempted to access to render a page correctly. This report was crucial during the mobile-first indexing era when blocking critical resources could prevent Google from understanding that a site was genuinely mobile-friendly.

The disappearance of this tool is part of a gradual simplification of Search Console. Google justifies this decision by a reduction in mobile accessibility issues caused by robots.txt blockages. In practice, fewer sites are making the mistake of blocking files essential for mobile rendering.

Why does Google consider this problem resolved?

Since the full deployment of mobile-first indexing, most modern CMS and frameworks have adapted their default settings. WordPress themes, Shopify, and other popular solutions no longer systematically block CSS/JS as it was common a few years ago.

Consequently, Google observes fewer reports of pages deemed non-mobile-friendly due to inaccessible resources. This statistical decline has motivated the removal of a tool that has become — according to their analysis — underutilized for its primary function. However, this logic does not consider all use cases.

What are the limitations of this decision?

The fact that mobile issues have decreased does not mean blocking resources is without consequences. Blocked files can still slow down crawling, complicate server-side rendering, or prevent Google from detecting certain content injected via JavaScript.

The removal of this tool deprives SEOs of a direct visibility into what Googlebot is actually trying to load and what is being denied. John Mueller implicitly acknowledges this point by mentioning that the feature is "requested" — a sign that the need on the ground persists, even if Google considers the issue marginal.

• Detection of blocked resources allowed identifying invisible configuration errors in robots.txt
• Mobile-first indexing has reduced but not eliminated problematic blockages, especially on legacy or custom sites
• Lack of a native tool now forces reliance on manual audits or third-party tools to check resource accessibility
• Google prioritizes the simplicity of Search Console over features deemed little used, even if they remain relevant for some cases
• Requests for the return of this feature suggest a gap between Google's vision and the needs of certain SEO practitioners

Is this removal really justified by on-the-ground data?

Google claims that "sites are facing fewer mobile issues related to blocked resources" — but this statement lacks public numeric data for verification. [To be verified]: is this a reduction of 90%, 50%, or just a trend observed on a non-representative sample? Without precise metrics, it is difficult to judge if the removal is proportionate.

On the ground, SEO audits still regularly reveal unintentional blockages — particularly on custom e-commerce sites, legacy platforms, or poorly migrated server configurations. The fact that these cases are "less frequent" does not make them negligible, especially when they directly impact crawl budget or Google's understanding of content.

What practical consequences for SEO audit?

Missing this report in Search Console complicates quick diagnostics. Previously, a quick glance was enough to spot that a critical CSS file was blocked. Now, one must go through the URL inspection tool, analyze server logs, or use third-party crawlers to detect these blockages — all actions that lengthen the audit time.

For SEO teams managing dozens of sites, this removal represents a loss of productivity. The fact that Google considers the problem marginal does not change the reality: when a blocked resource prevents the correct rendering of a strategic page, the business impact is real, even if the case is statistically rare.

Why does Google remove features that are still requested?

This decision is part of a simplification logic of Search Console, aimed at making the tool more accessible to non-experts. Google prefers a limited number of well-understood features over a multitude of little-used options. However, this approach can frustrate advanced practitioners who need granularity.

The fact that John Mueller explicitly mentions requests for return suggests that Google is aware of this gap. It remains to be seen whether such feedback will be enough to reintegrate the feature — or if Google believes that third-party tools can take over. Let’s be honest: relying on external solutions for data that Google holds natively is a regression in terms of transparency.

How can you detect blocked resources without the Search Console tool?

First option: use the URL inspection tool in Search Console, which still displays the resources loaded or blocked for a given page. However, this approach requires testing URL by URL, which quickly becomes impractical on a large site. It’s a stopgap measure, not a true audit solution at scale.

Second method: analyze your server logs to identify Googlebot requests that receive a 403 code or are blocked by robots.txt. This requires access to logs, a parsing tool (Screaming Frog Log Analyzer, OnCrawl, Botify), and the ability to interpret technical details — not something everyone can do.

What mistakes to avoid in robots.txt configuration?

The main mistake is to block entire directories without checking their content. Blocking /wp-content/ may seem logical to avoid crawling unnecessary media, but if your critical CSS/JS are stored there, you break rendering. Always test the impact of a Disallow rule before pushing it to production.

Another pitfall: too permissive rules or poorly ordered directives in robots.txt. A misplaced directive can inadvertently block resources that you thought were permitted. And contrary to what Google asserts, some secondary search engines or specialized crawlers still strictly adhere to robots.txt — even for resources that Googlebot would ignore.

Should you continue monitoring resource blockages?

Yes, especially if you manage complex sites with custom architectures, ongoing migrations, or specific server configurations. Just because Google has removed the tool doesn’t mean the risk has disappeared — it’s simply become less visible in their interface.

Incorporate this check into your regular SEO audits: a quarterly review using Screaming Frog or an equivalent crawler allows you to detect blockages before they impact your performance. And if you discover an issue, document it: technical teams do not always see the SEO impact of a robots.txt blockage.

• Regularly check Disallow rules in robots.txt and their impact on critical resources (CSS, JS, fonts)
• Use the URL inspection tool to test the rendering of strategic pages and identify blocked resources
• Analyze server logs to spot Googlebot requests blocked by robots.txt, especially on new sections of the site
• Crawl the site with a third-party tool in Googlebot mode to simulate what the bot actually sees
• Test any modifications to robots.txt in staging before deployment, especially on e-commerce sites or those rich in JavaScript
• Document detected blockages and their resolutions to avoid regressions during CMS or theme updates