Rendering and JavaScript Reality

Google renders JavaScript, but not the way you think

Google can execute JavaScript and render client-side content. This is true. But the way it does this is different from how a browser does it, and the differences create real SEO problems that are invisible unless you know where to look.

How Google renders pages

Google's rendering pipeline has two phases:

Phase 1: HTML crawl. Googlebot fetches the raw HTML. It extracts links, metadata, and any content that exists in the initial HTML response. This happens immediately.

Phase 2: Rendering. Google places the page in a rendering queue. When resources are available, it executes the JavaScript in a headless Chromium browser to see the final page content. This can happen minutes, hours, or days after the initial crawl.

The gap between phase 1 and phase 2 is where problems hide.

What can go wrong

Content invisible in phase 1. If your page content is loaded entirely via JavaScript (common in React, Vue, and Angular single-page applications), Google sees an empty or near-empty page during the initial crawl. The content only becomes visible after rendering, which may be delayed.

Links invisible in phase 1. If your navigation or internal links are rendered via JavaScript, Google cannot follow them during the initial crawl. This affects how Google discovers other pages on your site.

Rendering failures. Google's renderer may fail to execute your JavaScript correctly. Common causes: third-party scripts that block rendering, API calls that time out, authentication requirements, or JavaScript errors that crash the page.

Resource blocking. If your robots.txt blocks JavaScript files, CSS files, or API endpoints that the page needs to render, Google cannot see the final content.

Dynamic content. Content that loads on scroll, on click, or after a delay may not be visible to Google's renderer. Google does not scroll or interact with pages the way a human does.

How to check if Google sees your content

URL Inspection tool. In Google Search Console, use the URL Inspection tool and check the rendered HTML. This shows you exactly what Google sees after rendering. Compare it to what you see in a browser.

View source vs rendered source. Right-click "View Page Source" in your browser shows the raw HTML (what Google sees in phase 1). The browser's DevTools Elements panel shows the rendered DOM (what Google sees after phase 2, if rendering succeeds).

Google cache. Check Google's cached version of your page. If the cached version is missing content that you see in the browser, rendering is failing.

Solutions by framework

Server-side rendering (SSR). The most reliable solution. The server generates the full HTML before sending it to the browser. Google sees all content in phase 1. Next.js, Nuxt, and similar frameworks support this.

Static site generation (SSG). Pre-render pages at build time. Google gets fully rendered HTML. Works well for content that does not change frequently.

Hybrid rendering. Use SSR for pages that need to be indexed and client-side rendering for interactive elements that do not need indexing.

Dynamic rendering. Serve a pre-rendered version to Googlebot and the JavaScript version to users. Google officially supports this as a workaround, but it adds complexity and maintenance burden.

What to avoid

Do not rely on client-side rendering for any content you want indexed. Even though Google can render JavaScript, the delay, potential failures, and resource costs make it unreliable for SEO-critical content.

Do not block JavaScript or CSS resources in robots.txt. Google needs these to render your pages.

Do not lazy-load above-the-fold content. Content that requires scrolling or interaction to appear may never be seen by Google.

Takeaway

Test every important page with the URL Inspection tool in GSC. If the rendered HTML does not contain your main content, you have a rendering problem. The fix is almost always to move content rendering to the server side.