§ rendering

Can AI crawlers read JavaScript-rendered content?

Three crawlers document that they render JavaScript. The AI-native operators document nothing either way. Here is exactly who says what, why the popular answer is an assumption, and how to test your own site in one command.

the short answer

Googlebot, bingbot and Applebot all document rendering JavaScript. OpenAI, Anthropic, Perplexity and Meta document nothing either way, so "AI crawlers cannot read JavaScript" is an assumption rather than a fact, including in our own writing until we checked it. Since silence guarantees nothing, server-rendering the content is the only position that does not depend on being right about this.

the full crawler table →

§ in detail

What the documentation actually says.

Who documents that they render

Three, all with search-engine heritage. Google is explicit about a distinct pipeline: "Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing", and "Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript". Microsoft said in 2019 that "Bing is adopting Microsoft Edge as the Bing engine to run JavaScript and render web pages" and committed to keeping it evergreen. Apple documents that "Applebot may render the content of your website within a browser", and warns that blocking JS, CSS or XHR in robots.txt can break that rendering.

Who says nothing at all

OpenAI, Anthropic, Perplexity, Meta, Amazon and Common Crawl document nothing about JavaScript execution. Not a denial, not a confirmation: the words do not appear in their crawler documentation. That silence is the actual state of public knowledge, and it is why a page asserting "GPTBot cannot read your React app" is telling you something nobody has published. The practical consequence is unchanged, because you cannot build on a guarantee that does not exist, but the reasoning matters when someone quotes a confident number at you.

The tempting evidence that does not apply

Anthropic does document a component that cannot render JavaScript: "The web fetch tool currently does not support websites dynamically rendered with JavaScript." That is the web fetch API tool available to developers building on Claude, not ClaudeBot and not Claude-User. Quoting it as evidence about Anthropic's crawler is exactly the kind of near-miss that turns into folklore, so it is here to be ruled out rather than left for someone else to misread.

AI Overviews inherit Google rendering

A useful consequence of the split: Google states that to appear as a supporting link in AI Overviews or AI Mode, "a page must be indexed and eligible to be shown in Google Search with a snippet", and that "There are no additional technical requirements". So for Google's AI surfaces specifically, rendering is Googlebot's rendering, and there is no separate non-rendering pipeline to optimise for. Whatever Search sees, those surfaces see.

What the vendors say to do instead

Google deprecated dynamic rendering, calling it "a workaround and not a long-term solution for problems with JavaScript-generated content in search engines", and recommends server-side rendering, static rendering or hydration. Apple recommends making JS and CSS crawlable, or ensuring the page "renders cleanly, even if all of the resources are not available", which is graceful degradation by its older name. Bing recommended dynamic rendering with server-side prerendering, but that advice is from 2018 and now contradicts Google's current guidance, so date it if you cite it.

Test your own site in one command

Fetch as a bot, strip the tags, count the words. If a page with a thousand words of content returns a couple of dozen, the content is arriving via JavaScript and any client that does not render is seeing a shell. This is the check worth running before you argue about which crawler renders, because it answers the only question that affects you.

bash

curl -s -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot" \
    https://your-site.com \
  | sed 's/<script[^>]*>.*<\/script>//g; s/<[^>]*>//g' \
  | tr -s '[:space:]' ' ' | wc -w

# A few dozen words on a page that has hundreds means the
# content is rendered client-side and a non-rendering client
# receives nothing useful.

The irony worth keeping in mind

While researching this page, Microsoft's own Bing Webmaster help documentation could not be quoted from, because it is a JavaScript-only application that returns "You need to enable JavaScript to run this app" to every non-browser client. The Microsoft quotes above therefore come from dated Bing blog posts instead. A company that documents its renderer on a page its own statements cannot be read from without one is the clearest possible illustration of the problem.

§ who documents what

Rendering, per vendor

Documented means the vendor states it in writing. Silent means the words do not appear in their crawler documentation, which is not the same as a documented no.

