JavaScript SEO in 2026: Why Google Renders Your Site and AI Engines Do Not

Here is the uncomfortable version of the JavaScript SEO story in 2026. Your site can rank on the first page of Google and return a blank page to ChatGPT. Google got very good at running your JavaScript. The AI answer engines that increasingly sit between your content and your buyer mostly do not run it at all. If you only optimize for one of those readers, you are leaving the other one staring at an empty page.

This is a working guide to how search engines actually process JavaScript, where it silently breaks, and how to stay visible to both Google and the AI engines. No framework tribalism, just what moves the needle.

How search engines read JavaScript

Google processes a page in two waves. First it crawls the raw HTML and indexes what it finds. Then the URL goes into a render queue, where Google’s Web Rendering Service, an evergreen headless Chromium, runs your JavaScript and indexes whatever the script produced. [1]Google Search CentralJavaScript SEO basicsGoogle documents the two-wave crawl-render-index model and the stateless render (no clicks, scrolls, or logins).View source ↗ The render is stateless. Google does not click, scroll, log in, or accept cookies, so anything gated behind those actions does not exist as far as indexing is concerned.

The practical consequence is simple. If a piece of content only appears after JavaScript runs, it is invisible until that second wave, and it is only ever seen the way a fresh, logged-out browser would see it.

The render queue is real, but not the boogeyman

For years the advice was to fear the render queue. The data says relax, mostly. In a study of more than 37,000 matched page pairs on a large production site, Vercel and MERJ found Google rendered 100 percent of the valid HTML pages it crawled, with a median render delay of about ten seconds, not the hours of folklore. [2]Vercel + MERJHow Google Handles JavaScriptStudy of 37K matched page pairs: Google rendered 100% of valid HTML pages, median render delay ~10 seconds.View source ↗ The tail is real, the ninetieth percentile stretches to a few hours, but for most pages render happens in seconds to minutes.

Two caveats keep this from being a free lunch. Endless no-op query strings and infinite URL variations burn crawl budget on re-rendering pages that did not change. And on very large sites, the render step competes for that budget. Render is cheap per page and expensive at scale.

Four rendering strategies, one rule

Every framework argument comes down to where the HTML gets built. There are four common answers.

• Client-side rendering (CSR). The server sends a near-empty shell and the browser builds everything. Worst case for SEO, and as you will see, catastrophic for AI visibility.
• Server-side rendering (SSR). The server returns finished HTML on every request. Your content is in the first response.
• Static generation (SSG or ISR). Pages are pre-built and served from cache. Best crawl efficiency, content in the HTML, cheap to serve.
• Hydration. Server-rendered HTML that JavaScript then wires up for interactivity. Visible immediately, but the hydration step has a cost you pay in responsiveness.

The one rule that survives every framework debate: anything you need indexed or cited must be in the server HTML before your JavaScript runs. [3]web.devRendering on the WebGoogle-authored guide comparing CSR, SSR, static rendering, and hydration and their SEO tradeoffs.View source ↗ Everything else is a preference.

Dynamic rendering is a dead end

Dynamic rendering, serving a pre-rendered version to bots and the JavaScript app to humans, was Google’s own recommendation for years. It is not anymore. Google now calls it a workaround rather than a long-term solution and steers you toward server-side or static rendering instead. [4]Google Search CentralDynamic RenderingGoogle now calls dynamic rendering a workaround, not a long-term solution, and recommends SSR or static rendering.View source ↗ It is brittle by design: two code paths to maintain, user-agent sniffing to keep current, and constant drift between what the bot sees and what the user gets. Build new work on real server rendering and skip it.

The failure modes that quietly cost you

Most JavaScript SEO problems are not exotic. It is the same short list, over and over. Each one is a symptom with a one-line fix.

