Server-side rendering builds the page HTML on the server, so what arrives already contains the content. Client-side rendering sends a minimal shell and builds the page in the browser with JavaScript. For search, the difference is whether the content exists when the page is first fetched.
Why it matters for indexing
Google does render JavaScript, so client-side rendering is not fatal. It is, however, conditional in a way server-side rendering is not.
- Server-rendered content is present in the initial response. Nothing has to succeed for it to be seen.
- Client-rendered content requires the script to load, execute and complete. Any failure leaves the page empty.
- Rendering is deferred. Content that needs JavaScript is processed later than content that does not, which delays indexing.
- Other crawlers are less capable. Many social, tool and AI crawlers do not execute JavaScript at all.
The practical summary: server-side rendering is reliable, client-side rendering usually works. On pages that generate revenue, usually is a weaker guarantee than most teams want.
Where client-side rendering breaks
- A script fails or times out and the page renders empty.
- Content depends on an API that is slow or rate-limited during crawling.
- Links are generated in JavaScript rather than as anchor tags, so crawlers cannot follow them.
- Content loads on scroll or interaction, which crawlers do not perform. See infinite scroll SEO.
- Meta tags and canonicals are set client-side, so the initial response contains defaults or nothing.
That last one is particularly damaging, because the directives arrive after the initial assessment.
The middle options
- Static generation: pages built at deploy time. The most reliable option where content changes infrequently.
- Hybrid rendering: critical content server-rendered, the rest hydrated client-side. This is the pragmatic answer for most applications.
- Dynamic rendering: serving pre-rendered HTML to crawlers. Once recommended, now discouraged as a long-term approach, though still used as a stopgap.
A useful rule: whatever must be indexed should be in the initial HTML. Everything else can be client-side.
Testing what Google sees
- Compare rendered HTML against page source using URL Inspection. See the URL Inspection tool.
- Disable JavaScript and load the page. What remains is roughly the guaranteed minimum.
- Check that internal links exist as anchor tags in the source.
- Confirm titles, canonicals and meta directives are in the initial response.
- Test on templates that matter commercially, not just the homepage.
Frequently asked questions
Is client-side rendering bad for SEO?
Not inherently, and many CSR sites rank well. It introduces a dependency that server rendering does not have, and that dependency fails silently when it fails.
Does Google render JavaScript?
Yes, but in a deferred second pass. That delay affects how quickly changes are picked up, and other crawlers are less capable than Google’s.
Should we switch to server-side rendering?
If content is not being indexed reliably, yes. If everything indexes correctly, the case is weaker. Test what Google actually sees before rebuilding anything.
What about dynamic rendering?
It works as a stopgap and is no longer recommended as a permanent solution. Hybrid or static rendering is the better long-term answer.
Consulting CTA
If your content is not being indexed and your site depends on JavaScript rendering, book an SEO consultation for a rendering review.