JavaScript SEO

How does Google process JavaScript?

Google describes three phases. During crawling, Googlebot fetches the URL and reads the HTML in the server response. Pages that return status 200 are then queued for rendering, where a headless, evergreen version of Chromium runs the JavaScript. The rendered HTML is what Google uses for indexing. How long a page waits in the render queue depends on Google’s resources.

The gap between the raw HTML and the final DOM is where problems start. Content that only appears after a click, a scroll event, or a failed API call may be missing from the version Google indexes. The rendering service also clears cookies, localStorage, and sessionStorage between page loads and declines permission requests such as camera or location access.

Other crawlers don’t necessarily render at all. A December 2024 analysis by Vercel found that the crawlers of OpenAI, Anthropic, and Perplexity fetch some JavaScript files but don’t execute them. For those bots, content that exists only after client-side rendering is invisible. The AI operators do not document this behavior, so it rests on third-party measurements, and according to reports nothing has changed as of October 2026. Google’s own guidance notes that not all bots can run JavaScript.

In practitioner tests of JavaScript changes from 2017, the home page reflected them in search results after eight days, while less important pages took about two months. Google now says a page often spends only a few seconds in the rendering queue, though it can take longer. The time until the next crawl comes on top of that.

Rendering options

With client-side rendering (CSR), the browser builds the page from JavaScript. With server-side rendering (SSR) or static generation, the server sends finished HTML. Google recommends server-side rendering, static rendering, or hydration. It calls dynamic rendering, a separate prerendered version for bots, a workaround and not a long-term solution.

Example

A store loads the products of a category page with fetch(). The source HTML contains only:

<div id="products"></div>
<button onclick="loadMore()">Load more</button>

After rendering, Google sees the first 24 products. The rest appear only after a button click and have no URL of their own. Paginated links such as <a href="?page=2"> give crawlers a way to reach them.

Checklist

These points come from Google’s JavaScript SEO basics.

• Important content, links, and metadata are present in the rendered HTML, checked with the URL Inspection tool in Search Console.
• Every page has a unique <title> and its own meta description, even when JavaScript sets them.
• Links are <a> elements with an href attribute.
• Single-page apps use the History API for routing instead of fragment URLs.
• Error pages in single-page apps use a JavaScript redirect to a URL that returns 404, or add noindex with JavaScript.
• A canonical set by JavaScript is identical to the canonical in the original HTML.
• Pages that should be indexed have no noindex in the served HTML.
• robots.txt doesn’t block JavaScript files or APIs needed for rendering.
• JavaScript file names include a content fingerprint, such as main.2bb85551.js, so Google doesn’t use outdated cached files.

FAQ

How can I see what Google renders? The URL Inspection tool in Search Console and the Rich Results Test show the rendered HTML, loaded resources, and JavaScript console messages. Comparing that output with the page source shows which content depends on JavaScript.

Is React bad for SEO? Google can render React apps like any other JavaScript. Problems come from implementation choices, such as content that depends on user interaction or links without href. Server-side rendering or static generation reduces the risk for Google and for crawlers that don’t run JavaScript.

Last updated: October 8, 2026