SEO

JavaScript Rendering: How Google's Render Queue Works

Google queues every page that returns a 200 status code for rendering, with or without JavaScript. JavaScript rendering usually completes within seconds. A 2024 study of 37,000+ renders on nextjs.org found a 10-second median, while the slowest 10% of pages waited 3 hours or more.

Sercan Gökpınar
11 min read

A common picture of JavaScript rendering at Google has three parts. Script-heavy pages get a separate queue, the wait runs to weeks, and the crawler cannot run modern code. Google's documentation and the largest public measurement contradict all three.

The real risks sit elsewhere. They sit in what the renderer refuses to do, in the order Google reads a page, and in crawlers that never render at all.

How Google Processes a JavaScript Page

Google's JavaScript SEO guide describes three phases: crawling, rendering, and indexing. Googlebot takes a URL from the crawl queue and checks robots.txt before it sends a request. A disallowed URL is skipped, and Google does not render JavaScript from blocked files either. That second rule is why blocking a framework's script folder empties the page.

Since May 2019, Googlebot rendering has run on an up-to-date version of Chromium, which Google's announcement called "evergreen." Bing made the same commitment for Microsoft Edge in October 2019. The belief that search engines cannot handle modern JavaScript rendering is seven years out of date.

Media

The Page Is Read Twice

Google parses a page for links two times. The first pass reads the HTML response and adds every URL found in an href attribute to the crawl queue. The second pass reads the rendered HTML, finds links again, and queues them as well.

Google also indexes from the rendered HTML, and content missing from it cannot be indexed. On a server-rendered page, both passes see nearly the same document. On an app shell page, the first pass sees a container and a script tag, and everything that matters arrives in the second.

A failed JavaScript rendering pass is one technical cause of the gap between crawling and indexing. The server log shows a healthy 200, while Google holds a page with nothing to index.

What Gets Into the Render Queue

The render queue does not select pages by technology. In Google's words, "All pages with a 200 HTTP status code are sent to the rendering queue." That holds "no matter whether JavaScript is present on the page," so a static page and a single-page application (SPA) wait in the same line.

Two things keep a page out. A status code other than 200 means rendering "might be skipped," with a 404 page as Google's example. A robots meta tag or header that blocks indexing keeps the page out as well.

Vercel and MERJ tested both conditions on live sites in April 2024. Every 200 HTML page was rendered, however much JavaScript it carried. Pages returning other 3xx, 4xx, and 5xx codes were not.

The status code therefore sets the render cost as well as the indexing decision. An SPA that serves error pages with a 200 queues broken pages that Google can flag as soft 404 errors. Google's fix is a JavaScript redirect to a URL that returns a real 404, or a noindex tag added by JavaScript.

The noindex Trap

The noindex rule works in one direction only. JavaScript can add a noindex tag, and Google will see it during rendering. JavaScript cannot reliably remove one.

Google's guide explains why: when Google finds noindex, "it may skip rendering and JavaScript execution." The script that would delete the tag never runs. Vercel and MERJ observed the same outcome, with no render at all for pages carrying noindex in the initial HTML.

Sequence diagram between a web server, Googlebot and the Web Rendering Service. When the initial HTML carries noindex, Googlebot skips rendering and does not index the page, so the script that would remove the tag never runs. When the initial HTML has no noindex, the page is rendered, the renderer's API call returns a 404, JavaScript adds noindex, and Google sees the tag.
Sequence diagram between a web server, Googlebot and the Web Rendering Service. When the initial HTML carries noindex, Googlebot skips rendering and does not index the page, so the script that would remove the tag never runs. When the initial HTML has no noindex, the page is rendered, the renderer's API call returns a 404, JavaScript adds noindex, and Google sees the tag.

The mistake shows up in templates that ship noindex by default and lift it once data loads. The browser shows the rendered Document Object Model (DOM), so the page looks correct there. Open view-source instead.

How Long the Render Queue Takes

Google's own answer carries no number. A page "may stay on this queue for a few seconds, but it can take longer than that." Rendering starts once Google's resources allow.

Two numbers exist. At Chrome Dev Summit 2019, Google gave a median render time of 5 seconds and a 90th percentile of "minutes." Ilya Grigorik, then at Google, posted the figures on November 13, 2019, but they never entered Google's documentation.

The newer number is a measurement. Vercel and MERJ matched more than 37,000 Googlebot crawls on nextjs.org with the moment each render finished. The median delay was 10 seconds, and 25% of pages rendered within 4 seconds.

