Do AI Crawlers Render JavaScript? What GPTBot Sees

You published a page, it renders fine in your own browser, but three months later it still doesn't show up in a ChatGPT or Perplexity answer. If the same page ranks fine in Google, the usual excuses — thin content, no backlinks — don't fit. The real cause is often simpler: the AI crawler that fetched the page never saw the part of the content that JavaScript added after the initial load. It graded an empty shell.

GPTBot is OpenAI's crawler for ChatGPT's browsing and retrieval features, and like most AI bots it requests a URL, reads whatever the server hands back in that one response, and moves on. It does not open a browser engine and wait for scripts to run. That single fact explains a large share of "why isn't my site cited" tickets, so it's worth answering directly.

Do AI Crawlers Render JavaScript?

No. GPTBot, ClaudeBot, PerplexityBot, and Applebot-Extended all fetch the raw HTML response and do not execute JavaScript, based on each vendor's published crawler documentation. If your headline, main content, or FAQ block is injected by React, Vue, Angular, or a client-side script after the page finishes loading, none of these four crawlers ever see it.

This is different from how Googlebot works. Googlebot fetches the raw HTML first, queues the page, and later runs it through a separate rendering pass that does execute JavaScript. That two-step process is why a page can rank in Google while still being invisible to an AI crawler that only performs the first step.

Which AI Crawlers Are We Talking About?

Five user agents cover almost all AI-driven traffic to a typical site today. Each behaves differently enough that lumping them together leads to wrong conclusions.

Google-Extended is worth a separate note because it does not crawl on its own. It's a permission flag that tells Google whether it may reuse content Googlebot already fetched and rendered for search. That's why Google-Extended is the one entry in the table that behaves differently from the rest — it inherits Googlebot's rendering, the other four do not. For a breakdown of how each of these five user agents is treated elsewhere on the site, see the AskEO blog.

How Client-Side Rendering Hides Your Content

A server-rendered page sends complete HTML on the first response — headings, paragraphs, and FAQ text are already in the markup. A client-rendered page often sends a near-empty shell plus a bundle of JavaScript, and the browser builds the visible page after that script runs. A human never notices the gap because the browser does the work in under a second.

A crawler that skips the JavaScript step reads only that near-empty shell. It sees a title tag, maybe a loading spinner's markup, and a script reference — not the article, not the pricing table, not the FAQ answers a person actually asked about. The page can look complete and still hand a crawler almost nothing to cite.

How Do You Check What a Crawler Actually Sees?

You don't need to guess. A five-minute check on any page tells you whether it's a client-rendering problem before you touch any code.

1. Fetch the page with a bot-style request: curl -A "GPTBot" https://yoursite.com/page and read the raw response.
2. Compare that raw HTML against what you see in the browser's "View Page Source" (not "Inspect Element," which shows the rendered DOM, not the server response).
3. Search the raw HTML for one exact sentence from your main content — if it's missing, it was added by JavaScript.
4. Open browser devtools, disable JavaScript, and reload the page to see the same shell a non-rendering crawler sees.
5. Count words in the raw response versus the rendered page; a large gap confirms the content depends on client-side rendering.

Fixing It: Server-Side Rendering, Static Generation, or Prerendering

Checking every template by hand with curl, view-source, and devtools gets tedious once a site has more than a handful of page types — that's the exact crawlability check AskEO runs automatically as part of every scan, alongside the AI crawler allow-list and structured data checks. See what a scan covers on the pricing page.

Three fixes solve the underlying problem, in order of effort. Server-side rendering (Next.js, Nuxt, SvelteKit, and similar frameworks all support it) renders the full page on your server before sending it, so every crawler gets complete HTML. Static site generation goes further and builds the HTML once at deploy time, which is the simplest option for content that doesn't change per visitor. Where neither is practical, a prerendering service can detect a bot user agent and serve it a fully rendered HTML snapshot while regular visitors still get the client-rendered app. More on how AskEO evaluates crawlability during a scan is on the about page.

Is This Worth Fixing If Most of My Traffic Still Comes From Google?

It's a fair question, and the honest answer is: fixing it costs you nothing on the Google side. Because Googlebot already renders JavaScript in its second pass, moving to server-side rendering or static generation doesn't change how Google sees your content — it changes how the four crawlers that skip rendering see it. You're not trading Google performance for AI visibility; you're adding a channel that was previously closed. The main cost is developer time, which is real, but it's a one-time fix at the template level, not an ongoing tax.

What to Do Next

Create a free AskEO account and run a homepage scan — it fetches your page the same way GPTBot does and flags any section that only appears after JavaScript runs, so you know within the report whether this applies to your site before you change any code.