Blog · Answer Checkup team · Last checked

Do AI crawlers render JavaScript? How to check

Most AI crawlers that have been measured don't run JavaScript. If your page builds its content in the browser, those crawlers get the HTML your server sent before any script ran, and on a client-rendered app that can be little more than an empty container. They can't cite what they can't read.

Below is what the published research and the crawler docs say, a five-minute test, and the fixes.

What the research found

In December 2024, Vercel and MERJ published measurements of AI crawler traffic on nextjs.org and Vercel's network, checked against two job board sites built on different stacks. Their finding: "none of the major AI crawlers currently render JavaScript." The list they tested included:

  • OpenAI's OAI-SearchBot, ChatGPT-User and GPTBot
  • Anthropic's ClaudeBot
  • PerplexityBot
  • Common Crawl's CCBot, which they note "does not render pages"

They also found that OpenAI's and Anthropic's crawlers do fetch JavaScript files but don't execute them. There were two exceptions. Google's Gemini uses Googlebot's infrastructure, which renders JavaScript fully, and Apple's Applebot renders JavaScript through a browser-based crawler, similar to Googlebot.

One caveat from the same article helps you. Content that's already in the initial HTML response, "like JSON data or delayed React Server Components, may still be indexed," because models can read non-HTML content. What's missing is content that only appears after a script runs.

This is one measurement from late 2024, and crawlers change. We checked the crawler pages from OpenAI, Anthropic and Perplexity on October 15, 2026. None of them says whether their bots run JavaScript. So the safe assumption is that they don't, and the safe fix is to put your content in the HTML.

What Google says

Google is the one company here that documents rendering in detail. Its JavaScript SEO basics say Googlebot queues pages for rendering, then renders them with a headless Chromium. A page "may stay on this queue for a few seconds, but it can take longer than that." The same page says server-side rendering or prerendering is "still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript."

Google's dynamic rendering page adds that "other search engines may choose to ignore JavaScript and won't see JavaScript-generated content."

That queue delay is documented for Googlebot only. So even at Google, rendering is a separate step that can lag behind the crawl. With other crawlers, it may not happen at all.

How to test your own pages

You're comparing two things: the HTML your server sends, and the page your browser shows after scripts run.

1. Look at view-source. In your browser, open view-source:https://example.com/ (or right-click and choose View Page Source). This is the raw HTML, before JavaScript. Don't use the Elements panel in DevTools for this, since it shows the page after scripts ran. If view-source shows your headline, your prices and your contact details, crawlers can read them. If it shows a <div id="root"></div> and a list of script tags, they can't.

2. Fetch it with curl. This is closest to what a crawler gets:

curl -sL https://example.com/ | grep -ciF "a phrase from your page"

Pick a short phrase from the rendered page with no apostrophes, quotes, ampersands or bold words in it. React, for example, encodes apostrophes in the HTML, so a phrase with one can fail to match. A 0 means the phrase probably isn't in the raw HTML. Try a second phrase before you conclude it's missing.

3. Count the words. Strip scripts, styles and tags from the raw HTML and count what's left:

curl -sL https://example.com/ | perl -0pe 's/<script\b.*?<\/script>//gis; s/<style\b.*?<\/style>//gis; s/<[^>]+>/ /g' | wc -w

Then count the rendered page. Open DevTools on the live page and run this in the console:

document.body.innerText.split(/\s+/).filter(Boolean).length

If the first number is a small fraction of the second, most of your page only exists after JavaScript runs. Both counts are rough, but a gap like 30 versus 900 is hard to miss.

4. Turn JavaScript off. web.dev's guide to rendering on the web suggests disabling JavaScript and loading the page to see how it was built. What's left is roughly what a crawler that doesn't render sees.

Test more than the homepage. Product pages, pricing pages and blog posts often use different templates.

The fixes

The web.dev guide defines the main options. In order of how much they change your setup:

Server-side rendering (SSR). The server builds the full HTML for each request. In web.dev's words, "rendering an app on the server to send HTML, rather than JavaScript, to the client." Frameworks such as Next.js and Nuxt do this. Good for pages that change often or are personalized.

Static generation. Pages are rendered to HTML at build time, one file per URL. web.dev calls this static rendering. It's fast to serve and easy to cache on a CDN. It gets hard when you have too many URLs to build ahead of time.

Prerendering. web.dev defines it as "running a client-side application at build time to capture its initial state as static HTML." The app still boots in the browser, but the first HTML already holds the content.

Vercel's recommendation is the same family: server-render critical content, including main content, titles and descriptions, and navigation, using server rendering or static generation. Client-side rendering is fine for extras like view counters, chat widgets and interactive UI.

What about dynamic rendering? That means serving bots a server-rendered version and users the client-side one. Google calls it "a workaround and not a recommended solution" and recommends server-side rendering, static rendering or hydration instead.

If you can't change the rendering this month, put your key facts in the initial HTML anyway: a real <h1>, a paragraph that says what you do, who it's for and where, your prices if you publish them, and your contact details. Put your title, meta description and JSON-LD in the server HTML too, not injected later. It's a partial fix, but it means a crawler that skips JavaScript still gets the basics.

What our scan checks

Our free scan doesn't run JavaScript either. It reads the raw HTML, the same way a non-rendering crawler would. Its raw-content check counts the words in that HTML after removing scripts and styles, and looks for an <h1>. A page with fewer than 50 words, plus either an empty app container or external scripts, is flagged as likely client-rendered, with a high-priority fix to use server-side rendering or static generation. The check is worth 20 of the 100 points. Our post on whether AI crawlers can see your site covers all six checks.

Rendering is one of several things that keep a site out of AI answers. If crawlers can read your pages, the next questions are whether robots.txt lets them in, covered in our robots.txt guide for AI crawlers, and whether anyone else writes about you, covered in our AI SEO guide.

FAQ

Do AI crawlers render JavaScript?
Vercel's December 2024 measurements found that none of the major AI crawlers they tested did, including OpenAI's, Anthropic's ClaudeBot and PerplexityBot. The exceptions were Gemini, which uses Googlebot's infrastructure, and Applebot.
Why can't ChatGPT see my React site?
If your React app renders in the browser, the HTML your server sends may only contain an empty root element and script tags. Vercel found OpenAI's crawlers fetch JavaScript files without running them. Server-side rendering, static generation or prerendering puts the content in the HTML.
Does Google see my client-rendered content?
Usually, yes. Google says Googlebot renders pages with a headless Chromium, though rendering can be delayed. Google still recommends server-side or prerendering because not all bots run JavaScript.
Is serving bots a different version of my page cloaking?
Google says dynamic rendering generally isn't cloaking as long as the content is similar, but calls it a workaround and recommends server-side rendering, static rendering or hydration instead.

Check your own site

Run the free scan on the Answer Checkup homepage. It tells you how many words are in your raw HTML and whether the page looks client-rendered. To see whether AI answers mention you at all, read how to check if ChatGPT recommends your business.

Answer Checkup is not affiliated with Vercel, MERJ, OpenAI, Perplexity, Google, Anthropic, Apple or Common Crawl.
Contact: [email protected]

Sources

All pages fetched and checked on October 15, 2026.