What is Server-side rendering?
Nati Elimelech·Updated 27.07.2026 Server-side rendering (SSR) is the approach where the server sends a page's HTML ready, instead of the browser building it in JavaScript.
Server-side rendering is made of three parts: application code that runs on the server, the ready HTML it returns in the first response, and the hydration layer that wires up the interactivity in the browser. The difference from client-side rendering (CSR) is who does the work: with CSR the server sends an empty skeleton, and the browser builds the content in JavaScript. The two approaches live together in one site, page by page and component by component. A user with a browser gets the content either way; a bot that does not run JavaScript sees a full page in the first case and an empty shell in the second.
How server-side rendering works
The server runs the application code, assembles the full HTML and sends it as the first response, so the content exists before a single line of JavaScript has run in the browser. After the page is displayed, the hydration layer wires up the interactivity: scripts that run client-side and make buttons and forms live. Hydration is also the cost of the approach: a page can look ready a moment before it actually responds.
What happens to a page without server-side rendering
Server-side rendering skips the rendering stage; without it, the content exists only after something runs the JavaScript. At Google that means a separate rendering queue and execution in Chromium, usually seconds but sometimes longer, with no cookies and no local storage. Bing runs JavaScript too, but documents that doing it at scale on every page of every site is difficult.
With AI engines nothing is officially documented, but the field data is unambiguous: in a log analysis Vercel published in December 2024, the major crawlers of OpenAI, Anthropic and Perplexity did not execute JavaScript, even when they fetched the JS files themselves. Gemini is the exception in that group, because it rests on Google’s rendering infrastructure, and Applebot renders as well, through a browser-based crawler.
I tested sites built with AI builders: the content simply was not in the HTML those crawlers fetch, and there is nothing to cite from a page that arrives empty.
How server-side rendering relates to SEO and GEO
If the content is in the initial HTML, every bot gets it, from Googlebot to the crawlers feeding the answers. Google itself writes that server-side or pre-rendering is still a great idea, because not all bots can run JavaScript. A page that arrives ready also saves Google the rendering stage, which connects to crawl budget. Citation starts with an HTML fetch, and what is not in the fetch is not in the answer.
The difference between server-side rendering and dynamic rendering
Dynamic rendering serves bots a separately rendered version and users the regular application. At Google it is no longer recommended: Google defined it as a workaround and not a long-term solution, and its recommendation instead is server-side rendering, static rendering or hydration. Bing, on the other hand, still recommends it for large sites that lean on JavaScript, which makes this one of the places the two engines disagree. And every gap between the version the bot gets and the version the user sees is a bug that is hard to catch.
Questions about Server-side rendering
How do you check if a site has server-side rendering?▼
Open View Source, not DevTools, and search for a sentence from the page body. If the text is in the initial HTML, the page is server-rendered. If you only see a skeleton and scripts, the content is built in the browser.
Does Google manage without server-side rendering (SSR)?▼
Google usually manages without SSR: it runs JavaScript in an up-to-date Chromium and renders what it crawls. But rendering is a separate stage with its own queue, usually seconds by Google's wording but sometimes longer, and it starts from a clean slate every time: cookies, Local Storage and Session Storage are cleared between loads, permission requests are declined, and a page returning a non-200 status may skip rendering entirely.
Server-side rendering skips the rendering stage entirely: no queue, no dependency, and the content exists on the first fetch.
Do AI engine bots run JavaScript?▼
No AI engine documents whether its crawlers run JavaScript. In a log analysis Vercel published in December 2024, the crawlers of OpenAI, Anthropic and Perplexity fetched JavaScript files but did not execute them, so content built in the browser stayed invisible to them.
The exceptions are Gemini, which rests on Google's rendering infrastructure, and Applebot, which renders through a browser-based crawler. And Google itself writes that not all bots can run JavaScript.
What is the difference between server-side rendering and static rendering (SSG)?▼
Static rendering (SSG) is a sibling of server-side rendering, not a bypass: the same principle of ready HTML, except the page is produced once at build time instead of assembled per request. Google recommends both in the same breath. The practical difference: SSG fits content that rarely changes, SSR fits content that needs to be current on every fetch.
Does every page need server-side rendering?▼
Not every page needs server-side rendering. The principle: any content meant to be read by search engines and AI engines must arrive in the initial HTML. Internal interactive areas, like dashboards, can stay client-side.