• Content that only exists after JS runs. Server-render it, or accept that it is invisible in wave one and to every AI crawler.
• Links built as onClick handlers or router.push calls. Crawlers follow a real href, not a click handler. Use actual <a href> anchors.
• JavaScript, CSS, or APIs blocked in robots.txt. Google cannot render what it is not allowed to fetch. Unblock them.
• Hash routing, the /#/page pattern. The whole app can collapse into a single indexed URL. Use real path-based routes.
• A noindex in the initial HTML that JavaScript later removes. Google honors the noindex it saw first. [1]Google Search CentralJavaScript SEO basicsGoogle documents the two-wave crawl-render-index model and the stateless render (no clicks, scrolls, or logins).View source ↗ Never ship a tag you plan to strip client-side.
• Client-rendered soft 404s and JavaScript redirects. Return real status codes from the server so crawlers get an honest answer.

Core Web Vitals and heavy JavaScript

Two of the three Core Web Vitals are where JavaScript bites. Largest Contentful Paint suffers when a render-blocking bundle or a client-rendered hero delays the main content. Interaction to Next Paint, which replaced First Input Delay as a Core Web Vital in March 2024, [5]web.devInteraction to Next PaintINP replaced First Input Delay as a Core Web Vital in March 2024; it is dominated by main-thread JavaScript.View source ↗ measures how quickly the page responds to input, and it is dominated by main-thread JavaScript work, including the hydration tax. The fixes rhyme: ship less JavaScript, stream server-rendered HTML, and hydrate selectively instead of all at once.

The 2026 problem: AI crawlers do not run your JavaScript

Here is the part that changes the stakes. Googlebot renders JavaScript well. The AI answer engines do not. In network-log analysis across the major AI crawlers, Vercel and MERJ found that no major AI crawler executes JavaScript. GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Meta’s crawler, Bytespider, and CCBot all fetch raw HTML and stop. [6]Vercel + MERJThe Rise of the AI CrawlerNetwork-log analysis: no major AI crawler executes JavaScript. GPTBot fetched JS ~11.5% of the time, ClaudeBot ~23.84%, neither ran it.View source ↗ GPTBot was seen downloading JavaScript files about 11.5 percent of the time and ClaudeBot about 23.84 percent, but neither one ran them. The only engines that render are Gemini, which rides on Googlebot, and AppleBot.

So a client-rendered page can rank on page one of Google and hand a blank body to every major AI crawler. If your goal is to get named in AI answers, and that is exactly the game I break down in my guide to answer engine optimization, then server-rendered HTML is the price of admission. You cannot be cited for content the engine never saw.

Diagnose it yourself, then the checklist

You do not need a lab. Three checks catch most of it.

• Search Console URL Inspection. Compare the raw HTML to the rendered HTML, and use View Crawled Page to see exactly what Google stored.
• The poor-person’s AI-crawler test. Turn JavaScript off in your browser, or just read view-source. Whatever is missing is what GPTBot and its peers see. This single test tells you more than any dashboard.
• Screaming Frog or Sitebulb in JS-rendering mode. Crawl with rendering on and off, then diff the two. Anything that shows up only in the rendered crawl is content at risk.

The checklist is short. Server-render or statically generate anything you want found or cited. Use real anchor links. Never block JavaScript, CSS, or APIs. Keep noindex, canonical, and title tags correct in the server HTML. Ship less JavaScript and watch LCP and INP. Then verify with URL Inspection and a JavaScript-off read.

Build for the stricter reader. If the AI engines can see your content without running a single line of your code, Google certainly can too. Ranking and getting cited stop being two separate problems and start being one.

Frequently asked questions

Does JavaScript SEO still matter if my site already ranks well on Google?

Yes. Google may render your JavaScript without trouble, but the AI answer engines that increasingly sit between your content and your buyer do not run it. A page can rank on Google and still be invisible to ChatGPT, Claude, and Perplexity, so “we rank fine” no longer means “we are visible everywhere that matters.”

Is a single-page app or headless build bad for SEO?

Not by itself. The deciding factor is whether your content arrives in the server’s response. A single-page app that server-renders or pre-renders its content is fine. A purely client-rendered one that ships an empty shell and builds everything in the browser is the risky case, both for Google’s render queue and for AI crawlers that never render at all.

Does prerendering help with AI search visibility?

For AI crawlers, yes. Because they read raw HTML and never run your JavaScript, serving prerendered or static HTML is exactly what makes your content visible to them. This is a different question from Google, which renders JavaScript itself and now treats dynamic rendering as a workaround rather than a long-term solution.