Citevera
Run free audit
All posts
6 min read

SSR vs CSR for AI Crawlers: Why JavaScript Rendering Decisions Matter for AEO

AI crawlers vary dramatically in their JS execution. Here is what each major crawler renders, what it ignores, and how to architect for both.

A diagram comparing server-side rendering and client-side rendering paths with AI crawler bots labeled by which content path each one consumes.

If your site is built on React, Vue, or any modern JS framework, the rendering decision (SSR, SSG, ISR, or pure CSR) directly determines what AI crawlers can read. Get it wrong and your most important content is invisible to the engines that decide whether to cite you. Most teams optimize SSR/CSR for Googlebot and assume AI crawlers behave the same way. They do not.

This post covers what each major AI crawler does with JavaScript, the rendering modes that work, and the architecture decisions that matter most.

What SSR vs CSR actually means in 2026

Quick refresher with the variants that matter:

  • SSR (server-side rendering) - HTML is generated on the server for each request and shipped fully formed.
  • SSG (static site generation) - HTML is generated at build time and served as static files.
  • ISR (incremental static regeneration) - SSG with on-demand re-renders for changed content.
  • CSR (client-side rendering) - the server ships an empty HTML shell with JS bundles; the browser renders the page after fetching data.

For AEO, SSR, SSG, and ISR are functionally equivalent: the crawler receives complete HTML on the first request. CSR is the variant where AI crawlers struggle.

Which AI crawlers execute JavaScript

This is the key question. As of 2026, the answer varies:

| Crawler | JS execution | Notes | |---|---|---| | GPTBot (OpenAI) | Limited | Executes inline scripts in some cases; does not reliably hydrate React/Vue/Svelte apps. | | ClaudeBot (Anthropic) | Limited | Similar profile to GPTBot for hydration; reads SSR/SSG cleanly. | | PerplexityBot | Limited | Optimized for fast retrieval; CSR-only pages frequently miss content. | | Google-Extended | Yes | Inherits Googlebot's rendering pipeline including JS execution. | | Applebot-Extended | Limited | Uneven; assume CSR will be partial. |

The pattern: only Google-Extended reliably executes JS on the level needed for hydrated SPAs. The other major AI crawlers either skip JS or execute a subset that misses framework-rendered content. This is materially different from Googlebot's well-understood rendering capability.

What "limited JS execution" actually means in practice

Three behaviors you can observe:

1. The crawler reads the initial HTML response. Anything in the static HTML is captured. 2. The crawler does not wait for DOMContentLoaded or load events. Hydration that depends on these events may not complete. 3. The crawler does not run async data fetches. A component that calls useEffect to fetch and render content typically misses extraction.

The practical implication: a CSR-only site delivers a near-empty HTML response to AI crawlers, which then have nothing to extract. The site is technically reachable but functionally invisible.

How to test what AI crawlers see

Three techniques:

Curl with the crawler's user-agent


curl -A "GPTBot/1.0 (+https://openai.com/gptbot)" https://your-site.example/page

Compare the response to what you see in a browser. If the curl output is mostly empty <div id="root"></div> while the browser shows content, you have a CSR problem.

View source vs DevTools Elements panel

In Chrome, "View source" shows what the server initially sent. The Elements panel shows the live DOM after JS has run. The gap between the two is what AI crawlers (without full JS) miss.

Server logs for crawler requests

Filter your access logs by AI crawler user-agents. Note the response sizes and status codes. Consistently small response sizes for content-rich pages signal that you are serving thin HTML to crawlers.

Rendering modes that work for AEO

Three patterns, in order of recommendation:

SSG (static site generation)

The strongest pattern for AEO. Pages are rendered to static HTML at build time. AI crawlers receive complete HTML. No runtime cost, no JS execution dependency.

Best for: marketing sites, blogs, documentation, glossaries, landing pages. Most content that does not change per-user is a candidate.

Frameworks: Next.js (getStaticProps), Astro, Hugo, 11ty, Gatsby, Jekyll.

SSR (server-side rendering)

Strong pattern. Each request returns complete HTML rendered on the server. Slightly higher infrastructure cost than SSG but still delivers full HTML to AI crawlers.

