Dynamic Rendering vs SSR vs Pre-rendering: Which One Fixes Your SPA's SEO?

The problem: your SPA is invisible to most crawlers

If your site is built with React, Vue, Angular, or any client-side JavaScript framework, most crawlers see an empty HTML shell instead of your content. Googlebot is the only major crawler that executes JavaScript — every AI crawler (GPTBot, ClaudeBot, PerplexityBot) and every social bot (LinkedIn, X, Facebook, Slack) sees nothing.

There are three established approaches to fixing this. Each has real trade-offs. This guide compares them honestly.

The three approaches at a glance

Server-Side Rendering (SSR)

How it works

With SSR, the server runs your JavaScript on every request and sends complete HTML to the browser. The browser then "hydrates" the page — attaching event listeners and making it interactive.

Frameworks like Next.js (React), Nuxt (Vue), SvelteKit (Svelte), and Remix (React) are built for this model.

When SSR is the right choice

• New projects. If you're starting from scratch, SSR is the cleanest architecture. Build with Next.js or Nuxt from day one.
• Highly dynamic content. Pages that change per-user or per-request (dashboards, personalized feeds) need server-side rendering.
• You have engineering resources. SSR frameworks require ongoing maintenance — server infrastructure, caching strategies, deployment pipelines.

When SSR is the wrong choice

• Existing SPAs. Migrating a working React SPA to Next.js is a rewrite, not an upgrade. Budget $30K–$80K+ and 2–4 months.
• Simple marketing sites. SSR is overkill if your site is mostly static content.
• Solo founders without backend experience. SSR adds server complexity. If you're using Cloudflare Pages or Netlify to host a static SPA, SSR means changing your entire hosting and deployment setup.

Trade-offs

• Pro: Complete solution. Every crawler gets full HTML.
• Pro: Better initial load performance (no JavaScript required for first paint).
• Con: Server costs (every request requires rendering).
• Con: Added complexity (caching, error handling, deployment).
• Con: Migration cost from existing SPA is high.

Static Site Generation (SSG)

How it works

SSG builds every page as a static HTML file at build time. When anyone visits — human or bot — they get the pre-built HTML file. No server-side rendering needed.

Tools like Astro, Gatsby, Hugo, and Next.js (static export) support this approach.

When SSG is the right choice

• Content sites. Blogs, documentation, marketing pages with content that changes infrequently.
• Performance-critical sites. Static files served from a CDN are as fast as it gets.
• Simple hosting. Deploy to Cloudflare Pages, Netlify, Vercel, or any static host.

When SSG is the wrong choice

• Dynamic applications. If your content changes per-user or per-request, SSG can't handle it.
• Large sites with frequent updates. Rebuilding thousands of pages on every content change is slow and wasteful.
• Existing SPAs with dynamic features. You can't SSG a dashboard or a personalized feed.

Trade-offs

• Pro: Excellent performance. No server needed.
• Pro: Every crawler gets full HTML.
• Pro: Simple and cheap to host.
• Con: Build times grow with page count.
• Con: Content is stale until the next build.
• Con: Not viable for dynamic applications.

Pre-rendering / Dynamic Rendering

How it works

A middleware layer sits between your site and incoming requests. When a crawler visits, the middleware renders the page (using headless Chromium or a similar browser engine) and serves the complete HTML. When a human visits, they get the normal SPA experience.

This is also called dynamic rendering — Google's own term for serving different content to bots vs. humans, as long as the content is the same (not cloaking).

Managed services

• CrawlReady — Cloudflare Worker that renders on the customer's own Cloudflare account. $9–$29/mo.
• Prerender.io — Managed rendering proxy. $49–$199/mo.
• LovableHTML — DNS-based rendering proxy. $19–$199/mo.
• DataJelly — Rendering proxy. $19–$75/mo.

DIY options

• Rendertron — Google's open-source rendering server. Free but requires your own infrastructure.
• Puppeteer + Lambda — Custom rendering pipeline on AWS. Free-ish but complex to maintain.

When pre-rendering is the right choice

• Existing SPAs. You have a working React/Vue/Angular app and need crawler visibility now.
• Speed matters. You need a fix in hours, not months.
• Zero code change tolerance. You can't (or don't want to) modify your application.
• AI builder apps. Sites built with Lovable, Bolt.new, or Base44 that you can't easily reconfigure.

When pre-rendering is the wrong choice

• New projects. If you're starting fresh, build with SSR from the beginning.
• You want a single architecture. Pre-rendering adds a middleware layer. Some teams prefer a single rendering path.

Trade-offs

• Pro: No code changes. Deploys in minutes.
• Pro: Works with any SPA framework.
• Pro: Human experience is completely unchanged.
• Con: Adds a middleware dependency.
• Con: Rendered content may lag behind the live site (depends on cache refresh frequency).
• Con: Some solutions route all traffic through a proxy (privacy/performance concern).

The cloaking question

A common concern: is serving different content to bots vs. humans considered cloaking?

No — as long as the content is the same. Google's own documentation explicitly endorses dynamic rendering as a legitimate approach. The key rule: the rendered HTML that bots receive must contain the same content that humans see. No hidden text, no keyword stuffing, no different content for bots.

Pre-rendering serves the same DOM that a browser would render — just as static HTML instead of requiring JavaScript execution. This is equivalent to what Googlebot's own rendering service does.

Decision framework

Choose SSR if:

• You're building a new project from scratch
• You have engineering resources for the migration
• Your content is highly dynamic and personalized
• You're comfortable with server infrastructure

Choose SSG if:

• Your site is primarily static content (blog, docs, marketing pages)
• Content changes infrequently
• You want the simplest, fastest hosting

Choose pre-rendering if:

• You have an existing SPA you can't or don't want to rewrite
• You need a fix this week, not in 3 months
• You built with an AI builder (Lovable, Bolt, Base44) and can't change the architecture
• You want zero risk to your existing application

The honest answer

For most existing SPAs where SEO and AI visibility matter, pre-rendering is the pragmatic choice. It solves the problem immediately without the cost and risk of a framework migration.

For new projects, SSR with Next.js or Nuxt is the right architecture. Build it right from the start.

For content-only sites, SSG with Astro or static Next.js export is the simplest path.

These aren't mutually exclusive — some teams use SSR for their main app and pre-rendering for legacy routes during a gradual migration.

Next steps

1. Run a CrawlReady audit to see your current visibility gap
2. Read our guide on React SPA SEO without migrating to Next.js for the React-specific deep-dive
3. Check our analysis of whether a Next.js migration is worth the cost for the detailed ROI calculation

This comparison reflects the rendering landscape as of March 2026. All approaches described are actively maintained and widely used in production.