Renderizado para SEO: SSR, SSG, CSR y prerenderizado

La guía de JavaScript y SEO técnico de esta sección explica por qué Google procesa el HTML en dos fases y qué falla cuando el contenido depende de una ejecución de JavaScript. Esta guía da un paso atrás y compara, a nivel de arquitectura, las estrategias que existen para evitar ese problema desde el diseño del proyecto: no es una cuestión de "qué framework usar" sino de "dónde y cuándo se genera el HTML", una decisión que afecta a rendimiento, coste de infraestructura y complejidad de desarrollo mucho más allá del SEO.

Client-Side Rendering (CSR): el punto de partida y sus costes reales

En CSR, el servidor entrega un HTML casi vacío y el navegador ejecuta JavaScript para construir la página entera. La ventaja es una arquitectura de despliegue muy simple (el servidor solo sirve archivos estáticos de JavaScript, sin necesidad de ejecutar código en cada petición) y una experiencia muy fluida en la navegación entre páginas una vez cargada la aplicación, porque las transiciones no requieren recargar el documento completo. El coste, además del ya cubierto en la guía de JavaScript y SEO (el desfase entre rastreo y renderizado), es un Time to First Byte técnicamente rápido pero engañoso: el servidor responde enseguida, pero el contenido visible tarda mucho más en aparecer porque todavía falta descargar, parsear y ejecutar el JavaScript, lo que penaliza directamente métricas de Core Web Vitals como LCP.

Server-Side Rendering (SSR): HTML completo en cada petición

SSR genera el HTML completo en el servidor, con los datos ya insertados, en cada petición individual. Esto resuelve de raíz el problema de indexación (el rastreador recibe contenido real desde el primer byte, sin depender de ninguna fase de renderizado posterior) y mejora el LCP percibido porque el navegador tiene contenido que pintar de inmediato. El coste es doble: por un lado, cada petición exige tiempo de cómputo en el servidor (consultar datos, ejecutar la lógica de renderizado, generar el HTML) antes de poder responder, lo que aumenta el TTFB real frente a servir un archivo estático; por otro, la infraestructura necesaria es más compleja y cara que servir archivos estáticos, porque hace falta un entorno de ejecución de servidor (Node.js u otro runtime) siempre activo y con capacidad de escalar bajo carga, no solo un servidor de ficheros.

Static Site Generation (SSG): el mismo HTML, generado por adelantado

SSG genera ese mismo HTML completo, pero en tiempo de build, antes de que llegue ninguna petición real, y lo sirve después como archivos estáticos puros. El resultado es el mejor TTFB posible (no hay cómputo alguno en el momento de la petición, solo entrega de un archivo ya generado) y el coste de hosting más bajo, porque un CDN de archivos estáticos es más barato y sencillo de escalar que un entorno de ejecución de servidor. El coste se traslada al proceso de build: si el sitio tiene miles de páginas, regenerarlas todas cuando cambia un solo dato (un precio, una entrada de blog) puede tardar minutos u horas, y ese tiempo de build se convierte en el nuevo cuello de botella del proyecto, no la petición del usuario.

Coste que se paga...                     CSR   SSR   SSG
TTFB (tiempo hasta el primer byte)        bajo  medio bajo
Contenido visible / LCP real              lento rápido rápido
Complejidad de infraestructura            baja  alta  baja
Coste de hosting a escala                 bajo  alto  bajo
Frescura del contenido                    total total según build
Coste al hacer un solo cambio de dato     nulo  nulo  rebuild completo*

*sin ISR: ver siguiente sección

Incremental Static Regeneration (ISR): el intento de tener las dos cosas

ISR nace específicamente para resolver el problema de SSG en sitios grandes: en vez de regenerar todo el sitio cada vez que cambia un dato, cada página estática lleva asociado un tiempo de vida (por ejemplo, "esta página puede servirse tal cual durante 60 segundos"); pasado ese tiempo, la siguiente petición sigue recibiendo la versión ya generada (sin esperar), pero dispara en segundo plano una regeneración de esa página concreta, que sustituye a la anterior para las siguientes peticiones. El resultado práctico es un TTFB tan bueno como el de SSG puro (nunca se hace esperar al usuario a que se genere el HTML) combinado con una frescura de contenido cercana a la de SSR, sin pagar el coste de regenerar el sitio entero por cada cambio. La complejidad que añade es la de gestionar correctamente ese tiempo de vida por tipo de página (no todo el contenido necesita la misma frescura) y aceptar que, durante una ventana corta, algunos usuarios pueden ver una versión ligeramente desactualizada mientras la regeneración en segundo plano termina.

Dynamic rendering / prerenderizado: el parche, no la solución

Antes de que SSR y SSG fueran tan accesibles como hoy, una técnica intermedia ganó popularidad: el prerenderizado dinámico (dynamic rendering), que consiste en detectar si quien hace la petición es un rastreador (por el user-agent) y, solo en ese caso, servirle una versión ya renderizada del HTML generada de antemano por un servicio externo, mientras a los usuarios reales se les sigue sirviendo la aplicación CSR normal. Google llegó a documentar esta técnica como una solución aceptable a corto plazo para sitios que no podían permitirse migrar su arquitectura, pero la ha ido despriorizando como recomendación a medida que el renderizado propio de Google ha mejorado, y conviene entenderla como lo que es: un parche temporal, no una arquitectura objetivo. El riesgo técnico es servir contenido distinto según quién pregunta, lo que roza conceptualmente el cloaking si el contenido servido a bots diverge de forma sustancial del que ven los usuarios reales; usado con honestidad (mismo contenido, solo pre-renderizado antes de tiempo) no es cloaking, pero es una distinción que hay que vigilar activamente, no dar por hecha.

Qué arquitectura conviene según el tipo de sitio

No hay una respuesta universal, pero sí patrones claros según el tipo de proyecto. Un ecommerce grande con miles de referencias, precios que cambian y stock en tiempo real suele necesitar SSR (para las páginas de producto y de carrito, donde la frescura del dato es crítica) combinado con SSG o ISR para contenido más estable como páginas de categoría o de marca. Un blog o sitio de contenido editorial, donde el contenido cambia por publicación deliberada y no en tiempo real, encaja casi siempre mejor con SSG puro o ISR con un tiempo de vida generoso, porque el coste de infraestructura de SSR no aporta ningún beneficio real frente a regenerar cuando se publica. Una web app con partes públicas indexables (una landing, páginas de ayuda) y partes privadas tras login (el propio panel de la aplicación) suele beneficiarse de un enfoque híbrido: SSR o SSG para todo lo que necesita indexarse, y CSR puro para el área autenticada, donde el SEO no aplica y la prioridad es la fluidez de la interacción.

Preguntas frecuentes