TL;DR

For AI-friendly delivery, choose by content shape: SSG / ISR for marketing, docs, blogs, and rarely-changing pages; full SSR for personalized or session-aware pages; streaming SSR for pages with mixed fast and slow data sources; never CSR for content you want cited. Keep critical content above any boundary so it lands in the first network flush.

Why SSR matters for AI search

Non-Google AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Bytespider, Meta-ExternalAgent) do not execute JavaScript (Vercel, 2024). Their visible content set equals the response body of a single GET. SSR is the simplest way to guarantee that response body contains real content. SSG and ISR are precomputed flavors of the same idea — the user receives static HTML that any crawler can parse.

Googlebot does render JavaScript, but rendering is queued and inconsistent for high-churn or low-priority pages (Vercel + MERJ, 2024). Even for Googlebot, SSR shortens time-to-indexed-content.

Rendering strategies compared

flowchart TB
    subgraph build["Build time"]
        SSG["SSG: HTML at build"]
        ISR["ISR: HTML at build
+ background revalidate"]
    end
    subgraph req["Request time"]
        SSR["Full SSR: HTML per request"]
        STREAM["Streaming SSR: HTML in chunks"]
    end
    subgraph client["Client time"]
        CSR["CSR: shell + JS only"]
    end
    SSG --> AI["AI crawlers see content"]
    ISR --> AI
    SSR --> AI
    STREAM --> AI
    CSR --> NA["Non-Google AI crawlers see nothing"]

Streaming SSR done right

Streaming SSR (React 18+, Next.js App Router, Remix defer) sends the HTML shell to the browser before all data resolves, then streams the rest as boundaries finish (patterns.dev, 2024).

For AI eligibility, the rule is simple: the indexable content must land in the first flush. Place the headline, intro paragraph, and any key facts above . Wrap below-the-fold widgets (recommended posts, comments, recently viewed) in with skeleton fallbacks.

jsx

export default async function Page({ params }) {

const article = await getArticle(params.slug); // resolved before flush

return (

);

}

React Server Components (RSC)

React Server Components render server-side, never enter the client bundle, and can fetch data directly from databases or filesystems (React docs, 2025). For AI search, RSC is ideal: the server emits HTML, no "use client" needed for read-only content, no bundle cost.

Guidelines:

• Default every component to a Server Component. Add "use client" only when you need state, effects, browser APIs, or event handlers.
• Pass plain serializable props from server to client components.
• Keep "use client" boundaries small and leaf-positioned.

Framework decision matrix

Next.js (App Router)

• Default: Server Components + caching. Use export const revalidate = N for ISR.
• Personalized routes: full SSR by setting dynamic = 'force-dynamic' or reading cookies/headers.
• For static-friendly pages, prefer generateStaticParams to prebuild known slugs.
• Streaming: built-in via boundaries.

Remix

• SSR by default. Use loader for server data and defer for streaming.
• Designed for the Web Fetch API runtime; deploys to Node, Vercel, Cloudflare Workers, Deno (Hygraph, 2024).
• For ISR-like behavior, use HTTP cache-control with stale-while-revalidate.

Nuxt 3

• SSR by default. Configure ISR per-route with routeRules: { '/blog/**': { isr: 3600 } }.
• Use useAsyncData / useFetch for server-resolved data.
• Hybrid rendering supported: pick SSR, SSG, ISR, SWR, or CSR per route.

SvelteKit

• Default ssr: true in +page.ts/+layout.ts.
• For static-friendly routes, set prerender = true per page.
• Use load functions; do not fetch primary content from onMount.

Astro

• Zero-JS HTML by default — the most AI-crawler-friendly framework out of the box.
• Use island architecture: opt into JS only for components that need it.
• For dynamic data, add an SSR adapter (@astrojs/node, @astrojs/cloudflare, etc.).

Patterns to avoid

• Marking content components "use client" unnecessarily — turns SSR into CSR for that subtree.
• Fetching primary content with useEffect when SSR data fetching exists.
• Wrapping the entire page body in a single — delays critical content.
• Returning 200 OK with empty HTML before ISR has built the route. Use notFound() or a server-rendered fallback instead.
• Disabling SSR globally to fix one bug — fix the bug at component scope with dynamic({ ssr: false }).

Verifying SSR coverage

Use curl with an AI bot user-agent to confirm content is in the first response:

curl -A "Mozilla/5.0 (compatible; ClaudeBot/1.0)" 
  https://example.com/articles/my-post 
  | grep -E "<h1|<article|key sentence"

For CI: add a smoke test for top routes that asserts a known string appears in the SSR output.

FAQ

Q: Is SSG enough, or do I need full SSR?

For content that does not depend on the requesting user, SSG (or ISR) is enough and often preferable: cheaper, faster, and equally crawler-friendly.

Q: Does streaming SSR break AI crawler indexing?

No, as long as critical content is in the first flush. Crawlers read the body as it arrives. Below-the-fold streamed content is also indexed if the connection stays open until completion.

Q: Can I mix SSR and CSR on the same page?

Yes. Use Server Components for the article body and Client Components for interactive widgets. The article body remains crawlable; only the interactive parts require JS.

Q: What about Edge SSR vs regional SSR?

Edge SSR reduces latency and improves Web Vitals; both are equally crawlable. Pick edge when your data sources are also globally available; pick regional when you have a single primary database.

Q: Should I prerender every dynamic route at build time?

No. Prerender popular routes; use ISR or full SSR for the long tail. Prerendering tens of thousands of low-traffic routes at build is wasteful and slows deploys.

Q: Does AI search ranking improve with SSR alone?

SSR is necessary but not sufficient. It makes content discoverable; ranking still depends on content quality, structured data, citation worthiness, and Web Vitals.