Definition
JavaScript rendering is the step where a crawler executes a page's JavaScript to produce the final content a browser would show. For AI search it decides a basic question: if your text, links or structured data only appear after JavaScript runs, can AI crawlers see them? For most of them, the answer is no.
The most cited measurement comes from Vercel and the consultancy MERJ, who analyzed AI crawler traffic across Vercel's network in late 2024. They found that none of the major AI crawlers rendered JavaScript, including OpenAI's GPTBot, OAI-SearchBot and ChatGPT-User, Anthropic's ClaudeBot, Meta-ExternalAgent, ByteDance's Bytespider and PerplexityBot. GPTBot and ClaudeBot did download JavaScript files (11.5% and 23.8% of their requests) but did not execute them. Common Crawl's CCBot, a major source of training data, also does not render. Google's Gemini features use Googlebot's infrastructure and do render JavaScript, and Applebot renders too.
Later tests point the same way. A controlled experiment published by Search Engine Land in 2026 put half of a test site's internal links in plain HTML and half behind JavaScript. GPTBot and ClaudeBot crawled every HTML-linked page and none of the JavaScript-linked ones; OAI-SearchBot, ChatGPT-User, Meta's and Amazon's crawlers also reached zero JavaScript-linked pages. Only Google's crawlers executed the JavaScript, and even Googlebot reached a small fraction of those pages during the test.
The risk is easy to miss because the page looks fine in a browser and may rank fine in Google, which renders JavaScript in a second pass. Meanwhile a client-side rendered single-page app can serve AI crawlers an almost empty HTML shell. That removes the page from ChatGPT search, Perplexity and Claude citations, and it can also hide everything linked from it. The same applies to content behind tabs or accordions that load on click, prices or stock pulled in by script, and schema markup injected after load.
The fix is to put content that matters into the initial HTML response. Server-side rendering, static generation and incremental static regeneration all do this, and most modern frameworks support them. Pre-rendering services can serve static HTML to bots as a stopgap, though Google describes dynamic rendering as a workaround rather than a long-term solution. Client-side JavaScript remains fine for enhancements such as chat widgets, view counters and interactive filters, as long as the core text, links, prices and structured data are already in the HTML. Vercel's study also notes that data embedded in the initial response, such as JSON in the page, may still be read even when it is not rendered.
To check a page, fetch it without JavaScript (view source, curl, or the AI crawler URL inspector) and confirm the main content, internal links and structured data are present. Then watch AI crawler logs after any front-end change: if GPTBot or OAI-SearchBot requests to a section drop after a redesign, a rendering regression is a likely cause. Our guide to AI crawler bots explains which bots fetch for training and which fetch for live answers.
Examples of JavaScript Rendering for AI Crawlers
- A JS-heavy product page loses its citations in ChatGPT after a redesign; the AI crawler URL inspector shows the raw HTML contains only a loading spinner and an empty root element.
- A travel company switches its destination guides from client-side rendering to static generation and sees OAI-SearchBot requests to those pages rise within two weeks.
- A retailer's prices load from an API after page load, so Perplexity answers cite the product page but quote a competitor's price; moving the price into the server-rendered HTML fixes it.
- A documentation site keeps its interactive code playground client-side but server-renders the article text and sidebar links, so AI crawlers can read and navigate every page.
