SEO for JavaScript-rendered sites: CSR, SSR, and SSG

Modern search engines, Google specifically, do execute JavaScript when crawling a page — this isn't the early-2010s problem where a JavaScript-heavy site was invisible to search entirely. The real, current issue is subtler: rendering happens in a separate, deferred stage, and it doesn't always behave identically to what a real browser does.

What a client-side-rendered (CSR) page actually sends first

<!-- The raw HTML a crawler initially receives from a pure CSR React app -->
<div id="root"></div>
<script src="/static/js/bundle.js"></script>

This is genuinely close to the entire initial HTML response for a traditional client-side-rendered single-page app — the actual content only exists after JavaScript runs and populates #root. Googlebot handles this in two passes: an initial crawl of this empty shell, then a second, deferred rendering pass (queued separately, sometimes with a real delay of hours to days under high load) that actually executes the JavaScript and sees the real content. Other crawlers — social media link-preview bots, many SEO auditing tools, some AI crawlers — often don't execute JavaScript at all, and see only the empty shell shown above, permanently.

Why server rendering removes the risk rather than reducing it

// A Server Component (Next.js App Router) — this content is in the
// initial HTML response, no client-side rendering pass required at all
export default async function PostPage({ params }) {
  const post = await getPost(params.slug);
  return <article><h1>{post.title}</h1><p>{post.content}</p></article>;
}

This is the real mechanism the Next.js series covers in depth — a Server Component's HTML is fully generated on the server, before the response ever reaches a crawler (or a browser). There's no deferred rendering pass to wait on, no dependency on a crawler successfully executing JavaScript correctly: the content that matters for indexing is present in the very first response, identically to a plain static HTML page from the search engine's perspective.

SSG, SSR, and ISR — the same SEO benefit, different tradeoffs

The Next.js series' rendering strategies part covers Static Site Generation, Server-Side Rendering, and Incremental Static Regeneration as a performance and freshness tradeoff — from an SEO standpoint specifically, all three share the identical advantage over pure client-side rendering: real content in the initial HTML, every time, regardless of which one a given page uses.

A practical middle ground: hydration, not a rewrite

A large existing CSR app doesn't necessarily need a full framework migration to fix this. Server-side rendering the initial HTML (with a tool that supports it) while the app "hydrates" into a fully interactive client-side app afterward gets the SEO benefit — real content in the first response — without discarding the existing client-side architecture entirely. This is effectively what frameworks like Next.js do by default, but the same principle applies to a retrofit on an existing app, not only a ground-up rebuild.

Verifying what a crawler actually sees

Google Search Console's URL Inspection tool (part 20) includes a "View Crawled Page" option showing the actual rendered HTML Googlebot captured — the single most direct way to confirm content is genuinely present after rendering, rather than assuming it based on how the page looks in a regular browser tab.

The technical SEO fundamentals are covered. Next: off-page SEO — everything covered so far has been fully within a site owner's control; backlinks are the first factor that genuinely isn't.