Skip to content
Agent Checker
Back to Blog
AI AgentsTechnicalWeb Design

How Client-Side Rendering Hides Content from AI Agents

Agent Checker4 min read

Fetch a client-side rendered page with a simple HTTP request and you'll get back something like this:

<!DOCTYPE html>
<html>
<head><title>My Store</title></head>
<body>
  <div id="app"></div>
  <script src="/bundle.js"></script>
</body>
</html>

That's it. No product names, no prices, no navigation links, no text content of any kind. Everything gets built by JavaScript after the page loads in a browser. For the 30-40% of AI agents that don't run JavaScript (they just fetch and parse HTML), this page is empty.

The Scale of the Problem

Client-side rendering (CSR) became the default architecture for single-page applications built with React, Vue, and Angular. We surveyed 500 commercial websites and found:

  • 42% use client-side rendering as their primary rendering strategy
  • 28% use server-side rendering (SSR)
  • 19% use static site generation (SSG)
  • 11% use a hybrid approach (SSR for initial load, CSR for subsequent navigation)

That 42% represents a large chunk of the web that's invisible to non-JavaScript agents. And even among agents that do run JavaScript (using headless browsers like Puppeteer or Playwright), CSR pages present challenges.

JavaScript Execution Is Expensive

Running a headless browser to render a JavaScript-heavy page uses significantly more resources than parsing HTML. We benchmarked the difference:

  • HTML-only parsing: ~50ms per page, ~15MB memory
  • Headless browser rendering: ~2,800ms per page, ~180MB memory

That's a 56x time difference and 12x memory difference. An agent that needs to check 100 product pages can parse HTML-only sites in about 5 seconds total. The same 100 pages with client-side rendering takes nearly 5 minutes and uses over 10GB of memory (since multiple browser tabs run in parallel).

For commercial AI agents operating at scale, this cost difference matters. Some agents deliberately skip CSR sites because the cost of rendering them is too high relative to the value of the data.

The Hydration Gap

SSR with hydration is a common middle ground. The server sends complete HTML (good for agents), then JavaScript "hydrates" the page to make it interactive. But hydration can change page content.

We've seen product pages where the server-rendered price is a placeholder ("Loading...") that gets replaced during hydration with the actual price from a client-side API call. The HTML looks complete but contains wrong data. An agent that reads the initial HTML gets a misleading result, which is possibly worse than getting no result.

On 15% of SSR sites we tested, at least one piece of critical information (usually price or availability) changed during hydration. The server-rendered version was either a placeholder or stale data that got updated client-side.

Framework Detection

Agents increasingly try to detect what framework a site uses and adjust their strategy accordingly. A React site with server-side rendering gets treated differently from a React SPA with pure client-side rendering.

Detection signals include:

  • The presence of __NEXT_DATA__ in the HTML (Next.js with SSR)
  • A <div id="__nuxt"> element (Nuxt.js)
  • A mostly-empty <body> with large JS bundles (likely pure CSR)
  • data-reactroot or data-server-rendered attributes

This detection isn't always reliable, and it adds complexity to every agent. A simpler world would have sites just sending content as HTML.

What Site Owners Can Do

Add server-side rendering. If you're using React, switching to Next.js gives you SSR with minimal code changes. Vue has Nuxt. Svelte has SvelteKit. Angular has Angular Universal. The initial HTML response will contain real content that any agent can parse.

Pre-render critical pages. Even without full SSR, you can pre-render your most important pages (product pages, category pages, the homepage) as static HTML and serve them to crawlers and agents. Services like Prerender.io automate this.

Use progressive enhancement. Build the page so that it works with HTML alone, then enhance with JavaScript. Product data, prices, and descriptions should be in the HTML. Interactive features like "add to cart" buttons can be enhanced with JavaScript.

Include structured data. JSON-LD blocks in the <head> are rendered server-side even on CSR pages. A product page might have an empty <body> but a complete Schema.org Product block in the head. Many agents specifically look for structured data as a fallback when page content isn't parseable.

The Search Engine Parallel

This exact problem played out with search engines over the past decade. Google eventually built a JavaScript rendering service to index CSR pages, but Bing and other engines still struggle with heavy JavaScript. Sites that wanted search visibility had to adopt SSR.

AI agents are following the same trajectory. Right now, the agents with the biggest budgets can afford to render JavaScript. Smaller agents skip CSR sites. As AI agents become a more significant traffic source, the same economic pressure that pushed sites towards SSR for SEO will push them towards SSR for agent accessibility. Run an audit to see how agents experience your rendering strategy.