What Is the Difference Between Server Side and Client Side Rendering in SEO?
This decision is made once, early in a build, usually by a developer. It constrains a great deal afterwards. It is rarely discussed with the business paying for it and it is expensive to change later. The point of this page is to let you ask a sensible question before that happens rather than after.
A Decision Made Before Anybody Asks You
Somebody chose this during your build. It was almost certainly not raised with you, because it does not look like a business decision. By the time its consequences appear it has become structural.
Why it is not discussed. It reads as a technical preference.
To a developer this sits alongside dozens of implementation choices nobody would trouble a client with. That is a reasonable position and it happens to be one of the few where the consequences reach the commercial side of the business.
When it gets made. At the start, by default.
Usually by picking a framework, which brings a default with it. Very often nobody explicitly decided anything, which matters because a default nobody examined is easier to revisit than a choice somebody defended.
Why changing it later is expensive. It is not a setting.
Moving between approaches after a site is built is a rebuild rather than an adjustment. Rebuilds carry the risks our site migrations material covers. That asymmetry is the reason to ask early.
What this page is not. A recommendation.
There is no correct answer here, only a set of trade-offs that depend on your site. What follows is what those trade-offs actually are, in language that survives contact with a developer.
What Each Approach Means
The difference is where the page gets put together and, as a result, what arrives when somebody asks for it.
Assembled before sending. The server does the work.
Somebody requests a page, the server builds the complete thing and sends it. What arrives is finished. Nothing further has to happen for the content to exist.
Assembled after arriving. The visitor's device does the work.
What gets sent is a frame plus instructions. The device carries out those instructions, fetches what it needs and constructs the page in front of the person. What arrived initially was not the page.
Why the second approach exists at all. It is not laziness.
It makes applications feel fast once loaded, because moving between views does not require going back to the server for a whole new page. For anything behaving like software rather than like a document, that is a genuine benefit.
Where the tension comes from. Two different jobs.
The web is used both for documents to be read and for applications to be used. These approaches suit those differently. Most business sites are closer to documents than their builders assume.
The Middle Options
The choice is not binary any more. Most modern builds do both, assembling some things in advance and others on demand. Treating it as two options describes a decision nobody is actually making.
What in between looks like. Per page, else per part of a page.
Pages that rarely change can be built once and served ready-made. Pages that change constantly can be assembled when requested. A single page can even have a fixed frame with one section fetched separately.
Built in advance and stored. The strongest option for most business sites.
Where content changes rarely, pages can be produced ahead of time and simply served. That is fast, cheap and removes the dependency entirely. It suits an enormous proportion of ordinary business websites.
Why defaults now lean this way. The frameworks moved.
Modern tooling commonly assembles in advance by default rather than leaving everything to the device. A site built recently is considerably less likely to have a problem here than one built some years ago.
What this means for the question you ask. Not which one.
Asking whether a build is one approach or the other invites a misleading answer. The useful question is which parts of the site are handled which way, which is block eight.
What It Changes For Search
Assembling in advance removes the uncertainty entirely. Assembling on demand introduces a dependency that may or may not cause a problem. That is the whole of it. The difference is between certainty and a variable.
Why certainty is worth something on its own. Nothing to monitor.
Content that exists in what was sent is content nobody has to check on. It cannot be partially understood, delayed or missed, so an entire category of possible problems does not apply to your site.
Why the dependency is a variable rather than a fault. It frequently works.
Content assembled on demand is often handled without incident. The point is that it now depends on something happening rather than being guaranteed. Depending is different from being certain even when the outcome is usually the same.
What the risk is proportional to. How much rests on it.
A dependency affecting a decorative element is not worth a conversation. The same dependency affecting your main content or your navigation is a different matter entirely.
Where the symptoms are covered. Deliberately not here.
What actually goes missing, how to spot it and what to do about it belongs in what is JavaScript SEO. This page owns the choice. That page owns the consequence.
And What It Changes For Everything Else
This is not only a search decision. Treating it as one is how search advice loses credibility inside technical teams. Four other considerations move with it and a business should weigh all of them.
Speed for the visitor. It cuts both ways.
Assembling in advance means the first thing somebody sees arrives sooner. Assembling on the device can make everything afterwards feel quicker. Which matters more depends on whether people view one page or many.
Hosting cost. Where the work happens is where you pay.
Assembling on the server means your infrastructure does it for every request. Assembling on the device moves that cost to the visitor. At volume this is a real number rather than a rounding error.
Development complexity. Which becomes an ongoing cost.
More sophisticated arrangements need more capable people to maintain them. They also narrow the pool of who can work on your site later.
Behaviour on a poor connection. The one nobody tests.
A page requiring the device to fetch and assemble several things behaves worse on a slow connection or an older phone than a page that arrived complete. Everybody tests on good equipment on fast connections. Your customers are not always on either.
Where It Matters Most
This decision matters far more for large sites with a great deal of content and far less for a small one. Getting the proportion right prevents both complacency and unnecessary spending.
Why size changes it. Multiplication.
A dependency on thirty pages is thirty small uncertainties. The same dependency across thirty thousand is a structural characteristic of the site. At that scale it interacts with how attention gets allocated, which is what is crawl optimisation at scale.
What else raises the stakes. Change frequency.
A site whose content changes constantly, such as stock, prices or availability, relies more on things being understood promptly. A site whose pages sit unchanged for months is far less exposed.
Where it barely matters. Small, stable sites.
A business site of a few dozen pages that change occasionally has very little riding on this. It is worth knowing which situation you are in and then stopping.
The warning sign for a smaller business. Complexity without a reason.
A business being sold an elaborate architecture for a simple site should ask why. The good answers do exist. Frequently the answer is that it is what the supplier prefers building, which is a legitimate preference and not a reason for you to pay for it.
Most Platforms Decide This For You
If your site is on a hosted platform, you are not making this choice. It was made on your behalf and made well. That is a legitimate reason to be on one.
Why their decision is generally sound. Their incentive.
A platform serving very large numbers of businesses has strong commercial reasons for sites on it to be findable and fast. They have engineering resources most individual businesses do not, applied to a problem they only have to solve once.
What that removes from your list. An entire category.
You are not weighing infrastructure trade-offs, not maintaining an architecture and not exposed to somebody making a poor choice on your behalf. That is worth something and it rarely gets counted.
The trade you are making instead. Control.
You accept their decisions, including ones you would have made differently. For most businesses that is a good trade. The ones it does not suit usually know why.
Why we are saying this. It tells some readers there is nothing here for them.
If you are on a hosted platform, this page is background rather than a task list. Saying so is more use to you than manufacturing a concern.
The Question To Ask Before A Build
Ask which parts of the site will be assembled before being sent and which will be assembled on the visitor's device. Phrased that way it cannot be answered with a yes.
Why not to ask which approach. The answer will be a label.
Naming an approach tells you almost nothing, since most builds are a mixture. Asking which parts forces a specific answer about your actual content.
What a good answer covers. Four things.
Which parts are assembled where. Why that split was chosen. Whether your main content and navigation are in what the server sends. And what would have to change if you later wanted more assembled in advance.
The last one matters most. It reveals the cost of reversing.
Somebody who can answer it has thought about the constraint. Somebody who has not may be committing you to something they have not considered the end of.
What a poor answer sounds like. Reassurance about search.
Being told search engines handle this fine now is true, incomplete and not what was asked. The question was about your site rather than about capability in general.
What to do with the answers. Weigh all five variables.
Search, speed, cost, complexity and poor connections. Deciding on search grounds alone produces a technically defensible site that costs more than it needed to. The full series is on the advanced SEO guide.
Ask before
the build,
not after.
We can review what your build actually does, which parts are assembled where and whether anything commercially important depends on something running. If you are on a hosted platform we will tell you there is nothing here to change rather than manufacturing a concern.
What the national tier covers:
The national tier is £1,550 a month. It suits businesses competing beyond one town. We will say so if a lower tier would serve you better.
Every guide.
One practice.
Semantic search, machine learning, topical authority, programmatic production, rendering, log files, crawl allocation, information architecture, content pruning and how strategy changes with scale.
