EngineeringGuide

SSR vs CSR: What It Means for Agent Readiness

Single-page apps are not inherently agent-hostile. The problem is how much truth exists before hydration. Here is the spectrum.

Lena Ortiz· Agent UX engineer2026-04-186 min read

There is a persistent myth that frameworks like React or Vue are “bad for SEO,” and now “bad for agents.” The truth is subtler: rendering strategy matters less than what the first byte of HTML contains.

The render spectrum

Static / pre-rendered: full content in the HTML file. Best case for agents.
SSR: content computed per request and sent in the initial HTML. Excellent.
Hybrid (SSG + client islands): content static, interactivity hydrates. Excellent.
Pure CSR: empty shell plus a bundle. The shell is what agents parse first.

A pure-CSR shell that fails agent checks

<body>
  <div id="root"></div>
  <script src="/main.js"></script>
  <script src="/vendor.js"></script>
</body>

<!-- vs. an SSR shell that passes -->
<main>
  <h1>Agent-ready docs</h1>
  <p>Searchable, semantic, and script-safe.</p>
</main>

Where agents get stuck

Two failure modes dominate. First, the agent’s snapshot is taken before hydration completes, so it parses a shell. Second, the page blocks on a slow API response and the agent times out waiting for content that should have been in the HTML.

Client-side only rendering is not a death sentence. But it makes the timeout race the deciding factor in whether an agent reads your page at all.

A pragmatic target

Render the core truth server-side — the headline, the main links, the primary form — and let JavaScript add everything else. Your audit’s “Read content without JavaScript” check is a good proxy: if it passes, agents will parse your page reliably.

See what agents read on your own site.

Run a free scan of any page and get a 0–100 readiness score with copy-pasteable fixes.

Run your first audit