Application frontends
What is server-side rendering?
Server-side rendering means a server builds the full HTML for a page before sending it to the browser or crawler, instead of shipping a near-empty page that JavaScript fills in later. It's faster on first load and more reliably readable.
Last reviewed 2026-08-16
The detail
The longer answer
Server-side rendering, usually shortened to SSR, is a way of building web pages where the server generates complete HTML for a given request and sends that finished page to whoever asked for it, whether that's a browser, a search engine crawler, or an AI assistant fetching content. The alternative, client-side rendering, sends a nearly blank HTML shell plus a bundle of JavaScript, and the browser has to run that JavaScript before any real content appears.
The practical difference shows up in three places. First, initial load: with SSR, a user sees content the moment the page arrives, because it's already built. With client-side rendering, they see a blank screen or a spinner until the JavaScript finishes fetching data and rendering it. Second, reliability of parsing: a server-rendered page hands over finished HTML, so anything reading it gets the real content without needing to execute code first. Third, resilience: if JavaScript fails to load, is blocked, or times out, an SSR page still shows its content, while a client-rendered page can show nothing at all.
There are a few flavors. Full SSR renders on every request. Static generation renders once at build time and serves the same HTML to everyone until the next build. Incremental approaches mix the two, rendering most pages statically and regenerating specific ones on a schedule or on demand. Frameworks like Next.js support several of these modes in the same application, which lets a team choose per-page rather than committing the whole site to one approach.
SSR isn't free. It requires a server or edge function to actually do the rendering work on each request (unless it's static), which adds infrastructure and complexity compared to a simple client-side app that can be hosted as flat files. It also requires more careful handling of things like caching, since you don't want to regenerate the same page for every visitor when nothing has changed.
The decision of whether to use SSR should be made per page or per section, not as a blanket rule for a whole application. Pages meant to be found through search, cited by AI assistants, or loaded quickly by first-time visitors generally benefit from server rendering. Logged-in, highly interactive views that no crawler needs to read, like an internal settings panel, can reasonably stay client-rendered if that's simpler to build and maintain.
The confusion we see most often is teams assuming their site is server-rendered because it looks fine to a person browsing it. A browser executes JavaScript, so a client-rendered page looks normal to a human. Whether it's actually server-rendered only becomes obvious when you check what HTML is returned before any JavaScript runs, which is exactly what a crawler sees.
Key points
What to take away
- SSR builds complete HTML on the server before sending it, rather than shipping a shell that JavaScript fills in.
- It improves first load speed and gives a fallback if JavaScript fails to run.
- Static generation and incremental regeneration are variants of server rendering, not client-side rendering.
- SSR adds server or edge infrastructure and caching complexity compared to a pure client-rendered app.
- The rendering approach can and often should differ page by page within one application.
- A page can look fine to a human in a browser while still being invisible to a crawler that doesn't run JavaScript.
Common misconception
What people get wrong
If a page looks correct when I browse it, it must be server-rendered.
Your browser runs JavaScript automatically, so a client-rendered page looks completely normal to you. Whether it's server-rendered only shows up when you look at the raw HTML returned before any script executes, which is the difference that matters to crawlers and AI assistants.
Related questions
Questions that come up next
Rendering, architecture, and migration questions that decide whether a crawler sees your content at all.
Where this gets applied
The work behind this answer
Each link explains why it is relevant, not just where it goes.
How Lingows handles this
In practice
We build application frontends with server-side rendering as the default for anything that needs to be found, read, or cited, and we make the client-versus-server rendering call deliberately for each section of an app rather than defaulting to one approach everywhere.
When we inherit a client-rendered site that isn't performing in search, checking what HTML actually gets returned to a crawler is one of the first things we look at, before touching design or content.
Want this handled properly on your own site
Start with a diagnosis. You get the roadmap and the quote before anyone builds anything.