SSR vs CSR: lo que pierdes en SEO y GEO si elegiste mal

Si tu sitio es una SPA pura (React, Vue, Svelte sin pre-render), estás dejando dinero en la mesa. No es opinión, es comportamiento medible de los motores de búsqueda y los LLMs en 2026. Este post explica las diferencias entre los modos de renderizado y cuándo usar cada uno, sin manual técnico, con foco en lo que importa para SEO y GEO.

Qué es cada modo

Las cuatro siglas que importan:

• CSR (Client-Side Rendering): el servidor manda HTML mínimo (<div id="root"></div>) + JavaScript. El navegador del usuario ejecuta el JS y construye la página. Ejemplo: una app React clásica con Vite o create-react-app.
• SSR (Server-Side Rendering): el servidor genera el HTML completo en cada request y lo manda al navegador ya renderizado. El JS se hidrata después para hacer la página interactiva. Ejemplo: Next.js con dynamic = "force-dynamic".
• SSG (Static Site Generation): el HTML se genera en build (cuando deployas), y se sirve estático desde CDN. Cada usuario recibe la misma versión cacheada. Ejemplo: Next.js sin export dinámico, Astro, Hugo.
• ISR (Incremental Static Regeneration): SSG + revalidación periódica. Las páginas se generan estáticas, pero se regeneran en background cada cierto tiempo o bajo demanda. Ejemplo: Next.js con revalidate: 3600.

Hay una quinta variante que vale la pena mencionar: streaming SSR (Next.js App Router con React 18+), que combina SSR con la posibilidad de enviar partes de la página progresivamente. Para SEO y GEO se comporta como SSR.

Cómo lo ven Google y los LLMs

Tabla rápida:

| Modo | Googlebot | Crawlers de IA (GPTBot, ClaudeBot) | Velocidad inicial usuario | |---|---|---|---| | CSR puro | Limitado, con delay | No leen | Lenta (espera al JS) | | SSR | Sí, completo | Sí, completo | Media | | SSG | Sí, completo | Sí, completo | Rápida | | ISR | Sí, completo | Sí, completo | Rápida | | Streaming SSR | Sí, completo | Sí (lee HTML inicial) | Muy rápida |

El detalle crítico: Google ejecuta JavaScript pero con limitaciones (delay de horas/días, recursos limitados, no espera a APIs lentas). En cambio, los crawlers de IA leen el HTML que devuelve el servidor sin ejecutar JS. Si tu sitio es CSR puro, el LLM ve un <div id="root"></div> vacío y eso es todo lo que indexa.

Por qué CSR puro pierde tráfico aunque "Google rendere JS"

Tres razones documentadas:

1. Delay de indexación: Google rendere SPAs en una segunda pasada (después del crawl inicial). Eso significa que páginas nuevas tardan más en aparecer en SERP, a veces semanas. SSR/SSG aparecen en horas.
2. Cobertura parcial: Google no garantiza renderear todo el JS. Si tu app depende de una API que falla, o tarda más del timeout interno de Google, esa página no se indexa.
3. LLMs no entran: ChatGPT, Claude, Perplexity y Google AI Overviews no ejecutan JS. Para ellos tu sitio CSR no existe. Pierdes la capa nueva de búsqueda completamente.

Caso real: una agencia que hizo su sitio con React + Vite (CSR puro) tenía 0 menciones en ChatGPT pese a llevar 2 años publicando blog y rankear bien en Google. La razón: Google indexaba el blog (con delay), pero los LLMs no veían absolutamente nada. Migrar a Next.js SSG les dio menciones en ChatGPT en 60 días sin cambiar el contenido.

Migración SPA → Next.js: qué esperar

Si decides migrar, esto es lo que vas a tocar:

