Do AI crawlers render JavaScript?
Mostly no. Vercel's December 2024 study, The rise of the AI crawler, analyzed AI crawler traffic on its own network. It found that among the major AI crawlers at the time, those from OpenAI, Anthropic and Perplexity did not render JavaScript, while Apple's and Google's did.
| Company | Crawler | Runs JavaScript? (Vercel, 2024-12) |
|---|---|---|
| OpenAI | GPTBot, OAI-SearchBot, ChatGPT-User | No |
| Anthropic | ClaudeBot | No |
| Perplexity | PerplexityBot | No |
| Common Crawl | CCBot | No |
| Apple | Applebot | Yes (renders with a browser-based crawler, similar to Googlebot) |
| Gemini（经 Googlebot 的基础设施） | Yes (full rendering) |
Vercel also found a detail: the ChatGPT and Claude crawlers download JavaScript files (11.50% and 23.84% of their requests) but do not execute them. They can see that a script exists, but not what the script draws.
The limits of this study should be clear: the data comes from Vercel's network and nextjs.org, it dates from late 2024, and the crawlers may have changed since. So do not rely on this table alone; test your own site with the methods below.
What does this mean for my site? Why can't ChatGPT see my React site?
In a single-page app built with a front-end framework such as React or Vue, the HTML the server sends is often just an empty shell. The body text appears only after the browser downloads and runs the scripts. A crawler that does not run JavaScript gets only the shell. You see the full page in your browser; it reads almost no words.
When a user asks ChatGPT to open your link, or ChatGPT search reads your page, what it gets is this shell. With no body text or prices in it, the AI has nothing to cite. If your pages are server-rendered or generated at build time, the text is already in the HTML and this problem does not exist.
How far apart are the raw HTML and the rendered page on real sites?
A kagentx evaluation takes each page's raw HTML (scripts not run) and its browser-rendered version, and compares how many words each has. Below is data from two real evaluations: GammaSlide on 2026-10-26 and MochiStamp on 2026-10-22. It shows each site on the day it was evaluated, not after any fixes.
| Site | Page | Words in raw HTML | Words after rendering | Ratio |
|---|---|---|---|---|
| GammaSlide | gammaslide.com/ | 314 | 18,630 | 59.3× |
| GammaSlide | gammaslide.com/ja/ | 200 | 11,146 | 55.7× |
| GammaSlide | gammaslide.com/zh-hans/ | 155 | 7,381 | 47.6× |
| MochiStamp | mochistamp.com/ | 8,790 | 9,625 | 1.1× |
| MochiStamp | mochistamp.com/en/ | 16,912 | 18,487 | 1.1× |
| MochiStamp | mochistamp.com/zh-hant/ | 6,553 | 7,258 | 1.1× |
GammaSlide's home page has only 314 words in its raw HTML and 18,630 after rendering, so a crawler that does not run JavaScript can read under 2% of it. MochiStamp's raw HTML already has 8,790 words against 9,625 rendered, not much different: the text is already in the HTML.
This only shows how much content each site hands to a crawler that does not run scripts. It does not show which site AI recommends more. For the full evaluation data, see GammaSlide case study and MochiStamp case study.
How do I check whether my site has this problem?
1. Look at the raw HTML with curl
Run the line below in a terminal, replacing the text in quotes with a sentence from your home page. If it prints 0, that sentence only appears after JavaScript runs:
curl -s https://your-site.com/ | grep -c "a sentence from your homepage"
Test the home page, pricing page, feature page and one article. Prices and features are the most likely to be rendered on the front end.
2. Estimate how many words the raw HTML has
The line below strips the tags and counts words. If the result is dozens of times smaller than the page in your browser, there is a problem (this is a rough estimate; text inside scripts is counted too):
curl -s https://your-site.com/ | sed -e 's/<[^>]*>/ /g' | wc -w
3. Turn JavaScript off in the browser
In Chrome DevTools press Cmd+Shift+P (Ctrl+Shift+P on Windows), type Disable JavaScript, press Enter and reload. If the page goes blank or shows only a loading hint, that is what the crawler reads. Remember to turn it back on afterwards.
4. Compare View page source with Inspect
Right-click the page and choose View page source to see the raw HTML; Inspect shows the rendered page. If the text is only in the latter, it is rendered on the front end.
5. Make sure crawlers are not blocked
Text in the HTML is not enough; crawlers also have to get in. Use AI crawler check to see whether robots.txt allows or blocks each AI crawler, and How to write robots.txt for AI crawlers for how to change it.
How do I fix it?
There is one goal: the first HTML a crawler gets should already contain the body text and prices. Common approaches, from smallest change to largest:
| Approach | what it is | Best for |
|---|---|---|
| Build-time generation (SSG) | Each page is rendered to an HTML file at build time, and what you deploy is ready-made HTML. | Pages whose content rarely changes: home, pricing, features, blog, docs. |
| Server-side rendering (SSR) | On each request the server renders the HTML first and sends it, and the browser then takes over the interactivity. | Pages whose content changes with the user or live data. |
| Prerendering an existing single-page app | Keep your framework and use a headless browser at build time to render the key routes to static HTML. | Projects with a lot of front-end code that cannot switch frameworks for now. |
Frameworks such as Next.js, Nuxt, Astro and SvelteKit have the first two built in. Even if you do not convert the whole site, fixing the pages that need to be found (home, pricing, features, each product page) solves most of the problem.
Two things to watch after the change. First, if the HTML holds only a skeleton and the body text is still filled in by the browser from an API, crawlers still see an empty page. Second, do not block JavaScript and CSS files in robots.txt: Apple's documentation says Applebot may not be able to render a page properly when they are blocked. After the change, run the curl test from the first step again.
Once the pages are in the HTML, the next step is getting AI to cite you. See Why ChatGPT doesn't recommend my product, or work through AI visibility audit checklist. A site with developer docs may also consider What is llms.txt.
FAQ
Is it true that ChatGPT can't see my React site?
In Vercel's December 2024 study, OpenAI's GPTBot, OAI-SearchBot and ChatGPT-User all did not render JavaScript. If your body text only appears after a script runs, what they read is an empty shell. Whether your site has this problem, one curl on the raw HTML will tell you.
Google can fetch my pages, so can the AI crawlers?
Not necessarily. Googlebot renders JavaScript and Gemini uses its infrastructure, so Google can see the content; but in Vercel's study the crawlers from OpenAI, Anthropic and Perplexity do not render. Being indexed by Google does not mean ChatGPT can read you.
Is a loading skeleton enough?
No. A skeleton is a placeholder in the HTML, not body text. A crawler wants words: what the product is, who it is for, what it costs. Those must be in the first HTML.
Is this study still accurate?
Vercel's data is from late 2024 and comes from its own network. The crawlers may have changed since, and we have no newer comparable study to cite. So test your own site with curl and with JavaScript off.
Do I have to move the whole site to server-side rendering?
No. Fix the pages that need to be found first: home, pricing, features, product pages and articles. Things like a logged-in dashboard do not need to be read by crawlers and can stay rendered on the front end.
Sources
- Vercel · The rise of the AI crawler （Published 2024-12, original checked 2026-11-04）
- Apple · About Applebot （checked 2026-11-04）
- OpenAI · Overview of OpenAI Crawlers （checked 2026-11-04）
- kagentx evaluations: the data on the case study pages; each example gives its date.