Does JavaScript still hinder Google's crawling without server-side rendering?

Why does Google still emphasize distinct URLs and HTML links?

Because JavaScript crawling remains a two-step process: Google first fetches the raw HTML, then schedules a deferred rendering to execute the JavaScript. If your URLs are dynamically generated on the client side, the bot won't see them during the initial crawl.

Normal links — <a href> tags — are directly detected in the DOM, even without JS execution. Links constructed via onClick, history.pushState, or SPA frameworks without server-side hydration go unnoticed until Googlebot has rendered the page. And that rendering can take hours or even days after the initial crawl.

What does John Mueller mean by 'Google is improving'?

Google has indeed modernized its rendering engine to support ES6, JavaScript modules, and an increasing portion of browser APIs. But 'improving' does not mean 'perfect'.

The rendering budget remains limited. Heavily loaded pages, with external dependencies that take time to load, might see their JavaScript partially executed or abandoned. And if critical content relies on asynchronous requests after the first rendering, there’s no guarantee Googlebot will wait for the process to complete.

What’s the difference between 'crawling' and 'indexing' in this context?

Crawling = Googlebot fetches the raw HTML. Rendering = the bot executes the JavaScript to generate the final DOM. Indexing = the processed content is stored and categorized.

A full JS site can be crawled just fine, but if rendering fails or is delayed, the indexing of the actual content is compromised. Tools like Search Console do not always show these discrepancies — a page can be 'indexed' with empty or incomplete content if the JS hasn't run correctly.

• Distinct URLs: each resource must have a unique URL, no # fragments or client states not reflected in the URL.
• Standard HTML links: <a href> must point to resources, not just JavaScript handlers.
• Pre-rendering or SSR: serving full HTML from the initial crawl ensures that content is visible without waiting for deferred rendering.
• Testing: Mobile-Friendly Test and the URL inspector in Search Console show the rendered DOM, but not always timing or external resource errors.
• Limited rendering budget: large sites or those with many third-party JavaScript resources may exceed Googlebot's rendering capabilities.

Is this guidance consistent with real-world observations?

Yes, but with a significant caveat: Google consistently underestimates the real problems that full JS sites encounter. Audits regularly show 'indexed' pages where the main content never appears in SERPs because rendering failed.

Modern frameworks (Next.js, Nuxt, SvelteKit) have adopted SSR or SSG precisely because relying solely on client rendering remains risky. If Google were truly comfortable with JavaScript, why do market leaders continue to recommend pre-rendering?

What nuances should be added to this statement?

John Mueller doesn't specify the average rendering delay or the criteria that trigger the abandonment of a rendering. Some sites wait weeks before Google executes their JavaScript, especially if they have a low crawl budget. [To verify]: no official data documents the rendering queue or timeout thresholds.

Additionally, 'ensuring compatibility' is extremely vague. Compatibility with which version of Chromium? What tolerance for console errors? How are resources blocked by robots.txt or CORS handled? Google does not provide a clear assessment grid.

In what cases does this rule not fully apply?

High crawl budget sites (Amazon, Wikipedia, major media) see their JavaScript rendered almost in real time. For them, the difference between SSR and CSR is negligible in terms of indexing.

Conversely, recent or niche sites, with few backlinks and low refresh rates, may wait a long time before rendering is triggered. For these sites, unpre-rendered JavaScript is a clear handicap.

What should you do concretely for a full JavaScript site?

Prioritize SSR or pre-rendering if launching a new project or revamping an existing site. The gains in indexing speed and crawl stability far outweigh the implementation cost.

If you must remain on pure client-side rendering (legacy SPA), ensure that all critical URLs are declared in an XML sitemap and that every internal link uses <a href> with a complete URL. Avoid SPAs that rely on history.pushState without distinct URLs.

What mistakes should you absolutely avoid?

Never let main content depend on a non-blocking asynchronous fetch. If your React component loads data after the first rendering, Googlebot may crawl an empty shell.

Also, avoid blocking JavaScript or CSS resources via robots.txt. Google needs these files to execute rendering. A Disallow: /assets/ that is too broad can break the whole process. Test using the URL inspector and check blocked resources in the 'Coverage' tab.

How can I check if my site is being crawled and indexed correctly?

Use Search Console's URL inspector on your key templates (product page, article, category). Compare source HTML with the rendered DOM. If the main content only appears in the rendering, you are dependent on JavaScript.

Run a crawl with Screaming Frog in JavaScript enabled mode and compare it with a JS-disabled crawl. The discrepancies show what Googlebot sees before and after rendering. If 30% of your content disappears without JS, you have a problem.

• Enable SSR or pre-rendering (Next.js, Nuxt, Rendertron, Prerender.io)
• Use <a href> tags for all critical internal links
• Declare all URLs in an up-to-date XML sitemap
• Check that robots.txt doesn't block the crawling of JS/CSS resources
• Test rendering with the URL inspector and Mobile-Friendly Test
• Monitor JavaScript errors in the browser console (they also break Googlebot's rendering)