Rendering for SEO: SSR, SSG, CSR and prerendering

The JavaScript and technical SEO guide in this section explains why Google processes HTML in two phases and what breaks when content depends on a JavaScript execution. This guide steps back and compares, at the architecture level, the strategies that exist to avoid that problem from the project's design stage onward: it isn't a question of "which framework to use" but of "where and when the HTML gets generated," a decision that affects performance, infrastructure cost and development complexity far beyond SEO.

Client-Side Rendering (CSR): the starting point and its real costs

In CSR, the server delivers an almost empty HTML shell and the browser runs JavaScript to build the whole page. The upside is a very simple deployment architecture (the server only serves static JavaScript files, with no need to run code per request) and a very smooth navigation experience once the app has loaded, since transitions don't require reloading the full document. The cost, beyond what's already covered in the JavaScript and SEO guide (the gap between crawling and rendering), is a technically fast but misleading Time to First Byte: the server responds right away, but visible content takes far longer to appear because the JavaScript still has to download, parse and execute, which directly hurts Core Web Vitals metrics like LCP.

Server-Side Rendering (SSR): complete HTML on every request

SSR generates the complete HTML on the server, data already inserted, on every individual request. This solves the indexing problem at the root (the crawler gets real content from the first byte, with no dependency on any later rendering phase) and improves perceived LCP because the browser has content to paint immediately. The cost is twofold: every request requires server compute time (querying data, running the rendering logic, generating the HTML) before it can respond, which raises real TTFB compared to serving a static file; and the required infrastructure is more complex and expensive than serving static files, since it needs an always-on server runtime (Node.js or another runtime) able to scale under load, not just a file server.

Static Site Generation (SSG): the same HTML, generated in advance

SSG generates that same complete HTML, but at build time, before any real request arrives, and then serves it afterward as pure static files. The result is the best possible TTFB (no compute at all at request time, just delivery of an already-generated file) and the lowest hosting cost, since a static-file CDN is cheaper and simpler to scale than a server runtime. The cost shifts to the build process: if the site has thousands of pages, regenerating all of them when a single piece of data changes (a price, a blog entry) can take minutes or hours, and that build time becomes the project's new bottleneck instead of the user's request.

Cost paid...                              CSR    SSR    SSG
TTFB (time to first byte)                 low    medium low
Visible content / real LCP                slow   fast   fast
Infrastructure complexity                 low    high   low
Hosting cost at scale                     low    high   low
Content freshness                         full   full   per build
Cost of a single data change              none   none   full rebuild*

*without ISR: see next section

Incremental Static Regeneration (ISR): trying to get both

ISR exists specifically to solve SSG's problem on large sites: instead of regenerating the entire site every time a piece of data changes, each static page carries an associated lifetime (for example, "this page can be served as-is for 60 seconds"); once that time passes, the next request still gets the already-generated version (no waiting), but triggers a background regeneration of that specific page, which replaces the old one for subsequent requests. The practical result is TTFB as good as pure SSG's (the user is never made to wait for the HTML to be generated) combined with freshness close to SSR's, without paying the cost of regenerating the entire site on every change. The added complexity is correctly managing that lifetime per page type (not all content needs the same freshness) and accepting that, for a short window, some users may see a slightly outdated version while the background regeneration finishes.

Dynamic rendering / prerendering: the patch, not the solution

Before SSR and SSG became as accessible as they are today, an intermediate technique gained popularity: dynamic rendering, which detects whether the requester is a crawler (via user-agent) and, only in that case, serves it an already-rendered version of the HTML generated in advance by an external service, while real users keep getting the normal CSR app. Google went as far as documenting this technique as an acceptable short-term fix for sites that couldn't afford to migrate their architecture, but has been deprioritizing it as a recommendation as Google's own rendering has improved, and it's worth understanding it for what it is: a temporary patch, not a target architecture. The technical risk is serving different content depending on who's asking, which conceptually borders on cloaking if the content served to bots diverges substantially from what real users see; done honestly (same content, just pre-rendered ahead of time) it isn't cloaking, but it's a distinction that has to be actively watched, not assumed.

Which architecture fits which type of site

There's no universal answer, but there are clear patterns by project type. A large ecommerce site with thousands of SKUs, changing prices and real-time stock usually needs SSR (for product and cart pages, where data freshness is critical) combined with SSG or ISR for more stable content like category or brand pages. A blog or editorial content site, where content changes through deliberate publishing rather than in real time, almost always fits better with pure SSG or ISR with a generous lifetime, since SSR's infrastructure cost adds no real benefit over regenerating on publish. A web app with public, indexable parts (a landing page, help pages) and private parts behind login (the app's own dashboard) usually benefits from a hybrid approach: SSR or SSG for everything that needs indexing, and pure CSR for the authenticated area, where SEO doesn't apply and interaction smoothness is the priority.

Frequently asked questions