Server-Side Rendering (SSR)
Server-side rendering builds the HTML on the server before sending it to the browser. Learn how SSR works, how it differs from CSR, and why AI crawlers need it.
TL;DR
Server-side rendering (SSR) is a technique where the server builds the full HTML for a page and sends it to the browser ready to display. The alternative, client-side rendering, ships a near-empty HTML shell plus JavaScript that the browser runs to build the page. The difference matters most to anything reading your site that is not a person with a modern browser, which now includes every AI crawler.
Why server-side rendering matters
A page that only exists after JavaScript runs is invisible to anything that does not run JavaScript, and plenty of important visitors do not.
- AI crawler access: Most AI crawlers fetch raw HTML without executing JavaScript, so a client-rendered page reads to them as an empty shell.
- First paint: Users see content sooner because the browser paints markup it already has instead of waiting on a script bundle.
- Search indexing: Googlebot renders JavaScript but defers it to a second pass, which delays indexing and occasionally misses content.
- Social previews: Link unfurls read the initial HTML, so client-rendered titles and images often fail to appear.
How server-side rendering works
The browser requests a URL
A user, crawler or bot asks your server for a page.
The server runs the application code
Your framework executes the components, fetches whatever data the page needs, and produces complete HTML on the server.
The server returns finished markup
The response contains real content: headings, paragraphs, prices, product details. Anything reading the raw response sees the page.
The browser paints immediately
Content is visible before any application JavaScript has finished loading.
Hydration attaches behaviour
JavaScript loads afterward and wires up interactivity on top of the existing markup, so buttons and forms start working.
Later navigation may go client-side
Many frameworks render the first page on the server and handle subsequent clicks in the browser, which keeps the entry point crawlable.
Server-side rendering vs. client-side rendering
Server-side rendering: HTML arrives complete. Slower time to first byte, faster time to visible content, and readable by any crawler that fetches the page.
Client-side rendering: HTML arrives nearly empty and JavaScript builds the page. Cheaper to host and smooth between views, but invisible to anything that does not execute scripts.
Static site generation sits alongside both: HTML is built once at deploy time rather than per request, which gives the crawlability of SSR without the per-request server cost, at the price of staleness between builds.
Rendering decides whether your content can be read at all, and most teams discover a problem here only after their pages stop appearing in answers. Findrix runs a 31-point technical check that includes crawler access and rendering, alongside weekly tracking of how seven AI engines cite you against named competitors. Every gap comes with the fix already written: technical, content and off-site. The audit is free, takes about a minute, and requires no signup.
How to check whether your pages render server-side
- View source, not inspect: Right-click and choose view page source. That is the raw HTML a crawler receives. If your content is missing there, it is client-rendered.
- Fetch without JavaScript: Request the URL with curl and read the response body. Same test, scriptable across many URLs at once.
- Compare rendered and raw: The difference between what the browser shows and what the source contains is exactly what non-rendering crawlers miss.
- Check the pages that matter: Pricing, product, documentation and comparison pages get cited most often, so test those before the homepage.
- Watch server logs by user agent: Confirm AI crawlers are fetching and receiving 200 responses rather than errors or empty shells.
What SSR does not fix
Rendering makes your content readable; it does not make it worth citing. A server-rendered page with vague claims and no specific facts gives an engine nothing to lift, and plenty of client-rendered sites get cited because third-party sources describe them well enough that engines never need the original.
There are real costs too. Server rendering puts computation on every request, which raises hosting bills and adds latency under load, so caching strategy becomes part of the decision rather than an afterthought.
SSR is a floor rather than a strategy. Get the pages carrying your important facts rendering on the server, then spend the remaining effort on whether those facts are clear, current and specific enough to quote.
Frequently asked questions
What is the difference between SSR and CSR?
SSR builds the page HTML on the server and sends it complete. CSR sends a minimal HTML shell and lets the browser JavaScript build the page. The practical consequence is that SSR content is visible to crawlers that do not run scripts, and CSR content is not.
Do AI crawlers execute JavaScript?
Most do not. The crawlers that feed AI answers generally fetch raw HTML, so content that only appears after scripts run is invisible to them. Googlebot is the notable exception, and even it renders JavaScript on a delayed second pass rather than immediately.
Is server-side rendering necessary for SEO?
Not strictly, since Googlebot can render JavaScript, but it removes an entire category of risk. Rendering delays, script errors and blocked resources all cost you indexing on client-rendered pages, and none of those failure modes exist when the HTML arrives complete.