GuidePublished: June 30, 2026 · Last updated: June 30, 2026 · ~4 min read
Mihir Naik — Senior PM (AI) at seoClarity

Do AI Crawlers Render JavaScript? Rendering & Content Extractability

You can pass every access check and still be invisible—because the crawler fetched your page and found an empty shell. Most AI crawlers don’t run JavaScript; they read the raw HTML your server returns. If your content is assembled in the browser, it isn’t there when the bot looks. This part covers why that happens and how to make your content present and extractable.
Executive summary
Reaching your page (access) and reading your page (rendering) are separate problems. Most AI crawlers fetch raw HTML and do not execute JavaScript, so client-side-rendered content is effectively invisible to them—even when the page looks perfect in a browser.
  • If your content only appears after JavaScript runs, assume AI crawlers can’t see it.
  • Server-side rendering (SSR) or static generation (SSG) puts your content in the initial HTML, where crawlers actually look.
  • Rendering is necessary but not sufficient—content also has to be extractable: semantic, in the main document, not hidden behind interaction.

Do AI crawlers render JavaScript?

As a working assumption: no. Unlike Googlebot—which maintains an expensive two-pass rendering pipeline—most AI crawlers fetch the HTML your server returns and move on. Rendering JavaScript at the scale of the open web is slow and costly, so retrieval and training bots overwhelmingly read raw HTML.
Design for the lowest common denominator: if your important content isn’t in the raw HTML response, treat it as invisible to AI.

How client-side rendering hides your content

In a client-side-rendered app (a typical single-page React/Vue/Angular build), the server sends a near-empty HTML shell plus a JavaScript bundle. The browser runs that bundle to build the page. A crawler that doesn’t run JavaScript receives only the shell.
What a non-rendering crawler sees from a CSR app
<!doctype html>
<html>
  <head><title>Loading…</title></head>
  <body>
    <div id="root"></div>
    <script src="/static/bundle.js"></script>
  </body>
</html>
Every headline, paragraph, and proof point lives inside that bundle’s runtime output—none of it is in the markup the bot reads.
For leadership
If your site is a single-page app, this is likely your single biggest AI-visibility risk—and it won’t show up in a browser QA pass, because your browser runs the JavaScript the crawler won’t.

The fix: render on the server

Put your content in the HTML before it leaves the server. Two well-supported approaches:
  • Server-side rendering (SSR): the server renders the page’s HTML per request (e.g. Next.js, Nuxt, Astro, Remix). Good for dynamic/personalized pages.
  • Static site generation (SSG): pages are pre-rendered to HTML at build time and served as static files. Ideal for content like guides, docs, and marketing pages.
Both produce the same crawler-visible result: your real content in the initial HTML response. Hydration can still add interactivity afterward—what matters is that the content doesn’t depend on it.

Beyond rendering: making content extractable

Rendering gets your content into the HTML. Extractability decides whether a model can isolate, attribute, and reuse it cleanly. Even server-rendered pages can bury their value.
What helps a machine extract you accurately:
  • Semantic HTML—real headings (h1–h3), paragraphs, lists, and a clear main/article landmark instead of a sea of unlabeled divs.
  • Your primary content in the document, not collapsed inside tabs/accordions that only populate on click, or loaded by infinite scroll.
  • Important claims as text, not baked into images or screenshots a text crawler can’t read.
  • A clear content hierarchy so the answer to a question sits under a heading that matches the question.
Tabs and ‘load more’ are great UX and quiet visibility killers. If content matters for AI answers, make sure it exists in the served HTML, not just after an interaction.

Test what the crawler actually sees

Stop trusting the rendered browser view. Inspect the raw HTML the way a non-rendering crawler does.
See the raw, pre-JavaScript HTML
# Fetch raw HTML (no JS execution) and search for your content
curl -s https://example.com/your-page | grep -i "your key phrase"

# If the phrase is missing here but visible in the browser,
# it’s rendered client-side and likely invisible to AI crawlers.
Two more quick checks:
  • Right-click → View Source (not Inspect). Source shows the served HTML; Inspect shows the post-JavaScript DOM.
  • Disable JavaScript in your browser and reload. What remains is roughly what a non-rendering crawler gets.
Part 4 of 6
A part of Why AI Search Engines Can’t See Your Website — and How to Fix It.
  1. Why AI Search Engines Can’t See Your Website — and How to Fix It
  2. AI Search Crawlers: GPTBot, ClaudeBot, PerplexityBot & the Bots Reading Your Site
  3. How to Configure robots.txt for AI Crawlers (Without Going Invisible)
  4. Do AI Crawlers Render JavaScript? Rendering & Content Extractability · you’re here
  5. How to Audit Your Site for AI Search Crawlability (Step-by-Step)
  6. Fixing AI Crawlability by Platform: Next.js, WordPress, Headless & CDN
← robots.txt & CDNThe audit →
What’s next
Becoming visible in AI search is a technical problem with a revenue outcome. If you'd rather have it diagnosed and fixed, here's how I can help.
Mihir Naik
About the author
Mihir Naik — Senior Product Manager (AI) at seoClarity, building Clarity ArcAI. Born in Surat, India; based in Toronto. In SEO since 2011. Available for consulting.
Read full bio →