Rendering

TL;DR — RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. is the step where a search engine runs your page’s code — including JavaScript — in a browser to build the finished page, so it can see your content and links. Google does this for basically every page in its Web Rendering Service, and it usually works. How your site produces its HTML (server, browser, or at build time) decides how safe you are.

What rendering is

When you open a page, your browser downloads some HTML, then runs the CSS and JavaScript to build the page you actually see. Search engines do the same thing. Rendering is the step where a search engine runs your page’s code to build the final version of the page, so it can read the content and follow the links the way you can.

It sits in the middle of how Google handles a page:

1. Crawl — Google downloads the raw HTML of your URL.
2. Render — Google runs the page’s JavaScript in a browser to build the finished page.
3. IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. — Google reads that finished page and files it away.

If your content only shows up after JavaScript runs, Google has to render the page successfully before it can see it. So rendering is the bridge between fetching a page and understanding it.

Google renders in a real (but unusual) browser

Google’s renderer is called the Web Rendering Service (WRS). It’s a headless Chrome that’s “evergreen,” meaning it keeps up with the current version of Chrome and supports modern web features. So the old fear — “Google can’t run JavaScript” — isn’t true. It can. Evidence for this claim Google Search runs JavaScript with an evergreen version of Chromium. Scope: Google's Web Rendering Service; browser support does not guarantee that every application-specific interaction or resource will work. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix Search-related JavaScript problems

It’s just an unusual browser. It doesn’t scroll or click, it forgets everything between pages (no staying logged in), and it caches files hard. Those quirks are where most surprises come from, and the Advanced tab covers them.

The big choice: where your HTML gets built

The single most important decision for SEO is where your page’s HTML is produced:

• In the browser (client-side rendering) — the server sends a near-empty page and JavaScript builds everything. Riskiest for search.
• On the server (server-side rendering) — the server sends a complete page. Safe.
• At build time (static / prerendering) — pages are built once, ahead of time. Safest and fastest.

Most modern frameworks mix these. The rule of thumb: if your important content is in the HTML before any JavaScript runs (or arrives almost immediately), you’re in good shape.

Want the deeper version — how the Web Rendering Service actually behaves, whether “two waves of indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.” is still a thing, and a full comparison of every rendering option? Switch to the Advanced tab. For the practical JavaScript problems and fixes, see JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript..

TL;DR — Google renders your JS in an evergreen, headless Chromium — the Web RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. Service — to build the DOM it indexes. It happens for essentially all pages, usually within seconds-to-minutes, so “two waves of indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.” is largely outdated and there’s no per-page render budget. The WRS is stateless, declines permission prompts, doesn’t interact with the page, and caches aggressively. Your rendering option decides your SEO risk: SSR / static / prerendering / hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers. are low-risk; full CSR is the risky one; dynamic rendering is a workaround Google advises against. For the practical JS problems this creates, see JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript..

Where rendering sits

Google is explicit that JavaScript apps move through three phases: “Google processes JavaScript web apps in three main phases: 1. CrawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. 2. Rendering 3. IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..” Evidence for this claim Google documents crawling, rendering, and indexing as the three main phases for processing JavaScript web apps. Scope: Google Search processing of JavaScript web applications; the phases can overlap operationally. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Rendering is the bridge. CrawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. fetches the raw HTML; rendering runs the JavaScript to build the finished DOM; indexing reads that rendered DOM, and any new links the renderer finds get fed back into crawling. In Google’s words: “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.”

The Web Rendering Service

Google renders in the Web Rendering Service (WRS) — a headless Chrome that’s evergreen: “While Google Search runs JavaScript with an evergreen version of Chromium…” it tracks current Chrome, so modern JavaScript and CSS features work.

The catch is that the WRS is a peculiar browser, and its quirks cause most real problems:

