JavaScript Rendering SEO: What Google Actually Sees

Key takeaways #

Google can render JavaScript, and it renders nearly every page it crawls. The real risk is not whether rendering happens but when it happens, and what your initial HTML says before it does. Sites that ship critical content, links, and meta signals in the first server response get indexed faster, more reliably, and by every crawler, including the AI crawlers that never run JavaScript at all.

Open your site in any browser, and everything looks fine. The headline loads, the product grid fills in, the pricing table appears. But the page your visitors see and the document your server actually sends are often two different things. If your site relies on JavaScript to build its content, the first version Google downloads may be little more than an empty div and a script tag.

Understanding that gap is the whole game in JavaScript rendering SEO: what exists before scripts run, what exists after, and how Google moves a page from one state to the other. This guide walks through Google's crawl, render, and index pipeline, the measured numbers behind the render queue, how the main rendering strategies compare, and how to find and fix the JavaScript SEO issues that keep content out of search results and AI answers.

The Gap Between What Users See and What Google Fetches #

Modern sites lean heavily on JavaScript. The 2025 Web Almanac from HTTP Archive (Page Weight chapter, January 2026) puts the median page at 646 KB of compressed JavaScript on mobile and 708 KB on desktop, second only to images in page weight. Frameworks such as React, Vue, and Angular drive much of that weight by moving page construction into the browser: the server sends a thin HTML shell, the browser downloads the scripts, executes them, and assembles the page on the spot.

Human visitors rarely notice, because browsers do this work as the page loads. A crawler that reads only the initial server response notices immediately. Where your customer sees a finished pricing page, that first fetch contains a title, a script reference, and an empty container waiting to be filled. Everything that matters for search, from the copy and product details to the internal links, arrives only after the JavaScript runs.

That distinction matters twice. Once for Google, which can close the gap by rendering the page itself. And once for everything else that reads your site without a full browser, which cannot.

Googlebot JavaScript Rendering in Three Phases: Crawl, Render, Index #

Google's JavaScript SEO documentation (last updated March 2026) describes three phases: crawling, rendering, and indexing. Googlebot pulls a URL from the crawl queue, checks robots.txt, fetches the page, and parses the raw HTML for links, which go straight back into the crawl queue. Every page that returns a 200 status code is then queued for rendering, whether it contains JavaScript or not, unless a robots meta tag or header tells Google not to index it.

Rendering happens in a headless Chromium browser that Google has kept evergreen since May 2019, meaning it runs a current version of Chrome and supports modern JavaScript features. When resources allow, the renderer executes the page's scripts, and the finished HTML flows back into processing, where Google indexes the content and extracts any links that appeared only after rendering.

Two details in that pipeline deserve special attention. First, when Google finds a noindex tag in the initial HTML, it may skip rendering and JavaScript execution altogether, so using JavaScript to remove that noindex later may never take effect. If you want a page indexed, keep noindex out of the original page code. Second, rendering is deferred. Google's documentation says a page may sit in the render queue for a few seconds but can wait longer, which raises the obvious question: how much longer?

The Render Queue in Real Numbers #

The best public answer comes from a joint study by Vercel and MERJ published in July 2024, which analyzed more than 100,000 Googlebot fetches and matched over 37,000 of them to completed renders. The headline finding: excluding error pages and non-indexable URLs, Google fully rendered 100 percent of the HTML pages it crawled, including pages with complex client-side JavaScript.

The timing data retired an old fear. The median page waited just 10 seconds between crawl and completed render, and a quarter of pages rendered within 4 seconds. The long tail existed but stayed rare: the 90th percentile waited about 3 hours and the 99th percentile about 18 hours. The multi-week second wave of indexing that older SEO guides warned about did not appear anywhere in the data.

One pattern is worth flagging for marketers: URLs with query strings rendered noticeably slower, with a median of 13 seconds and a 75th percentile of 31 minutes in the same dataset. If your campaign pages or filtered views depend on parameters that do not change the content, that overhead buys you nothing.

Why a Perfect Render Rate is not the Whole Story #

If Google renders everything, it is tempting to conclude that rendering no longer matters. Three realities argue otherwise.

Rendering can still fail on your side. The render succeeds only when the renderer can reach every file that builds the page. Scripts blocked in robots.txt, fragile error handling, and timeouts all produce a partial page, and Google indexes whatever survived. On large sites, rendering cost adds up: Google's crawl budget documentation, aimed at sites with 10,000+ pages that change daily or a million-plus pages that change weekly, notes that the faster Google can load and render your pages, the more of your content it may be able to read.

