The rendering method you choose for your website is one of the most consequential technical decisions you will make — and it is often made by default rather than by design.
Most developers reach for what they know. React developers spin up a Vite project and get client-side rendering. WordPress developers get server-side rendering automatically. Teams evaluating Next.js discover they can do all three. And without a clear framework for evaluating these choices, many sites end up with an architecture that works well for developers but performs poorly for crawlers.
This article gives you that framework. We will define all three rendering methods clearly, compare their performance characteristics, and evaluate each one specifically for SEO and AI search visibility — so you can make the right choice for your situation.
SSR Explained: Server-Side Rendering
Server-side rendering (SSR) means the server generates the complete HTML for a page on each request and sends that finished HTML to the browser.
How It Works
- A user (or crawler) requests a URL
- The request reaches the server
- The server runs application code, fetches any required data, and assembles a complete HTML document
- The complete HTML — with all content, metadata, and structured data included — is sent in the HTTP response
- The browser displays the page immediately, then loads JavaScript to add interactivity
The HTML that arrives in the browser is fully populated. There is no waiting for JavaScript to build the page. The content exists in the response from the first millisecond.
Common SSR Implementations
- Next.js —
getServerSideProps(Pages Router) or async Server Components (App Router) - Nuxt.js — Vue-based SSR framework
- SvelteKit — server rendering with Svelte components
- Remix — full-stack React framework with SSR by default
- WordPress — PHP renders complete HTML on every request (the original SSR)
- Traditional web frameworks — Rails, Django, Laravel, Express with template engines
Strengths of SSR
- Complete HTML on first response — fully readable by all crawlers immediately
- Dynamic content — each request can serve personalized or real-time content
- Fresh data — the server fetches current data on each request; no rebuild required for content changes
- Fully crawlable — both Googlebot and AI crawlers receive complete content
Weaknesses of SSR
- Server load — every page request requires server computation
- Latency — the server must finish rendering before the browser receives anything, adding time to the first byte
- Infrastructure complexity — requires a running server, not just static file hosting
- Caching required — without caching, high traffic can overwhelm the server
CSR Explained: Client-Side Rendering
Client-side rendering (CSR) means the server sends a minimal HTML shell, and JavaScript running in the browser builds the page content after it arrives.
We covered CSR in depth in the previous article. Here is the summary:
How It Works
- Request arrives at server
- Server responds with a near-empty HTML file containing a
<div>placeholder and<script>tags - Browser downloads JavaScript bundles
- JavaScript executes and builds the page content in the browser
- Page becomes visible
Common CSR Implementations
- Create React App — CSR by default
- Vite (with React, Vue, or Svelte) — CSR by default
- Angular — CSR by default
- Vue CLI — CSR by default
Strengths of CSR
- Rich interactivity — full SPA experience with smooth, app-like navigation
- Simple hosting — static files served from a CDN, no server required
- Decoupled architecture — frontend and backend are fully independent
- Great developer experience — large ecosystems, fast local development
Weaknesses of CSR
- Empty initial HTML — no content in the server response for crawlers
- Poor AI crawlability — AI crawlers receive nothing meaningful
- Delayed Google indexing — Google’s two-wave rendering introduces indexing lag
- Slow initial load — users must wait for JavaScript to download and execute before seeing content
- SEO risk — content-dependent on JavaScript execution is inherently fragile for search visibility
SSG Explained: Static Site Generation
Static site generation (SSG) means all pages are pre-built as complete HTML files at deploy time and served directly from a CDN.
How It Works
- At build time, the framework generates HTML for every page (fetching data from APIs, CMSes, or files as needed)
- The finished HTML files are deployed to a CDN
- When a user (or crawler) requests a URL, the CDN serves the pre-built HTML file instantly
- No server-side computation happens at request time — the file is already done
Common SSG Implementations
- Next.js —
getStaticPropsandgenerateStaticParams(orexport const dynamic = 'force-static'in App Router) - Astro — SSG-first framework with optional islands of interactivity
- Gatsby — React-based SSG
- Hugo — extremely fast SSG (written in Go)
- Jekyll — the original static site generator
- Eleventy (11ty) — lightweight, flexible SSG
Strengths of SSG
- Fastest possible delivery — pre-built files served from CDN edge nodes globally
- Perfect crawlability — complete HTML exists before any request is made
- Lowest hosting cost — static files are cheap to serve at scale
- Excellent Core Web Vitals — TTFB is typically under 50ms from CDN edge
- Zero server load at request time — no computation required per request
Weaknesses of SSG
- Content requires rebuilds — when content changes, a new build must be deployed for changes to appear
- Not suitable for dynamic content — personalized pages, real-time data, and user-generated content cannot be truly static
- Build time scales with page count — sites with tens of thousands of pages can have long build times
- Preview complexity — content editors cannot preview unpublished changes without a preview environment
ISR: Incremental Static Regeneration
Next.js introduced a hybrid called Incremental Static Regeneration (ISR) that addresses SSG’s rebuild limitation. With ISR, pages are pre-built statically but regenerated in the background at defined intervals (e.g., every 60 seconds) or on demand when content changes.
ISR delivers static-speed performance for most requests while keeping content relatively fresh — without requiring a full site rebuild on every change. It is one of the most practical solutions for large content sites that need both performance and freshness.
Performance Comparison
How each rendering method performs for the metrics that matter most to users and crawlers:
| Metric | SSR | CSR | SSG |
|---|---|---|---|
| Time to First Byte | 200–800ms | 50–200ms (shell) | 20–100ms |
| Time to Interactive | Fast | Slow (JS load) | Very Fast |
| Largest Contentful Paint | Good | Poor | Excellent |
| Hosting complexity | High | Low | Very Low |
| Infrastructure cost | Medium–High | Low | Very Low |
| Scales under traffic | Needs caching | Excellent | Excellent |
| Content update speed | Instant | Instant | Requires rebuild |
Notes on the table:
- CSR’s fast TTFB is deceptive — the shell HTML arrives quickly, but it contains no content. Users still wait for JavaScript before they see anything.
- SSR’s TTFB can be reduced significantly with caching. A CDN-cached SSR response can approach SSG speeds while retaining SSR’s dynamic capabilities.
- SSG’s rebuild requirement is mitigated by ISR in Next.js and similar approaches in other frameworks.
SEO and AI Crawlability Comparison
This is where the architectural choice has the most direct impact on visibility:
| Dimension | SSR | CSR | SSG |
|---|---|---|---|
| Googlebot crawlability | Excellent | Limited (Wave 2) | Excellent |
| AI crawler crawlability | Excellent | Poor — near zero | Excellent |
| Initial HTML content | Complete | Empty shell | Complete |
| Schema markup delivery | Server-rendered | Risk of JS dep. | Pre-rendered |
| Indexing speed | Fast | Slow | Very Fast |
| Freshness for retrieval | High (per request) | N/A (not crawled) | Medium (rebuild) |
| Dynamic personalization | Full | Full | Not supported |
| GEO readiness | High | Low | High |
| Ideal content type | Dynamic, personalized | Apps, dashboards | Blogs, docs, marketing |
The Verdict by Use Case
For a content blog or marketing site: SSG wins. Pages are pre-built, delivered instantly from CDN, fully readable by all crawlers, and require no server infrastructure. Build times for typical blog sizes (under 5,000 pages) are fast enough that rebuilds on content changes are practical.
For a news site or e-commerce store with frequently changing content: SSR wins. Product prices, inventory, and breaking news need to be current on every request. SSG’s rebuild cycle is too slow for content that changes minute-to-minute. SSR with caching delivers fresh content without the crawlability penalty of CSR.
For a SaaS product’s marketing and documentation site: SSG or SSR both work. SSG is simpler and faster; SSR offers more flexibility for personalization and A/B testing. Next.js with ISR is a common choice — static by default, regenerated on a schedule.
For a web application (dashboard, tool, authenticated interface): CSR is appropriate. Crawlability is irrelevant for authenticated pages. CSR’s developer experience advantages and rich interactivity benefits apply here without the visibility cost.
The rule that applies in all cases: any page whose visibility to search engines or AI systems matters must deliver its content in the initial HTML response. SSR and SSG both satisfy this requirement. CSR does not.
Choosing Your Rendering Strategy
The decision is rarely all-or-nothing. Most modern web properties use different rendering strategies for different parts of the site:
yourproduct.com/ → SSG (homepage, marketing)
yourproduct.com/blog/ → SSG (content pages)
yourproduct.com/docs/ → SSG (documentation)
yourproduct.com/pricing/ → SSR (dynamic pricing)
app.yourproduct.com/ → CSR (authenticated application)This is not over-engineering — it is matching the architecture to the requirement. Each section of the site has different needs: the marketing site needs crawlability and performance, the app needs interactivity and real-time data.
Next.js makes this particularly practical because it supports SSR, SSG, and ISR within the same framework, with the rendering method defined per page or per route. A single Next.js codebase can handle all of the above.
The One Rule That Overrides Everything
Rendering methods come with tradeoffs. Performance, hosting cost, freshness, interactivity — these all vary by approach.
But for search visibility and AI crawlability, there is one rule that overrides all other considerations:
Content that does not exist in the initial HTML response does not exist for crawlers.
SSR puts content in the initial response. SSG puts content in the initial response. CSR does not.
Everything else — schema markup, internal linking, content quality, keyword strategy, structured data — builds on this foundation. If the foundation is missing, nothing built on top of it will compensate.
Next: Why Server-Side Rendering Matters for Generative Engine Optimization →
← Previous: Why Client-Side Rendered Websites Can Lose Visibility in AI Search
This article is part of a 20-article series on SEO, GEO, and AI Visibility. View the complete series →
Leave a Reply