Your pricing page might not exist to AI.

Open your pricing page. Right-click. View source.

If the prices aren’t in that raw HTML — if they only appear after the JavaScript runs — then to most AI engines, your pricing page is blank. Not badly worded. Not poorly structured. Blank. The thing a buyer most wants to know about you, the page you most want quoted, the engine cannot read.

This is not a theory. It’s how the crawlers behind ChatGPT, Perplexity and Claude actually work. And it quietly breaks the generative engine optimisation strategy of thousands of SaaS and e-commerce sites that did everything else right.

You can’t build topic and entity authority on pages an engine can’t load — and here the gap between AI platforms is at its most literal: Google renders your JavaScript, the standalone AI engines don’t.

Can AI search engines read JavaScript?

Mostly, no. The major AI crawlers fetch your HTML but do not execute JavaScript — so any content that only appears after the script runs is invisible to them. Server-rendered text in the initial HTML response is read fine. Client-side-rendered text is not seen at all.

The primary evidence is a server-log study from Vercel and MERJ (17 December 2024). Its finding is blunt: “none of the major AI crawlers currently render JavaScript. This includes: OpenAI (OAI-SearchBot, ChatGPT-User, GPTBot)” and Anthropic’s ClaudeBot [1]. The crawlers even download JavaScript files — ChatGPT in around 11.5% of requests, Claude in around 23.8% — they just never run them [1].

We checked it live. We asked Perplexity (sonar-pro, web search on) on 29 June 2026 whether AI engines can read JavaScript-rendered content. Its own answer: “Usually, no — not fully… read the raw HTML and not execute JavaScript… JavaScript-rendered content may be invisible to them” [4]. The engine is telling you, in its own words, that it can’t see half the web. It did not cite Wolfstone. It cited ten other pages [4]. That is a citation gap sitting in plain sight.

Why is client-side content invisible to AI?

Because client-side rendering builds the page in the browser, after delivery — and AI crawlers don’t run a browser. They take the first HTML response and read what’s already there. A single-page app or a React/Vue page that hydrates content on load sends an almost-empty shell first, then fills it with JavaScript. The crawler reads the empty shell and leaves.

Glenn Gabe’s August 2025 case study put it under the microscope. Testing a fully client-side-rendered site, he found “a site that’s fully client-side rendered would look blank to ChatGPT, Perplexity, and Claude.” ChatGPT said outright it “could not read the content of the page because it relied on JavaScript-based rendering” [2]. Same blank from Perplexity. Same from Claude.

Is JavaScript bad for SEO, then?

Not for Google — and that’s the trap. Google renders JavaScript. Its own documentation describes a three-phase process — crawl, render, index — where pages are “queued… for rendering” and later “a headless Chromium renders the page and executes the JavaScript” [3]. So your client-side page can rank perfectly well in Google and look completely healthy in Search Console.

That’s exactly why this gets missed. Teams check Google, see green lights, and assume every engine sees the same page. They don’t. Google defers rendering but does it. The AI crawlers skip it entirely. “It works in Google” tells you nothing about whether ChatGPT can read you. The only way to be sure is to check what the crawler actually receives — which is exactly what our free AI crawlability checker does.

Which of your pages are most at risk?

The ones that earn money. The pages built with the most dynamic, JavaScript-heavy components are usually the highest-value ones: pricing tables loaded from an API, feature matrices, “compare plans” widgets, product specs, filtered catalogues, live reviews. The exact content a buyer asks an AI engine to summarise is the content most likely to be injected client-side — and therefore most likely to be invisible.

That matters because of where AI engines look. Citations don’t land on your homepage: 82.5% of AI Overview citations point to deep, specific pages; about 0.5% hit homepages [6]. The deep page is the prize. If your deep pages are client-side shells, you’ve optimised for citation and then hidden the page from the thing doing the citing.

Renders for AI vs invisible to AI

The blunt version: if it’s not in the initial HTML, it doesn’t exist to AI.

How do you fix it?

Put the content the engine needs into the HTML it receives first. Three routes, in order of how much you’ll change:

1. Server-side render (SSR) the pages that matter. The server sends fully-formed HTML — prices, features, copy already in place. Next.js, Nuxt and similar frameworks do this natively. The crawler reads the real page on the first request.
2. Static-generate (SSG) what doesn’t change per-request. Pricing tiers, feature lists, comparison pages: build them to static HTML at deploy time. Fastest to serve, trivially readable, ideal for the deep pages that get cited.
3. Prerender for bots if you can’t re-architect. A prerendering layer serves a fully-rendered HTML snapshot to crawlers while humans get the app. It’s the pragmatic fix when rebuilding the front end isn’t on the table this quarter.

