JavaScript Rendering and AI Crawlers: What Breaks and How to Fix It
If your most important content only appears after JavaScript runs in the browser, many AI crawlers may never see it. Unlike Googlebot — which has a mature rendering step — a lot of AI crawlers fetch raw HTML and move on. The fix is to send complete HTML in the first response through server-side rendering (SSR) or static generation. Here’s what breaks, why, and how to check what bots actually receive.
Why this happens
There are two moments in a page’s life:
- The initial HTML response — what the server sends the instant a crawler requests the URL.
- The rendered DOM — what exists after the browser downloads, parses, and executes JavaScript.
A traditional single-page app (SPA) ships a nearly empty initial HTML shell — often just a <div id="root"></div> — and then JavaScript builds the real page in the browser. Your human visitors see everything, because their browsers run that JavaScript. But a crawler that stops at the initial response sees an empty shell.
Googlebot handles this with a second rendering pass. The problem: you cannot assume AI crawlers do the same. Many don’t render at all, and the space is new enough that behavior is inconsistent and undocumented. The safe engineering assumption is: if it’s not in the raw HTML, it might not exist to an AI crawler.
What breaks, specifically
When content depends on client-side JavaScript, these are the common casualties:
- Body copy injected after load — the actual text you want cited.
- Internal links rendered by the framework’s router instead of real
<a href>tags in the HTML. - Structured data (JSON-LD) added dynamically instead of served in the document.
- Metadata — titles and descriptions set at runtime rather than in the initial
<head>. - Content behind interaction — tabs, accordions, or “load more” buttons that only fetch content on click.
Any of these being JavaScript-dependent can quietly erase you from AI answers, even while your site looks perfect to human visitors.
How to check what crawlers see
You don’t need special tools. Use the method that shows the raw response, not the rendered DOM:
# Fetch the raw HTML your server sends — no JavaScript executed
curl -A "Mozilla/5.0 (compatible; test)" https://yourdomain.com/your-page
# Then search the output for text you expect to be there.
# If your headline and body copy are missing, they're JS-dependent.
In a browser, use View Source (Ctrl+U), not Inspect Element. “View Source” shows the raw HTML; “Inspect” shows the post-JavaScript DOM and will mislead you into thinking everything is fine.
A quick checklist:
- Open View Source on a key page.
- Search (
Ctrl+F) for a full sentence of your main content. - Search for a few of your internal link URLs.
- Confirm your JSON-LD
<script type="application/ld+json">is present. - If any are missing, that content is JavaScript-dependent and at risk.
The fix: send real HTML
The goal is simple — put your content in the initial response. Three approaches, in rough order of robustness for content sites:
- Static generation (SSG). Pages are built to HTML at deploy time. Nothing depends on runtime JavaScript for content. This is the strongest option for marketing sites and blogs. Frameworks like Astro default to shipping static HTML with zero client JavaScript unless you opt in.
- Server-side rendering (SSR). The server renders full HTML per request. Great for dynamic or personalized pages. Next.js and Nuxt support this.
- Prerendering. A build step generates HTML snapshots of otherwise client-rendered routes. A retrofit for existing SPAs.
You don’t have to give up interactivity. Modern frameworks let you serve complete HTML and hydrate interactive components on top — you get crawlable content and a rich UI. This is exactly the architecture we favor in our web development work: static-first, fast, and legible to every crawler.
The rule of thumb: your content should be readable with JavaScript turned off. Interactivity can be additive; content should not depend on it.
Rendering and speed reinforce each other
Serving real HTML doesn’t just help crawlers understand you — it usually makes pages faster, because the browser paints content without waiting for a JavaScript bundle to download and execute. That feeds directly into Core Web Vitals and crawl efficiency. Rendering strategy and performance aren’t separate projects; they’re the same decision.
If you’re weighing how AI search differs from classic SEO on the technical side, our comparison of AI SEO vs traditional SEO puts rendering in that broader context.
The next constraint: agents
The same rendering discipline decides whether AI agents can operate your site, not merely read it. We cover that in agentic search optimization.
The bottom line
- Assume AI crawlers don’t run JavaScript unless an operator documents otherwise.
- Put your content, links, and structured data in the initial HTML.
- Verify with View Source or
curl, not the rendered DOM. - Prefer static or server rendering; add interactivity on top, not underneath.
Want to know exactly what AI crawlers receive when they hit your pages — and where JavaScript is hiding your content? Get an AI visibility audit and we’ll show you the raw HTML picture, page by page.
Frequently asked questions
Do AI crawlers execute JavaScript?
Most do not, or do so inconsistently. Unlike Googlebot, which runs a rendering step, many AI crawlers fetch raw HTML and move on. If your content only appears after JavaScript runs in the browser, those crawlers may never see it.
How do I know if my content needs JavaScript to appear?
Fetch your page's raw HTML with curl, or use 'View Source' rather than 'Inspect' in your browser. If the main text and links are missing from that raw HTML and only appear in the rendered DOM, your content depends on JavaScript.
Does server-side rendering fix the problem?
Largely, yes. Server-side rendering (SSR) or static generation sends complete HTML in the initial response, so a crawler that doesn't run JavaScript still receives your content. Frameworks like Astro, Next.js, and Nuxt support this.
Is a single-page app bad for AI search?
A client-only SPA is risky for AI visibility because its content is assembled by JavaScript after load. You can keep an SPA's interactivity while adding SSR or prerendering so crawlers receive real HTML.
Does Googlebot rendering mean AI crawlers will render too?
No. Googlebot has a mature two-pass rendering pipeline, but that is specific to Google. You cannot assume other AI crawlers share it. Treat non-rendering as the safe default and serve complete HTML.