Does a website with server-side rendering have to do without JavaScript?

No. With server-side rendering, the server delivers the finished HTML, and JavaScript can then make the page interactive in the browser, for example for filters, forms, or a shopping cart; developers call this step hydration. What matters is that the core content does not depend on JavaScript to appear.

When is static generation a better choice than server-side rendering?

Static generation suits content that is the same for every visitor and does not change with each request, such as service pages, blog posts, or documentation: the HTML is produced once when the website is built and can be delivered quickly because the server does not have to generate it for each request. Server-side rendering on every request is a better fit for content that changes constantly or differs from person to person. For programs that don’t run JavaScript, the result is the same either way, because the content is in the delivered HTML.

Can server-side rendering be switched on for only part of a website?

Yes. JavaScript frameworks such as Angular and Nuxt let developers set the type of rendering for individual routes, meaning individual URLs or URL patterns. Pages with services, products, prices, and contact details can then be generated on the server or in advance, while a customer area behind a login, for example, is still built in the browser.

What is SSR? Server-side rendering explained

SSR (server-side rendering) is one answer to a simple question: is the content of a web page put together on the server or not until it reaches the browser? With SSR, the server does it. Rendering here means turning templates, data, and program code into HTML, the text with headings, paragraphs, and links that browsers and other programs read. The HTML the server delivers then already contains the main heading, such as “Heat pump maintenance” (marked as h1 in the code), followed by the description, the prices, and the links to other pages.

JavaScript is the programming language websites use to load content in the browser and to run features such as filters, forms, or shopping carts. The counterpart to server-side rendering is client-side rendering, in which the browser itself builds the text, images, and links with JavaScript. Programs that don’t run JavaScript then see hardly any content; which programs these are and how the problem arises is explained under JavaScript rendering.

Server-side, static, prerendered

With classic server-side rendering, the server generates the HTML fresh for each request, for example with current data from an e-commerce or content management system. Other approaches lead to the same result—the content is in the delivered HTML:

Static generation: The HTML of every page is produced in advance, when the website is built (developers call this step the build), and is then ready as a finished file. Google calls this variant static rendering.
Prerendering: An application that normally renders in the browser is run once at build time, and its initial state is saved as finished HTML.
Progressive enhancement: A design principle that starts with HTML. Content, links, and forms work without JavaScript, and JavaScript adds convenience features in browsers that run it.

Dynamic rendering is something different: the server recognizes bots by the name they send with every request (the user agent) and serves only them a prerendered version, while people get the page built in the browser. Google calls dynamic rendering a workaround, not a long-term solution, and recommends alternatives such as server-side or static rendering instead.

Why SSR matters for GEO

According to Google, not all bots can run JavaScript, which is why Google calls server-side rendering or prerendering “a great idea”—it also makes a website faster for users and crawlers. For visibility in AI answers, this means that content in the delivered HTML reaches every program that fetches a page, whether it runs JavaScript or not. That includes AI crawlers that collect pages as potential sources, user-triggered fetchers that retrieve a page on a person’s behalf, and AI agents that complete tasks on websites. Structured data can be delivered the same way: according to Google, sites that render on the server can include it directly in the delivered HTML.

Server-side rendering ensures that content arrives in readable form, making it one of the technical foundations of crawlability and of On-Page GEO. Whether an AI system then selects a page as a source is up to each provider, and none quantifies an effect of SSR on AI citations.

Server-side rendering in practice

Whether a website renders on the server depends on the technology it is built with. Content management systems such as WordPress usually generate their pages on the server. Even then, it is worth checking individual components that load later via JavaScript, such as embedded customer reviews, pricing tables, or product lists. For websites built with a JavaScript framework—a toolkit for web applications—the default varies: Next.js and Nuxt render pages on the server by default, while Angular renders them in the browser. In Angular, server-side rendering or prerendering can be switched on (for existing projects, with an add-on package); in Nuxt, conversely, it can also be switched off. What matters is how the specific project is configured.

For a conversation with your developers or agency, two questions are usually enough: Are our pages generated on the server, statically generated in advance, or not built until they reach the browser? And are texts, prices, contact details, links, and structured data already in the HTML the server delivers? If the answer is “in the browser,” moving to server-side rendering or static generation is the robust solution. Whether a piece of content is in the delivered HTML can be checked in the page source.

SSR (server-side rendering)

Definition

Server-side, static, prerendered

Why SSR matters for GEO

Server-side rendering in practice

Frequently asked questions