• It’s stateless. As I put it in my JavaScript SEO guide, “Google loads each page stateless like it’s a fresh load.” Google’s docs spell out the pieces: “Local Storage and Session Storage data are cleared across page loads” and “HTTP Cookies are cleared across page loads.” Don’t rely on anything persisted client-side to serve your content.
• It declines permissions. “Expect GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. to decline user permission requests.” Content gated behind a geolocation, notification, or camera prompt won’t render.
• It doesn’t interact. No scrolling, clicking, or hovering — so content that only loads on one of those events is invisible by default. (This is the root of most lazy-load and infinite-scroll bugs; the fixes live on the JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. page.)
• It caches aggressively. “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. caches aggressively in order to reduce network requests and resource usage. WRS may ignore cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. headers.” That means Google can run an outdated version of your JS or CSS. Fix it with file fingerprinting — version your filenames (app.4f2a9c.js) so a content change forces a fresh fetch.

Is “two waves of indexing” still a thing?

For years the mental model was “two waves of indexing”: Google would index the raw HTML first, then come back days or weeks later to render and index the JavaScript content. That model is now largely outdated. Martin Splitt has said the two-waves idea plays less and less of a role, that many pages go through the render phase even when they don’t rely on JavaScript, and that crawling, rendering, and indexing are converging over time.

In practice, rendering happens for essentially every page, and it’s usually fast. Google’s current documentation says a crawled page “may stay on this queue for a few seconds, but it can take longer than that” — there’s no published fixed delay or timeout. Evidence for this claim Google says a crawled page may stay on the rendering queue for a few seconds, but it can take longer than that. Scope: Google's rendering queue for a page that returns a 200 status and is eligible for rendering. The source gives a variable duration, not a fixed timeout or service-level guarantee. Confidence: high · Verified: 2026-07-25 Google Search Central: rendering-queue duration Supports: A page may remain on the rendering queue for a few seconds or longer. As a historical data point, Google staff (Martin Splitt and Tom Greenaway) once put the figure at a median of about five seconds, with the 90th percentile in minutes — not the “weeks” the old fear implied. I cite that figure in my JavaScript SEO guide, but treat it as a dated conference data point rather than a current published metric — Google hasn’t republished it as an ongoing number, and the queue-timing quote above is the current official framing.

And there’s no render budget in the way people imagine. Google doesn’t track a per-page “how expensive was this to render” score you need to conserve. Rendering is cheap at Google’s scale — optimize for your users and performance, not a phantom render budget.

The rendering options

“Where is the HTML built?” is the question that decides your SEO risk. The full menu:

• Client-side rendering (CSR). The server sends a near-empty shell; the browser (or WRS) runs JavaScript to build everything. This is “the most problematic one … full client-side rendering where all of the rendering happens in the browser.” It can work, but you’re betting everything on the render succeeding, and it’s the slowest to get indexed.
• Server-side rendering (SSR). The server builds the full HTML for each request. Content is in the raw HTML, so it’s low-risk for search.
• Static site generation (SSG) / prerendering. HTML is built once at deploy time. Lowest risk — content is in the raw HTML and it’s fast.
• Hydration (isomorphic / universal). You SSR or SSG the first paint, then JavaScript “hydrates” it in the browser to add interactivity. This is what most modern frameworks do, and it’s low-risk for content — just watch for hydration mismatches that blank out or replace content.
• Incremental Static Regeneration (ISR). Static pages regenerated on a schedule or on demand. Like SSG, with fresher content — good for large catalogs.
• Edge rendering. SSR run at CDN edge nodes — same low risk as SSR, with faster time-to-first-byte for a global audience.
• Streaming SSR. HTML streamed to the browser in chunks as it’s ready. Low-risk, but make sure indexable content isn’t trapped only in a late or deferred chunk.

My bottom line from my JavaScript SEO guide: “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” The framework matters less than the rendering mode you ship — the same Next.js app is safe or risky depending on whether you serve SSR/SSG or full CSR.

Dynamic rendering — a workaround, not a strategy

Dynamic rendering means detecting botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. and serving them a prerendered, JavaScript-free version while users get the client-side version. Google is now blunt about it: “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines,” and “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” Evidence for this claim Google describes dynamic rendering as a workaround and does not recommend it as a long-term solution. Scope: Google Search guidance for JavaScript-generated content; server-side rendering, static rendering, or hydration are the recommended alternatives. Confidence: high · Verified: 2026-07-14 Google Search Central: Dynamic rendering as a workaround I agree, and I always have — to be honest I never recommended it, and I’m glad Google now recommends against it too. It’s serving different content to bots and users, which is awfully close to cloaking. Reach for SSR, static, or hydration instead.

