SSR vs CSR: what you lose in SEO and GEO if you chose wrong

If your site is a pure SPA (React, Vue, Svelte without pre-render), you're leaving money on the table. It's not opinion, it's measurable behavior of search engines and LLMs in 2026. This post explains the differences between rendering modes and when to use each, without technical manual, with focus on what matters for SEO and GEO.

What each mode is

The four acronyms that matter:

• CSR (Client-Side Rendering): the server sends minimal HTML (<div id="root"></div>) + JavaScript. The user's browser executes the JS and builds the page. Example: a classic React app with Vite or create-react-app.
• SSR (Server-Side Rendering): the server generates the complete HTML on each request and sends it to the browser already rendered. JS hydrates after to make the page interactive. Example: Next.js with dynamic = "force-dynamic".
• SSG (Static Site Generation): HTML is generated at build (when you deploy), and served static from CDN. Each user receives the same cached version. Example: Next.js without dynamic export, Astro, Hugo.
• ISR (Incremental Static Regeneration): SSG + periodic revalidation. Pages are generated static, but regenerated in background every certain time or on demand. Example: Next.js with revalidate: 3600.

There's a fifth variant worth mentioning: streaming SSR (Next.js App Router with React 18+), which combines SSR with the ability to send page parts progressively. For SEO and GEO it behaves like SSR.

How Google and LLMs see them

Quick table:

| Mode | Googlebot | AI crawlers (GPTBot, ClaudeBot) | User initial speed | |---|---|---|---| | Pure CSR | Limited, with delay | Don't read | Slow (waits for JS) | | SSR | Yes, full | Yes, full | Medium | | SSG | Yes, full | Yes, full | Fast | | ISR | Yes, full | Yes, full | Fast | | Streaming SSR | Yes, full | Yes (reads initial HTML) | Very fast |

The critical detail: Google executes JavaScript but with limitations (delay of hours/days, limited resources, doesn't wait for slow APIs). On the other hand, AI crawlers read the HTML the server returns without executing JS. If your site is pure CSR, the LLM sees an empty <div id="root"></div> and that's all it indexes.

Why pure CSR loses traffic even if "Google renders JS"

Three documented reasons:

1. Indexing delay: Google renders SPAs in a second pass (after the initial crawl). That means new pages take longer to appear in SERP, sometimes weeks. SSR/SSG appear in hours.
2. Partial coverage: Google doesn't guarantee rendering all the JS. If your app depends on an API that fails, or takes longer than Google's internal timeout, that page doesn't get indexed.
3. LLMs don't enter: ChatGPT, Claude, Perplexity, and Google AI Overviews don't execute JS. For them your CSR site doesn't exist. You lose the new search layer completely.

Real case: an agency that built their site with React + Vite (pure CSR) had 0 mentions in ChatGPT despite spending 2 years publishing blog and ranking well in Google. The reason: Google indexed the blog (with delay), but LLMs saw absolutely nothing. Migrating to Next.js SSG gave them mentions in ChatGPT in 60 days without changing the content.

SPA → Next.js migration: what to expect

If you decide to migrate, this is what you'll touch:

1. Routing: switch from React Router to Next.js App Router (file-based routing). The paradigm change takes 1-2 weeks depending on site size.
2. Data fetching: switch from useEffect + fetch on client to Server Components or getServerSideProps/getStaticProps. This is what takes most because you have to rethink where each datum loads.
3. Global state: Redux/Zustand still work but with hydration considerations. Some patterns change.
4. Styles: Tailwind works the same. CSS-in-JS (styled-components, emotion) requires specific setup for SSR.
5. Authentication: cookies instead of localStorage for tokens, or specific setup for SSR auth.
6. Images: leverage next/image which gives WebP/AVIF automatic and lazy loading.

Realistic timeline: a medium site (10-30 pages, 1 blog, 1 form) takes 4-8 weeks with a senior dev. The most subtle part is exhaustive hydration testing: common errors are hydration mismatches that break interactivity without visible error.

When CSR is still OK

Three cases where CSR doesn't hurt SEO/GEO because SEO/GEO isn't priority:

1. Internal apps behind auth: dashboards, team tools, CRMs. No one crawls them, they don't need to index. CSR is valid.
2. Complex webapps (not marketing site): Figma, Linear, Notion. Their value is in interactive UX, public content is marketing apart (which is in SSG).
3. Very early MVPs: if you're validating idea with 50 beta users, SEO doesn't matter yet. CSR is fast to iterate functionality. But migration plan before public marketing.

When NOT to use it

Pure CSR does NOT go for:

• Landing pages: the first contact point with clients. Has to rank, has to load fast, has to be read by LLMs.
• Blogs: content that lives off organic search. CSR takes too long to index and blocks GEO.
• Ecommerce: catalog + product + filters. You need each product to be individually indexable.
• Agency or professional services sites: depend on appearing in "agency X mexico" and similar. Without SSR you lose position to competitors who do.
• Corporate institutional sites: image + public content. SSR/SSG give the right balance of performance + indexing.

How to verify your site in 30 seconds

Without tools, in browser:

1. Open your site in a new window (not logged in, no extensions).
2. Right-click → "View page source" (or Cmd/Ctrl+U on Mac/Windows).
3. Look at the HTML.

If you see:

• All visible content (texts, headings, referenced images) in the HTML → SSR or SSG, OK.
• Only <div id="root"></div> or <div id="__next"></div> empty + scripts → pure CSR, problem.
• Content but missing interactive parts → SSR + hydration, OK.

Confirm with Google Mobile-Friendly Test → shows what Googlebot sees.

To confirm what LLMs see, an option is to use a bot user-agent:

curl -A "Mozilla/5.0 (compatible; GPTBot/1.0)" https://yourdomain.com

If the response is full HTML with your content, LLMs read you. If it's empty HTML with scripts, they don't.

Quick decision per your case

| Your situation | Recommendation | |---|---| | New site, pre-launch | Next.js with SSR/SSG from day 1 | | Existing CSR site, marketing site | Migrate to Next.js, 4-8 week timeline | | Existing CSR site, internal webapp | Stay in CSR, no problem | | Hybrid (marketing in CSR + app in CSR) | Separate marketing site to SSG, keep app in CSR | | WordPress | Already rendered server-side (PHP), OK by default. Optimize performance | | Webflow / Wix / Squarespace | Server-rendered, OK. Limitations in enriched schema |

If your case doesn't fit clearly in any row, write us. We do free technical audit and tell you honestly if you need migration or if tactical adjustments are enough.

The simple rule for 2026: if your site depends on being found by clients, SSR or SSG. Pure CSR is for apps behind login.