Dot plot on a logarithmic time axis of the delay between Googlebot's crawl and the completed render on nextjs.org in April 2024: within 4 seconds at the 25th percentile, 10 seconds at the median, 26 seconds at the 75th percentile, about 3 hours at the 90th, about 6 hours at the 95th, and about 18 hours at the 99th.
Dot plot on a logarithmic time axis of the delay between Googlebot's crawl and the completed render on nextjs.org in April 2024: within 4 seconds at the 25th percentile, 10 seconds at the median, 26 seconds at the 75th percentile, about 3 hours at the 90th, about 6 hours at the 95th, and about 18 hours at the 99th.

The queue shows in the tail: near 3 hours at the 90th percentile, 6 hours at the 95th, and 18 hours at the 99th.

What the 2024 Numbers Measure

The study covers one frequently updated documentation site over one month. Sections like /docs that change often rendered faster than static ones, so the queue is not first in, first out.

URLs with query strings waited longer: 31 minutes at the 75th percentile, against 22 seconds for clean URLs. A site that spreads one page across tracking or filter parameters pays that delay on every variant. The same variants already consume crawl budget.

Where the "9x Slower" Figure Comes From

Some SEO guides still say Google needs nine times longer to crawl JavaScript content than plain HTML. The figure traces back to an undated agency experiment we could not open. Search summaries describe it as timing Google's path through a seven-page chain of links. That measures discovery across several steps, not the wait for one page.

The direction is plausible, because each link that exists only after JavaScript rendering adds a render wait to the chain. Current data does not support the size, so we do not repeat the number as a fact.

What Googlebot's Renderer Cannot Do

An up-to-date engine does not make the renderer behave like a visitor. Google's troubleshooting guide and lazy-loading guide list differences that a browser test never shows.

Fishbone diagram of why content goes missing from Google's rendered HTML, grouped into five causes: blocked resources such as a disallowed JavaScript file or API endpoint, rendering skipped because of a non-200 status or noindex, content that loads on click or scroll, content that depends on cookies, localStorage or consent, and unsupported features such as WebSockets, WebGL and permission prompts.
Fishbone diagram of why content goes missing from Google's rendered HTML, grouped into five causes: blocked resources such as a disallowed JavaScript file or API endpoint, rendering skipped because of a non-200 status or noindex, content that loads on click or scroll, content that depends on cookies, localStorage or consent, and unsupported features such as WebSockets, WebGL and permission prompts.

It Does Not Click or Scroll

"Google Search does not interact with your page," the lazy-loading guide states. Content that loads after a click, such as a "show more" button that fetches new text, stays out of the rendered HTML. Tabs and accordions are safe when their content already sits in the DOM and is only hidden with CSS.

Scrolling works the same way. Load images and sections when they enter the viewport, with native lazy loading or IntersectionObserver, rather than on a scroll event. Infinite scroll needs a paginated version with a unique, persistent URL for each chunk.

It Forgets Everything Between Pages

Google's Web Rendering Service (WRS) opens every URL with a clean slate. Local Storage, Session Storage, and HTTP cookies are cleared across page loads. Google therefore indexes the version a first-time visitor sees, before any consent, language choice, or saved preference.

A language setting stored in a cookie shows Google the default language on every page. A consent banner that loads the article only after approval shows Google no article, because Google never clicks it.

It Speaks Only HTTP

Googlebot fetches content over HTTP only, without WebSockets or WebRTC, so content streamed over those connections never reaches the index. It declines permission requests such as camera access and has no WebGL support. Google's fix for all three is to detect the feature and provide a fallback.

Links Found Only After Rendering

Google can reliably follow a link only when it is an <a> element with an href attribute. The link guide adds that links inserted by JavaScript are crawlable "as long as it uses the HTML markup shown above." A routerLink attribute, a <span> with an href, or an onclick handler may not be parsed.

Timing matters as much as shape. A link in the HTML response enters the crawl queue on the first pass. A link that appears only after rendering waits for the render queue first, and a chain of such links repeats that wait at every step.

Vercel and MERJ found two details that reduce the cost. Google discovered URLs inside a non-rendered JSON payload, and an up-to-date XML sitemap "significantly reduces, if not eliminates" the discovery gap between rendering methods. Google still judged a link's value for site architecture only after the full render. Put primary navigation in the initial HTML as plain anchor links.

Client-Side vs Server-Side Rendering for Search

For search, the choice between rendering methods comes down to one question: is the content in the first HTML response? Client-side rendering (CSR) sends a shell and builds the page in the browser. Server-side rendering (SSR) builds the HTML on each request, and static site generation (SSG) builds it before any request arrives.

