If you build websites for clients, you've probably seen this pattern: ship a slick React or Vue SPA, everyone's happy with the demo, and three months later the client is asking why the site isn't showing up in Google.
Nine times out of ten, the answer is rendering strategy, not content quality.
The core problem
A pure client-side rendered (CSR) app sends the browser a nearly empty index.html and lets JavaScript build the DOM after load. Modern Googlebot can execute JavaScript, but it does so in a second rendering wave, with a delay, a resource budget, and no guarantee of full execution — especially on sites with heavy hydration, client-side routing, or render-blocking scripts. In practice, that means:
Meta tags, canonical tags, and structured data can resolve to homepage defaults or nothing at all
view-source: shows an empty shell — no headings, no body copy
Sitemaps generated client-side can return as unparseable to crawlers instead of clean XML
Pages look finished to a human, but Search Console shows them as "Discovered — not indexed" or "Crawled — not indexed" indefinitely
This isn't a hypothetical. It's a documented, sitewide failure mode I've seen firsthand — agencies shipping otherwise well-designed sites that are functionally invisible to search because nobody checked the rendering strategy against SEO requirements before launch.
The fix isn't complicated
SSR (Next.js, Nuxt, SvelteKit, Astro's server mode) — render on request, crawler gets full HTML immediately
SSG/ISR — prerender at build time or on a cache interval, serve static HTML with JS hydration on top
Dynamic rendering as a stopgap — serve a prerendered snapshot to known crawler user-agents while keeping CSR for real users (not ideal long-term, but works as a bridge)
What doesn't work: telling the client "Google can render JS now" and shipping pure CSR anyway. It technically can. It doesn't reliably, at scale, on a timeline your client's business depends on.
Why this matters beyond the technical fix
I ended up going down this rabbit hole while helping evaluate web design vendors for a project — turns out this exact SSR/CSR distinction is one of the clearest signals for telling a technically competent agency from one that's just good at sales. If an agency can't answer "will this be SSR or CSR" in one sentence, that's informative on its own.
I wrote up a longer, less code-heavy version of this as part of a broader comparison of web design agencies — worth a look if you're on the business side of this decision rather than the dev side: the technical writeup
Curious how others handle this on client projects — do you default to SSR/SSG now, or is dynamic rendering still in your toolkit as a stopgap?
Top comments (0)