In short
Yes. Googlebot uses a recent version of Chrome to execute JavaScript and index the resulting content, so client-rendered pages can rank. But rendering happens in a second wave that can lag crawling by hours or days, it has resource limits, it does not click or scroll, and content that depends on user interaction or fails to render for any reason is simply not indexed. Most AI crawlers and many other search engines do not execute JavaScript at all. For content that must be found, serve it in the HTML.
How Google processes a JavaScript page
Google's pipeline has three stages, and understanding the gap between the first two explains most JavaScript SEO problems.
Crawl. Googlebot fetches the HTML. If the content is in the HTML, indexing can proceed from here. If the HTML is an empty shell with a script tag, which is what a typical single-page application serves, there is nothing to index yet.
Render. The page is queued for the Web Rendering Service, which loads it in a headless Chrome, runs the JavaScript, waits for the network to settle, and captures the resulting DOM. Google has said this queue is usually processed within seconds to minutes for most pages, but it can take longer, and it is subject to resource limits: scripts that time out, requests that fail, and pages that consume too much CPU are rendered incompletely or not at all.
Index. The rendered content is processed as if it had been in the HTML.
So a client-rendered page gets indexed, eventually, if everything went right. Both qualifiers matter.
What goes wrong
Content behind interaction. Googlebot does not click, tap, scroll, or fill in forms. Content that loads on a button press, an infinite scroll, or a tab switch that fetches data is invisible unless it is also present in the initial render or reachable by a link.
Blocked resources. If robots.txt disallows the JavaScript or API endpoints the page needs, rendering fails silently. This is the most common cause of a JavaScript site indexing as blank.
Timeouts and errors. A third-party script that hangs, an API that responds slowly, or a runtime error in the bundle can stop rendering before the content appears. Googlebot's Chrome is patient but not infinitely so.
State that depends on the visitor. Content that requires cookies, local storage, geolocation permission or a logged-in session does not exist for Googlebot, which arrives with none of those.
Metadata set late. Titles, meta descriptions and canonical tags injected by JavaScript are honoured only after rendering. If the initial HTML has a placeholder title, that is what may appear in results in the interim, and any conflict between the HTML and the rendered version is resolved unpredictably.
Links that are not links. Navigation implemented as click handlers on div elements, without href attributes, is not followed. Googlebot discovers pages through real anchor links.
Crawl budget. Rendering costs Google far more than fetching HTML. Large JavaScript-rendered sites are rendered more slowly and less completely, which is where the crawl budget discussion becomes real.
Other crawlers mostly do not render
Bing renders JavaScript to a degree. Most other search engines, social platforms generating link previews, and, importantly, the crawlers used by AI assistants and answer engines fetch the HTML and read what is there. A page whose content exists only after JavaScript runs is, to those systems, an empty page. If being cited by AI search matters, and in 2026 it does, the content has to be in the HTML.
How to check what Google sees
Search Console's URL Inspection tool fetches and renders a page as Googlebot and shows the rendered HTML and a screenshot. If the content you expect is missing from the rendered HTML, Google is not indexing it. The tool also lists resources that were blocked or failed to load, which usually points straight at the cause.
A quicker check: search for a distinctive sentence from the page in quotes. If it returns the page, the content is indexed; if not, it may not be.
View the page's source, as opposed to the browser's rendered DOM, to see what non-rendering crawlers get.
The rendering strategies
Server-side rendering (SSR). The server runs the JavaScript and sends complete HTML; the browser then attaches interactivity. Every crawler sees the content immediately. This is what frameworks such as Next.js, Nuxt and SvelteKit do by default.
Static generation (SSG). Pages are rendered to HTML at build time and served as files. Fastest, cheapest, and perfectly crawlable; right for content that does not change per request. A static site is this pattern in its simplest form.
Hybrid. Content rendered on the server or at build; interactive widgets hydrated on the client. The practical default for most sites in 2026, and what modern front-end architecture generally means.
Client-side rendering with care. Acceptable for applications behind a login where indexing is irrelevant, and for content-light interfaces. For anything that needs to be found, it is the option that depends on everything going right.
Dynamic rendering, serving pre-rendered HTML to bots and the client app to users, was a stopgap Google no longer recommends.
The decision
If a page exists to be found, its content and its links belong in the HTML the server sends. Google will probably render it otherwise, but probably and eventually are poor foundations for a ranking, and the systems that increasingly decide visibility do not render at all. If you are unsure what your site is serving to crawlers, book a call and we will show you the difference between the source and the render.
Common questions
Can Google index JavaScript-rendered content?
Yes. Googlebot renders pages in a headless Chrome and indexes the resulting content, so single-page applications can rank. Rendering happens in a second wave that may lag crawling, has resource limits, and fails silently when scripts or API calls are blocked or time out. Content that only appears after user interaction is not indexed.
How long does Google take to render JavaScript?
Google has said most pages are rendered within seconds to minutes of being crawled, but the render queue can lag by hours or occasionally days under load, and heavy pages may be rendered incompletely. During the gap, only the initial HTML is known, so titles and content set by JavaScript may be missing or stale in results.
Do AI crawlers like GPTBot render JavaScript?
Generally not. Most crawlers used by AI assistants and answer engines fetch the raw HTML and do not execute scripts, so content that exists only after JavaScript runs is invisible to them. If being cited by AI search matters, the content must be present in the server-sent HTML.
How do I check if Google can see my JavaScript content?
Use the URL Inspection tool in Search Console, which renders the page as Googlebot and shows the rendered HTML, a screenshot and any blocked or failed resources. Also search Google for a distinctive sentence from the page in quotation marks; if the page is returned, the content is indexed.
Is server-side rendering better for SEO than client-side rendering?
Yes, for any page that needs to be found. Server-side or static rendering puts the content in the HTML every crawler receives, removing the dependence on Google's render queue and making the page visible to non-rendering crawlers including AI systems. Client-side rendering is fine for applications behind a login where indexing does not matter.
