CSR vs SSR vs SSG vs ISR: an SEO comparison without the framework marketing

Every framework's docs will tell you its rendering mode is great for SEO. They're not lying, exactly. But "great for SEO" hides real trade-offs that matter for specific kinds of pages.

This post compares the four common strategies on the things that actually affect search: what HTML a crawler receives, how quickly changes show up, and the typical ways each one goes wrong.

The one test that matters most

Before comparing anything, here's how to see what a simple crawler sees on your site:

curl -s https://example.com/products/oak-chair | grep -o '<title>[^<]*</title>'
curl -s https://example.com/products/oak-chair | grep -c 'Oak Chair'

If your title, main heading and body text appear in the raw HTML, search engines don't need to run JavaScript to understand the page. If they only appear after JavaScript runs, you're relying on rendering, which works for Google most of the time, but later and less predictably, and may not work at all for other crawlers and link-preview bots.

1. CSR: client-side rendering

The server sends a nearly empty HTML shell. JavaScript fetches data and builds the page in the browser.

<!-- What curl sees -->
<html><head><title>Shop</title></head>
<body><div id="root"></div><script src="/app.js"></script></body></html>

SEO strengths: almost none specific to CSR. It's fine for pages that shouldn't be indexed anyway (dashboards, account pages).

SEO risks:

• Content and often titles/meta tags only exist after JavaScript runs.
• Status codes are usually all 200, even for "not found" pages, unless you handle that on the server.
• Social previews and many tools see the empty shell.
• Slower to show content on weak devices.

Use for: logged-in app screens. Avoid for pages you want found in search.

2. SSR: server-side rendering

The server builds full HTML for every request.

SEO strengths:

• Complete HTML immediately, with correct titles, meta tags and content.
• Real status codes per page (404 for missing products, 301 for moved ones), because the server knows.
• Always fresh: a price change is visible on the next request.

SEO risks:

• Server response time becomes your problem. A slow database means a slow first byte for every visitor and crawler.
• Load spikes (including from crawlers) hit your servers directly unless you cache.
• Hydration mismatches can cause content to flash or change after load.

Use for: pages that change often or are personalised but still public: search results you want indexed (carefully), live inventory, frequently updated listings.

3. SSG: static site generation

HTML is built once at deploy time and served as static files, usually from a CDN.

SEO strengths:

• Very fast, very reliable. Full HTML, served from close to the user.
• Hard to break at runtime: there's no server code to fail.

SEO risks:

• Content is only as fresh as the last build. Change a price, and it's wrong until you rebuild.
• Large sites can have long build times, which tempts teams to build less often.
• Status codes depend on your host's configuration. Make sure missing pages return a real 404, and set up redirects at the host level.

Use for: content that changes rarely: blogs, docs, marketing pages, most small business sites.

4. ISR: incremental static regeneration (and similar "stale-while-revalidate" approaches)

Pages are generated statically, then regenerated in the background after a set time or when triggered.

// A Next.js-style example: regenerate this page at most every 10 minutes
export const revalidate = 600;

SEO strengths:

• Static-like speed with content that stays reasonably fresh.
• Scales to large catalogues: pages can be generated on first request instead of all at build time.

SEO risks:

• Visitors and crawlers may see stale content for up to the revalidation window.
• Errors during regeneration can leave old content in place silently, or, depending on configuration, cache an error page.
• More moving parts: harder to reason about exactly what a crawler saw at a given moment.

Use for: large catalogues and content sites where minutes-old data is acceptable.

Side by side

	CSR	SSR	SSG	ISR
Full HTML without JS	❌	✅	✅	✅
Real per-page status codes	Hard	✅	Host config	Mostly
Content freshness	Live	Live	Last build	Within window
Speed for crawlers	Slow to content	Depends on server	Fast	Fast
Typical failure	Empty pages	Slow responses	Stale content	Silent staleness

Mixing strategies is normal

Most real sites shouldn't pick one. A sensible mix:

• SSG for the marketing site, blog and docs.
• ISR or SSR for product and listing pages.
• CSR behind login.

The mistake is applying one strategy everywhere because it was the framework default.

What to monitor whichever you choose

• Raw HTML contains the important content (the curl test above, automated for key templates).
• Status codes for missing and moved pages are correct.
• Freshness: for SSG/ISR, check that a recent change actually appears on the live page.
• Response times for SSR pages, especially under crawler load.

An SEO monitor such as seotto.com can watch titles, status codes and content across your important pages, so a rendering change that quietly empties them gets caught quickly.

Related reading

• JavaScript SEO FAQ: 11 questions frontend devs ask (with straight answers)
• View source vs Inspect element: the SEO bug hiding between raw and rendered HTML
• Image SEO: 7 things I'd do differently on the next big site (starting with hashed filenames)
• Breadcrumbs are the most underrated SEO component in your design system
• There is no duplicate content penalty (but duplicate content still costs you)

Which rendering strategy are your public pages using today, and was it a deliberate choice or the framework default? Have you been bitten by one of these failure modes? Let's compare in the comments.