JavaScript rendering: definition for crawlers

JavaScript rendering is the process of running a page's scripts so the browser, or a crawler acting like one, can build the finished Document Object Model (DOM).

Every page has two versions:

• The raw HTML response. What the server sends before any script runs.
• The rendered DOM. What exists after JavaScript has fetched data, injected text and built the layout.

On a server-rendered page the two are close to identical. On a page built with client-side rendering, the raw HTML can be an almost empty shell, and the headings, prices and product copy appear only after scripts run. A crawler that renders sees the second version. A crawler that doesn't sees the first.

A rendering crawler fetches the HTML, requests the linked JavaScript, executes it in a headless browser, waits for the DOM to settle, then extracts text and links. A non-rendering crawler stops after the first step and reads only the raw HTML.

Fetching a script is not the same as running it. Vercel's crawler study found that ChatGPT and Claude crawlers do fetch JavaScript files (11.50% and 23.84% of their requests) but "don't execute them. They can't read client-side rendered content." Our summary of Vercel's AI crawler study covers the method and its limits.

The non-rendering results were independently re-confirmed in June 2026. Crawler behavior can change, so treat this table as a snapshot as of October 2026. See the Applebot entry for how Apple's crawler differs.

Rendering sits at the access stage: whether a crawler can read your content at all, before any engine decides what to retrieve or cite. If your pricing, feature list or one-line product definition loads only after JavaScript runs, the tested AI crawlers never receive it.

Say you run a SaaS company whose pricing table is fetched by a script after page load. Googlebot renders it. OAI-SearchBot and PerplexityBot get the empty container. Those engines can only work from what they did receive, or from other sites.

The fix is to put load-bearing content in the initial HTML, through server-side rendering, static generation or prerendering. To find the gap, compare the raw HTML with the rendered DOM using the raw HTML vs rendered DOM check. For the full picture, including frameworks and edge cases, read the guide to JavaScript rendering and AI crawlers.

• "The crawler downloaded my JS, so it saw my content." Downloading and executing are separate. The Vercel data shows AI crawlers fetch scripts without running them.
• "If Google indexes it, AI engines can read it." Googlebot renders. Most tested AI crawlers don't. Google's surfaces and everyone else's can see different versions of the same page.
• "Server-side rendering gets you cited." It removes a block. It doesn't make an engine more likely to select your page. Nobody controls that step, and whether SSR increases AI citations has no published before-and-after study.
• "Any data loaded by a framework is lost." Vercel notes that JSON or React Server Components data present in the initial HTML response may still be indexed. What matters is whether the content is in that first response.

• Hydration: attaching JavaScript behavior to server-sent HTML, and where content can slip in only after load.
• Client-side rendering: building the page in the browser, the pattern most exposed to non-rendering crawlers.
• Applebot: one of the two named crawlers that renders.
• Server-side rendering: generating the full HTML on the server so every crawler receives the content in the first response.

Do Google AI Overviews and AI Mode need server-side rendering? Not for rendering reasons. Google says a page must be indexed and eligible to show with a snippet to appear as a supporting link, with no additional technical requirements. Googlebot renders JavaScript, so client-side content can reach Google's index. Server-side rendering still helps other engines, because the tested crawlers from OpenAI, Anthropic and Perplexity don't execute scripts.

How can I tell if my key content depends on JavaScript? Fetch the page with JavaScript disabled and save the raw HTML. Then load it in a headless browser and extract the rendered text. Diff the two. Any heading, price, product name or claim that appears only in the rendered version is invisible to non-rendering AI crawlers. Start with your homepage, pricing page and main product pages.

How reliable is the Vercel study? Its central finding has been independently re-confirmed as of June 2026. It has caveats worth knowing: the data is a one-month snapshot from late 2024 on nextjs.org, a Next.js-heavy sample. Microsoft Copilot was excluded because it lacks a unique user agent. Vercel also sells server-side rendering hosting. The mechanism holds; the exact request percentages are a point-in-time figure.

Should I serve AI crawlers a different version of my pages? No. Put the same content in the initial HTML for everyone. Showing AI crawlers content that human visitors don't see is cloaking, an illegitimate tactic that risks search penalties and misrepresentation. Prerendering is fine when the prerendered HTML matches what users get. The goal is one page that every crawler and every visitor can read.