Can ChatGPT read JavaScript? The 2-minute test for your site

Your site looks perfect in a browser, ranks on Google, and still never gets cited by ChatGPT. One of the most common reasons is invisible from the outside: the content is built by JavaScript in the visitor’s browser, and AI crawlers don’t run JavaScript.

Here’s what AI crawlers actually see, a 2-minute test to check your own site, and how to fix it on the most common setups.

What AI crawlers actually do with JavaScript

Vercel looked at crawler traffic across its network in late 2024. In one month, GPTBot made 569 million requests and Anthropic’s crawler 370 million. Both downloaded JavaScript files, but neither ran a single line. Vercel’s advice was blunt: “ChatGPT and Claude don’t execute JavaScript, so any important content should be server-rendered.”

In practice that means an AI crawler sees your page the way it looks with JavaScript switched off:

The same study found both crawlers hit missing pages a lot: about 34% of their fetches returned 404 errors. So broken links and missing redirects cost you here too.

Why your site can rank on Google and still be blank to ChatGPT

Google renders JavaScript. Its documentation says “a headless Chromium renders the page and executes the JavaScript” before indexing. So a client-rendered page can rank fine on Google, and Google’s AI Overviews can use it, while ChatGPT’s crawler sees nothing.

Even Google recommends not relying on that: “server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” AI search crawlers are exactly the bots it means.

Why this costs you more in AI answers than in SEO

In classic SEO, a page that Google couldn’t fully render might rank a bit lower. In AI answers the cost is sharper: if the crawler can’t read the text, there’s nothing to quote, so the page can’t be a source at all.

And the pages most likely to rely on JavaScript are the ones AI answers lean on most. Comparison and alternatives content took 33% of all citations in Something Inc’s study of 4,100 B2B queries, and product pages and docs another 18%. Those are exactly the pages that tend to use interactive pricing tables, feature toggles and tabbed comparisons.

There’s a second cost. When ChatGPT can’t read your pricing page, it doesn’t say “I don’t know your price”. It uses whatever it can find: an old review, a competitor’s comparison, a listicle from last year. Buyers then arrive with the wrong number. Getting your own pages readable is how you make sure the facts AI repeats about you are yours.

The 2-minute test

Run any of these on your three most important pages: the homepage, your main product page, and a comparison or pricing page.

Test 1: View source (30 seconds). Open the page, right-click and choose View Page Source (or press Ctrl+U / Cmd+Option+U). Press Ctrl+F and search for a sentence from the middle of the page. Found it? That text is in the server HTML. Not found? It’s loaded by JavaScript.

Test 2: Turn JavaScript off (1 minute). In Chrome, open DevTools, press Ctrl+Shift+P (Cmd+Shift+P on Mac), type “Disable JavaScript” and press Enter, then reload. What you see now is roughly what an AI crawler sees.

Test 3: Fetch it like a crawler (1 minute). In a terminal, request the page with an AI crawler’s user agent and search the result:

curl -s -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" https://yoursite.com/pricing | grep -i "a sentence from your page"

No output means the crawler didn’t get that text. This test also catches a second problem: if the command returns a 403 error or a challenge page, your CDN or firewall is blocking the crawler before it ever sees your HTML.

Write down the result for each page as pass or fail. If all three pages pass, you’re in good shape and can move on to content and mentions. If any fail, the rest of this guide shows what to check and how to fix it.

What to check on each page

Pricing and comparison pages are where a failure hurts most, because they’re exactly the pages AI answers cite for buying questions. Fix those first.

How to fix it, by setup

Next.js, Nuxt, SvelteKit, Remix, Astro. These frameworks render on the server by default. The problems usually come from components marked as client-only that fetch their own data. Move data fetching to the server (server components, getServerSideProps, loaders) or pre-render the page at build time.

React, Vue or Angular single-page apps. Out of the box these send an almost empty HTML file. Options, from most to least effort: move to a framework with server rendering, add server-side rendering to the existing app, or use a pre-rendering service that serves static HTML snapshots to crawlers.

WordPress, Webflow, Shopify, Squarespace. These mostly serve real HTML already. Problems come from plugins and embeds: pricing tables, review widgets, tabbed content and page builders that load content with scripts. Check those specific blocks with view-source.

