Outrings
AI visibility and answer engines

Does JavaScript hurt AI crawlers?

Yes, more than it hurts search engines. If your content only exists after JavaScript runs, most AI crawlers see an empty page.

3 min read
Short answer

Yes. Googlebot renders JavaScript; almost no AI crawler does. A client-rendered app serves an empty container to them, so the page has no content as far as they are concerned — regardless of how complete it looks in a browser.

Why the two behave differently

Rendering JavaScript means running a headless browser for every page. It is expensive, slow and fragile. Google has spent years and considerable infrastructure making it work, and even Google renders on a delay and not always.

AI crawlers are mostly fetching HTML and moving on. That is a reasonable engineering choice for their purpose, and it means a client-rendered page is, to them, a page with no content.

How to tell in ten seconds

curl -sL https://yoursite.com | grep -i "a sentence from your page"

Nothing back means the content is not in the HTML. You can also compare sizes: if curl returns 4 KB for a page that shows two thousand words, the page is assembled in the browser.

A more visual version: disable JavaScript in your browser's developer tools and reload. What remains is roughly what an AI crawler sees.

The fix, by situation

SituationWhat to do
Next.js, Nuxt, SvelteKit, Remix, AstroUse server-side rendering or static generation for content pages. All of these support it directly; the default in several is already correct.
Create React App, Vite SPA, plain client-side appAdd a prerendering step at build time, or migrate content routes to a framework that renders on the server.
WordPress, Ghost, static site generatorAlready server-rendered. Check that a plugin or theme has not moved key content into a client-side widget.
Content inside a tabbed or accordion componentFine if it is in the HTML and merely hidden with CSS. Not fine if it is fetched when the tab is clicked.

The partial cases that catch people out

It is rarely all or nothing. Common patterns where the important part is the missing part:

  • The article renders server-side, but reviews, comments or specifications load afterwards by fetch.
  • The page is server-rendered but the <title> and meta description are set by client-side script.
  • Navigation is client-side only, so crawlers cannot discover the rest of the site from any page.
  • Product prices and availability are injected after load, so the extractable content omits exactly the facts people are asking about.
Worth stating plainly: this has nothing to do with using JavaScript. Interactive behaviour, analytics, components — all fine. The requirement is that the words a reader came for exist in the HTML the server sends. Hydrate on top of that as much as you like.

What you gain by fixing it

Server rendering the content improves AI visibility, makes Google's job cheaper and more reliable, improves first-paint time on slow connections, and makes link previews work on social platforms and messaging apps — which read the same HTML and have the same limitation. It is one change with four separate payoffs.

What our audit reports about this

Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.

  • The proportion of visible text present in raw HTML versus added after load.
  • Whether title, meta description and canonical are server-rendered or set by script.
  • Whether internal links are discoverable in the HTML, so a crawler can reach the rest of the site.
  • Whether Open Graph tags — which drive link previews — are present without JavaScript.

For agents and scripts, the same measurement is at /api/v1/ai?url=yoursite.com — see the API documentation.

Related questions

Does Google handle JavaScript?

Yes, but on a delay and not with certainty. It costs Google considerably more to render your page than to read it, and rendering is queued separately from crawling. Server-rendering makes you cheaper to index, which is not a neutral fact.

What about React or Vue — do I have to abandon them?

No. Both render perfectly well on the server. This is a rendering-strategy question, not a framework question. Next.js, Nuxt, Remix and Astro all exist to solve exactly this.

Is prerendering the same as server-side rendering?

Close enough for this purpose. Prerendering generates HTML at build time, SSR generates it per request. Either puts the content in the response, which is all a crawler needs. Choose based on how often your content changes.

Read next

All 50 guides · How every check works · API for agents