What is server side rendering?

Server side rendering (SSR) is a technique in which the web server generates the complete HTML of a page before sending it to the browser or crawler. Text, links, and structured data are therefore already part of the server’s first response and can be read without JavaScript. Its counterpart is client side rendering, where JavaScript in the browser builds the page content first.

Term profile

How does server side rendering work?

Server side rendering runs in 4 steps: request, generation on the server, delivery of the finished HTML, and activation in the browser. The decisive step is the second one, because that is where the content is created before any JavaScript runs on the visitor’s device.

1. Step 1, request: A browser or a crawler requests a URL.
2. Step 2, generation: The server loads the data from the database, inserts it into the template, and generates the complete HTML of the page.
3. Step 3, delivery: The server sends the finished HTML. Browsers display the content immediately, and crawlers can read it immediately.
4. Step 4, activation: Modern JavaScript frameworks then load their code and make the page interactive. This step is called hydration.

Classic content management systems have always rendered on the server. WordPress generates every page with PHP on the server, even when a page builder designs the layout. An example from this glossary: The German entry on JavaScript SEO delivers its roughly 1,200 words in the very first HTML document, measured on October 5, 2026 without any JavaScript executed.

What is the difference between server side rendering and client side rendering?

With server side rendering, the server builds the page; with client side rendering, the browser builds it with JavaScript. With client side rendering, the server first delivers an almost empty HTML shell and a JavaScript bundle; text and links only appear once the script has run.

What it means for search engines when content is only created by JavaScript is covered in depth in the entry on JavaScript SEO.

What types of rendering are there?

There are 5 common types of rendering: server side rendering, client side rendering, static site generation, hydration as a combination, and dynamic rendering. They differ in when and where the HTML is created.

1. Server side rendering: The HTML is created anew on the server for every request.
2. Client side rendering: The HTML is created in the visitor’s browser by JavaScript.
3. Static site generation: The HTML is created once at publishing time and is then ready as a finished file. Static site generation is just as readable for crawlers as server side rendering and usually faster.
4. Hydration: The server delivers finished HTML, and JavaScript then makes it interactive. Google explicitly lists hydration as a recommended solution.
5. Dynamic rendering: The server delivers a pre-rendered version to crawlers and the JavaScript version to visitors. In its documentation, Google calls dynamic rendering a workaround that creates additional complexity and recommends server side rendering, static rendering, or hydration.

Why is server side rendering important for SEO?

Server side rendering ensures that Google sees the full content of a page on the first fetch and does not have to wait for a second processing stage. Google can run JavaScript, but it does so in a separate rendering step after crawling.

A study by Vercel and MERJ analyzed more than 100,000 Googlebot fetches in April 2024. Google fully rendered all HTML pages in that study, including pages with complex JavaScript. The delay until rendering was 10 seconds at the median, but around 3 hours at the 90th percentile and around 18 hours at the 99th percentile. For indexing, this means: Client-side rendered content does reach Google, but often later, and any error in the script can prevent the content entirely.

Google itself still recommends server-side rendering or pre-rendering, because it makes websites faster for users and crawlers and because not every bot can run JavaScript. If a JavaScript application delivers an empty shell with status code 200 for missing pages, soft 404s easily occur as well, and Google removes those from the index.

Why does server side rendering decide visibility in AI systems?

Most AI crawlers do not run JavaScript and only read the HTML the server delivers directly. Whatever is only created in the browser does not exist for them. An analysis by Vercel from December 2024 shows this:

• No rendering: None of the major AI crawlers from OpenAI, Anthropic, Meta, ByteDance, and Perplexity renders JavaScript.
• Scripts fetched, not executed: ChatGPT’s crawler fetches JavaScript files in 11.50 percent of its requests, Claude’s in 23.84 percent. The code is not executed.
• Large volume: GPTBot made 569 million fetches per month in the period studied, Claude’s crawler 370 million. Googlebot was at 4.5 billion.
• Exceptions: Applebot renders JavaScript through a browser-based crawler. Gemini uses Googlebot’s infrastructure.

A website that renders its content on the client is therefore an empty page for ChatGPT, Claude, and Perplexity. It can neither be cited nor recommended in their answers, no matter how good the content is. Which AI crawlers exist and how to control them in robots.txt is explained in our guide to controlling GPTBot and other AI crawlers.

How do you check whether your website renders on the server?

3 simple tests show whether a website renders on the server, and all of them look at the HTML before any JavaScript runs. If the page text is already there, the page is readable for crawlers without JavaScript.

1. View the source code: With Ctrl + U or the prefix view-source: in front of the URL, the browser shows the HTML the server sent. Search there for a sentence from the visible text.
2. Turn off JavaScript: JavaScript can be disabled in the browser’s developer tools. If the page stays empty afterward, it renders on the client.
3. Fetch without a browser: A command-line request shows the raw response exactly as an AI crawler receives it:

curl -s https://www.your-domain.com/ | grep -c "A sentence from your text"

If the command returns 0, the sentence is not in the delivered HTML. The URL Inspection tool in Google Search Console complements these tests: It shows the rendered HTML from Googlebot’s perspective, and with it what Google sees after the rendering step.

What are the drawbacks of server side rendering?

Server side rendering shifts work to the server and therefore increases server load and often response time. Three points belong in the planning:

• Response time: If the server generates every page anew on every request, the time to first byte rises. A page cache or a content delivery network serves pre-generated pages and compensates for this.
• Interactivity: With hydration, the JavaScript loads after the HTML. Large script bundles delay when the page responds to input, even though the content is already visible.
• Complexity: Frameworks in SSR mode need a server that can run JavaScript and a well-thought-out caching strategy.

For load time, the advantage usually outweighs the cost. Because the content arrives with the first response, the largest visible element appears sooner, and the largest contentful paint drops. That is why we build websites that need to be readable for search engines and AI systems alike with server-side rendering, as described on our page about SEO web design.

Frequently asked questions about server side rendering

Does WordPress render on the server?
WordPress renders on the server, because PHP generates every page on the server. Exceptions are individual plugins or widgets that only load their content via JavaScript.

Is dynamic rendering still recommended?
Google calls dynamic rendering a workaround and no longer recommends it. Server side rendering, static site generation, or hydration are the long-term solutions.

Does every website need server side rendering?
Every website whose content should appear in search engines and AI answers benefits from server-rendered or statically generated HTML. Applications behind a login that are not meant to be found at all can manage with client side rendering.