Can ChatGPT Read JavaScript Sites? How to Test What OpenAI's Crawlers See
Can ChatGPT crawl JavaScript? OpenAI does not say, but the best public data we found, a 2024 Vercel and MERJ study of real crawler traffic, reports that OpenAI's crawlers fetch JavaScript files without executing them. If your content only appears after client-side JavaScript runs, assume ChatGPT may see an empty page. Below is how to test your own site in five minutes and how to fix it.

The short answer, with sources
There are two kinds of evidence, and they should not be confused:
- What OpenAI documents. OpenAI's crawler overview describes what OAI-SearchBot, GPTBot and ChatGPT-User are for, their user agents and IP lists. It says nothing about JavaScript rendering. We found no official OpenAI statement either way.
- What independent measurement shows. In The rise of the AI crawler (December 17, 2024), Vercel and MERJ analyzed crawler traffic on nextjs.org and the Vercel network and concluded that none of the major AI crawlers they measured render JavaScript, naming OAI-SearchBot, ChatGPT-User and GPTBot among them. They report that ChatGPT's crawlers do fetch JavaScript files (11.50% of requests) but do not execute them, so they cannot read client-side rendered content.
That study is now almost two years old and is one company's dataset. Crawler behavior can change without notice. The practical rule still holds: if the words are not in the HTML your server sends, do not count on ChatGPT reading them. Test it rather than trust anyone's summary, including this one.
Why this matters more for ChatGPT than for Google
Google is the exception that made many developers comfortable with client-side rendering. Google's JavaScript SEO basics describes three phases, crawling, rendering and indexing, with a headless, evergreen Chromium executing JavaScript once resources allow. Even so, the same page says server-side or pre-rendering "is still a great idea" because "not all bots can run JavaScript".
| Crawler | Executes JavaScript? | Source |
|---|---|---|
| Googlebot | Yes, in a later rendering phase | Google Search Central documentation |
| OAI-SearchBot (ChatGPT search) | Not documented by OpenAI; measured as no in 2024 | Vercel and MERJ study |
| ChatGPT-User (user-triggered fetches) | Not documented by OpenAI; measured as no in 2024 | Vercel and MERJ study |
| GPTBot (training) | Not documented by OpenAI; measured as no in 2024 | Vercel and MERJ study |
The same study notes that content present in the initial HTML response, including JSON data embedded in the page, may still be picked up. That is good news for frameworks that ship page data inside the HTML, and it is the key to the fixes below.
Test 1: view source vs inspect
The quickest check needs only a browser.
- Open the page and press Ctrl+U (Cmd+Option+U on Mac) to view source. This is the raw HTML your server sent, roughly what a non-rendering crawler receives.
- Search the source (Ctrl+F) for a distinctive sentence from the middle of your article, a product price or an FAQ answer.
- Compare with Inspect (right click, Inspect), which shows the DOM after JavaScript ran.
If the sentence is in Inspect but not in view source, that content depends on JavaScript. A bare <div id="root"></div> or <div id="app"></div> with script tags and little else is the classic sign of a fully client-side app.
A second browser check: Chrome DevTools lets you disable JavaScript for the current tab. Reload with JavaScript off and look at what is left. Menus, article text, prices and reviews that vanish are invisible to a non-rendering bot.
Test 2: fetch the page as OAI-SearchBot with curl
Some servers and CDNs send different HTML to different user agents, so test with OpenAI's documented user agent. OpenAI's crawler page gives this string for OAI-SearchBot:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36; compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot
Then run, replacing the URL and the phrase:
curl -s -A "PASTE-UA-HERE" https://yoursite.com/page/ | grep -c "a distinctive sentence"
- Result 1 or more: the text is in the served HTML. Good.
- Result 0: the text is missing. Either it is rendered by JavaScript, or the server answered with something else. Run the command again with
-o page.html -w "%{http_code}"to see the status code and open the file. - Status 403 or a challenge page: your firewall treats this user agent as hostile. That is a separate and more serious problem.
Note the user agent contains "Chrome/131". That is a compatibility label, not evidence that the bot runs a browser engine. Also note the limits of this test: your curl request comes from your own IP, not OpenAI's, so it tests the HTML, not your firewall's IP rules. To see what bots actually received, check server logs for OAI-SearchBot requests from the IPs in searchbot.json and their status codes and response sizes. A long run of tiny responses to a page that should be large is a warning sign.
Test 3: ask ChatGPT to read the page
Paste the URL into ChatGPT and ask it to summarize the page or quote a specific section. This triggers a user-initiated fetch. If ChatGPT says it cannot access the content, describes only your navigation, or invents details, compare with Tests 1 and 2. Treat this as a rough check: answers vary between runs, and the model may fill gaps from other sources.
Which sites are at risk
| Setup | Typical risk | What to check |
|---|---|---|
| Classic server-rendered CMS (WordPress, Ghost, Drupal, Joomla) | Low for article text | Content loaded by widgets or "load more" buttons, reviews, tabs |
| Static site generators (Hugo, Jekyll, Astro, Eleventy) | Low | Interactive components that fetch data in the browser |
| React, Vue or Angular single-page apps without SSR | High | Whether view source contains anything beyond an empty root element |
| Next.js or Nuxt | Depends on rendering mode per page | Pages using client-only data fetching |
| Hosted website builders | Varies by builder and template | Run Tests 1 and 2; do not assume either way |
Even on a server-rendered site, the parts that most often go missing are the ones that sell: prices loaded from an API, reviews from a third-party widget, FAQ answers hidden in accordions that load on click, and comparison tables built in the browser.
How to fix a JavaScript-dependent site
Google's guidance on dynamic rendering calls serving a separate pre-rendered version to bots "a workaround and not a long-term solution", and recommends server-side rendering, static rendering or hydration instead. The same direction works for AI crawlers. In order of preference:
- Static generation. Build HTML at deploy time for pages that change rarely: articles, docs, landing pages. Every crawler gets full content.
- Server-side rendering with hydration. The server sends complete HTML; JavaScript then makes it interactive. Most modern frameworks support this per page. web.dev's Rendering on the Web explains the trade-offs.
- Move critical content into the initial HTML. If a full migration is not possible, render at least the main text, headings, prices, FAQ answers and structured data on the server, and keep JavaScript for the interactive extras.
- Pre-rendering as a stopgap. A pre-rendering service can snapshot pages for bots, but it adds a moving part that can serve stale or broken snapshots. Keep the content identical to what users see.
Whatever you choose, put JSON-LD structured data in the server-sent HTML rather than injecting it with a tag manager. Our guide to schema markup for AI search covers which types are worth adding.
A quick audit you can do today (illustrative)
For a site with 20 to 50 important pages, a realistic one-hour audit looks like this: pick your top ten pages by traffic, run Test 2 on each with one distinctive sentence, mark the failures, then group them by template. Fixes are usually per template, not per page: if one product page fails, they probably all do. The numbers here are an example for planning, not a benchmark.
What to do next
Rendering is only one way AI crawlers fail on a site. The other common one is never reaching the page at all. Before you rebuild anything, confirm the basics in our guide to getting your website indexed by ChatGPT and make sure your robots.txt does not block the wrong bot (see blocking AI crawlers in robots.txt).
Then run Satelo's free AI crawler checker on a key page. It shows, bot by bot, whether OAI-SearchBot, GPTBot and other AI crawlers are allowed by your robots.txt and what your server returns to them, which is the first thing to rule out before you blame JavaScript. For a wider look at speed and crawlability, the free site check takes about 30 seconds.
FAQ
Can ChatGPT crawl JavaScript websites?
OpenAI does not document whether its crawlers render JavaScript. A December 2024 Vercel and MERJ study of real crawler traffic reported that OAI-SearchBot, ChatGPT-User and GPTBot fetch JavaScript files but do not execute them, so content rendered only in the browser may be invisible to ChatGPT.
Does OAI-SearchBot render JavaScript like Googlebot?
There is no official statement from OpenAI. Googlebot renders pages with a headless Chromium in a later phase, as Google documents. Independent 2024 data found no JavaScript execution by OpenAI's crawlers, so server-rendered HTML is the safe choice.
How do I check what ChatGPT's crawler sees on my page?
Compare view source with Inspect in your browser, then fetch the page with curl using OpenAI's documented OAI-SearchBot user agent and search the output for a sentence from your content. Check server logs for real OAI-SearchBot visits and their status codes.
Is my React or Vue site invisible to ChatGPT?
If it renders entirely in the browser and view source shows only an empty root element with scripts, it is likely that AI crawlers see little or no content. Server-side rendering or static generation fixes this.
Can ChatGPT read content in accordions or tabs?
If the text is in the HTML and only hidden with CSS, a crawler receives it. If it is loaded from an API when the user clicks, a non-rendering crawler does not get it. Check with view source.
Does WordPress have this problem?
Usually not for article text, because WordPress renders pages on the server. Problems tend to come from widgets, review plugins or page builders that load content with JavaScript, so test your key templates.
Read next




Check your site's Quality Score
Free, no sign-up: a 0–100 score from mostly open data. Then add your site to Satelo and get partner articles from sites of your level.
Enter a domain like example.com
Add my site