Server-side rendering (SSR) means the server builds a page's HTML before sending it to the browser. When a person or a bot requests a URL, it gets back a complete page with the text, links and metadata already in place. The alternative, client-side rendering, sends a mostly empty page plus JavaScript that builds the content in the browser.
For businesses, SSR matters because not every visitor runs your JavaScript. Google can render it, sometimes after a delay, but many AI crawlers appear not to. If your key content only exists after scripts run, it may be invisible to the tools people increasingly use to research purchases.
What is server-side rendering?
Google's web.dev guide to rendering on the web defines SSR as "rendering an app on the server to send HTML, rather than JavaScript, to the client." Client-side rendering (CSR), by contrast, is "rendering an app in a browser, using JavaScript to modify the DOM."
Most modern JavaScript frameworks support server-side rendering, and many let you mix approaches page by page. A few related terms come up often:
- Static rendering: HTML is generated once at build time and served as files. web.dev notes it achieves a consistently fast time to first byte.
- Hydration: client-side scripts run on top of server-rendered HTML to add interactivity.
- Dynamic rendering: serving a pre-rendered version to bots and a client-rendered version to people. Google's dynamic rendering page calls it "a workaround and not a recommended solution."
Why server-side rendering matters
Google recommends it. Google's JavaScript SEO basics says that even though Googlebot runs JavaScript, "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript."
AI crawlers may not run JavaScript. Vercel's December 2024 study of crawler traffic found that "none of the major AI crawlers currently render JavaScript," including OpenAI's and Anthropic's. Gemini, which uses Google's infrastructure, was the exception. Crawler behavior can change, but SSR removes the guesswork for AI crawlers of every kind.
It can speed up what people see. web.dev notes that SSR "generally produces a fast FCP," or First Contentful Paint, because the browser has real HTML to display right away. That often helps Largest Contentful Paint too.
How server-side rendering works
The request cycle
With SSR, a request arrives, the server fetches any data it needs, builds the HTML and sends it. The browser displays the content immediately, then downloads JavaScript to make interactive parts work. With CSR, the browser receives a shell, downloads and runs JavaScript, fetches data and only then shows the content.
How Google processes each approach
Google handles JavaScript sites in three phases: crawling, rendering and indexing. It queues pages that return a 200 status code for rendering, and Google says a page may wait in that queue for a few seconds or longer before a headless Chromium renders it. With SSR, the content is already in the initial HTML, so Google can read it without waiting on the render step.
The trade-offs
SSR isn't free. web.dev notes that generating pages on the server takes time, which can increase time to first byte. Hydration can also hurt responsiveness: web.dev warns that it "can have a significant negative impact on TBT and INP, even if it improves FCP." That's why Interaction to Next Paint deserves a close look after any rendering change. Caching, streaming and static rendering for pages that rarely change can help balance these costs.
How to check whether your site needs SSR
- View the raw HTML. Open your page's source, not the element inspector, and search for a sentence from the main content. If it's missing, crawlers that don't run JavaScript won't see it either.
- Use URL Inspection. In Google Search Console, inspect the URL and check that the rendered HTML includes your main content.
- Prioritize templates. Product, service, pricing, blog and location pages matter most. Dashboards behind a login usually don't need SSR.
- Server-render the essentials. Vercel recommends keeping main content, metadata and navigation server-rendered, while client-side rendering is fine for non-essential features like chat widgets.
- Measure after changes. Watch Core Web Vitals field data to make sure SSR didn't slow server response or responsiveness.
Common mistakes and misconceptions
"Google renders JavaScript, so SSR doesn't matter." Google does render, but other crawlers, including many AI crawlers, may not. Google itself still recommends server-side or pre-rendering.
"SSR means no JavaScript." Most server-rendered sites still use JavaScript for interactivity. The difference is that the content doesn't depend on it.
"Dynamic rendering is just as good." Google describes dynamic rendering as a workaround and recommends server-side rendering, static rendering or hydration instead.
"SSR automatically makes a site fast." A slow server or heavy hydration can cancel out the benefits. SSR makes content available; speed still needs measuring.
Server-side rendering vs. client-side rendering
With SSR, the content arrives in the first response, which is better for crawlers and usually for first paint. With CSR, the browser builds the page, which can suit highly interactive apps but leaves crawlers dependent on running JavaScript. For marketing pages that need to be found, SSR or static rendering is usually the safer default. Our JavaScript SEO entry covers the wider topic.
How Butter approaches server-side rendering
At Butter, JavaScript issues usually surface during technical reviews, when a page that looks fine to people shows thin or missing content in the raw HTML. Our first check is simple: what does a crawler get before any script runs? Because our GEO work is about earning visibility in AI answers, we pay close attention to that initial HTML, since some AI crawlers may never execute your scripts.
On our GEO+SEO plan, technical fixes like crawl issues and broken links are part of the monthly work, and we flag rendering problems in our on-page recommendations. Larger changes, like moving a framework to server-side rendering, are a developer project. In those cases we explain the problem clearly and help your team prioritize the templates that matter most.
Frequently asked questions
Is server-side rendering better for SEO?
Usually, yes. Google says server-side or pre-rendering is still a great idea because it makes sites faster for users and crawlers, and not all bots can run JavaScript. It ensures your main content is in the HTML from the first request.
Do AI crawlers need server-side rendering?
Often. A December 2024 Vercel study found that the major AI crawlers it observed, including OpenAI's and Anthropic's, did not execute JavaScript. Server-rendered content is the safest way to make sure those crawlers can read your pages.
What is the difference between SSR and static rendering?
SSR builds the HTML on the server for each request. Static rendering builds it once at build time and serves the same files to everyone. Both deliver complete HTML. Static rendering is often faster, while SSR suits content that changes often or is personalized.
How can I tell if my site uses client-side rendering?
View the page source in your browser and search for text from the main content. If the text is missing and the source is mostly script tags, the page relies on client-side rendering for its content.