Skip to content

SYSTEM Cited by 1 source

Google Web Rendering Service (WRS)

Google's Web Rendering Service (WRS) is the post-2018 rendering stage of Googlebot: a pool of headless Chromium instances that accept URLs from the crawl queue, fetch all sub-resources (JS, CSS, images, fonts, API responses), execute the page's JavaScript, and emit a fully-rendered DOM to the indexer. The WRS is what lets Google index client-rendered React, streamed RSC output, and dynamic-API-call content without requiring sites to publish pre-rendered HTML snapshots.

Three defining properties

  1. Universal rendering. Every HTML page Googlebot crawls (200 or 304 status, not noindex) is enqueued for render; there is no pre-render triage that keeps static HTML on a bypass path. See concepts/universal-rendering. "100 % of HTML pages resulted in full-page renders, including pages with complex JS interactions."
  2. Stateless rendering. Each render is a fresh Chromium session with no cookies, no session state, no localStorage carry-over, and no click / tap / tab / cookie-banner interaction. See concepts/stateless-rendering. The render is "the page as a first-time unauthenticated visitor would see it without interacting."
  3. Internal asset caching. WRS does not obey the page's HTTP Cache-Control headers when deciding whether to re-fetch a sub-resource. "Google's Web Rendering Service employs its own internal heuristics to determine when cached assets are still fresh." See concepts/google-asset-caching-internal-heuristics.

(Source: sources/2024-08-01-vercel-how-google-handles-javascript-throughout-the-indexing-process.)

Status-code triage

Status WRS behaviour
200 Full render
304 Not Modified Render using the cached body from the most recent 200 response
3xx redirects Not rendered — follow the redirect to the new URL (which may itself be rendered)
4xx errors Not rendered
5xx errors Not rendered (may be re-crawled later)

The triage is pre-render, on the HTTP status of the initial crawl. A page that fails the HTTP status check never hits WRS.

noindex is pre-render

A <meta name="robots" content="noindex"> (or an X-Robots-Tag: noindex response header) is detected by the crawl stage on the initial HTML body and the URL is removed from the render queue before WRS sees it. Client-side JavaScript that removes the noindex tag after mount never runs from Google's perspective — the JS would only run during WRS execution, and WRS never gets the URL. See concepts/client-side-removal-of-noindex-ineffective.

The rendering queue

WRS accepts inputs through a queue, and the queue has non-trivial latency. The canonical empirical distribution (Vercel + MERJ, April 2024, nextjs.org, 37,000+ server-beacon pairs) is:

Percentile Time from crawl to render completion
p25 ≤ 4 s
p50 10 s
p75 26 s
p90 ~3 h
p95 ~6 h
p99 ~18 h

See concepts/rendering-delay-distribution. Queue delay is the structural reason link value assessment is post-render and therefore post-queue.

Prioritisation signals

WRS's prioritisation isn't strictly FIFO. Empirical signals that correlate with faster rendering:

  • High-update-frequency paths render faster. /docs (changes often) has shorter median delay than /showcase (changes rarely) on nextjs.org.
  • Path-only URLs render faster than query-string URLs. p75 = 22 s path-only vs ~31 min with ?ref=...-style parameters — Google appears to de-prioritise URLs that likely serve the same content as a canonical path-only peer.
  • <lastmod> in sitemap is a strong re-render / re-crawl signal.
  • JS complexity does not correlate with rendering delay on the nextjs.org scale — though it does raise per-render cost which feeds into per-site crawl budget.

What WRS does not do

  • Click on things. Tabbed content, cookie-banner-gated content, "load more" buttons — all invisible unless the initial DOM- after-render includes them.
  • Honour HTTP Cache-Control for asset freshness. WRS uses its own heuristics.
  • Run with persistent cookies or localStorage. Authenticated / personalised content is WRS-invisible.

Positioning

  • WRS is the production serving-system behind Google Search Central's "Google can render your JavaScript" claims.
  • The Vercel + MERJ study is the first public empirical-distribution disclosure of WRS queue latency at scale on a Next.js site, and the first public confirmation that React 18 streaming SSR + RSC payloads are indexed.
  • Comparable services: Bingbot's rendering pipeline (undisclosed behaviour shape); DuckDuckGo / Yandex (also unmeasured in this study).

Seen in

Last updated · 476 distilled / 1,218 read