SEO advice on rendering tends to collapse into "server-side render everything." That is directionally safe and frequently wrong on cost. The actual decision depends on properties of your content that are easy to state.
The options
Static site generation (SSG). Pages built to HTML at deploy time. Served from a CDN as files. Fastest possible delivery, cheapest hosting, zero rendering risk. Requires a rebuild to change content.
Server-side rendering (SSR). HTML generated per request. Always current, supports personalization, costs server capacity on every request and adds latency proportional to your backend.
Incremental static regeneration (ISR). Static pages regenerated on a schedule or on demand after a cache expiry. Most of SSG's benefits with bounded staleness. Framework-dependent.
Client-side rendering (CSR). Server returns a shell; JavaScript builds the page in the browser. Simplest deployment, best for application-like interfaces, worst for SEO because it depends on the render queue described in Google's two-stage indexing.
The decision, by content property
Does the content change per user? If yes, that portion cannot be static. But note that "the page has a personalized element" does not mean "the page must be SSR" — the article can be static and the recommendation widget can hydrate client-side.
How often does it change? Content that changes on a publishing cadence (blog posts, marketing pages, documentation) suits SSG or ISR. Content that changes continuously (inventory, prices, availability) suits SSR, or SSG with a client-side refresh for the volatile field.
How many pages are there? SSG build times scale with page count. At tens of thousands of pages, full rebuilds become operationally painful, which is exactly the problem ISR solves.
Does it need to be indexed? Anything behind a login does not. Application interfaces, dashboards, and account pages can be pure CSR with no SEO consequence, and treating them as if they need SSR wastes engineering effort.
The split that usually wins
Most sites do not need one strategy. They need a boundary.
Static or server-rendered: marketing pages, blog and editorial content, product and category pages, documentation, anything you want indexed. The full HTML in the initial response — content, internal links, title, meta description, canonical, robots directives, structured data.
Client-rendered: interactive widgets, personalization, search-as-you-type, dashboards, checkout flows, account management. None of it is indexable content, so none of it needs the SEO guarantees.
Drawing that boundary explicitly is usually a much smaller change than migrating a rendering strategy wholesale, and captures nearly all of the SEO benefit.
What actually goes wrong in practice
Hydration mismatches. The server renders one thing, the client renders another, React or Vue throws a hydration error and re-renders. Users see a flash; Googlebot may see the server version, the client version, or a broken intermediate. Usually caused by rendering something time- or locale-dependent without guarding it.
Client-side redirects. A page that renders, then redirects via JavaScript. Google may index the intermediate. Server-side 301s are unambiguous; client-side redirects are a guess.
Meta tags injected client-side. Title and description set by a client-side head manager may be picked up, but conflicting values between the raw HTML and the rendered DOM resolve unpredictably. Put them in the server response.
Streaming SSR flushing content late. Frameworks that stream HTML in chunks can send the shell first and content later. Generally handled correctly, but worth verifying with the URL Inspection tool rather than assuming.
Soft 404s from client-side routing. A URL that does not exist returns 200 with a shell, then renders "not found" in JavaScript. Google sees a 200 and may index it. The server needs to return an actual 404 status.
Verifying whatever you chose
Three checks, whatever the architecture:
curlthe URL and confirm the primary content, title, canonical, and internal links are present in the raw response.- Run URL Inspection's live test and check the rendered HTML plus the failed-resource list.
- Confirm that a URL which should 404 actually returns a 404 status, not a 200 with an error message.
Passing all three means your rendering strategy is not the problem, whatever it is. That is a more useful conclusion than a blanket rule about which strategy is best, because it is one you can actually verify.