who	verdict	what they say	source
Googlebot	renders	A separate queued rendering stage: "Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript."	vendor doc →
bingbot	renders	"Bing is adopting Microsoft Edge as the Bing engine to run JavaScript and render web pages", with a commitment to stay evergreen. Stated in 2019.	vendor doc →
Applebot	renders	"Applebot may render the content of your website within a browser", and blocking JS, CSS or XHR in robots.txt can prevent it rendering properly.	vendor doc →
OpenAI	silent	No mention of JavaScript, rendering, browsers or headless clients anywhere in OpenAI's crawler documentation.	vendor doc →
Anthropic	silent	The crawler documentation says nothing about rendering. The separate web fetch API tool does document not supporting JavaScript-rendered sites, but that is a developer tool, not ClaudeBot.	vendor doc →
Perplexity	silent	No mention of JavaScript or rendering in the crawler documentation.	vendor doc →
Meta	silent	No mention of JavaScript, rendering or headless browsers anywhere in Meta's crawler documentation.	vendor doc →
Amazon	silent	Amazon documents Amazonbot's robots.txt handling and publishes IP ranges, but says nothing about executing JavaScript.	vendor doc →
Common Crawl	silent	Common Crawl documents CCBot's robots.txt behaviour and its archive format, but nothing about rendering JavaScript.	vendor doc →

§ faq

Questions, answered.

Can ChatGPT read my JavaScript-rendered site?

Nobody outside OpenAI can answer that from published information, because OpenAI documents nothing about whether its crawlers execute JavaScript. Confident claims in either direction are guesses. What you can control is the risk: if your content is in the server-rendered HTML, the question stops mattering, and if it is not, you are betting your AI visibility on an undocumented behaviour. Fetch your page as GPTBot and count the words that come back.

Does Googlebot render JavaScript?

Yes, and it is the best-documented pipeline of any crawler. Google describes three phases, crawling, rendering and indexing, queues every page that returns a 200 for rendering unless a robots meta tag says not to index it, and states that a headless Chromium renders the page and executes the JavaScript once resources allow. Because AI Overviews and AI Mode draw on ordinary Search indexing, they inherit that rendering rather than needing anything extra.

Should I use dynamic rendering for AI crawlers?

Google deprecated the practice, describing dynamic rendering as "a workaround and not a long-term solution for problems with JavaScript-generated content in search engines", and recommends server-side rendering, static rendering or hydration instead. Serving different HTML to bots than to people also invites cloaking questions you do not need. If a client that does not render must be able to read your page, the durable answer is to send the content in the initial HTML for everyone.

My page returns 200 but AI tools see nothing. What is wrong?

Almost certainly that the response body is a shell. A client-rendered application returns a successful status with an empty root element, and every status-code checker calls that healthy while a non-rendering client walks away with nothing. The fix is to server-render the primary content. The diagnosis takes one curl: fetch the page with a bot user agent, strip the tags, and count the words that survive.

Is it true that AI crawlers do not run JavaScript?

It is an assumption that is repeated everywhere, including in our own earlier writing, and no vendor documents it. The verifiable picture is a split: Googlebot, bingbot and Applebot document that they render, and the AI-native operators publish nothing either way. Treat the claim as unproven in both directions and design so that it does not matter, which means shipping the content in the HTML rather than assembling it in the browser.

LintPage is not affiliated with any operator or platform named on this page. Vendor claims here were last verified on 2026-09-17. Dashboards and defaults move quickly, so follow the source links before relying on one.

§ related

Next to read.

complianceDo AI crawlers respect robots.txt?What every major AI operator commits to in writing, the eight documented exceptions - five for user-initiated fetches, three for special-case or integrity crawls - and what independent measurement actually found. Including which crawler has a peer-reviewed finding of non-compliance.blockingHow to block AI crawlers.Every documented way to block AI crawlers: robots.txt, Cloudflare, Vercel, Netlify, AWS WAF and Fastly, with the exact settings as the vendors document them today. Including the blocks that cost you more than you think.toolAI Crawler CheckerTest if ChatGPT, Claude, and Perplexity can actually read your page — not just whether your robots.txt says they can.

→ Why ChatGPT Can't Find Your Site (Even Though robots.txt Says It Can)

§ the measurable part

Find out what they actually get back.

Settings describe intent. A live fetch tells you what your edge really returns to each bot. Free, no signup.

run the AI crawler check →