Main area
Agency
technisches-seo

JavaScript Rendering at Google — How Googlebot Sees Your JS Content

Redaktion ·

If your page builds its content with JavaScript in the browser, one simple but hard question arises: does Google see that content at all? The answer depends on whether Google not only crawls your page but also renders it correctly. And at Google, rendering is a separate step with its own budget — not a given.

The Three Stages: Crawling, Rendering, Indexing

Google processes JavaScript pages in three separate phases that can be far apart in time:

1. Crawling. Googlebot fetches the URL, checks the robots.txt, reads the served HTML, and collects links from href attributes. In this phase Google sees only the raw HTML the server sends — for a pure client-side app that is often an almost empty <div id="root">.

2. Rendering. Pages with HTTP status 200 move into a render queue. There the Web Rendering Service (WRS) runs the JavaScript with an evergreen version of Chromium — a current, continuously updated headless Chrome. Only after rendering does the HTML that Google actually evaluates come into being.

3. Indexing. From the rendered HTML, Google extracts content and further links, indexes the page, and sends newly found URLs back into the crawl.

The crux sits between steps 1 and 2.

Why Rendering Has Its Own Budget

Rendering is expensive. Crawling a page means downloading an HTTP response — cheap. Rendering a page means starting a whole browser, executing JavaScript, waiting for network requests, and calculating layout — orders of magnitude more costly. That’s why rendering doesn’t happen immediately on crawl but is deferred until resources are free.

In Google’s own words, a page may stay in the queue “a few seconds, but it can take longer than that.” In practice that ranges from seconds to days, depending on the site’s popularity and crawl demand. For indexing that means: JS-dependent content potentially appears in the index later than server-delivered content — and with a small crawl budget, less reliably too.

The Two-Wave Indexing Myth

For a long time the picture of “two waves” held: the first wave indexes the raw HTML, the second wave days later the rendered HTML. Google itself has since qualified this model — the second wave today often arrives within minutes, sometimes almost simultaneously. But often is not guaranteed. Relying on fast rendering is a bet, not a plan. Anyone who generates critical content — title, main heading, prices, canonical signals — exclusively via client JS risks Google seeing an empty shell in the first indexing pass.

What Typically Goes Wrong

Content only via client JS. The most common problem. If the actual content isn’t in the initial HTML, everything hinges on successful rendering. If that fails, the page looks content-empty to Google.

Blocked JS/CSS resources in robots.txt. The most expensive mistake. Google says it plainly: “Google Search won’t render JavaScript from blocked files or on blocked pages.” If you block your /assets/ or /_next/ paths via robots.txt, you take away the building blocks Google needs to render — the content stays invisible.

Faulty or missing hydration. If the framework diverges between server markup and client rendering, the rendered state can break.

JavaScript errors. A single unhandled error in the critical path can abort rendering — the WRS then sees only what existed up to the crash.

Identical titles/descriptions. SPAs often set <title> and meta description per route via JS. If that goes wrong, Google indexes the same title for every route.

How to Test It

URL Inspection in Google Search Console. The most important tool. It shows you the rendered HTML that Google actually sees — plus a screenshot and any loading errors on resources. Compare this rendered HTML with what’s visible in the browser. If the main content is missing from the rendered HTML, you have a rendering problem.

Rich Results Test. Also shows the rendered HTML and additionally checks structured data.

Compare raw vs. rendered. Look at the server HTML (e.g. via “view page source” or curl) and compare it with the rendered DOM. The difference is exactly what depends on rendering — and therefore the risk.

The Clean Solution: SSR Instead of Dynamic Rendering

Google itself recommends: “server-side or pre-rendering is still a great idea, because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” That is the sustainable answer — server-side rendering (SSR), static pre-rendering, or a hybrid approach where critical content is already in the initial HTML.

Dynamic rendering — serving bots a pre-rendered version and users the JS version — is explicitly classified by Google as a workaround, not a long-term solution. It’s complex, error-prone, and with modern SSR frameworks simply unnecessary. You’ll find the full arc from crawling through rendering to indexing in the overview of technical SEO.

FAQ

Does Google render JavaScript at all? Yes. Googlebot renders pages with an evergreen version of Chromium in the Web Rendering Service. Content from client JS can therefore be indexed — but only after rendering, which happens deferred in its own queue.

How long does rendering take? Google says “a few seconds” but concedes it can take longer. In practice it ranges from seconds to days, depending on crawl budget and the site’s popularity.

Why doesn’t Google see my JS content? Most common causes: JS/CSS resources are blocked in robots.txt, a JavaScript error aborts rendering, or the content depends on external requests the WRS doesn’t load. URL Inspection in Search Console shows what Google actually renders.

Do I need dynamic rendering? Usually no. Google classifies dynamic rendering as a workaround, not a long-term solution. Server-side rendering or pre-rendering is cleaner, faster for users, and fixes the problem at its root.

How do I test whether Google renders my content? Use URL Inspection in Google Search Console and compare the rendered HTML with the visible content. If the main content is missing there, you have a rendering problem. The Rich Results Test is a second source for the rendered HTML.

Themenuebersicht

Technisches SEOJavaScript SEO