The short version
- Server-rendered content is in the HTML. Client-rendered content requires JavaScript to execute first.
- Search engines can render JavaScript, but it is a second pass, and relying on it is a risk with no compensating benefit.
- The check takes ten seconds: view source — actual source, not the inspector — and look for your content.
- For any page that needs to rank, render it server-side or statically. There is no SEO argument for the alternative.
This is one of very few technical decisions that can take a page from ranking to invisible, which makes it worth more attention than its share of SEO discussion suggests. The failure is also unusually easy to ship, because a client-rendered page looks perfect in a browser.
The short answer
Fit for your workflow
Server-render or statically generate anything that needs to rank.
Search engines do execute JavaScript, and Google documents how. But it happens in a second pass with no guarantee of timing, and other consumers of your pages — including some AI crawlers — may not execute JavaScript at all. Since modern frameworks make server rendering straightforward, the risk buys you nothing.
- Marketing and content pages
- Static generation. Fastest and most reliable.
- Frequently changing content
- Server-side rendering.
- Logged-in application views
- Client-side is fine — these should not be indexed anyway.
- Existing client-rendered site
- Check what is indexed before assuming there is a problem.
The approaches
The fifth row is worth separating out, because it causes confusion. A React or Vue app that server-renders and then hydrates in the browser is server-rendered for SEO purposes — the content is in the HTML. Using a JavaScript framework is not the problem; shipping an empty HTML shell is.
How to check in ten seconds
- View page source — Ctrl+U or right-click, View Page Source. Not the inspector, which shows the rendered DOM and will mislead you.
- Search the source for a distinctive sentence from your main content.
- Not there? Your content is client-rendered and you are relying on a second pass.
- Cross-check with the URL Inspection tool in Search Console, which shows the rendered HTML Google actually used.
- Crawl with JavaScript disabled in Screaming Frog to see the whole site the way a non-executing crawler does.
What else reads your HTML
Search engines are the most forgiving consumers of your pages, not the least. Google documents a rendering pipeline that executes JavaScript; many other things that read your site do not. Social preview crawlers, link preview generators in messaging apps, RSS readers, archival crawlers and a number of AI agents fetch the HTML and never run a script.
That widens the cost of client-side rendering well beyond rankings. A client-rendered page can produce an empty preview when someone shares it, contribute nothing to how an assistant describes your category, and be archived as a blank shell. Server rendering fixes all of those at once, which is why Google’s own JavaScript SEO guidance treats it as the safer default rather than merely the faster one.
There is a middle case worth knowing. A page can be server-rendered for its main content and client-rendered for secondary elements — reviews loaded on scroll, a related-products carousel, comments. That is usually fine, because the thing being indexed is present. The test is not whether any JavaScript runs; it is whether the content you want ranked is in the initial HTML.
The inspector is not the source
Developer tools show the DOM after JavaScript has run, which means a client-rendered page looks identical to a server-rendered one there. This single confusion is responsible for a lot of sites shipping invisible content with everyone satisfied it was fine.