Glossary
What is Server-Side Rendering (SSR)?
Definition
Server-side rendering (SSR) is building a page’s HTML on the server so the response already contains the content. Client-side rendering does the opposite, sending a near-empty shell and assembling the page in the browser with JavaScript. A crawler that does not run JavaScript sees only what the server sent.
At a glance
- CategoriesTechnical
- Related fieldsTechnical
- DifficultyAdvanced
At a glance
- SSR returns complete HTML, so content exists before any JavaScript runs.
- Client-side rendering returns a shell and builds the page in the visitor’s browser.
- Static site generation reaches the same outcome as SSR from a crawler’s point of view.
Where the HTML gets assembled
The work happens in one of two places, and the choice decides what a crawler receives.
With server-side rendering, the request reaches your server, the server fetches the data, fills the template and returns finished HTML. Your headings, copy and prices are all in that response.
With client-side rendering, the server returns a small shell and a JavaScript bundle. The browser downloads the bundle, calls your API and builds the page. Until that finishes, the document is close to empty.
Static generation lands in the same place as SSR as far as a bot is concerned: the HTML was built ahead of time and arrives complete. Hybrid frameworks let you choose per route.
The question is never which approach is more modern. It is what sits in the response body.
The page that looks perfect and arrives empty
Open the page in Chrome and everything is there. That is the trap. Your browser runs the JavaScript, so you never see what the crawler saw.
Googlebot renders JavaScript, on a delay and within a budget. Plenty of other clients do not. An AI crawler pulling a source while an answer is being written will not wait for a bundle to execute.
So a client-rendered product page can be perfectly indexable in Google and entirely absent from the material an assistant draws on. One URL, two realities, and nothing in your analytics tells them apart.
The failure is silent and it scales. Every page on the template carries it, and the symptom is a competitor getting named instead of you.
Check what a bot actually receives
- Disable JavaScript in your browser and reload a key page. Whatever disappears is missing for any crawler that does not render.
- View source instead of inspecting the DOM. The inspector shows the page after scripts ran, which is the wrong picture.
- List which parts come back empty. Prices, specifications, reviews and FAQ blocks are the usual casualties, arriving from separate API calls.
- Ask engineering which routes are server-rendered. Most frameworks allow this per route, so it is often configuration rather than a rebuild.
- Fix in order of commercial value. Product, category and reference pages first. A logged-in dashboard can render wherever it likes.
For a JavaScript-heavy site this is the largest single lever on crawlability, and it costs less than the content program that gets funded instead.
SSR vs client-side rendering
| Server-side rendering | Client-side rendering | |
|---|---|---|
| What the server returns | Complete HTML | A shell and a JavaScript bundle |
| What a non-rendering bot sees | The full page | Close to nothing |
| Time to first content | Faster | Slower |
| Server cost per request | Higher | Lower |
| Right for | Public content pages | Logged-in applications |
Frequently asked questions
-
Does Google index client-side rendered pages?
Usually, yes. Googlebot renders JavaScript, though on a delay and within a processing budget, so heavy pages can be indexed late or incompletely. Google managing it does not mean everything else will. Treat Google as the most capable client you have, not the typical one.
-
Is static generation as good as SSR?
For a crawler they are equivalent, because both deliver complete HTML. The difference is operational: static pages are built ahead of time and served fast, which suits content that changes on a schedule. SSR suits pages that must reflect live data such as stock or pricing.
-
Does SSR matter more for AI search than for Google?
Yes, and that surprises people. Google renders JavaScript and usually gets there eventually. Several AI clients take the raw HTML and nothing more, so server-rendered content is the difference between being a usable source and being an empty page.
-
Is this worth rebuilding the site for?
Usually not as a rebuild, and that framing is where budgets go to die. Most modern frameworks support rendering per route, so the realistic project is switching your important templates rather than replatforming. If your stack genuinely cannot do it, prerendering key routes is the cheaper interim answer.