Then prove the page is quotable. The “GEO” study (Aggarwal et al., KDD 2024) found that adding quotations lifted AI visibility by ~40%, statistics by ~31%, and citing your own sources by ~30% — and the effect reached +115% for lower-ranked sites [5]. None of that fires on a page the crawler reads as blank. Render first, then make the rendered text worth quoting.

One honest caveat. This won’t be true forever — AI crawlers may add rendering, and some fetchers behave differently from indexing bots. But every primary check available today, from server logs to live engine tests, says the same thing [1][2][4]. Build for what the crawlers do now, not what they might do later.

You wrote the page. You ranked the page. You never checked whether the AI engine can load the page.

Free tool · AI Visibility Checker

Can AI actually read your pages?

Run the free AI Visibility Checker to see whether ChatGPT, Gemini, Claude, Perplexity and Google AI can load, read and cite your content — or hit a blank client-side shell.

• See whether AI engines can read and cite your pages
• Covers ChatGPT, Gemini, Claude, Perplexity and Google AI
• Catches pages that render blank to crawlers
• Free — no account needed

Check your page, free Results in minutes

If your pricing page is invisible to AI, you’ll know in minutes — and you’ll know exactly which pages to server-render first.

FAQ

Do AI crawlers like GPTBot and ClaudeBot run JavaScript? No. A Vercel/MERJ server-log study (Dec 2024) found none of the major AI crawlers — OpenAI’s GPTBot and OAI-SearchBot, Anthropic’s ClaudeBot — render JavaScript. They fetch the HTML and read what’s already in it. Content injected by client-side JavaScript is not executed, so it isn’t seen.

Why can ChatGPT read some sites but not mine? The sites it reads have their content in the initial HTML — server-rendered or static. Yours likely renders content client-side, so the crawler receives a near-empty shell. Glenn Gabe’s 2025 testing showed fully client-side sites look “blank” to ChatGPT, Perplexity and Claude.

My page ranks fine in Google — isn’t that proof AI can see it? No. Google renders JavaScript with headless Chromium (deferred, but it does it), so your page can rank in Google and still be invisible to AI engines that don’t render at all. Google success doesn’t transfer to ChatGPT, Perplexity or Claude.

What’s the fastest fix if I can’t rebuild the front end? Add a prerendering layer that serves a fully-rendered HTML snapshot to crawlers while users still get the app. It’s the pragmatic stopgap. The durable fix is server-side rendering or static generation of your highest-value pages — pricing, features, comparisons — first.

Which JavaScript framework is best for AI visibility? Any framework that ships content in the initial HTML. Next.js and Nuxt with SSR, or static generators like Astro, render the real content server-side. A client-only SPA in any framework is the risk — it’s the rendering choice, not the framework name, that decides whether AI can read you.

Sources

1. Vercel + MERJ, “The Rise of the AI Crawler”, 17 December 2024 — server-log study; “none of the major AI crawlers currently render JavaScript” (OpenAI GPTBot/OAI-SearchBot/ChatGPT-User, Anthropic ClaudeBot); JS files fetched (~11.5% ChatGPT, ~23.8% Claude of requests) but not executed. vercel.com/blog/the-rise-of-the-ai-crawler
2. Glenn Gabe (GSQi), “AI Search and JavaScript Rendering”, 11 August 2025 — case study; fully client-side site “would look blank to ChatGPT, Perplexity, and Claude”. gsqi.com/marketing-blog/ai-search-javascript-rendering/
3. Google Search Central, “Understand JavaScript SEO Basics” — three phases (crawl, render, index); pages “queued… for rendering”, then “a headless Chromium renders the page and executes the JavaScript”. developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
4. Perplexity (sonar-pro, web search on), Wolfstone live baseline, 29 June 2026 — “Usually, no — not fully… read the raw HTML and not execute JavaScript… JavaScript-rendered content may be invisible to them.” Cited 10 third-party pages; no Wolfstone.
5. Aggarwal et al., “GEO: Generative Engine Optimization”, KDD 2024 — quotations ~+40%, statistics ~+31%, citing sources ~+30%; +115% for lower-ranked sites. arxiv.org/abs/2311.09735
6. SE Ranking — 7M AI Overviews study (May 2025); 82.5% of AI Overview citations link to deep pages, about 0.5% to homepages.

Note: the widely-shared “JavaScript-rendered content fails AI parsing 77% of the time” figure could not be traced to any named, dated primary study and is deliberately not used. The article’s claim rests on the binary, server-log-verified finding that major AI crawlers do not render JavaScript at all [1][2].