Server-Side Rendering (SSR)

Server-side rendering (SSR) means the web server builds the full HTML for a page before sending it to the browser. Visitors and search engine crawlers receive the content, links and metadata straight away, without waiting for JavaScript to run.

Written by Paul Hoda, SEO consultant since 2005. Last updated 8 November 2026.

How server-side rendering works

When someone requests a page, the server fetches the data, fills in the template and returns finished HTML. The browser can display the content immediately. JavaScript may then load to add interactivity, a step often called hydration.

Traditional websites built with PHP, such as WordPress, have always worked this way. Modern JavaScript frameworks offer SSR too, for example Next.js for React, Nuxt for Vue and SvelteKit for Svelte.

The alternative is client-side rendering, where the server sends a mostly empty page and the browser builds the content with JavaScript.

Why SSR matters for SEO

  • Content is visible on first fetch: search engines can read the text, links and tags in the initial HTML, without relying on rendering.
  • More reliable indexing: Google can render JavaScript, but rendering takes extra resources and can be delayed or fail. SSR removes that dependency.
  • Other crawlers benefit: many crawlers, including several AI crawlers and social media link previewers, do not run JavaScript, so they only see what is in the HTML.
  • Faster perceived loading: content often appears sooner, which can help Largest Contentful Paint.

Google has said that server-side rendering, static rendering or hydration are good long-term solutions for JavaScript sites.

Related approaches

  • Static site generation (SSG): pages are built into HTML files ahead of time, at deploy. Ideal for content that changes rarely.
  • Incremental or on-demand regeneration: static pages are rebuilt in the background when data changes.
  • Streaming SSR: the server sends HTML in chunks as it becomes ready.
  • Dynamic rendering: serving pre-rendered pages only to bots. Google now describes this as a workaround rather than a recommended solution.

Trade-offs

SSR puts more work on the server, which can raise hosting costs and slow down time to first byte if data is slow to fetch. Caching and a CDN usually solve this. Hydration can also add heavy JavaScript that delays interactivity, so developers should keep client-side code lean.

Another common issue is a mismatch between the server HTML and what JavaScript renders afterwards. If the server sends one title or canonical and the browser later swaps it for another, search engines receive mixed signals. Aim for the server output to be complete and correct on its own, with JavaScript only adding interactivity on top.

How to check a page is server-rendered

  1. View the page source (not the inspected DOM) and look for your main content, headings and links.
  2. Fetch the page with JavaScript disabled in your browser and see what remains.
  3. Use the URL Inspection tool to compare the crawled HTML with what you expect.
  4. Crawl the site with JavaScript rendering off and on, and compare the results.

Key Takeaways

  • Server-side rendering builds the full HTML on the server before sending it.
  • Crawlers see content, links and metadata without running JavaScript.
  • It is the most reliable rendering approach for SEO and AI crawlers.
  • Static generation and hydration are closely related, SEO-friendly options.
  • View the page source to confirm key content is in the initial HTML.

Related Terms

Not sure how your own site measures up? Request a free SEO review, or keep learning in the SEO Encyclopedia.