Links wait for the render. Links present in the initial HTML enter the crawl queue immediately. Links that only exist after JavaScript runs wait for the renderer, which slows discovery across deep architectures. Server-rendered pages keep every internal link visible from the first fetch, and the Vercel and MERJ data showed that an up-to-date XML sitemap narrows the discovery gap considerably for everything else.

Google is no longer the only reader that counts. Vercel and MERJ's follow-up AI crawler study (December 2024) found that none of the major AI crawlers, including GPTBot, ClaudeBot, and PerplexityBot, render JavaScript; the ChatGPT and Claude crawlers download script files but never execute them. Only Gemini, which runs on Googlebot's infrastructure, and AppleBot fully render pages. Content that exists only after a client-side render is simply absent from the assistants shaping buying decisions, which is why AI search optimization and generative engine optimization both start with the same requirement: put the substance of the page in the initial HTML.

Choosing a Rendering Strategy for SEO #

Rendering strategy sounds like an engineering topic, but you decide it at the same table as web design, platform, and budget, and it quietly sets the ceiling on your organic performance. Four approaches cover almost every site, and one older workaround still turns up in audits.

Static generation and incremental static regeneration #

Static generation (SSG) builds the full HTML ahead of time and serves it instantly, which makes it the strongest option for content that changes rarely: blogs, guides, service pages. Incremental static regeneration (ISR) keeps those prebuilt pages fresh on a schedule without full rebuilds, so a large catalog can stay current without giving up prebuilt HTML.

Server-side rendering SEO: complete HTML on every request #

Server-side rendering (SSR) assembles HTML per request, which suits content that changes constantly, such as inventory, pricing, or personalization. For SEO, the payoff is that crawlers receive finished copy, links, titles, and canonicals in the first response, with nothing waiting on the render queue. The cost is server work on every request, which caching and a content delivery network usually keep under control.

Client-side rendering SEO: where the risk sits #

Client-side rendering (CSR) ships the empty shell and does everything in the browser, which is fine for logged-in application screens and risky for anything you want discovered. Google will usually render it, but every page then depends on a successful render, links wait for the renderer, and AI crawlers see only the shell. Most modern frameworks support hybrid setups that prerender the page and then hydrate interactivity on top, which keeps the app experience without the SEO exposure.

Dynamic rendering SEO: a workaround, not a strategy #

Dynamic rendering detects crawlers and serves them a prerendered snapshot while human visitors get the client-side version. It was a common patch for single-page apps, but Google's dynamic rendering documentation (updated December 2025) now calls it a workaround and not a long-term solution, and recommends server-side rendering, static rendering, or hydration instead. If your site still relies on it, treat it as a bridge to one of those options and check that the snapshot bots receive matches what users see.

Matching the strategy to the page #

The decision is easiest to make early, which is why it belongs in web design and build conversations rather than post-launch fixes. There is also a commercial bonus: prerendered pages usually load faster, and speed pays twice. Google's page experience signals reward it through Core Web Vitals, and Deloitte's Milliseconds Make Millions study (2020), commissioned by Google, found that a 0.1 second improvement in mobile site speed lifted conversion rates by 8.4 percent for retail sites and 10.1 percent for travel sites, the kind of gain a conversion rate optimization program works hard for.

Six JavaScript SEO Issues that Keep Rendered Content Out of the Index #

When JavaScript sites lose visibility, the cause is rarely exotic. The same six problems account for most of the damage we see in technical audits.

1. Critical scripts blocked in robots.txt. If the renderer cannot fetch app.js, it cannot build the page. Audit your robots.txt against the resources the page actually loads.

2. Links without real href attributes. Google only follows anchor elements with an href, per its crawlable links guidelines. Buttons with click handlers and router links that never touch the DOM as anchors leave whole sections undiscovered.

3. A noindex tag in the initial HTML. Google may skip rendering when it sees one, so a script that removes the tag may never run. Staging flags that leak into production are a classic source.

4. Content that appears only on scroll or click. Google Search does not interact with your page, so content fetched only after a click, a tab change, or a scroll never loads for the renderer. Text that is already in the HTML but tucked inside a closed tab or accordion can still be rendered and indexed; text requested only on interaction cannot. Google's lazy loading guidance recommends patterns like IntersectionObserver and paginated URLs so content loads without interaction. This hits ecommerce marketing hardest, where infinite scroll product grids can hide most of a category from the index.

5. Titles and canonicals set only client-side. They usually get picked up at render time, but they arrive late and can contradict the raw HTML. The 2025 Web Almanac SEO chapter found JavaScript changing the canonical tag during rendering on about 3 percent of mobile sites, and its authors call a static, server-side canonical the safer option. Put titles, meta descriptions, and canonicals in the server response.

