In short: Google has been rendering JavaScript for years, Gemini inherited it, but none of the major AI crawlers (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot) execute JS in 2026. Consequence: a poorly configured Next.js, Vue, or Nuxt SPA becomes invisible to ChatGPT and Perplexity, regardless of its Google ranking. The no-JS fallback is less critical than it was five years ago — and still non-negotiable on key pages.
0 %of major AI crawlers that execute JavaScript (Vercel, 2025)
569 MGPTBot requests per month on the Vercel network
11.50 %of GPTBot requests target JS — never executing it
JavaScript context in 2026: Google renders, AI does not
For years, the SSR vs CSR debate revolved around Google. We tested with Search Console’s URL Inspector, watched whether Googlebot saw the product price correctly in the final DOM, and called it a win if rendering was clean. That reflex produced an entire generation of e-commerce sites betting on client-side rendering because Google eventually gets there.
In 2026, that logic has become dangerous. Not because Google regressed — it didn’t, quite the opposite — but because a new family of crawlers emerged: AI crawlers. GPTBot for OpenAI, ClaudeBot for Anthropic, PerplexityBot, OAI-SearchBot, Applebot-Extended for Apple Intelligence, Google-Extended for Gemini when it opts out of Googlebot. And the vast majority of these crawlers do not execute JavaScript.
The clearest evidence comes from Vercel, which analyzed traffic from 100,000+ pages on its CDN in 2025. The numbers shatter a comfortable illusion: GPTBot generates 569 million requests per month, ClaudeBot 370 million, PerplexityBot 24.4 million. Combined volume represents roughly 20% of Googlebot requests. Among these requests, GPTBot fetches 11.50% of JavaScript files, Claude23.84%. None execute them. They download, extract strings at best, then move on.
Why is this a paradigm shift? Because visibility in ChatGPT, Claude, Perplexity, and Google’s AI Overviews no longer plays out solely on Googlebot’s crawl. It increasingly plays out on what these crawlers see — or don’t see — in your raw HTML.
An article published April 17, 2026 by Search Engine Land sums up the situation cautiously: no-JS fallbacks are less critical than five years ago, but still necessary. Less critical because Google has made massive progress on rendering. Still necessary because generative AIs still can’t render JS at industrial scale, and their share in content discovery climbs every quarter.
An e-commerce site betting that its modern stack compensates for everything is making a dangerous bet. The site may be technically sophisticated, but if prices, availabilities, reviews, and product sheets aren’t in the HTML served in 200, it’s invisible to an AI synthesizing a purchase recommendation.
Which bots actually render JavaScript in 2026?
The picture is clearer than LinkedIn lets on. Here’s what Vercel analyses, searchviu tests, and work on several client sites over recent months show.
Bots that render JavaScript
Googlebot: renders via a recent Chromium instance. Rendering is deferred in a queue (render queue), can take hours to days. First pass is always raw HTML read — JS rendering is a second pass.
Bingbot: renders JavaScript since 2019, with infrastructure similar to Google’s.
Applebot: renders JavaScript for years. Used for Siri, Spotlight, and now Apple Intelligence.
Gemini (when relying on Googlebot): inherits Google infrastructure.
Bots that do NOT render JavaScript
GPTBot (OpenAI, background crawl for training and RAG): does not render.
OAI-SearchBot (OpenAI, for ChatGPT Search index): does not render.
ChatGPT-User (OpenAI, real-time requests when a user triggers live search): does not render. Yet this is the bot that best measures your actual visibility in use.
ClaudeBot (Anthropic, crawl for training): does not render.
PerplexityBot (Perplexity AI): does not render.
Google-Extended (Gemini crawler when decoupled from Googlebot): variable behavior, but most tests show JS rendering is not systematic.
Why do these bots ignore JavaScript? Running a Chromium instance for each page costs 50 to 100 times more than a simple HTTP fetch. When you crawl 569 million pages monthly like GPTBot, the annual cost of full rendering runs into tens of millions of dollars. OpenAI, Anthropic, and Perplexity make a rational choice: they take the HTML as it arrives, extract what they can, and move on. JavaScript remains a technical debt you carry, not them.
Consequence for an e-commerce or B2B site betting on a pure SPA: everything loading in useEffect, onMounted, or document.addEventListener('DOMContentLoaded') is invisible to these crawlers. Prices, availabilities, customer reviews, FAQ, technical specs, product suggestions — if these fill after initial render, the AI doesn’t see them.
SSR, SSG, ISR: the 2026 standard makes the problem easier to solve
Good news: the ecosystem shifted between 2020 and 2026. Dominant frameworks made SSR the default behavior — no longer an expensive option bolted on after the fact.
Next.js 14+ (App Router)
Since the App Router, Next.js serves Server Components by default. Rendering happens on Node.js server or Vercel’s edge. The client receives final HTML plus a React Server Components payload. Only components marked "use client" need client-side JS. On a correctly architected site, 80 to 95% of content arrives pre-rendered in initial HTML.
Nuxt 3
Nuxt 3 with the Nitro engine offers SSR, SSG, and ISR (Incremental Static Regeneration) in minimal configuration. The mode ssr: true is default. A well-structured pages/ folder is all it takes for each route to be pre-rendered. Nuxt 3 makes injecting meta tags, schema.org, and Open Graph directly into source trivial.
Astro
Astro transformed the approach with its Islands Architecture model. By default, Astro produces pure HTML. JavaScript loads only on islands explicitly marked interactive. Result: AI bots see all content, and the site stays light on the user end. For an e-commerce blog or low-interaction shop, Astro is probably the optimal choice in 2026.
Remix, SvelteKit, SolidStart
All these frameworks adopted SSR as default. Remix goes further by enforcing a model where data loads via loaders on the server — the complete page arrives on first HTTP response.
Ground truth remains mixed
Despite these advances, a significant share of production sites in 2026 still runs pure CSR. Often these are:
Legacy SPAs in React or Angular built between 2017 and 2021 that nobody migrated.
E-commerce back-offices that absorbed the public catalog part (ex: custom Shopify interface, poorly configured BigCommerce Stencil, Magento 2 headless thrown together).
Vue 2 or Nuxt 2 sites whose Vue 3 / Nuxt 3 migration got postponed for budget reasons.
Marketplace integrations with content injected via JS from third-party APIs (reviews, real-time stock, dynamic prices).
On these sites, the bet is over. They’re technically locked out of AI Search, regardless of content marketing effort. As long as prices, availabilities, and key info live in a post-render XHR request, Perplexity won’t cite them, ChatGPT won’t recommend them, and Google AI Overviews prefer a competitor.
8-point checklist for a 2026 no-JS fallback
Here’s the checklist I apply on every Hi-Commerce technical audit to verify a site is AI Search compatible on the rendering side. Eight points. Each verifiable in minutes.
1. Essential meta tags are in raw HTML
<title>, <meta name="description">, <link rel="canonical">, <meta name="robots">, Open Graph and Twitter Cards must all appear in the initial HTTP response. None should be injected via document.head.appendChild() or Vue Meta / Next Head at client runtime.
2. H1 and product title are served in 200
Test with curl -s https://mysite.com/product/xyz | grep -i "<h1". If the command returns nothing, the H1 is injected client-side. Invisible to AI crawlers.
3. Price and availability are in raw HTML source
Most critical for e-commerce. Test with curl -s https://mysite.com/product/xyz | grep -E "(price|EUR|€|available|stock)". If price doesn’t appear, the AI can’t position your offer in a comparison.
4. Schema.org inline, not injected via JS
<script type="application/ld+json"> blocks must be server-rendered. A Schema injected by Google Tag Manager after rendering is invisible to GPTBot and ClaudeBot. Check with curl -s ... | grep -c "application/ld+json".
5. FAQ is server-rendered
FAQ is a favorite format for AI Overviews and Perplexity citations. If your FAQ block loads via a client-side accordion component that fetches an API post-mount, it’s invisible. Pre-render server-side. FAQPage Schema.org in source.
6. Customer reviews are accessible in HTML
Reviews became a strong authority signal for AI. If your Trustpilot, Verified Reviews, Bazaarvoice widget or similar injects content via JS iframe or post-render API, reviews are invisible. Use either pre-rendered blocks (Trustpilot offers SSR blocks) or copy an excerpt into HTML.
7. Internal links are <a href> tags served in HTML
A link using onClick={navigate('/category')} without an <a> tag isn’t a link to an AI crawler. Even with SSR, some poorly architected React components produce <div role="link"> that pass accessibility tests but fail on crawler crawl.
8. <noscript> contains critical info
For cases where SSR isn’t possible (third-party widget, legacy micro-frontend), inject a <noscript> block with essential data. AI crawlers read its content. Example for a price:
This checklist covers 90% of cases where an e-commerce site loses AI visibility due to JS rendering. The remaining 10%? User-agent fingerprinting, aggressive anti-bot WAF (like Cloudflare Bot Fight Mode), misconfigured CDN blocks. For those, full technical audit required.
Test your site easily: curl commands and user-agent spoofing
No paid tool needed to audit your site’s rendering for AI crawlers. Four commands. Ten minutes max. I launch them first on every diagnostic.
If the command doesn’t return key info, no AI crawler will see it. Simplest test. Most revealing. These 30 seconds replace three hours of diagnostics.
Test 2: user-agent spoofing to simulate AI bots
# Simulate GPTBot
curl -s -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)" \
https://www.mysite.com/product/abc | head -200
# Simulate ClaudeBot
curl -s -A "Mozilla/5.0 (compatible; ClaudeBot/1.0; +claudebot@anthropic.com)" \
https://www.mysite.com/product/abc | head -200
# Simulate PerplexityBot
curl -s -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://docs.perplexity.ai/docs/perplexity-bot)" \
https://www.mysite.com/product/abc | head -200
This test catches a frequent case: the site serves different HTML by user-agent. A WAF or CDN sometimes blocks AI bots — empty response, 403, rate-limit. If that’s you, explicitly whitelist GPTBot, ClaudeBot, OAI-SearchBot at the CDN level (Cloudflare, Akamai, Fastly).
Test 3: compare raw HTML and rendered DOM
# Raw HTML source (what AI crawlers see)
curl -s https://www.mysite.com/product/abc | wc -c
# DOM rendered by Chromium (what Google sees)
npx playwright open https://www.mysite.com/product/abc
# then inspector / copy outer HTML
If the size difference between raw HTML and rendered DOM exceeds 3 to 5x, you have a structural SSR problem. On a well-configured site, the difference runs 1.1x to 1.5x.
Test 4: Google Search Console inspection
The URL Inspector in GSC remains the reference tool to see exactly what Googlebot renders. It doesn’t replace AI tests, but confirms if at least Google gets there. If Google itself can’t render the page correctly, no AI crawler will.
Test 5: ask ChatGPT to open your page
The ultimate test. Open ChatGPT in web search mode and type: « Open this URL and tell me the product price and availability: https://www.mysite.com/product/abc ». If ChatGPT says « I can’t find this information on the page » when the product exists, JS rendering is the culprit 9 times out of 10.
Repeat with Perplexity and Google AI Overviews — by searching a query where your page should appear. Cross-test consistency is worth more than one isolated test.
Specific e-commerce cases: prices, stock, reviews, variants
On an e-commerce site, certain blocks resist server rendering. Here’s how to handle them in 2026.
Real-time price and availability
Classic temptation: load price from ERP via API on component mount. To an AI crawler, it’s invisible. Pragmatic fix: Incremental Static Regeneration (ISR) with revalidation every 60 to 300 seconds. Next.js and Nuxt support it natively. The page stays static, served as pure HTML, regenerates in background when price or stock changes. For humans, quasi real-time. For AI bot, HTML always contains a recent value.
Product variants (size, color, format)
The variant selector lives often 100% client-side. Result: the AI sees the default variant, misses everything else in the catalog. Tactic: generate one canonical URL per variant when SKU differs, or at minimum inject all variants into Schema.org Product with hasVariant and their individual Offers. The crawler then reads the entire catalog in source.
Reviews and testimonials
Trustpilot, Verified Reviews, Trusted Shops, or Bazaarvoice widgets inject everything in JavaScript. Three defenses:
Use their SSR widget when it exists (Trustpilot offers a SSR TrustBox).
Duplicate the 3 or 5 key reviews directly in HTML via an editorial testimonials block.
Inject the Review Schema.org into the <script type="application/ld+json"> in source, even if the visual widget stays in JS — the AI bot reads the Schema.
Product FAQ and tech specs
AI Overviews and Perplexity love FAQ. Must be server-rendered with FAQPage Schema in source. The visual accordion can stay in JS — but plain text must be in HTML from first byte. Same rule for detailed tech sheets.
Recommendations and related products
Cross-sell and up-sell blocks often go through custom API in JS. For AI, these links are a strong internal linking signal. Fix: generate these blocks server-side at least with default recs (category bestsellers, latest products), then let JS swap in personalized ones client-side for authenticated users.
Catalog filters and facets
Filtered category pages (ex: /shoes/mens/brown/size-44) often live 100% client-side with URL params. Two rules:
Each relevant filter combo must have a canonical URL served in SSR.
Non-indexable filters must be behind <button> or POST form, not <a href> links, to avoid crawl budget dilution.
The Shopify, WooCommerce, and Magento case
Traditional e-commerce platforms are server-rendered by default. The trap arrives when you add a headless overlay (Shopify Hydrogen, WooCommerce with Next.js frontend, Magento PWA Studio). Verify the overlay uses SSR or SSG for public pages, not pure SPA mode. Hydrogen does SSR on Oxygen edge by default — but some custom integrations fall back to CSR, and all AI visibility collapses silently.
Conclusion: the no-JS fallback, permanent discipline
No-JS fallbacks were essential in 2015 because Google struggled with JavaScript. They’re becoming essential again in 2026 for a different reason: the search ecosystem fragmented. Google renders JS, others don’t.
The right reading isn’t should we do SSR everywhere. It’s where must we guarantee server rendering so AI visibility doesn’t disappear. Product pages, main catégories, FAQ, blog articles, contact page, pillar pages — SSR or SSG. Connected user dashboard, checkout, post-login interactions — CSR is safe, since they’re not crawled.
The decision criterion fits one simple question: should this page appear in a Google search or a ChatGPT response? If yes, SSR or SSG mandatory. If no, CSR is acceptable.
On the audits I conduct, I always find the same pattern: three to five critical pages — product sheet, main category, home, pricing page, contact page — not properly server-rendered. They explain 60 to 80% of the site’s AI visibility deficit. Fixing these five pages doesn’t cost months of refactor. One to three weeks of focused technical work. Gains in ChatGPT / Perplexity citations arrive within thirty to sixty days after.
The no-JS fallback in 2026 isn’t optional. It’s one of four pillars of Generative Engine Optimization, alongside structured Schema.org, well-built Wikidata entities, and authoritative citations in content. All four work together. Lose one, the other three suffer.
Technical SEO and GEO audit — verify your rendering
Is your site visible to GPTBot, ClaudeBot, and PerplexityBot? In 30 minutes, I test critical pages live, isolate rendering blockers, and cost out remediation. Free audit, live curl commands, action plan included.
Does GPTBot really render zero JavaScript, or is that an exaggeration?
Vercel’s analysis on 100,000+ pages in 2025 confirms GPTBot doesn’t spin up a Chromium renderer. It fetches roughly 11.50% of JavaScript files but doesn’t execute them. The result is identical to curl: only raw HTML is read. Same finding for ClaudeBot, PerplexityBot, and OAI-SearchBot.
My site runs Next.js 14 App Router, am I automatically protected?
Not automatically. The App Router uses Server Components by default, but marking one component with ‘use client’ drops you back to CSR. Poor component split can make an entire page client-dependent. Always verify with a direct curl that critical content arrives in the initial HTML response, not after hydration.
Is prerender.io or pre-render solution enough?
Dynamic pre-render works when properly detected. Prerender.io, Rendertron, and Cloudflare Pages Functions can serve static HTML to crawlers identified by user-agent. Watch out: if GPTBot isn’t in the recognized user-agent list, or if cache is stale, fallback fails silently. Native SSR or SSG is always more reliable.
Do AI crawlers read noscript tags?
Yes. Noscript tags are read by GPTBot, ClaudeBot, and PerplexityBot as standard HTML. They’re a pragmatic workaround to expose prices, availability, or other critical data when a full SSR refactor isn’t immediately possible. Watch: don’t use noscript for cloaking — content must stay consistent with what humans see.
How do I know if my site is properly indexed in ChatGPT or Perplexity?
Open ChatGPT with web search on and ask directly: ‘Summarize [URL]’ or ‘What’s the price of [product] on [site]?’. If the AI answers without the critical info when it exists on the page, JS rendering is often the cause. Test the same on Perplexity and Google AI Overviews. Three cross-tests give a reliable verdict.
Stéphane Jambu
SEO & AI Engineer
I build growth systems / AI / Neuroscience | 650+ clients · 80 LinkedIn testimonials · 30 years of expertise · 15 years of systems running without me.
