Google processes JavaScript-rendered pages in two passes: an initial crawl of the raw HTML response as delivered by the server, indexed or at least queued immediately, and a second pass where the page is queued for rendering by Google’s evergreen, up-to-date Chromium-based renderer so that content injected by client-side JavaScript can be seen and indexed. Content that exists only after JavaScript execution isn’t available to Google until that second wave completes, and whether it ever completes depends on whether the page actually makes it through the render queue successfully, which isn’t guaranteed for every URL and isn’t instantaneous even when it does happen.
The mechanism: two distinct passes with a queue in between
Google’s documentation on JavaScript SEO describes the process in two stages. First, Googlebot crawls a URL and processes whatever is present in the initial HTML response, links, text, and metadata that exist without JavaScript execution get picked up here. If the page relies on client-side JavaScript to inject meaningful content (product descriptions rendered by a framework, navigation built dynamically, text populated from an API call after page load), that content isn’t part of what’s captured in this first pass, since no JavaScript has run yet.
The URL is then placed into a rendering queue. When resources allow, Google’s renderer, based on a recent, evergreen version of Chromium rather than a fixed old snapshot, executes the page’s JavaScript much the way a real browser would, and the resulting rendered DOM is what gets processed and indexed in this second wave. This is the pass where client-side-injected content actually becomes visible to Google’s indexing systems; until it happens, only the initial HTML is what Google has to work with for that URL.
What determines whether the second wave executes at all
Queueing for rendering isn’t automatic completion of rendering. Several failure points sit between “queued for the second wave” and “second wave successfully processed the injected content”:
JavaScript execution errors. If the script that injects the content throws an error during Google’s render pass, whether due to a genuine bug, a dependency that fails to load, or an environment difference between the render environment and a typical user’s browser, the content that script was supposed to inject may never appear in the rendered DOM Google evaluates.
Blocked resources. If robots.txt disallows crawling of JavaScript files, CSS, or other resources the page depends on to render correctly, Google’s renderer may be unable to execute the script or apply the styling needed to produce the same output a real visitor sees, resulting in an incomplete or broken render.
Render timeouts. Google’s renderer operates within resource and time constraints; a page that takes an unusually long time to finish its JavaScript execution (heavy client-side processing, slow API calls the page waits on) risks the render being cut off before the relevant content actually appears in the DOM.
Never being queued with meaningful priority. For very large sites or low-priority sections, a URL can sit in the rendering queue for an extended period, or in extreme resource-constrained cases, effectively never get prioritized for the second pass in a timeframe that matters, particularly on sites where crawl budget is already constrained by other factors.
Google’s engineers, including public statements from people like John Mueller and Martin Splitt on this exact rendering-queue timing question, have described the gap between the two waves as historically longer and more variable than site owners assumed, while also describing it as generally faster in more recent years as rendering infrastructure has scaled. Neither of those descriptions amounts to a fixed, quotable number of hours or days, and treating any specific figure as a guaranteed rendering delay isn’t something Google has substantiated; the honest framing is that the gap is variable and resource-dependent rather than fixed.
Why this doesn’t put all JavaScript-dependent content equally at risk
It’s worth being precise that not all JavaScript usage carries the same exposure here. Content present in the initial server-delivered HTML, including cases where a framework does server-side rendering or static generation so the meaningful content already exists in the raw response, doesn’t depend on the second wave at all and is available to Google in the first pass like any static HTML. The risk specifically concerns content that exists only after client-side JavaScript execution with no equivalent already present in the raw HTML, that’s the category of content genuinely gated behind successful completion of the second wave.
Practical implication
Compare the page’s raw HTML response (viewable via “View Page Source” or a simple fetch without executing JavaScript) against the rendered DOM as Google would see it (available through the URL Inspection tool’s rendered HTML view in Search Console) for any page relying on client-side content injection. If critical content, primary body text, product details, key navigation links, only appears in the rendered version and not the raw response, that content’s visibility to Google depends entirely on the second wave completing successfully, which isn’t guaranteed on the same timeline as the first pass, and isn’t guaranteed to complete cleanly at all if the page has render-blocking issues. Where feasible, shifting critical content into server-side rendering, static generation, or hybrid rendering so it’s present in the initial HTML response removes the dependency on the second wave entirely, which is the more robust approach for content that needs reliable, prompt indexing rather than being contingent on a rendering queue with variable timing and real failure modes.