6. Soft 404s in single-page apps. Client-side routers often return a 200 status for pages that don't exist. Google's guidance is to redirect missing content to a URL that returns a real 404, or to add a noindex robots meta tag to the error view.

How to Find and Fix JavaScript SEO Issues #

You never have to guess. The URL Inspection tool in Search Console shows the rendered HTML Google stored for an indexed page, and its live test reports the page resources and console messages it ran into. The Rich Results Test performs a live render when you need to check a fix before Google recrawls.

The workflow is a loop, not a one-time check. Inspect the rendered HTML, then compare it against what your browser displays; any content present in one and missing from the other is your problem statement. Diagnose the cause with the page resources and console reports, apply the fix, request indexing, and watch the Page indexing report until the numbers move. Google maintains a dedicated troubleshooting guide for search-related JavaScript problems that maps most symptoms you will find to their causes.

How to fix JavaScript indexing issues once you find them #

Most fixes come down to three moves. Get the content into the initial HTML through server-side rendering, static generation, or prerendering. Make every resource and link reachable by unblocking scripts in robots.txt and using real anchor tags with an href. Then send clean signals: titles, canonicals, status codes, and no stray noindex in the server response. One easily missed detail: Google's renderer caches aggressively and may ignore caching headers, so fingerprint your JavaScript filenames (app.3f9a2c.js rather than app.js) to make sure it fetches your fixed code instead of an old copy.

The 2026 Stakes: Every Answer Engine Reads Your HTML first #

The rendering conversation used to end with Google. It no longer does. AI Overviews and AI Mode inherit Googlebot's full rendering pipeline, but the assistant crawlers gathering training data and live citations do not, and neither do most of the smaller bots that feed answer engines. For a growing share of the queries that influence your buyers, the initial HTML response is the only version of your site that machines ever read.

That shifts rendering from a technical preference to a distribution decision. Content teams can produce the best guide in the category, but if the words only exist after a client-side render, a meaningful slice of the machines quoting answers to your prospects will never see them. Visibility this year looks like pairing server-rendered delivery with content production built for citation, clear claims, dated statistics, and structured data in the initial response.

What to Do With All of This #

Google sees something different from your users only for as long as your architecture makes it so. The pipeline is public, the queue is measured, and the failure points are known. Good JavaScript rendering SEO comes down to a short list: render your critical content on the server or at build time, keep every link a real anchor, keep noindex out of pages you want found, and verify with the URL Inspection tool instead of assuming. Sites that treat the initial HTML as the product, not the loading screen, get indexed faster by Google and stay visible to every crawler that follows.

Frequently Asked Questions #

What is JavaScript rendering SEO? #

It is the work of making sure search engines can see content that JavaScript builds. Google executes a page's scripts in a headless Chromium browser and indexes the rendered HTML, so the goal is for both the initial HTML and the rendered version to carry your critical content.

Can Google render JavaScript? #

Yes. A 2024 study by Vercel and MERJ found Google fully rendered 100 percent of eligible pages with a 200 status code, including complex client-side applications.

How long does Google's render queue take? #

The median delay between crawl and completed render is about 10 seconds, though the slowest 1 percent of pages waited around 18 hours in the same 2024 dataset.

Does client-side rendering affect SEO? #

Yes, as added risk rather than a penalty. Content that exists only after JavaScript runs depends on a successful render, reaches users more slowly, and stays invisible to AI crawlers that don't execute scripts.

Do AI crawlers like GPTBot render JavaScript? #

No. Vercel's December 2024 crawler research found that none of the major AI crawlers, including GPTBot, ClaudeBot, and PerplexityBot, execute JavaScript, so content rendered only in the browser is invisible to them. Gemini and AppleBot were the exceptions.

How do I see what Googlebot sees on my page? #

Use the URL Inspection tool in Search Console, open View crawled page, and check the HTML tab, or run a live test and open View tested page. Anything missing there is missing from Google's view of the page.

Is dynamic rendering still recommended for SEO? #

No. Google's documentation describes dynamic rendering as a workaround, not a long-term solution, and recommends server-side rendering, static rendering, or hydration instead.

Can JavaScript remove a noindex tag so the page gets indexed? #

Not reliably. When noindex appears in the initial HTML, Google may skip rendering, so the script that would remove the tag may never run. Leave noindex out of the original page code on any page you want indexed.

Does server-side rendering guarantee my pages get indexed? #

No. It removes the rendering dependency and speeds up discovery, but indexing still depends on content quality, internal linking, and crawlability.

What is the fastest fix for a JavaScript-heavy site? #

Ship critical content, titles, canonicals, and navigation links in the initial HTML through server-side rendering or prerendering, and keep every link a real anchor tag with an href.