One wrinkle: Bing still suggests dynamic rendering. Microsoft says “bingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. is generally able to render JavaScriptMaking sure search engines can crawl, render, and index content that depends on JavaScript.” but that doing it at scale is hard, so “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” The practical takeaway: SSR/SSG keeps both engines happy and sidesteps the whole debate.

What this means for your content

Rendering decides whether Google ever sees your JavaScript content — but seeing it is only half the job. Once the page is rendered, the practical concerns are real <a href> links, field-specific parity between raw and rendered HTML, robots-directive stage order, lazy content, infinite scrollInfinite scroll is a loading pattern where content appears automatically as a user scrolls, instead of via numbered pages. Because Googlebot doesn't scroll or click, indexable infinite scroll needs real per-chunk URLs (paginated loading) that update via the History API — otherwise deep content may never be crawled, or worse, get merged into the wrong page., and soft-404s. Those all live on the JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. page, with the testing workflow (URL Inspection’s rendered HTML, screenshot, and console).

This is the rendering stage of the search pipeline. For the stages around it, see crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. (how pages get fetched) and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. (what happens to the rendered page next), or the How Search WorksSearch works in three stages — crawling, indexing, and serving (ranking). A page has to clear each one to appear in results: getting crawled doesn't mean you're indexed, and getting indexed doesn't mean you rank. hub for the whole journey.

One audit rule is worth keeping here: rendered is a state, not a universal winner. For body content and crawlable links, the rendered DOM shows what successful JavaScript added or removed. For titles and descriptions, it shows additional inputs, while Google may still generate a title link or snippet from other sources. For robots directives, a raw noindex may prevent rendering, so JavaScript removal is asymmetric. For canonical, Google advises using one source or one JavaScript-set value rather than changing an existing value. And JavaScript cannot change the HTTP response status already received. Keep those columns separate in evidence and use Google’s current JavaScript SEO guidance for the field-specific behavior.

AI summary

A condensed take on the Advanced version:

• RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. = the bridge from crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. to indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. Google runs your JS in an evergreen, headless Chromium — the Web Rendering Service — to build the DOM it indexes. Three phases: crawl → render → index.
• “Two waves of indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.” is largely outdated (Splitt). Rendering happens for essentially all pages, usually fast. Google’s current docs say a page “may stay on this queue for a few seconds, but it can take longer than that” — no fixed delay is published. (A ~5s median/minutes-90th-percentile figure exists, but it’s a dated conference data point, not a current metric.) There is no per-page render budget.
• The WRS is a weird browser: stateless (localStorage/cookies cleared between loads), declines permission prompts, does not scroll/click/hover, and caches JS/CSS aggressively (may ignore cache headers) → fingerprint your filenames.
• Rendering options, by SEO risk: SSG/prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. (lowest) ≈ SSR ≈ hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers. ≈ ISR ≈ edge/streaming (low) ≪ full CSR (highest). Patrick: “SSR, static rendering, and prerendering … are all great”; full CSR is “the most problematic one.”
• Dynamic rendering is a workaround, Google advises against it (close to cloaking). Bing still recommends it — but SSR/SSG satisfies both.
• The framework doesn’t decide risk — the rendering mode does. The same app is safe or risky depending on whether you ship SSR/SSG or full CSR.
• Rendering is half the job — the practical JS problems (links, parity, lazy content, infinite scrollInfinite scroll is a loading pattern where content appears automatically as a user scrolls, instead of via numbered pages. Because Googlebot doesn't scroll or click, indexable infinite scroll needs real per-chunk URLs (paginated loading) that update via the History API — otherwise deep content may never be crawled, or worse, get merged into the wrong page., soft-404s, testing) are covered on the JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. page.

Official documentation

Primary-source documentation from the search engines.

Google

• Understand the JavaScript SEO basics — the three phases (crawl → render → indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.) and the evergreen Chromium renderer.
• Fix Search-related JavaScript problems — the WRS constraints: stateless storage/cookies, declined permissions, aggressive cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency..
• Dynamic rendering as a workaround — why dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. is a workaround, not a recommended long-term solution.
• In-Depth Guide to How Google Search Works — where rendering sits in crawl → index → serve.

Bing / Microsoft

• bingbot Series: JavaScript, Dynamic Rendering, and Cloaking. Oh My! — Bing’s stance that it can render JS but recommends dynamic rendering at scale.
• The new evergreen Bingbot — BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. rendering on Chromium-based Microsoft Edge.

Quotes from the source

On-the-record statements from Google and Bing (plus a few from my own writing). Each search-engine link is a deep link that jumps to the quoted passage on the source page.

Google — the render pipeline

• “Google processes JavaScript web apps in three main phases: 1. CrawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. 2. RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 3. IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..” Jump to quote
• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” Jump to quote
• “While Google Search runs JavaScript with an evergreen version of Chromium…” Jump to quote
• “The page may stay on this queue for a few seconds, but it can take longer than that.” — the current official framing on render-queue timing; no fixed delay is published. Jump to quote

Google — the Web Rendering Service

• “Local Storage and Session Storage data are cleared across page loads.” Jump to quote
• “HTTP Cookies are cleared across page loads.” Jump to quote
• “Expect GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. to decline user permission requests.” Jump to quote
• “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. caches aggressively in order to reduce network requests and resource usage. WRS may ignore cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. headers.” Jump to quote

Google — dynamic rendering

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” Jump to quote
• “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” Jump to quote

Microsoft Bing

• “bingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. is generally able to render JavaScriptMaking sure search engines can crawl, render, and index content that depends on JavaScript.…” Jump to quote
• “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” Jump to quote

Martin Splitt, Google (relayed via Onely’s transcript of a 2019 Webmaster Central hangout)

• On the two-waves model: Splitt has said it plays less and less of a role, that many sites go through the render phase even without JavaScript, and that crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., rendering, and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. are converging. Read the coverage

Patrick Stox (my own work — JavaScript SEO: A Definitive Guide)

• “Google loads each page stateless like it’s a fresh load.”
• “pages went to the renderer at a median time of five seconds” (90th percentile in minutes) — a dated conference-era data point, not a current published metric; see the current official queue-timing quote above.
• “The most problematic one is going to be full client-side rendering where all of the rendering happens in the browser.”
• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.”

The mental models

1. Crawl → render → indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. is the bridge. CrawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. fetches the raw HTML; rendering runs the JS to build the DOM; indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. reads that DOM. When JS content goes missing, ask which step failed — was it fetched? rendered? did the rendered DOM contain the content?

2. The renderer is a real browser with amnesia. Evergreen Chrome, but stateless (forgets cookies/storage between pages), no interaction (won’t scroll or click), and cache-happy (may run stale JS/CSS). Design as if every visit is a fresh, untouched, first load.

3. Rendering mode decides your risk, not your framework. SSR, static, prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal., and hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers. all put content in (or quickly into) the DOM — low risk. Full CSR bets everything on the render — highest risk. The same Next.js app is safe or risky depending on which mode you ship.

4. “Two waves” is the old map. Don’t plan around a deferred second wave of rendering days later. Rendering happens for essentially all pages, usually within seconds-to-minutes — and there’s no render budget to ration.

5. Dynamic rendering is a smell, not a strategy. Serving botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. different HTML than users is a workaround Google advises against (and is close to cloaking). If you’re reaching for it, the real fix is usually SSR/SSG.

6. Get content into the DOM, then verify. Pick a mode that puts content in the rendered DOM quickly, then confirm with URL Inspection’s rendered HTML. Your browser isn’t GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer..

Rendering options — SEO trade-offs

Web Rendering Service — quick facts

Render-readiness audit checklist

A pass to confirm your important content actually survives renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.:

• Primary content and main navigation links are present in the raw HTML response (view source, not DevTools’ inspected DOM) — not injected only after JavaScript runs.
• Every internal linkAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. a reader needs to follow is a real <a href="..."> — not a <div onclick>, a hash-only route (#/page), or a button that pushes state client-side with no matching link.
• No critical JS or CSS files are blocked in robots.txt (a blocked bundle can leave the WRS unable to build the page it needs to render).
• Content that loads on scroll, hover, or click also has a path that renders without any interaction — the WRS doesn’t scroll, click, or hover.
• Nothing important depends on localStorage, sessionStorage, or cookies persisting between requests — the WRS is stateless and clears all of that between page loads.
• Nothing important sits behind a geolocation, notification, or camera permission prompt — the WRS declines those by default.
• JS/CSS filenames are fingerprinted (app.4f2a9c.js) so a content change forces a fresh fetch instead of getting served from the WRS’s aggressive cache.
• URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.’s rendered HTML/screenshot in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. shows the same content and links you see in your own browser.
• The site isn’t using dynamic rendering as its answer to a CSR problem — the fix is SSR, static rendering, or hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers., not serving botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. a different version of the page.

Rendering mistakes that actually bite

Blocking the JS or CSS the page needs to render, in robots.txt. If the WRS can’t fetch a script or stylesheet the page depends on, it can’t build an accurate rendered DOM — you get a broken or empty render instead of the page you intended. Do instead: allow crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. of your JS/CSS assets; robots.txt should keep botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. out of low-value spaces, not the resources your own pages need.

Shipping content-critical pages as full client-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (CSR) with no fallback. CSR is “the most problematic one … full client-side rendering where all of the rendering happens in the browser” — it bets your entire page on the render succeeding, and it’s the slowest option to get indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. Do instead: reach for SSR, static generation/prerendering, or hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers. so content is in (or very quickly into) the raw HTML.

Relying on hash-based routes (#/product/123) as your only navigation. The WRS follows real <a href> links; a hash fragment that only changes client-side state, with no server-rendered equivalent URL, gives the renderer nothing to crawl onward to. Do instead: use real paths the server can respond to directly (/product/123), even in a client-heavy app.

Lazy-loading content with no non-interactive path to it. Because the WRS “doesn’t scroll, click, or hover,” content that only appears after one of those events is invisible to it by default. Do instead: load above-the-fold and reasonably-near-viewport content without requiring an interaction, and reserve true lazy-loading for content genuinely below the fold with a proper non-JS fallback.

Treating dynamic rendering as a long-term fix instead of a workaround. Google is explicit that “dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements” — and serving bots different content than users sits uncomfortably close to cloaking. Do instead: fix the rendering mode itself (SSR/static/hydration) rather than building a bot-detection layer around a CSR problem.

Validation tests

Pass/fail checks to confirm a renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. fix actually took effect — run these after you ship the change, not as an ongoing health metric.

Test: content now appears in the rendered DOM

• Test to run — Submit the URL to Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s URL Inspection tool and use “Test Live URL,” then open the rendered HTML tab (or run the page through the Render Gap tool to diff raw vs. rendered HTML directly).
• Expected result — The content you added or fixed appears in the rendered HTML/DOM view, not just in your own browser’s dev tools.
• Failure interpretation — If it’s still missing from the rendered HTML but present when you view the page normally, the WRS still can’t build it — check for a blocked JS/CSS resource, an interaction-only load, or a client-storage dependency before assuming the fix worked.
• Monitoring window — Immediate; URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.’s live test reflects the current state of the URL right away.
• Rollback trigger — The rendered HTML still doesn’t contain the content after the fix, or the live test throws a new crawl/render error it didn’t throw before.

Test: important links survive the render

• Test to run — Check the rendered HTML (URL Inspection or Render Gap) for real <a href> tags around every link a reader needs to follow, not just visible clickable elements.
• Expected result — Each link in the rendered DOM has a resolvable href pointing at a real, crawlable URL.
• Failure interpretation — A missing or empty href on what looks like a working link usually means it’s a <div>/<button> with a client-side click handler and no server-renderable path — the WRS can’t follow it.
• Monitoring window — Immediate.
• Rollback trigger — Links that mattered before the change are missing href attributes or point at a hash-only fragment in the rendered output.

Test: the fix doesn’t quietly regress on the next deploy

• Test to run — Re-run the rendered-HTML check (URL Inspection live test or Render Gap) after your next deploy that touches this page’s templates or build pipeline.
• Expected result — The same content and links are still present in the rendered DOM as when you first confirmed the fix.
• Failure interpretation — If content that was present disappears again, a later change likely reintroduced a client-only dependency or broke a server-rendered path.
• Monitoring window — Re-check after each deploy that touches the affected templates; not a one-time check.
• Rollback trigger — Content or links that were confirmed present drop out of the rendered DOM again.

Resources worth your time

My related writing

• JavaScript SEO: A Definitive Guide — my full guide to renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., rendering modes, DOM parityWhether the rendered DOM matches what you expect the raw HTML to become., infinite scrollInfinite scroll is a loading pattern where content appears automatically as a user scrolls, instead of via numbered pages. Because Googlebot doesn't scroll or click, indexable infinite scroll needs real per-chunk URLs (paginated loading) that update via the History API — otherwise deep content may never be crawled, or worse, get merged into the wrong page., and the two-pages-as-one problem.
• The Beginner’s Guide to Technical SEO — where rendering fits between crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., rendering (the WRS, stateless loads, no interaction), indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From others

• web.dev — Rendering on the Web — the canonical explainer of CSR / SSR / SSG / hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers. trade-offs from the Chrome team.
• Onely — Google’s Two Waves of Indexing — transcript-based coverage of Martin Splitt’s office-hours session explaining why the two-waves model is fading; cited in the article body.
• Search Engine Roundtable — Google: No Per-Page Search Cost — Google rep clarifying there is no per-page crawl/render/index cost to ration.
• Search Engine Journal — JavaScript SEO — industry coverage of JS SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. best practices, testing workflows, and framework considerations.
• Vercel — Rendering Strategies — Next.js/edge rendering docs; useful when choosing between CSR, SSR, SSG, ISR, and streaming SSR for a real project.
• r/TechSEO — the community for debugging render/index problems.

Videos

• Google Search Central (YouTube) — Martin Splitt’s JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. series and the renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. explainers are the best official video walkthroughs of how the Web Rendering Service handles your JS. Channel

Stats worth citing

• Current official framing: no fixed delay. Google’s documentation says a crawled page “may stay on this queue for a few seconds, but it can take longer than that” — there’s no published fixed delay or timeout for the render queue.
• Historical data point (dated) — ~5 second median render delay. In earlier conference remarks, Google staff (Martin Splitt and Tom Greenaway) put pages reaching the renderer at a median of ~5 seconds, with the 90th percentile in minutes — not the “weeks” the old two-waves fear implied. I cite this in my JavaScript SEO guide, but treat it as a historical data point, not a current published metric — Google hasn’t republished it as an ongoing figure.
• Two waves of indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. is fading. Per Martin Splitt, the two-waves model plays less and less of a role as crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. converge — rendering now happens for essentially all pages. Coverage
• No per-page render budget. Google has indicated it doesn’t track how expensive an individual page is to crawl, render, index, or serve — so there’s no “render budget” to conserve the way crawl budgetThe number of URLs an engine will crawl in a timeframe. gets discussed. Coverage

Test yourself: Rendering

Five quick questions on how Google renders pages. Pick an answer for each, then check.

Rendering

Turning HTML, CSS, and JavaScript into the final visual page and DOM.

Related: JavaScript SEO, Hydration

Rendering

The step where a search engine runs a page’s code — including JavaScript — in a headless browser to build the final DOM, so it can see the content and links the way your browser would. Google does this in its Web Rendering Service (WRS), an evergreen, headless Chromium, as part of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor.. It’s the bridge between crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.: content that only appears after JavaScript runs won’t be indexed unless it survives rendering. Gaps between the raw HTML and the rendered HTML are where most JavaScript-SEO problems hide.

Related: JavaScript SEO, Hydration

Changelog