Server-Side Rendering
Server-side rendering (SSR) is an approach in which the server builds the complete HTML for a page on each request from a user or search bot and sends it back ready to display. Because the content already lives in the HTML before the browser runs any JavaScript, search engines can read and index it immediately.
- Server-side rendering (SSR) generates the finished HTML on the server at request time, so search bots can read the content right away without executing any JavaScript.
- Google's official documentation states that "server-side rendering or pre-rendering is still a good idea," citing the fact that not every bot can run JavaScript.
- SSR delivers a fast First Contentful Paint, but heavy server computation can delay Time to First Byte, and the page stays non-interactive until hydration completes.
- SSR serves the same server-rendered HTML to every visitor, which sets it apart from dynamic rendering, where bots receive a different version than users.
- Combining CSR, SSR, SSG, and ISR according to the nature of each piece of content is the practical standard, and Google treats dynamic rendering as a stopgap rather than a recommended solution.
Overview
Server-side rendering (SSR) is a rendering approach in which, on every page request, the server executes JavaScript and responds with fully built HTML. The browser can paint the received HTML to the screen immediately, and search bots can likewise read the body text, metadata, and links straight away without having to run any JavaScript themselves.
This matters for SEO. Client-side rendering (CSR) initially sends little more than an empty HTML shell and lets the browser fill in the content with JavaScript, which means a search bot has to wait for that JavaScript to run before it can index the page. SSR skips this step, giving it greater indexing reliability.
How It Works
When a request arrives, the server renders the component tree into an HTML string and returns it in the response. In React, for example, the server streams the HTML with an API such as renderToPipeableStream, and the browser displays this static HTML immediately, then downloads the JavaScript and uses hydrateRoot to attach event listeners and make the page interactive. This final step is known as hydration.
According to web.dev's rendering strategies documentation, the hydration approach has a limitation: "the page may appear loaded and interactive, but it can't actually respond to input until the client-side scripts for that component have run." In other words, the screen appears quickly, but Time to Interactive depends on JavaScript execution.
Rendering Approaches Compared
| Approach | When HTML Is Generated | TTFB | SEO Indexing | Best-Suited Content |
|---|---|---|---|---|
| CSR (client render) | At runtime in the browser | Fast | Depends on the bot running JS (unfavorable) | Private screens such as post-login dashboards |
| SSR (server render) | On the server, per request | Can be delayed by server computation | Favorable (delivers finished HTML) | Frequently changing personalized or real-time pages |
| SSG (static render) | Pre-generated at build time | Very fast | Favorable (delivers finished HTML) | Rarely changing pages such as blogs and docs |
| ISR (incremental regeneration) | Regenerated on a set interval after build | Fast (cached) | Favorable | Large listings refreshed periodically |
CSR has a fast first byte, but Time to Interactive grows as the JavaScript bundle gets larger. SSG builds the HTML ahead of time at build, giving it the fastest TTFB, but it does not fit dynamic content that varies per request. SSR strikes a middle ground, reflecting request-time data while still delivering finished HTML. Frameworks like Next.js also offer approaches such as Partial Prerendering that combine these within a single page.
Distinction from Dynamic Rendering
A concept easily confused with SSR is dynamic rendering. Dynamic rendering is an approach in which the server detects whether the requester is a bot or a user and serves a different version to each, giving bots server-rendered HTML and users JavaScript-based content. SSR, by contrast, makes no distinction between bots and users and serves the same server-rendered HTML to everyone.
Google states that dynamic rendering "was a workaround for problems with JavaScript-generated content, not a long-term solution," and instead recommends server-side rendering, static rendering, and hydration. For a new project, then, going with SSR or SSG rather than dynamic rendering is the better choice.
SEO Benefits and Rationale
Google Search Central's JavaScript SEO basics documentation describes the indexing process in three stages: crawling, rendering, and indexing. During the rendering stage, Googlebot runs JavaScript with a headless Chromium, but this rendering passes through a separate queue between crawling and indexing, which can introduce delays. SSR provides finished HTML already at the crawling stage, reducing this dependence on rendering.
- Compatibility with all bots: Google's documentation notes that "not all bots can run JavaScript," explaining that server or pre-rendering ensures broader discoverability.
- Indexing reliability: Because the content is in the HTML from the start, it can be indexed immediately without being subject to the rendering queue.
- Performance: According to web.dev, SSR reduces the amount of JavaScript sent to the client, bringing First Contentful Paint forward and lowering Total Blocking Time, a benefit for both user experience and search engines.
Implementation Checklist
- Configure public, indexable pages (products, articles, landing pages) to deliver finished HTML through SSR or SSG.
- Use View Page Source to confirm that the title, meta description, canonical, and structured data are included within the server-rendered HTML.
- Avoid dynamic rendering or cloaking patterns that serve different content to bots and users, and deliver identical HTML instead.
- Mitigate TTFB delays caused by SSR with caching, a CDN, and ISR.
- Keep server and client render output consistent so that hydration mismatch errors do not harm SEO or UX.
References and Sources
- web.dev — Rendering on the Web (comparison of CSR, SSR, SSG, and hydration with performance trade-offs)
- Google Search Central — Understand the JavaScript SEO basics (the three stages of crawling, rendering, and indexing)
- Google Search Central — Dynamic Rendering (a workaround, not recommended)
- React — renderToPipeableStream (server streaming rendering)
- Next.js — Caching / Partial Prerendering (static shell and streaming rendering)