Can AI Crawlers Read JavaScript? Making Content Visible to ChatGPT

If your main text is only added to the page by JavaScript in the browser, an AI crawler that doesn't run JavaScript sees an empty shell: a title, a <div id="root"> and some script tags. Googlebot renders JavaScript and Applebot may, but OpenAI, Anthropic and Perplexity don't say whether their crawlers do. The safe approach is to make sure your important content is in the HTML the server sends, through server-side rendering, static generation or pre-rendering.

What is documented

Crawler	JavaScript rendering	Source
Googlebot	Yes. Google processes JavaScript pages "in three main phases": crawling, rendering and indexing	JavaScript SEO basics
Applebot	"Applebot may render the content of your website within a browser" and needs JS, CSS and XHR resources not to be blocked	About Applebot
GPTBot, OAI-SearchBot, ChatGPT-User	Not stated	OpenAI crawlers
ClaudeBot, Claude-SearchBot, Claude-User	Not stated	Anthropic crawlers
PerplexityBot, Perplexity-User	Not stated	Perplexity crawlers

Google adds a line worth taking at face value: "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."

The only large public measurement we know of comes from a hosting company, not from the AI companies. In December 2024 Vercel reported that in its network data "none of the major AI crawlers currently render JavaScript", naming OpenAI's and Anthropic's crawlers among others, while noting that they do fetch JavaScript files. That was one company's data at one point in time; crawlers change. It's a reason to test, not a permanent fact.

Which sites are affected

• Single-page apps built with React, Vue, Angular or Svelte without server rendering, where the HTML body is an empty mount point.
• Content loaded by fetch() after page load: article text, product details or prices pulled from an API on the client.
• Text behind interactions: tabs, accordions or "read more" buttons whose content isn't in the HTML until clicked.
• Infinite scroll lists where only the first few items are in the HTML.
• Website builders and widgets that inject text from a third-party script, such as reviews or FAQ widgets.

Sites built with WordPress, most static site generators, or Next.js and Nuxt pages that are server-rendered or statically generated usually send full HTML. "Usually" because a single component can still load its content on the client.

Test what's in your HTML

Look at the HTML the server sends, not what your browser shows after scripts run.

From a terminal:

curl -s https://example.com/your-article/ | grep -c "a sentence from the middle of your article"

0 means that sentence isn't in the raw HTML. Pick a sentence from the body, not the title, since titles are often server-rendered even on client-rendered sites.

In the browser: open the page, use View Source (not the Elements panel, which shows the DOM after JavaScript), and search for a sentence from the article.

Compare text length: copy the visible text of the page and compare it with the text in the raw HTML. If the HTML contains only a small fraction, the rest comes from JavaScript.

Google's URL Inspection tool in Search Console shows the rendered HTML, which is what Googlebot sees after rendering. That's useful for Google but doesn't tell you what a non-rendering crawler gets.

Fixes, from best to acceptable

1. Server-side rendering or static generation. Render the content on the server or at build time. In Next.js that means server components or static pages for content routes, and not fetching the article body in a client component. The Next.js AdSense guide covers the framework side.
2. Pre-rendering. Generate HTML snapshots of each route at build time with a pre-render step. Works well for content that changes rarely.
3. Put critical text in the initial HTML even if the rest is client-side. The article body, headings, title, meta description and main navigation links should be in the HTML. Comment counts, live widgets and personalisation can stay client-side.
4. Avoid hiding content behind clicks. Text inside a closed <details> element or a CSS-hidden tab is still in the HTML; text fetched only when the tab is clicked is not.

Google says dynamic rendering (serving pre-rendered HTML to bots and the client version to users) "was a workaround and not a long-term solution" (dynamic rendering). Prefer real server rendering.

Also check the basics

Rendering is only one way an AI crawler can miss your text. The request also has to get through:

• robots.txt: see allow AI crawlers in robots.txt;
• your CDN or firewall: see Cloudflare blocking AI bots and firewall and plugin rules.

JavaScript content and AdSense

These are separate questions, but the fix overlaps. Googlebot renders JavaScript, yet a page that shows almost nothing until scripts run can still look thin or broken if a script fails. The thin content guide covers what AdSense means by low-value pages, and a free Approvalens scan checks the things the AdSense review looks at.

Check your pages

The free AI crawler checker fetches your page the way a non-rendering crawler would and flags pages whose main text seems to depend on JavaScript. Its requests use AI bot user agents from our server, so they simulate the bot rather than being the bot; a firewall that checks IP ranges can answer them differently.

FAQ

Does ChatGPT run JavaScript when it reads my site?

OpenAI doesn't document it either way. Vercel's 2024 data found that OpenAI's crawlers fetched JavaScript files but didn't execute them. Don't rely on rendering; put the content in the HTML.

My site is in Google. Doesn't that prove crawlers can read it?

It proves Googlebot can, after rendering. Google renders JavaScript; that tells you nothing about crawlers that may not.

Is

It puts some text in the HTML, but it's usually a short message, not your article. Render the real content instead.

Will lazy-loaded images matter?

For text visibility, no. Images loaded on scroll are a separate issue; make sure each has meaningful alt text in the HTML.