Best for: pages that need fresh data per request (real-time pricing, dynamic comparisons, personalized content).

Frameworks: Next.js (getServerSideProps), Remix, SvelteKit, Nuxt.

ISR (incremental static regeneration)

Hybrid. Pages are SSG by default, regenerated on-demand or on schedule. Combines SSG's crawler-friendliness with SSR's freshness for changing content.

Best for: high-traffic pages with content that changes daily or weekly (blog index, product catalogs).

Frameworks: Next.js (revalidate option), Vercel ISR, Netlify on-demand builders.

Rendering modes that fail for AEO

Pure CSR (client-side rendering)

Avoid for any content that needs to be cited. The HTML response is mostly empty; AI crawlers extract nothing.

If you must use CSR (interactive web apps, dashboards, authenticated portals), separate your marketing surface (which should be SSR/SSG) from your app surface. Citevera, SiteAnswerAI, and most B2B SaaS sites do this: marketing on Astro or Next.js SSG, app on a CSR React or Vue bundle behind authentication.

Single-page apps with React Router and no SSR

A common architecture for early-stage products. Works for Googlebot's rendering pipeline but loses on AI crawlers. Migrate marketing pages to SSR/SSG before content investment compounds.

Hybrid architectures: marketing SSG + app CSR

The pattern most growing SaaS companies converge on:

  • acme.example and acme.example/blog/* and acme.example/docs/* - SSG with Astro, Next.js, or similar.
  • app.acme.example - CSR React/Vue bundle, behind authentication, never indexed.
  • acme.example/pricing, acme.example/customers, acme.example/integrations - SSG.

This separates the AEO surface from the app surface cleanly. Marketing earns citations; the app handles user interaction.

What about hydration?

Hydration is the process by which a server-rendered page becomes interactive client-side. For AEO, hydration is irrelevant because crawlers extract content from the initial HTML. As long as your initial HTML is complete, hydration mistakes only affect users, not crawlers.

The exception: if your hydration logic mutates the DOM significantly (replacing server-rendered content with different client-rendered content), there is a risk crawlers extract one version while users see another. Avoid this pattern for any content you want cited.

Tooling that helps

Three tools worth using:

  • Lighthouse has a "Mobile usability" check that flags content rendered after the initial response.
  • Vercel/Netlify build logs show which pages were SSG vs SSR vs ISR after each deploy.
  • A simple curl-based crawler-emulator script in CI that fails the build if a marketing page returns less than N kilobytes of body content under a crawler user-agent.

The CI check is the most valuable. It catches regressions where someone accidentally introduces a CSR pattern in a previously SSG page.

Migration playbook for an existing CSR site

If you are stuck on a CSR site and want to migrate:

1. Audit which pages need AEO citation. Marketing, blog, docs, glossary. Probably not the app. 2. Pick a target framework. Astro for content-heavy sites. Next.js for hybrid app-and-content. SvelteKit if you are already in Svelte. 3. Migrate routes in priority order. Start with the homepage, blog index, and top 10 pillar pages. These produce most of your AEO value. 4. Run the curl-based crawler test before/after. Verify response sizes go from 5KB shells to 30 to 80 KB content-rich HTML. 5. Monitor citation pickup. Most sites see new citations within 30 to 60 days post-migration as crawlers re-index.

The migration is rarely a one-week job, but the citation lift typically justifies a quarter of focused work for sites where AEO is strategic.

Key takeaways

  • Most AI crawlers in 2026 do not reliably execute JS at the level required for CSR-only sites.
  • SSG, SSR, and ISR all work for AEO; CSR does not.
  • Test with curl using crawler user-agents to see what your site actually serves.
  • Adopt hybrid architectures: marketing on SSG, app on CSR behind authentication.
  • A CI check that flags thin HTML responses prevents regressions.

What to do next

Run a free audit at scan.citevera.com to see whether your top pages serve content-rich HTML to AI crawlers or thin shells. The report flags pages where the initial response is below the threshold for citation extraction.

For the broader crawler picture, AI crawler user agents in 2026 covers each crawler's behavior and the allowlist patterns.

Related reading