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
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.
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.
“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.”
Server-rendered vs client-rendered vs hybrid
How to validate WRS rendering of your pages
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.
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.
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.
Next: External JS and CSS Fetch Budgets
Each external file Google fetches has its own budget. Too many = render fails. Here’s the math.
Related resources
Recent updates in search and AI
17 June 2026
AI assistants may not render JavaScript at all
A study found that ChatGPT and other assistants frequently skip JavaScript rendering when grounding responses. That extends the rendering problem beyond Googlebot: content injected client-side can be invisible to the models as well as to the first crawl pass. If you care about both search and AI visibility, server-side rendering stops being a performance preference and becomes a visibility requirement.