What is SSR (Server-Side Rendering)?
Definition
SSR (server-side rendering) means generating a web page's HTML on the server for each request and sending it to the browser with its content already in place. The browser can show text and links before any JavaScript runs, and search engines and other crawlers find the content directly in the HTML response. In modern frameworks SSR is usually paired with hydration, which makes the page interactive.
Also known as: server rendering, server-rendered HTML, universal rendering
Rendering strategies: CSR, SSR, SSG and ISR
"Rendering" here means combining data and templates into the HTML the browser displays. Where and when that happens shapes a site's speed, its server costs and what search engines see.
| Approach | Where and when HTML is produced | Good fit for |
|---|---|---|
| CSR (client-side rendering) | In the browser; the server mostly sends an empty shell plus a JavaScript bundle | Logged-in dashboards, app screens that don't need to rank |
| SSR | On the server, per request | Pages that vary by user, location or live data |
| SSG (static site generation) | Once, at build time | Articles, company pages, documentation |
| ISR (incremental static regeneration) | At build time, then regenerated in the background after a set interval or on demand | Catalog and content pages that change often but needn't be real-time |
ISR is Next.js terminology; other frameworks offer similar behaviour under different names. Real projects mix these approaches: marketing pages static, account screens client-rendered, product pages server-rendered.
SSR step by step
- The browser requests a URL.
- The server fetches the data it needs from a database or API and renders the components to HTML.
- The complete HTML is sent back, and the browser can paint it immediately.
- If the page needs interactivity, JavaScript loads and attaches to the existing HTML, a step called hydration.
Some frameworks stream the HTML instead of sending it in one piece: ready parts go out immediately, and sections waiting on slow data are added as they resolve.
What it means for SEO
With SSR or static generation, the main content, headings, internal links and meta tags are in the first HTML response. Google can run JavaScript, but it crawls first and renders in a separate step that can be delayed, and a single script error can stop content from appearing at all; the JavaScript SEO entry covers this in depth. Assuming JavaScript will be executed is riskier still for other search engines and many AI crawlers: if the content isn't in the raw HTML, those systems may see an empty page.
Google's official documentation states that dynamic rendering, serving a server-rendered version only to bots, was a workaround rather than a long-term solution, and recommends server-side rendering, static rendering or hydration instead. Google has not said that SSR is a ranking advantage in itself; the benefit comes from content being reliably accessible and usually displayed sooner.
Costs and caveats
- Server load: rendering on every request costs compute. For pages that rarely change, SSG, ISR or a cache is often more efficient.
- Time to first byte: if the server waits on a slow data source, the response starts late, which also delays LCP.
- Visible but unresponsive: after the HTML paints, buttons may not respond until hydration finishes; large JavaScript bundles stretch that gap.
- Browser-only code:
windowandlocalStoragedon't exist on the server. Touching them during render causes errors or mismatches between server and client output.
How to check it
A simple test: view the page source, or fetch it with curl, and check whether the main text, the H1 and internal links are in the raw HTML. Search Console's URL Inspection tool shows the HTML Google rendered. Doruva's SEO Checker also reports differences between the raw response and the browser-rendered page as separate findings.