Any setup. Keep important text out of images, avoid “load more” buttons for key content, and make sure tabs and accordions contain their text in the HTML even when collapsed.

Whichever route you take, you don’t have to give up interactivity. The goal is for the content to exist in the first HTML response; JavaScript can still add filters, toggles and animations on top. A pricing table that’s real HTML and becomes interactive once scripts load works for buyers, Google and AI crawlers alike.

Hidden culprits: patterns that quietly empty your page

Even sites that render on the server often have a few blocks that don’t. These are the usual suspects:

• Skeleton loaders. Grey placeholder boxes that get replaced by real content after an API call. The crawler only sees the boxes.
• Personalisation and A/B testing tools. Scripts that swap headlines or pricing after load. The crawler sees the original, or nothing.
• Consent and cookie managers that hold back page content until a visitor clicks “accept”.
• Lazy-loaded sections that only load when scrolled into view, such as feature grids, logos and FAQs further down the page.
• Language switching in the browser, where translated text is loaded by script rather than served on its own URL.
• Embedded comparison or pricing widgets from third-party tools, which often render inside an iframe or with their own JavaScript.

Run the view-source test on a page you think is fine and check each of these blocks. It’s common to find the hero and intro rendered properly while the comparison table or FAQ halfway down the page is missing.

How to brief your developer

“Make it work for AI” isn’t a ticket a developer can act on. Give them the specific pages, the specific content, and a test they can run themselves:

Title: Render key content in server HTML so AI crawlers can read it

Why: AI search crawlers (OAI-SearchBot, PerplexityBot, Claude-SearchBot) don’t run JavaScript. Content added after load is invisible to them.

Pages:
- /pricing: plan names, prices and feature table
- /compare/[rival]: comparison table and verdict
- /faq: all answers (keep collapsed with CSS if needed)

Done when: each item above appears in View Page Source, and
curl -A "OAI-SearchBot" https://yoursite.com/pricing | grep "[plan name]"
returns a match with a 200 status.

Include the “done when” test. It turns a vague request into something with a clear finish line, and it gives you a way to check the work.

Keep it fixed: add the check to every release

Rendering problems come back. A new pricing widget, a redesign or a plugin update can quietly move content back into JavaScript. Two habits stop that:

1. Add the view-source check to your launch checklist for any page that matters for buying questions: pricing, comparisons, product pages and key guides.
2. Check your server logs monthly for AI crawler visits and their status codes. Lots of 200s on your key pages is good. 403s mean a bot block; 404s mean broken links worth redirecting.

# AI crawler requests to your site, with status codes
grep -E "OAI-SearchBot|GPTBot|PerplexityBot|ClaudeBot|Claude-SearchBot" access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head -30

Two more things that block AI crawlers

1. robots.txt. OpenAI says sites that block OAI-SearchBot “will not be shown in ChatGPT search answers”. Check your robots.txt allows it, along with PerplexityBot and Claude-SearchBot.
2. CDN and firewall bot settings. Cloudflare and other providers can block AI crawlers even when robots.txt allows them. Test 3 above shows you whether that’s happening.

And skip llms.txt as a workaround. It doesn’t fix rendering, and four studies found AI crawlers almost never read it.

A 30-minute action plan

1. Run Test 1 on your homepage, product, pricing and top comparison page (5 min).
2. Run Test 3 on the same pages to rule out CDN blocking (5 min).
3. List every element that failed, using the table above (10 min).
4. Send the list to your developer with “render this on the server” as the ask (5 min).
5. Recheck in two weeks, then run your buyers’ prompts in ChatGPT to see if those pages start getting cited (5 min). Our citation playbook covers what to do next.

Common mistakes

• Assuming “it ranks on Google” means it’s fine. Google renders JavaScript; AI crawlers don’t.
• Testing only the homepage. The pages AI cites for buying questions are usually deeper: pricing, comparisons, guides.
• Putting prices in a widget. If buyers ask ChatGPT about your pricing, it needs to read your pricing page.
• Hiding FAQs behind clicks. Answers that load on click are invisible to crawlers. Put them in the HTML and collapse them with CSS.
• Fixing rendering but leaving a bot block in place. Always run the crawler test too.