SPOKE 03 · BYTE-LEVEL SEO

Google renders JavaScript through a headless Chrome instance called WRS. But “renders” doesn’t mean “renders fully”, it runs inside the same byte limits as the crawler, and that breaks more sites than anyone realizes.

What WRS actually is

Web Rendering Service is a fleet of headless Chrome browsers that Google runs in a second pass after the initial crawl. The crawler fetches raw HTML. WRS later executes JavaScript on that HTML to discover content that wasn’t in the initial response.

The two-pass indexing model

PASS 1 Initial Crawl Fetches raw HTML

queue

DELAY Render Queue Hours to days

PASS 2 WRS Render Executes JS

JavaScript content is indexed only after Pass 2 completes If Pass 2 fails, your dynamic content never reaches the index

CONFIRMED BY GOOGLE · MARCH 31, 2026

WRS is stateless, and that changes everything

In Google’s March 2026 “Inside Googlebot” post, the team confirmed a critical implementation detail most SEOs were not aware of: the Web Rendering Service operates statelessly. Every page render starts from zero. WRS does not persist cookies, localStorage, sessionStorage, or IndexedDB between page loads.

No session continuity
Content gated behind login state, geo-detection, or A/B test variants assigned via cookies will fail. Always render the public version first.

No service worker caching
PWA shells that rely on a service worker to hydrate content from cache will appear blank to WRS. Server-render the shell content.

No carry-over from past visits
If your personalization relies on WRS “remembering” past behaviour, that personalization simply doesn’t run. Default fallbacks matter.

Higher stakes in the AI Mode era
Since May 19, 2026, AI Mode is powered by Gemini 3.5 Flash and serves 1B+ users monthly. WRS failures mean lost AI citations, not just lost organic rank.

Reference: developers.google.com/search/blog/2026/03/crawler-blog-post

What can break in WRS rendering

1. JavaScript that exceeds the byte budget

WRS still respects the 2MB rule. If your bundled JavaScript pushes total response past the limit, WRS may execute incomplete code or skip rendering altogether. Heavy SPAs are most at risk.

2. Resources that don’t load in time

WRS has a rendering deadline per page. If a critical JS file takes too long to fetch from a CDN or your own server, the render aborts. Whatever content was meant to be injected by that JS is invisible to indexing.

3. Content that requires user interaction

WRS does not click buttons, scroll, or fill forms. Content hidden behind “Click to view more” or infinite scroll triggers is treated as if it doesn’t exist. Pre-render those by default.

4. Failed third-party API calls

If your page hydrates content from an external API (reviews, pricing, recommendations) and that API is rate-limited or geo-blocked from WRS, that content never indexes. Always have a server-side fallback.

Apurv Singh

PRACTITIONER NOTE

“I worked with a D2C jewellery brand that had built their product detail pages in React with reviews loaded from a third-party API. The reviews were 70 percent of the indexable content. We discovered through Search Console URL Inspection that WRS was rendering the page but the reviews never loaded, the API had geo-blocked Google’s data centers. Server-side rendering the reviews fixed indexation in 21 days.”

Apurv Singh, Founder HQ Digital

Server-rendered vs client-rendered vs hybrid

Rendering mode How WRS sees it SEO risk
SSR (Server-Side Rendering) Content in initial HTML Lowest, recommended
SSG (Static Site Generation) Content baked at build time Lowest, best for blogs
Hybrid SSR + CSR Initial paint SSR, then hydration Medium, test rigorously
CSR (Client-Side Rendering) Empty shell, content loads via JS High, avoid for SEO pages
Dynamic rendering Serve pre-rendered HTML to bots Deprecated by Google

How to validate WRS rendering of your pages

METHOD 1

URL Inspection > View Crawled Page

In Search Console, inspect a URL and click “View Crawled Page” then “More Info” then “HTML.” That is exactly what WRS rendered. Search for your critical content. If it’s not there, WRS failed.

METHOD 2

Live Test with screenshot

Same URL Inspection tool, click “Live Test.” Compare the screenshot to your browser. Missing elements indicate WRS rendering failure on critical paths.

METHOD 3

Disable JS in Chrome and reload

Open DevTools, Command Palette, “Disable JavaScript,” reload the page. What remains visible is approximately what WRS gets on the first pass. Critical SEO content should still be visible.

CONTINUE THE SERIES

Next: External JS and CSS Fetch Budgets

Each external file Google fetches has its own budget. Too many = render fails. Here’s the math.

Read Spoke 04 →