Googlebot can execute JavaScript. That fact alone has misled more development teams than almost any other statement in SEO. The ability to render is not the same as reliable, timely indexing. Googlebot crawls and renders in two separate phases, and the rendering queue can lag the initial crawl by hours, days, or weeks depending on the page's priority and Google's infrastructure load. Content that only exists after JavaScript execution may be invisible to Google for extended periods, and in 2026 it is invisible to most AI crawlers indefinitely. This article covers the full two-phase pipeline, the Web Rendering Service constraints, when server-side rendering is necessary versus when dynamic rendering suffices, and how to use the URL Inspection tool to see exactly what Google sees after rendering.
Why Does JavaScript Create a Crawling Problem for Search Engines?
Traditional web pages delivered complete HTML from the server. Googlebot could fetch the raw HTML, parse every word of content and every link, and move on. Modern JavaScript-heavy applications change this fundamentally: the server sends a minimal HTML shell containing a few script tags, and the actual content is assembled in the browser after the JavaScript bundle downloads, executes, and potentially fetches additional data from APIs.[1]Source 1Google Search Central. "Understand JavaScript SEO Basics."View source
For a user, this works seamlessly. For a crawler fetching raw HTML, the page is effectively empty. A React or Vue single-page application may return an HTML document containing nothing but <div id="app"></div> and a script tag. Every heading, every paragraph, every internal link is injected by JavaScript at runtime. If the crawler does not execute that JavaScript, it sees a blank page.
Google's response was to build the Web Rendering Service, a separate infrastructure layer that executes JavaScript after the initial crawl. But running a full browser render for every page at web scale is computationally expensive. This constraint is why rendering is decoupled from crawling and why delays emerge.
How Does Googlebot's Two-Phase Crawl Work?
Googlebot processes JavaScript pages in two clearly separated phases. Understanding the exact scope of each phase is what determines your site's crawlability.[1]Source 1Google Search Central. "Understand JavaScript SEO Basics."View source
Phase 1: The HTML Crawl
When Googlebot first requests a URL, it fetches the raw HTML response from the server: no JavaScript execution, no CSS processing. This fetch is subject to a 2 MB limit: content beyond 2 MB in the HTML document is not processed. Whatever exists in the initial HTML at the moment of response is immediately evaluated. Title tags, meta descriptions, canonical URLs, robots meta tags, and any content or links present in the server-sent HTML are all processed in this phase.
For client-side rendered applications, Phase 1 typically yields very little. Googlebot sees the shell HTML, extracts whatever metadata is present, and queues the page for Phase 2. For server-side rendered pages, Phase 1 is sufficient for full indexing. The page is complete on first fetch.
Phase 2: The Rendering Queue
Pages containing JavaScript are queued by Googlebot for rendering by the Web Rendering Service. The WRS uses a headless Chromium instance that has been "evergreen" since Google's 2019 update: continuously maintained to reflect the current stable Chrome version, with full support for ES6+, async/await, Promises, and modern web APIs.
The rendering queue is not instant. Google's documentation acknowledges that a page "may stay in the render queue for a few seconds, but it can take longer than that." In practice, independent research on JavaScript-heavy sites finds that 5 to 50 percent of newly published pages have JavaScript elements that remain unindexed after two weeks from sitemap submission. For pages with low crawl priority or on sites with high rendering loads, the gap between Phase 1 and Phase 2 can extend to several weeks.
During that gap, Google has only the Phase 1 HTML to work with. Content, links, and structured data that exist exclusively in the rendered DOM are invisible until rendering completes.
What Does the Web Rendering Service Actually Do?
The WRS functions as a headless browser running on Google's infrastructure. It downloads the JavaScript and CSS files referenced by the page, constructs the Document Object Model (DOM), executes JavaScript, waits for asynchronous network calls to resolve, and captures the final DOM state. That rendered snapshot is what feeds the indexer.
What WRS Can Do
WRS handles the substantial majority of modern JavaScript rendering scenarios. It supports dynamically injected content, content loaded via fetch() and XMLHttpRequest, web component-based UI, client-side routing in single-page applications, and lazy-loaded content that is triggered on initial page load. Since the 2019 evergreen upgrade, it supports modern syntax that older crawlers could not process.
What WRS Cannot Do: The Critical Limitations
Several categories of content that work perfectly for users remain invisible to WRS regardless of JavaScript support:
No user interaction. WRS does not click, scroll, type, or hover. Content that appears only after a click on a "load more" button, behind a scroll-triggered animation, or inside a modal dialog that requires user action is never exposed to the renderer. This is the most common invisible-content failure on modern JavaScript sites.
Time and depth limits. WRS has a finite rendering budget. Long chains of asynchronous API calls, slow-loading data endpoints, or complex lazy-loading sequences that take more than a few seconds to complete may be cut off before the full DOM is built. The renderer takes a snapshot and stops; content still loading at that moment is absent from the index.
No service worker access. WRS runs Chromium in headless mode without service workers active by default. Content or functionality that depends on a service worker, BroadcastChannel, or browser extension API will fail silently inside WRS while working correctly in a real browser.
2 MB limit per resource. Each individual JavaScript file downloaded by WRS is subject to its own 2 MB limit. A bundle exceeding 2 MB is truncated; code beyond that point is not executed.
The WRS Resource Cache: The 30-Day Problem
Google's December 2024 "Crawling December" blog post revealed a detail that is largely absent from SEO guidance: WRS caches every JavaScript and CSS resource it downloads for up to 30 days. The critical point is that this cache operates independently of your HTTP caching headers. Even if you set Cache-Control: no-cache, max-age=0 or purge your CDN, the WRS cache continues serving its version of your JavaScript file until its 30-day TTL expires.[3]Source 3Google Search Central Blog. "Crawling December: The How and Why of Googlebot Crawling." December 2024.View source
The practical consequence: when you deploy a JavaScript change, Google's renderer may continue executing your old JavaScript for up to 30 days. Updated content structure, new internal links injected by JavaScript, modified structured data, and revised metadata that exists only in JavaScript will all be invisible to WRS until the cache expires or Google re-fetches the resource.
This is why placing critical SEO signals (canonical tags, meta robots directives, primary content, and key internal links) directly in the server-rendered HTML is not just a best practice for performance. It is a reliability requirement for accurate indexing. Anything that depends on a JavaScript file to exist in the DOM carries an invisible up-to-30-day lag for any change.
Notice how this changes the urgency of moving away from client-side rendering for SEO-critical content: it is not only a question of rendering queue delays at discovery time, but also a question of update propagation lag for every subsequent content change deployed through a JavaScript bundle.
What Is Server-Side Rendering and Why Is It the Recommended Approach?
Server-side rendering (SSR) generates the complete HTML for each page on the server at request time. When Googlebot fetches the URL, it receives fully-formed HTML containing all content, all internal links, all metadata, and all structured data in the raw HTTP response. Phase 2 rendering is still queued, but Phase 1 alone is sufficient for complete indexing.[1]Source 1Google Search Central. "Understand JavaScript SEO Basics."View source
SSR eliminates the rendering queue delay, the WRS resource cache lag, the user-interaction limitation, and the 2 MB JavaScript bundle truncation risk for content. Googlebot's treatment of an SSR page is functionally identical to its treatment of a traditional HTML page.
The trade-off is server cost and implementation complexity. SSR requires the server to execute JavaScript for every request, which increases compute requirements relative to a client-side rendered architecture where the server only delivers a static shell. Modern frameworks including Next.js (React), Nuxt (Vue), and SvelteKit provide SSR with built-in hydration: the server delivers complete HTML, and the JavaScript bundle then makes the page interactive without re-rendering from scratch.
Static site generation (SSG) is a related approach where HTML is generated at build time rather than per-request. From Googlebot's perspective, SSG is identical to SSR: both deliver complete HTML on the first fetch. SSG is preferable when content does not change per-request (blog posts, marketing pages, documentation). SSR is preferable when content is personalized or changes frequently enough that build-time generation is impractical.
What Is Dynamic Rendering and When Should You Use It?
Dynamic rendering is a hybrid approach: the server detects whether the incoming request is from a crawler or a real user and serves different content accordingly. Crawlers receive pre-rendered HTML; users receive the standard client-side rendered application. Tools including Prerender.io and Rendertron implement this by running a headless Chrome instance on the server and caching the rendered HTML output.[2]Source 2Google Search Central. "Dynamic Rendering as a Workaround."View source
Google's own documentation describes dynamic rendering as a "workaround" rather than a recommendation. As of current guidance, it is explicitly described as a migration-phase solution: appropriate for teams that need to address JavaScript crawlability without a full SSR rewrite, but not the long-term architectural goal.
| Approach | Googlebot gets | Rendering queue delay | WRS cache lag | AI crawler visibility |
|---|---|---|---|---|
| Client-side rendering (CSR) | Empty HTML shell | Hours to weeks | Up to 30 days for JS changes | None (raw HTML only) |
| Server-side rendering (SSR) | Complete HTML | Minimal (Phase 1 sufficient) | None for HTML content | Full (raw HTML complete) |
| Static site generation (SSG) | Complete HTML | Minimal (Phase 1 sufficient) | None for HTML content | Full (raw HTML complete) |
| Dynamic rendering | Pre-rendered HTML for bots | Minimal | None for HTML content | Full (pre-rendered) |
The recommendation hierarchy, from most to least preferred for SEO: SSR or SSG as the foundation, pre-rendered HTML delivery as a valid alternative, dynamic rendering as a temporary workaround during migration, and client-side rendering only for content that is not intended to be indexed.
How Do You See What Googlebot Sees? The URL Inspection Tool
The URL Inspection tool in Google Search Console is the most direct way to verify what Google has rendered for any specific page. It exposes the full output of the WRS pipeline.
View Crawled Page shows the rendered HTML: the final DOM state after JavaScript execution, which is what the indexer actually processed. Comparing this against your page's raw source HTML (right-click in Chrome, then View Page Source) reveals exactly which content exists before JavaScript execution and which depends on rendering.
Screenshot shows a visual representation of how the page appeared to WRS after rendering. This is the single most diagnostic panel for JavaScript SEO. A page that renders correctly in a user's browser but shows blank sections, broken layouts, or a cookie consent modal occupying the full viewport in the screenshot reveals a rendering problem that would otherwise be invisible.
Page Resources lists every CSS, JavaScript, image, and font file the page requested during rendering, with the response status for each. Any resource returning 4xx errors or blocked by robots.txt is flagged. A blocked JavaScript file that is responsible for injecting critical content creates a rendering failure that only the Page Resources panel makes obvious.
JavaScript Console Messages (available in the Live Test only) shows every error and warning logged during rendering. A single uncaught JavaScript exception during framework hydration can prevent below-the-fold content from rendering entirely.
To run a Live Test: enter the URL, click "Test Live URL," wait for the render to complete, then click "View Tested Page." The live test reflects the current state of the page, while the indexed view reflects the state at the time of Google's last crawl.
AI Crawlers Do Not Render JavaScript
Google is not the only crawler that matters. GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Bytespider, Meta-ExternalAgent, and virtually every other AI crawler operate exclusively on raw HTML. They fetch the HTTP response and process only the content present in the server-sent HTML. No JavaScript is executed.
Vercel's analysis of over a billion monthly bot requests confirmed this pattern across all major AI crawlers. These crawlers see a client-side rendered application as an empty shell, identical to what Googlebot sees in Phase 1 before rendering. As AI-powered answer engines become a more significant source of organic traffic and citations, sites built on client-side rendering face a growing visibility gap that cannot be resolved by optimizing for Googlebot's rendering queue.
Server-side rendering or static generation is the only architecture that guarantees content visibility to all crawlers: Google's WRS-dependent pipeline and the raw-HTML-only AI crawlers simultaneously. A client-side rendered site that relies on Googlebot's rendering capability is already invisible to an expanding share of the answer-engine ecosystem.
Sources
-
Google Search Central. "Understand JavaScript SEO Basics."
-
Google Search Central. "Dynamic Rendering as a Workaround."
-
Google Search Central Blog. "Crawling December: The How and Why of Googlebot Crawling." December 2024.
