Does the mobile-friendly test really guarantee the indexing of your JavaScript?

Why does Google make this distinction between the two tools?

The mobile-friendly test is a public tool designed to quickly check the visual rendering of a page. It runs JavaScript, loads CSS resources, and produces a screenshot—but it does not take into account the robots.txt file. This particularity is not a bug: it is an acknowledged limitation of the tool.

The URL inspection tool in Search Console operates differently. It simulates the actual behavior of Googlebot by adhering to all directives: robots.txt, meta robots, X-Robots-Tag, noindex, and so on. It is the only tool that provides an accurate view of what Google truly indexes.

What does 'generally well indexed' mean?

Mueller uses the word 'generally', and this ambiguity is telling. If your JavaScript content shows up in the mobile-friendly test, that indicates that Googlebot can technically execute the JS and see the content. However, there is a world of difference between 'can see' and 'will index'.

JavaScript rendering does not guarantee indexing. Google may see your content but choose not to index it for quality, duplication, crawl budget reasons, or because a directive (robots.txt, noindex) prevents it. The mobile-friendly test does not detect these blockages.

What are the blind spots of the mobile-friendly test?

First blind spot: robots.txt. If you accidentally block a critical JavaScript file (app.js, bundle.js), the mobile-friendly test will still load the complete page and display the content. You might think everything is working fine, while Googlebot cannot execute the blocked JS and sees a blank page.

Second blind spot: meta robots directives added dynamically via JavaScript. If your SPA framework injects a noindex in JS, the mobile-friendly test will display the page normally. Only the URL inspection tool will detect the noindex and alert you.

• The mobile-friendly test ignores robots.txt—major risk of false positives on JS rendering
• The URL inspection tool respects all directives—it reflects the reality of indexing
• 'Generally well indexed' is not a guarantee—JS rendering alone is not enough, directives must be checked
• SPA frameworks are particularly vulnerable—meta tags injected in JS, critical resources blocked by mistake
• Cross-checking both tools is the only reliable method—use mobile-friendly for rendering, URL inspection for indexability

Is this statement consistent with field observations?

Yes, and that's precisely what poses a problem. In hundreds of JS audits, we regularly see sites where the mobile-friendly test shows perfect rendering while Googlebot indexes a blank page due to a misconfigured robots.txt. The common trap is blocking /wp-content/themes/ or /assets/js/ out of security reflex.

Mueller is right on one point: if the content appears in mobile-friendly, the JS rendering engine is technically functioning. But stating 'generally well indexed' implies that the test is sufficient — and this is where the issue lies. In practice, 30 to 40% of audited JS sites show a gap between what mobile-friendly displays and what Google truly indexes. [To be verified] on a larger representative sample.

What nuances should be added to this recommendation?

First point: Mueller does not mention rendering delay. The mobile-friendly test waits a few seconds for the JS to execute, but Googlebot in production may abandon if the Time to Interactive exceeds 5-7 seconds. A page may appear perfectly in the tool yet be indexed empty in production if the JS is too slow.

Second nuance: Single Page Applications with client-side routing. The mobile-friendly test does not follow internal links generated in JS — it tests an isolated URL. If your SPA loads content via pushState or replaceState, mobile-friendly will only see the entry page. The URL inspection tool does not perform much better in this regard, but at least it signals directive issues.

In what cases does this rule not apply at all?

Sites using pure CSR (Client-Side Rendering) without pre-rendering or SSR. If your initial HTML is empty (<div id="root"></div>) and all content comes via fetch() after hydration, the mobile-friendly test may display the page but Google may decide not to wait. The result: partial or no indexing, despite a positive test.

Another case: sites with geolocation or device-customized content. The mobile-friendly test simulates a US mobile (or depending on the tester's IP), but does not cover all variations. If your JS displays different content based on the country, the test will only detect one version—not the one Googlebot will see from its data centers.

What practical steps should be taken to validate JS indexing?

First action: systematically cross-check both tools. First, test with mobile-friendly to check that the rendering works, then pass each critical URL through the URL inspection tool to validate that Google can index it. If both match, you're likely safe. If mobile-friendly displays content not found in the inspection, dig deeper immediately.

Second reflex: a priori audit the robots.txt. Look for Disallow lines that block /js/, /scripts/, /dist/, /build/, /assets/. Even one blocked critical JavaScript file can break the entire rendering. Use the robots.txt testing tool in Search Console to check each JS and CSS resource loaded by the page.

What mistakes should be absolutely avoided?

Classic error: blocking JS files for security or to save crawl budget. Google needs to execute the JavaScript to see the content — blocking JS resources in robots.txt essentially serves a blank page to Googlebot. If you want to protect code, do it differently (obfuscation, Auth), not via robots.txt.

Another trap: relying on Google's HTML cache. The cached version displayed in the SERPs is not always the one that Googlebot actually indexes. The cache may show rendered JS content while the index contains an empty version. Only the URL inspection tool shows you what Google has actually crawled and indexed.

How to continuously monitor JavaScript indexing?

Set up automated monitoring via the Search Console API. Regularly retrieve URL inspection data for your strategic pages (top landing pages, product listings, recent articles). Compare raw HTML (without JS) to rendered HTML — if the gap narrows or disappears, it indicates that Google is poorly indexing your JS.

Also use index coverage reports to detect pages marked as 'Crawled, currently not indexed'. On a JS site, this error often signifies that Google has crawled the page but failed to extract enough content or encountered a blocking directive. Cross-reference with the URL inspection tool to diagnose.

• Test every strategic page in both the mobile-friendly test AND the URL inspection tool
• Ensure that robots.txt does not block any critical JavaScript or CSS files
• Audit meta robots tags and X-Robots-Tag, especially those injected in JS
• Monitor discrepancies between raw HTML and rendered HTML via the Search Console API
• Set up alerts for pages marked as 'Crawled, not indexed' to detect JS issues
• Test Time to Interactive and optimize if rendering exceeds 5 seconds