1. Routing: pasar de React Router a Next.js App Router (file-based routing). El cambio de paradigma toma 1-2 semanas dependiendo del tamaño del sitio.
2. Data fetching: pasar de useEffect + fetch en cliente a Server Components o getServerSideProps/getStaticProps. Esto es lo que más toma porque hay que repensar dónde se carga cada dato.
3. Estado global: Redux/Zustand siguen funcionando pero con consideraciones de hidratación. Algunos patrones cambian.
4. Estilos: Tailwind funciona igual. CSS-in-JS (styled-components, emotion) requiere setup específico para SSR.
5. Autenticación: cookies en lugar de localStorage para tokens, o setup específico para SSR auth.
6. Imágenes: aprovecha next/image que da WebP/AVIF automático y lazy loading.

Plazo realista: un sitio mediano (10-30 páginas, 1 blog, 1 form) toma 4-8 semanas con un dev senior. La parte más sutil es testing exhaustivo de hidratación: errores comunes son hydration mismatches que rompen interactividad sin error visible.

Cuándo CSR sigue siendo OK

Tres casos donde CSR no daña SEO/GEO porque el SEO/GEO no es prioridad:

1. Apps internas detrás de auth: dashboards, herramientas de equipo, CRMs. No los crawlea nadie, no necesitan indexar. CSR es válido.
2. Webapps complejas (no marketing site): Figma, Linear, Notion. Su valor está en la UX interactiva, el contenido público es marketing aparte (que sí está en SSG).
3. MVPs muy tempranos: si estás validando idea con 50 usuarios beta, SEO no importa todavía. CSR rápido para iterar funcionalidad. Pero plan de migración antes de marketing público.

Cuándo NO usarlo

CSR puro NO va para:

• Landing pages: el primer punto de contacto con clientes. Tiene que rankear, tiene que cargar rápido, tiene que ser leído por LLMs.
• Blogs: contenido que vive de búsqueda orgánica. CSR tarda demasiado en indexar y bloquea GEO.
• Ecommerce: catálogo + producto + filtros. Necesitas que cada producto sea indexable individualmente.
• Sitios de agencia o servicios profesionales: dependen de aparecer en "agencia X méxico" y similares. Sin SSR pierdes posición frente a competidores que sí lo hacen.
• Sitios institucionales corporativos: imagen + contenido público. SSR/SSG dan el balance correcto de performance + indexación.

Cómo verificar tu sitio en 30 segundos

Sin herramientas, en navegador:

1. Abre tu sitio en una ventana nueva (no logueada, sin extensiones).
2. Click derecho → "View page source" (o Cmd/Ctrl+U en Mac/Windows).
3. Mira el HTML.

Si ves:

• Todo el contenido visible (textos, headings, imágenes referenciadas) en el HTML → SSR o SSG, OK.
• Solo <div id="root"></div> o <div id="__next"></div> vacío + scripts → CSR puro, problema.
• Ves contenido pero faltan partes interactivas → SSR + hidratación, OK.

Confirma con Mobile-Friendly Test de Google → te muestra qué ve Googlebot.

Para confirmar qué ven los LLMs, una opción es usar un user-agent de bot:

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

Si la respuesta es HTML completo con tu contenido, los LLMs te leen. Si es HTML vacío con scripts, no.

Decisión rápida según tu caso

| Tu situación | Recomendación | |---|---| | Sitio nuevo, pre-launch | Next.js con SSR/SSG desde el día 1 | | Sitio existente CSR, marketing site | Migrar a Next.js, plazo 4-8 semanas | | Sitio existente CSR, webapp interna | Quedarte en CSR, sin problema | | Híbrido (marketing en CSR + app en CSR) | Separar marketing site a SSG, mantener app en CSR | | WordPress | Ya está renderizado en servidor (PHP), OK por default. Optimizar performance | | Webflow / Wix / Squarespace | Renderizado en servidor, OK. Limitaciones de schema enriquecido |

Si tu caso no encaja claro en ninguna fila, escríbenos. Hacemos auditoría técnica gratis y te decimos honestamente si necesitas migración o si con ajustes tácticos basta.

La regla simple para 2026: si tu sitio depende de ser encontrado por clientes, SSR o SSG. CSR puro es para apps detrás de login.