What is server-side rendering?

Server-side rendering (SSR), explained

With client-side rendering, the server sends a mostly empty HTML shell plus a JavaScript bundle, and the browser builds the page. With SSR, the server runs the same components, fills in the data and sends complete HTML. The browser shows it right away, then JavaScript attaches event handlers so the page becomes interactive. That last step is called hydration.

For search, the benefit is certainty. The content, links, title, canonical and structured data are all in the first response, so Googlebot sees them during crawling without depending on the render queue, and crawlers that don't execute JavaScript see them too. Google's JavaScript SEO guide recommends server-side rendering or prerendering for exactly that reason. Google's dynamic rendering page also lists server-side rendering, static rendering and hydration as the long-term alternatives to its old workaround.

SSR has costs. Every request runs code on the server, so slow data fetching becomes slow Time to First Byte. Under load, or when an upstream API fails, SSR pages can return 5xx errors that a static page never would. That's why many teams render marketing pages statically and keep SSR for pages that truly change per request, like dashboards or search results.

In Next.js App Router, server components render on the server by default. A route becomes dynamic when it reads request-time data like cookies or headers, and static otherwise. Check which one your important pages are, because the framework's build output tells you.

Why it matters for founders

SSR is the fix when a client-rendered app isn't getting indexed. But for pages that are the same for everyone, static generation gives you the same SEO benefit with less to go wrong.

Example

Your integration pages were rendered in the browser from an API. You move them to server components that fetch data on the server. curl now shows full content, and Google indexes them faster.

Common mistakes

• Rendering on every request pages that could be static.
• Slow data fetching that pushes TTFB past a second.
• Hydration mismatches that re-render the page and shift layout.
• Assuming SSR alone fixes thin or duplicate content.