Six reasons your next website should be server-rendered

Server-rendered means the page is put together before it's sent, so it arrives complete. The alternative sends a near-empty page and a set of instructions, and your visitor's phone does the assembly when it arrives. Both can look identical once finished. The difference shows up in how fast the page appears, whether machines can read it, and how much of it you control, which is why it's worth understanding before you commission anything.

Here's the plainest version of the difference. A server-rendered page is a meal delivered cooked. The other kind is a delivery of ingredients with a recipe, prepared in the visitor's kitchen on whatever equipment they happen to have. If they have a good kitchen - a new phone, a fast connection - the difference is small. If they're on a five-year-old handset on mobile data outside your shop, it is not small at all.

For a business website, cooked is usually the better choice. Here's why.

1. The page appears sooner

The visitor's device has less to do: it displays what it received. There's no waiting for code to download, run and fetch the content before anything can be shown.

This matters more than it sounds, because the first few seconds are where visitors are lost, and they leave without telling you. Few people email to say your site was slow. They go back to the results page and click the next one. That includes the visitors you paid to bring there, through advertising or search rankings you worked for.

2. Machines can read it without extra work

Search engines can generally handle pages that assemble themselves, though they do it on their own schedule and not always completely. AI tools are less consistent, and some read only what they're first given. If that's an empty shell, that's what gets read.

A server-rendered page avoids the problem. The words are in the page when it arrives, so search engines, AI tools and link previews get the content on the first attempt. As more people find businesses by asking an AI assistant rather than scrolling search results, this matters more.

3. You control every tag on the page

Titles, descriptions, heading structure, structured data, the image and headline that appear when your link is shared on WhatsApp or LinkedIn: on a custom server-rendered build, each of those is written deliberately, page by page.

On a platform or a heavy theme, you get whatever markup it produces, and whichever settings it chose to offer. When something is wrong - a heading level skipped, a title cut short, structured data missing or describing the wrong thing - you can often see the problem but cannot change it. With control of the markup, the fix is a small change rather than a support ticket.

4. Your site loads what it needs

A platform-built site can load code for features it does not use, so your visitors may download the machinery for a booking system you do not have. A self-hosted site with a long plugin list gets to the same place by a different route: each plugin can add weight to every page.

A custom build can load only what each page needs, with nothing arriving to support a feature you never asked for. It still takes care to keep it that way. A site of any kind gets slower if things keep being added and nothing is removed.

5. It handles growth without an upgrade

On some platforms, a feature you now need or an integration you have outgrown means a higher plan or another subscription.

Pages that are built ahead of time and served from a network of servers are, in effect, files sitting close to your visitors. A large spike in traffic is usually handled without any change to how the site is set up. Hosting a professionally built site is inexpensive - typically tens of euros a month, not hundreds - and the limit is somewhere you'll probably never reach.

6. It's ordinary code that other developers can pick up

This one matters in five years rather than five seconds.

Our own builds use Next.js and React, which are among the most widely used tools for this: well documented, and known by a large number of developers. That's what makes the point matter. A site built this way can be handed to another competent developer, moved to another host, and continued by someone who has never met us. There's no proprietary format, private framework or licence to renew.

Ask any prospective builder what happens if you stop working with them. On an ordinary, standards-based codebase, the answer should be: nothing much, you take it elsewhere.

What this does not mean

Two qualifications.

Server-rendering is not the same as being fast. It's a strong foundation that can still be undone by large unoptimised images, half a dozen tracking scripts and a video playing automatically in the header. Many slow sites are slow for those reasons rather than because of how they're built.

And some platform sites are perfectly quick. If yours is fast, indexed and doing its job, none of this is an argument for replacing it. The difference matters when you're choosing what to build next, not as a reason to throw away something that works.

The question to ask

If you're commissioning a website, ask one thing: "Will my pages be rendered on the server, so the content is in the HTML when it arrives?" You do not need to follow the answer into the technical detail. You need to see whether the person you're hiring understands the question and can answer it plainly.

If you already have a site, you can check it yourself: view the page source in your browser and search for a sentence from your homepage. If the sentence is there, the page arrives ready to read. Our free website health check then measures how quickly your main content appears, using Google's own test, and lists what is holding the site back. It takes a few seconds, with no sign-up.