Google does see client-side rendered content, so CSR is not invisible. It is dependent on the render queue, on crawlable scripts, and on the renderer's limits above. Google still recommends server-side or pre-rendering, partly because "not all bots can run JavaScript." Hydration, which adds interactivity to a server-built page, is on the same recommended list.

Dynamic Rendering Was a Workaround

Dynamic rendering serves bots a server-rendered page and users the client-side version. Google's documentation now uses the past tense: "Dynamic rendering was a workaround and not a long-term solution." Two render paths add complexity and resource requirements.

Guides that still recommend it often cite Bing. In October 2018, Bing did recommend it for sites that rely heavily on JavaScript. A year later, Bing moved its renderer to an evergreen Microsoft Edge. Its current guidelines page loads through JavaScript and could not be read, so Bing's present position is unconfirmed.

Timeline from 2015 to 2027 on a proportional scale: the AJAX crawling scheme deprecated in 2015, Bing recommending dynamic rendering in October 2018, Googlebot going evergreen in May 2019, Bingbot going evergreen in October 2019, Google citing a 5-second median render time in November 2019, the ranking guides we reviewed written in spring 2023, the Mobile-Friendly Test retired on December 1, 2023, and the Vercel and MERJ render-delay study published in July 2024.
Timeline from 2015 to 2027 on a proportional scale: the AJAX crawling scheme deprecated in 2015, Bing recommending dynamic rendering in October 2018, Googlebot going evergreen in May 2019, Bingbot going evergreen in October 2019, Google citing a 5-second median render time in November 2019, the ranking guides we reviewed written in spring 2023, the Mobile-Friendly Test retired on December 1, 2023, and the Vercel and MERJ render-delay study published in July 2024.

Not Every Crawler Renders

Google's dynamic rendering page warns that other search engines "may choose to ignore JavaScript." Rendering is expensive. Firecrawl's glossary notes that a plain HTTP request retrieves only the static HTML. Rendering means running a full browser for each page.

The sources we hold do not document which AI crawlers render JavaScript. Until that is settled, treat the initial HTML as the version any non-Google crawler reads. W3Techs puts JavaScript on 98.9% of websites in September 2026, so avoiding it is not an option for JavaScript SEO. Choosing where the content is built is.

How to Check What Google Rendered

Google names two tools for this job. The URL Inspection tool in Google Search Console shows the indexed version under View crawled page and a live test under View tested page. The Rich Results Test runs the same render without access to the property.

Both show loaded resources, console output, and the rendered DOM. Search the rendered HTML rather than trusting the screenshot. The console is where WebGL, WebSocket, or permission failures appear, because your own browser supports all three.

The Mobile-Friendly Test no longer belongs on this list. Google retired it, along with the Mobile Usability report, on December 1, 2023.

Turning JavaScript off in a browser answers a different question. Googlebot renders, so the test does not show Google's view. It shows what a crawler that never renders will read.

Run the checks in this order on one page per template:

  1. Confirm that error URLs return a real 404.
  2. Open view-source and find noindex, the canonical tag, the title, and primary navigation in the initial HTML.
  3. Run a live test in URL Inspection and search the rendered HTML for your text and links.
  4. Read the console for errors your own browser never throws.

Content that appears only after a click, a stored cookie, or a WebSocket message belongs in the first response. That move removes the JavaScript rendering dependency for the part of the page that matters.

Frequently Asked Questions

Does Google render JavaScript?

Yes. Googlebot rendering runs on an evergreen Chromium, and every page that returns a 200 status code enters the render queue. Pages with another status code or a noindex tag may skip rendering.

How long does Google take to render JavaScript?

Google says a page may wait a few seconds or longer. A 2024 measurement of more than 37,000 renders on nextjs.org found a 10-second median and about 3 hours at the 90th percentile.

Is client-side rendering bad for SEO?

Not by itself, because Google renders client-side content. It makes visibility depend on the render queue, crawlable scripts, and renderer limits. Google recommends server-side rendering, static rendering, or hydration instead.

Is dynamic rendering still recommended?

No. Google's documentation calls dynamic rendering a workaround and not a recommended solution, because it adds complexity and resource requirements. Bing's 2018 recommendation predates its October 2019 move to an evergreen, Edge-based renderer.

How do I see the rendered HTML that Google sees?

Use the URL Inspection tool in Google Search Console, or the Rich Results Test for pages outside your property. Both show the rendered HTML, loaded resources, and console errors.

Sources and Further Reading