Does Google really index JavaScript as it claims?

Why does Google emphasize distinct URLs so much?

Google's position is clear: every page must have a unique and stable URL. When a site generates content via JavaScript by dynamically changing the display without altering the URL, Googlebot struggles to understand that these are distinct pages.

Single Page Applications (SPA) perfectly illustrate this problem. If your React or Vue.js site loads multiple views under the same URL, Google considers there is only one page to index. The engine does not crawl application states; it crawls URLs.

What does proper rendering really mean?

Proper rendering means that Googlebot can execute JavaScript and access the final content as it appears in the DOM after execution. This is not guaranteed: if your JS code awaits user interaction, if the execution time exceeds Google's timeout, or if blocked resources hinder rendering, the content remains invisible.

Google uses a version of Chromium to render pages, but with limitations. The rendering budget is not infinite: slow sites, heavy scripts, and multiple API calls extend the process. The more complex you make the rendering, the greater the risk of partial indexing.

Is the Fetch and Render tool still relevant today?

The tool mentioned by Mueller has evolved. In the current Search Console, we refer to the URL Inspection tool which allows testing how Googlebot sees a page. This is your reference for detecting discrepancies between what you display and what Google indexes.

This tool shows two views: the raw crawled HTML and a screenshot after rendering. If the screenshot is empty or incomplete while your page displays rich content, you have a JavaScript rendering issue. Test your critical pages systematically, especially after a deployment.

• Unique URLs required: every distinct content requires its own crawlable URL
• Visible rendering by Googlebot: content must appear in the DOM after JS execution without user interaction required
• Systematic verification: use the URL Inspection tool to compare source HTML and final rendering
• Limited rendering budget: slow or complex sites risk partial indexing
• SPAs at risk: single-page applications must manage URL history on the client side (pushState) or implement SSR

Does this statement truly reflect on-the-ground practices?

Let's be honest: Google has made tremendous progress on JavaScript rendering, but claiming that everything works perfectly would be misleading. Tests show that late-loaded Ajax content, resources blocked by robots.txt, or poorly optimized scripts regularly slip under the radar.

We still observe situations where rendering fails silently. An e-commerce site with product listings generated in JS may see 70% of its catalog indexed correctly, while 30% is partially indexed or not indexed at all, with no visible errors in Search Console. [To be verified] for each critical project.

What are the unspoken limits of this approach?

Mueller does not mention the extended indexing times. A static HTML page is crawled, analyzed, and indexed quickly. A page requiring JavaScript rendering goes through an additional queue: the crawl budget consumed, then the rendering budget.

Timing matters immensely. If your content depends on API calls that take 2-3 seconds, Googlebot may timeout before obtaining the full content. The unspoken rule: everything that matters must be available in less than one second after the initial load.

Another overlooked point: Server-Side Rendering (SSR) or prerendering remains superior to relying on Google's rendering. Next.js, Nuxt, or a prerendering solution like Prerender.io ensure that the source HTML already contains the content. Less dependency equals less risk.

When does this rule not suffice?

Sites with personalized or geolocated content pose a real problem. If your page displays different prices based on the region or offers based on the logged-in user, Googlebot only sees one version. You then need to serve a canonical version or manage URLs by market.

Content hidden behind tabs, accordions, or modals generated in JavaScript are theoretically indexable if the HTML exists in the DOM, but Google may give them less weight than immediately visible content. If it's strategic, make it visible directly.

What actionable steps can be taken to secure JavaScript indexing?

First step: audit your architecture. Identify all critical content (titles, descriptions, product text, internal links) and check if they exist in the source HTML or only after JS execution. Use curl or a browser with JS disabled to see the raw HTML.

If essential content is missing from the source, two options: implement Server-Side Rendering to serve complete HTML from the start, or set up Dynamic Rendering (serving prerendered HTML to Googlebot and JS to users). The latter approach is allowed by Google as long as both versions display the same content.

What mistakes should be absolutely avoided?

Never block critical JavaScript and CSS resources in robots.txt. Google needs them to render the page. A too-restrictive robots.txt leads to impossible rendering, resulting in indexing based only on raw HTML, often empty or incomplete.

Avoid pure SPAs without history management. If your React application loads everything under the same URL, Google sees only one page. Implement React Router with an actual history (pushState), or switch to a framework with native SSR like Next.js.

Be cautious of external dependencies (Google Maps, third-party widgets, slow APIs). If a third-party script blocks rendering or takes too long, all downstream content can be ignored. Load non-critical scripts asynchronously or with defer.

How can I check if my site is compliant?

Use the URL Inspection tool in Search Console on your typical pages (homepage, product page, blog article). Compare source HTML and screenshot after rendering. If the screenshot is empty or lacks content, investigate JavaScript errors in the "More info" tab.

Complement with Screaming Frog in JavaScript rendering mode enabled. Compare a crawl without rendering and a crawl with rendering: number of pages discovered, depth, internal links extracted. A significant discrepancy signals a problem.

Also test rendering speed: use PageSpeed Insights or Lighthouse to measure Time to Interactive (TTI) and Largest Contentful Paint (LCP). If the main content appears after 3 seconds, Googlebot may not wait.

• Ensure every page has a unique and stable URL
• Test the URL Inspection tool in Search Console on all critical pages
• Compare source HTML vs final rendering with a Screaming Frog crawl
• Implement SSR, Dynamic Rendering, or prerendering if necessary
• Never block JS/CSS in robots.txt
• Measure rendering times and optimize for a TTI < 2s