The Rendering Problem
Modern web apps built with React, Vue, or Angular create content in the browser using JavaScript. Google can crawl JavaScript, but not perfectly or instantly. This creates an SEO problem that costs rankings and traffic if not addressed.
Server-side rendering (SSR) solves this by generating HTML on the server before sending it to the browser — exactly what static HTML did in 1999, but with the power of modern frameworks.
How Google Actually Crawls JavaScript
Googlebot crawls in two phases:
Crawl: Googlebot downloads the HTML. If it's a client-side app, this HTML may be near-empty (just a
<div id='root'></div>).Render: Days or weeks later, Googlebot processes the JavaScript and renders the full page.
The delay between crawl and render is the problem. During that window, Google indexes an empty or incomplete page. New content takes weeks to appear in search results. Dynamic content (personalized, filtered, paginated) may never be properly indexed.
The Four Rendering Approaches
Static Site Generation (SSG)
HTML is generated at build time. Fastest load, perfect SEO, but content only updates when you redeploy.
Best for: Marketing pages, blog posts, documentation — anything that doesn't change frequently.
// Next.js: generate at build time
export async function generateStaticParams() {
const posts = await getPosts()
return posts.map(p => ({ slug: p.slug }))
}
Server-Side Rendering (SSR)
HTML is generated on every request. Content is always fresh. SEO-perfect since Google receives complete HTML immediately.
Best for: Pages with user-specific data, frequently changing content, e-commerce product pages.
Cost: Every request hits your server. More expensive at scale.
Incremental Static Regeneration (ISR)
HTML is generated at build time and cached, but regenerates in the background at a set interval.
Best for: Most SaaS marketing sites and blogs. You get static speed with fresh content.
// Regenerate this page every 60 seconds
export const revalidate = 60
Client-Side Rendering (CSR)
HTML is minimal; JavaScript builds the page in the browser.
Best for: Authenticated app dashboards, admin panels, anything behind login (Google doesn't need to index these).
What Google Can and Can't Index
Can index: SSG pages immediately. SSR pages immediately. ISR pages after first regeneration. Simple CSR pages after render queue delay.
Struggles with: Complex CSR apps with lazy loading. Infinite scroll content. Content requiring user interaction to reveal. JavaScript-heavy navigation that doesn't update the URL.
The practical rule: If a page needs to rank in Google, render it on the server. If it's behind authentication and doesn't need to rank, CSR is fine.
Core Web Vitals and Rendering
Google uses Core Web Vitals as ranking signals. Rendering approach affects all three:
LCP (Largest Contentful Paint): SSG/SSR pages show content faster → better LCP. FID/INP (Interaction to Next Paint): Less JavaScript to parse on load → better scores. CLS (Cumulative Layout Shift): Server-rendered content doesn't shift as JavaScript loads → better CLS.
A well-configured Next.js site with SSG for marketing pages and ISR for dynamic content typically scores 90+ on all Core Web Vitals.
The Next.js Default
Next.js App Router makes good rendering decisions easy:
- By default, all components are Server Components (render on server)
- Add
'use client'directive only when you need browser APIs or interactivity - Use
fetchwith Next.js caching to control revalidation
This default-server-first approach means your SEO is correct by default, and you opt into client rendering only where necessary.
Quick Audit for Your Current Site
- Open your homepage in a browser with JavaScript disabled (Chrome DevTools → Settings → Disable JavaScript)
- Is the content visible? If yes, you're good. If not, Google sees what you see.
- Use Google Search Console → URL Inspection → 'Test Live URL' → 'View Tested Page' to see exactly how Google renders your page
This test reveals rendering issues faster than any tool.
