- La diferencia entre CSR, SSR, SSG e ISR está en qué HTML llega en la primera respuesta y qué se construye después.
- Googlebot renderiza JavaScript, pero con delay por la cola del WRS; los crawlers de IA (GPTBot, ClaudeBot, PerplexityBot) no lo ejecutan.
- Una web CSR pura es invisible para las respuestas de IA; SSR, SSG e ISR entregan el HTML ya listo.
- No hay un método ganador: se elige por tipo de página (SSG para estable, ISR para actualización periódica, SSR para dinámico, CSR solo sin SEO).
- Incluye cómo auditar el renderizado de una web en 15 minutos.
Renderizar es el proceso por el que el HTML, el CSS y el JavaScript se transforman en píxeles en pantalla. Hasta ahí, la definición es genérica. La pregunta que a un SEO le interesa es distinta: qué HTML llega al crawler y en qué momento.
Porque Google, Bing y los crawlers de IA (GPTBot, ClaudeBot, PerplexityBot) no ven tu web como el usuario. Cada uno tiene sus propias capacidades y sus propias limitaciones, y a partir de ahí se juega el partido de la indexación.
El viaje del HTML: del servidor al DOM al índice de Google
El flujo básico es siempre el mismo: el navegador o crawler hace una request, recibe una respuesta HTTP, procesa el HTML, construye el DOM, ejecuta JavaScript (si puede) y renderiza. La diferencia entre CSR, SSR, SSG e ISR está en qué llega ya cocinado en esa primera respuesta HTTP y qué se tiene que construir después.
De ahí sale una distinción que vas a leer en todo el post: HTML inicial vs HTML renderizado. El HTML inicial es lo que devuelve el servidor. El HTML renderizado es lo que existe en el DOM después de que el JavaScript termine de ejecutarse. Para muchos crawlers, esos dos HTML son mundos distintos.
Antes de auditar un CMS moderno, aprende a leer la waterfall de Network en Chrome DevTools. La primera fila —el request al documento HTML— te dice el 80% de lo que necesitas saber sobre cómo renderiza esa web.
Cómo renderiza Googlebot en 2026: el WRS y la cola de rendering
Googlebot no renderiza JavaScript en el mismo momento en que rastrea. El fetch es inmediato, pero el render entra en la cola del Web Rendering Service (WRS) y se ejecuta cuando hay recursos disponibles. Ese delay puede ir de segundos a días. Google usa una versión headless de Chromium evergreen (actualizada continuamente desde 2019), así que la capacidad técnica está resuelta; el problema es la latencia entre la publicación y la indexación efectiva.
En un blog de marca eso no importa. En un e-commerce que sube productos cada día o en un medio de noticias, sí.
La conclusión práctica: aunque Google sepa ejecutar JavaScript, no te conviene obligarle a hacerlo si tienes la opción de servirle el HTML ya listo. Las reglas de Google sobre enlaces, canonical y códigos de estado en una SPA las detallo en mis buenas prácticas de JavaScript SEO.
CSR — Client-Side Rendering
El servidor devuelve un HTML casi vacío, típicamente un <div id="root"></div> y un bundle de JavaScript. Todo el contenido se construye en el navegador ejecutando ese JS. El caso arquetípico son las SPAs con React, Vue o Angular sin capa de SSR.
Desde SEO es problemático por tres motivos: el HTML inicial no tiene contenido, las meta tags, incluida la etiqueta canonical, se inyectan tarde (o directamente no se inyectan si el JS falla) y el structured data queda expuesto al mismo timing. Google puede renderizarlo, pero con delay. Los AI crawlers no lo renderizan en absoluto. Y lo que solo aparece tras una interacción, como el scroll infinito o un botón de «cargar más», puede no llegar nunca al índice.
¿Cuándo sigue teniendo sentido CSR en 2026? Cuando el SEO es irrelevante: dashboards detrás de login, herramientas SaaS internas, apps admin. Un panel de administración no necesita rankear. Un e-commerce sí.
SSR — Server-Side Rendering
El servidor renderiza el HTML completo en cada petición y lo envía listo. El cliente lo pinta al instante y luego hidrata con JavaScript para añadir interactividad. Frameworks canónicos: Next.js (con Server Components dinámicos o getServerSideProps en Pages Router), Nuxt 3, Remix, SvelteKit.
Desde SEO es cómodo: HTML completo desde la primera respuesta, indexación óptima, funciona para todos los crawlers incluidos los de IA. El coste está en la infraestructura: mayor carga en servidor, TTFB peor si la lógica es pesada, y necesidad de una capa de cache bien pensada.
Idóneo para páginas que combinen SEO crítico y datos frescos: e-commerce con precios y stock dinámicos, feeds personalizados, cualquier ruta donde el contenido cambia al segundo.
Si vas a servir SSR puro, cachea a nivel de CDN (Cloudflare, Vercel Edge, Fastly). Pagar TTFB por cada request cuando el 90% del tráfico ve la misma versión es tirar dinero y ranking. Cómo configurar la caché para Googlebot y usuarios lo explico aparte.
SSG — Static Site Generation
El HTML se genera una única vez, en build time, durante el deploy. A partir de ese momento se sirve como archivos estáticos desde CDN. Frameworks: Astro, Hugo, Eleventy, Jekyll, Next.js con output: 'export', Gatsby.
Es la joya de la corona del SEO técnico: TTFB casi cero, FCP y LCP excelentes, HTML servido sin depender de JavaScript, todos los crawlers lo ven perfecto. La limitación es obvia: cada cambio requiere un rebuild.
Idóneo para blogs, documentación técnica, landing pages, sites de marca y portfolios. Este mismo site, cristofercruz.net, funciona con SSG puro y saca 100/99/100/100 en PageSpeed. No es magia; es que el servidor no tiene que pensar nada.
ISR — Incremental Static Regeneration
Híbrido entre SSG y SSR: el HTML se genera en build, pero puede regenerarse en background según una política. Nació en Next.js y hoy lo replican Nuxt, SvelteKit y Astro con matices propios.
Hay dos formas de disparar la regeneración: por tiempo (revalidate: 3600 en Next.js regenera la página cada hora si alguien la visita) y por evento (revalidatePath o revalidateTag invalidan la cache cuando cambia el CMS o el catálogo). Combinadas, dan lo mejor de dos mundos: HTML servido desde CDN con la frescura de un SSR selectivo.
Idóneo para e-commerce grande con cambios moderados, blogs de noticias con alto tráfico y portales con miles de páginas.
El escollo típico de ISR es el fallback. Con fallback: true mal configurado, la primera visita a una URL nueva devuelve un 404 percibido hasta que se completa la primera regeneración. Con fallback: 'blocking' esperas al render pero sirves bien. Elige en función del volumen de contenido nuevo.
Impacto real en SEO: lo que ve Googlebot, lo que ven los crawlers de IA
El debate "SSR es mejor que CSR para SEO" ha envejecido mal. Se ha quedado obsoleto porque no distingue entre el Googlebot moderno (que renderiza) y los AI crawlers (que no). En 2026 hay dos audiencias de máquinas, y cada una impone sus propias reglas.
| Método | HTML inicial | Indexación Google | Crawlers IA | LCP | TTFB | Coste infra | Frescura |
|---|---|---|---|---|---|---|---|
| CSR | Vacío | Con delay (WRS) | No | Malo | Bajo | Mínimo | Real time |
| SSR | Completo | Inmediata | Sí | Bueno | Medio-alto | Alto | Real time |
| SSG | Completo | Inmediata | Sí | Excelente | Muy bajo | Mínimo | Build time |
| ISR | Completo | Inmediata | Sí | Excelente | Muy bajo | Bajo | Regenerable |
La columna que casi nadie pone en su tabla comparativa es la de AI crawlers. Y es, en 2026, la más importante.
El punto ciego del sector: GPTBot, ClaudeBot y PerplexityBot no ejecutan JavaScript
Los principales AI crawlers de 2026 —GPTBot de OpenAI, ClaudeBot de Anthropic, PerplexityBot, Google-Extended, CCBot— hacen fetch del HTML pero no renderizan JavaScript. Punto. Se llevan lo que devuelve el servidor en la primera respuesta y ya está.
Consecuencia directa: una web CSR pura es literalmente invisible para ChatGPT y Claude cuando construyen respuestas o cuando entrenan modelos. No es que ranquee peor. Es que no existe.
Hay matices, claro. SearchGPT tira del índice de Bing, Perplexity combina indexación propia con búsqueda tradicional, y las citas en Overviews de Google usan la infraestructura de Google. Pero el HTML crudo sigue siendo el mínimo común denominador de todo lo que hoy llamamos GEO y AEO. Si publicas contenido y quieres que las IAs lo citen, servirlo desde una SPA sin prerender es un tiro en el pie. Y decidir cuáles de esos bots entran es otra capa: se controla en robots.txt para bots de IA.
Auditoría técnica de renderizado y visibilidad en IA.
Detecto si tu web es invisible para GPTBot, ClaudeBot y PerplexityBot, y te paso el plan mínimo viable para arreglarlo sin migrar todo el stack.
Si tu web es CSR y quieres aparecer en respuestas de ChatGPT o Claude sin migrar todo el stack, hay dos rutas rápidas: prerender.io (o similares) como capa intermedia que sirve HTML estático a los bots (con el mismo contenido que ve el usuario, o rozas el cloaking), o SSR selectivo solo para las rutas críticas de contenido (blog, landings principales, páginas de producto).
Cómo auditar el renderizado de una web existente en 15 minutos
Antes de recomendar migraciones, mide. Este es el procedimiento que uso en auditorías.
View Source vs HTML renderizado: qué comparar y qué buscar
La técnica más rápida: abre la URL en Chrome, haz clic derecho → Ver código fuente de la página (Ctrl+U). Luego abre DevTools (Ctrl+Shift+I) y ve a la pestaña Elements.
- Si el View Source está prácticamente vacío y el contenido solo aparece en Elements, es CSR.
- Si el View Source ya contiene el contenido visible, el
<title>, la meta description, el H1 y el structured data, es SSR, SSG o ISR (para distinguir entre esos tres necesitas mirar cabeceras y comportamiento en el tiempo).
Lo que tienes que buscar concretamente en el View Source: <title> con texto real (no "React App"), meta description populada, H1 presente, contenido principal en texto plano y JSON-LD de structured data ya renderizado. Si algo de eso falta en el View Source pero está en Elements, tu web depende del cliente para el SEO.
Screaming Frog en modo JS, URL Inspection y Chrome DevTools
Para auditar a escala:
- Screaming Frog en modo JS Rendering (Configuration → Spider → Rendering → JavaScript). Rastrea con y sin JS y compara HTML crudo vs renderizado en cientos de URLs.
- Google Search Console → URL Inspection → View Rendered Page. Es la fuente autoritativa: te muestra exactamente el HTML que Google indexó tras el WRS.
- Chrome DevTools → Network → filtro "Doc". La primera respuesta del documento revela si trae el HTML completo o solo el shell vacío.
Uso la extensión de Chrome que estoy manteniendo (Cristofer Cruz — SEO, v0.4.0) para detectar el tipo de renderizado en cada pestaña sin salir a herramientas externas. Está pensada para auditorías rápidas en cliente.
Señales de que tu CSR te está costando tráfico
Cinco síntomas concretos:
- Impresiones planas en GSC pese a publicar contenido nuevo cada semana.
- Delay entre publicación e indexación mayor a 48 horas.
- LCP superior a 4 segundos en móvil según datos de CrUX (el límite de «malo» en los umbrales de Core Web Vitals).
- Meta tags con valor vacío en el HTML servido y valores correctos solo en el DOM.
- Tráfico cero desde ChatGPT, Claude o Perplexity pese a rankear en Google.
Si cumples dos de cinco, audita a fondo. Si cumples tres o más, empieza a planificar la migración.
Lo que viene: React Server Components, Partial Prerendering, islands y resumability
Los cuatro conceptos que están redefiniendo el debate en 2026:
- React Server Components (RSC). Componentes que renderizan en servidor y no envían JavaScript al cliente. Adoptados en el App Router de Next.js, ya son el default de facto.
- Partial Prerendering (PPR). La misma página mezcla zonas SSG y zonas SSR dinámicas, servidas en streaming. Cabecera y layout estáticos; carrito y precios en tiempo real. Todo en la misma respuesta.
- Islands architecture. Modelo de Astro y Fresh: por defecto HTML estático, y solo se hidratan islas de interactividad puntuales. Menos JavaScript, mejor CWV.
- Resumability. Qwik y sus derivados evitan la hidratación completa. El JS se carga fragmentado y bajo demanda al interactuar con cada elemento.
La conclusión: la línea entre CSR, SSR, SSG e ISR se está difuminando. En pocos años dejaremos de hablar de "métodos" y hablaremos de estrategias híbridas por componente. La pregunta ya no será "qué método usa mi web" sino "cómo renderiza cada ruta y cada zona de la página".
Cómo elegir: matriz de decisión por tipo de página
Tres preguntas responden por ti:
- ¿La página necesita SEO? Sí / No.
- ¿El contenido cambia por usuario o por request? Sí / No.
- ¿La frescura importa al segundo, o basta con minutos u horas?
Del cruce sale el mapping natural:
- Contenido público estable (blog, docs, marca) → SSG.
- Contenido público con actualización periódica (e-commerce, noticias) → ISR.
- Contenido público muy dinámico o personalizado (feeds, precios en vivo, resultados de búsqueda) → SSR.
- Contenido privado sin SEO (dashboards, apps internas) → CSR.
Y ojo con la trampa de la elección única: el 90% de los proyectos reales combinan varias estrategias por ruta. Home en SSG, catálogo en ISR, ficha de producto con precio en SSR, panel de usuario en CSR. No elijas un método para todo el sitio; elige un método para cada tipo de página.
Preguntas frecuentes
¿Google indexa contenido renderizado con JavaScript?
Sí, Googlebot renderiza JavaScript a través del Web Rendering Service, con un delay que va de segundos a días según la carga de la cola. La indexación funciona, pero introduce latencia entre publicación y presencia en el índice. Si publicas contenido perecedero, mejor sírvelo ya renderizado.
¿ChatGPT y Claude leen mi web si es CSR?
No en el sentido útil. GPTBot y ClaudeBot hacen fetch del HTML pero no ejecutan JavaScript, así que si tu contenido se construye en cliente, para ellos tu página está vacía. Si te interesa aparecer en respuestas de IA, necesitas HTML servido, ya sea por SSR, SSG, ISR o una capa de prerender.
¿Merece la pena migrar de CSR a SSR solo por SEO?
Depende del delta. Si el delay de indexación de Google es aceptable y no publicas contenido perecedero, probablemente no. Si publicas noticias, productos nuevos cada día o quieres aparecer en respuestas de IA, sí. Mide el delay actual en GSC antes de decidir.
¿ISR es igual que SSG?
No. SSG genera todo el HTML en build y no lo toca hasta el siguiente deploy. ISR también genera en build, pero regenera páginas concretas en background según una política de tiempo o de eventos, sin necesidad de rebuild completo. En sitios con miles de URLs, la diferencia en tiempos de deploy es enorme.
¿Qué método usa Next.js por defecto en 2026?
El App Router de Next.js usa React Server Components por defecto, lo que produce HTML servido en el servidor (equivalente funcional a SSR) sin enviar el JS de esos componentes al cliente. Cada ruta puede además marcarse como estática, ISR o dinámica según la configuración de la página.
Referencias
Fuentes oficiales y lecturas recomendadas para profundizar en cada uno de los conceptos tratados en este artículo:
- JavaScript SEO basics Google Search Central
- Rendering on the web web.dev · Google
- Rendering — Next.js docs Vercel
- GPTBot documentation OpenAI
- ClaudeBot user-agent Dark Visitors
- Islands architecture Astro Docs
- Resumability Qwik Docs
Si te ha servido este post y quieres aplicarlo a tu proyecto, en la auditoría SEO completa reviso el modo de renderizado por ruta y el impacto real que tiene sobre tu indexación. Y si quieres una segunda opinión estratégica antes de migrar, mejor hablamos en consultoría.
