Server-side rendering (SSR) is a way of building websites in which the server assembles the full HTML of a page before sending it to the browser, so the text, links and images are there the moment the page arrives. The alternative, client-side rendering, sends a mostly empty page plus JavaScript that builds the content inside the visitor’s browser.
How server-side rendering works
Traditional sites built on WordPress, PHP and similar systems have always rendered on the server: a request comes in, the server pulls content from the database, fills in the template and returns finished HTML. The term SSR is mostly used about modern JavaScript frameworks such as React, Vue and Svelte. Built purely for the browser, an app made with these sends an HTML shell with an empty container, and the content appears only once JavaScript has run.
Frameworks such as Next.js, Nuxt and SvelteKit add server-side rendering to those apps. The server runs the same code, produces complete HTML and sends it. The browser shows the content straight away, then “hydrates” the page by attaching the JavaScript that makes it interactive. A related approach is static generation, where a static site generator renders pages once at build time and serves them as files.
Google can run JavaScript, but it does so in a separate step. Googlebot fetches the HTML first; pages that need JavaScript to show their content are queued for rendering, which may happen quickly or after a delay. Content and links missing from the first response are found later, and if rendering fails they may not be found at all.
Why it matters
With SSR, search engines receive everything they need in the first response: title, meta description, headings, body copy, internal links and structured data. That removes a whole class of JavaScript SEO problems. It matters even more beyond Google. At the time of writing (October 2026), many AI crawlers and some other search engines fetch HTML without running JavaScript, so a client-rendered site can look almost empty to them.
It tends to help perceived speed too. Visitors see content sooner, which can improve Largest Contentful Paint, although heavy hydration can still hold up interactivity. If a UK business has commissioned a React or Vue site from an agency, whether its pages are server-rendered is one of the first technical questions worth asking.
Common mistakes
- Assuming a site is server-rendered because it uses a framework that supports SSR; it may be set up for client rendering only.
- Server-rendering the layout but loading the main content or product list by JavaScript afterwards.
- Producing different content on the server and in the browser, which causes hydration errors or text that changes after the page loads.
- Relying on dynamic rendering, serving pre-rendered pages only to bots, which Google describes as a workaround rather than a long-term solution.
- Internal links built as click handlers instead of real anchor elements, so they are missing even from server-rendered HTML.
How to act on it
Open an important page, right-click and choose View Page Source (not Inspect, which shows the version after JavaScript has run). If you can read the main text and see your links in the source, the content is in the initial HTML. If the body is almost empty, the page depends on client-side rendering. The URL Inspection tool in Google Search Console shows what Google rendered, and a crawler set to text-only mode shows what non-rendering crawlers see.
If key pages rely on JavaScript, ask your developer about switching on SSR or static generation for them, starting with the pages that bring in enquiries or sales. Diagnosing rendering problems and briefing developers on the fix is part of my technical SEO service.