SSR vs CSR: qué recibe Google

A estas siglas casi nunca se llega por curiosidad. Se llega porque alguien las suelta: el desarrollador dice que la web «es una SPA», un informe de auditoría marca «CSR» en rojo, un proveedor explica que el problema de posicionamiento «viene del renderizado». Y a partir de ahí hay que decidir algo, normalmente con dinero de por medio, sin tener claro qué se está decidiendo.

La decisión pesa más de lo que parece, y por un motivo que hasta hace poco no existía: Google ha dejado de ser lo único que lee tu web. Los buscadores llevan años ejecutando el JavaScript de las páginas que rastrean, pero los bots que alimentan a ChatGPT, a Claude o a Perplexity no lo hacen. Así que el mismo sitio puede estar bien indexado en Google y ser invisible para todo lo demás, y de qué lado caes depende de una decisión técnica que casi nadie tomó a propósito.

Qué es el renderizado en servidor (SSR)#

Imagina que tu web es una carta. Alguien la pide, tu servidor la escribe entera y la mete en el sobre. Quien lo abre encuentra el texto ya escrito: el titular, los párrafos, los enlaces, los precios.

Eso es el renderizado en servidor. El HTML que sale de tu servidor ya contiene el contenido. El navegador todavía ejecuta código después, para que los menús se abran y los formularios funcionen, pero el contenido no depende de que eso ocurra. Si el código nunca se ejecuta, el texto sigue ahí.

Es como funcionaba la web entera antes de 2010, y es a lo que han vuelto casi todos los frameworks modernos después de una década larga probando lo contrario.

Qué es el renderizado en cliente (CSR)#

Ahora el mismo sobre, pero dentro hay un folio en blanco y una hoja de instrucciones para escribir la carta. Quien lo abre tiene que hacer el trabajo: leer las instrucciones, seguirlas y acabar con la carta delante.

Eso es el renderizado en cliente. El servidor entrega un documento casi vacío, normalmente un <div id="root"></div> y unos cuantos ficheros JavaScript, y es el navegador del visitante el que construye la página. Para una persona con un navegador normal la diferencia es invisible: el trabajo se hace en milisegundos y la web aparece.

La diferencia deja de ser invisible en cuanto quien abre el sobre no sabe seguir instrucciones, o no quiere.

Las diferencias que cambian algo#

Casi todas las comparativas de SSR y CSR presentan una lista de seis o siete características como si fueran dos productos entre los que se elige en un menú. En la práctica no eliges un modo de renderizado: eliges un framework y una plataforma, y el modo viene de serie con ellos. Por eso la tabla de abajo sirve para entender qué te tocó, más que para escoger.

	SSR	CSR
Qué entrega el servidor	La página con su contenido	Un contenedor vacío y código
Quién hace el trabajo	Tu servidor, una vez por visita	El dispositivo de cada visitante
Primera pantalla útil	Rápida	Depende del móvil y la red del visitante
Contenido visible sin JavaScript	Sí	No
Coste de servidor	Mayor	Menor
Mejor para	Contenido que hay que encontrar	Aplicaciones detrás de un login

Y hay una tercera opción que se cae de casi todos los artículos: el renderizado estático (SSG), donde las páginas se generan una sola vez al publicar y se sirven ya hechas. Para un blog o una web de empresa suele ser la respuesta correcta, porque tiene el contenido completo del SSR y el coste de un fichero suelto. La mayoría de proyectos reales, además, mezclan los tres: portada estática, panel de cliente en cliente, alguna página que se genera en cada visita porque muestra datos que cambian.

Qué recibe Google, y cuándo#

La documentación oficial de Google describe tres fases separadas: rastreo, renderizado e indexación. Googlebot pide la página, y para ejecutar su JavaScript la mete en una cola:

Todas las páginas con un código de estado HTTP 200 se envían a la cola de renderización […]. Las páginas suelen permanecer en esta cola durante unos segundos, aunque a veces podrían estar algo más de tiempo.

Google sí ejecuta JavaScript, así que una web en CSR puede acabar indexada perfectamente. Lo que cambia es el camino. Con SSR, el contenido se indexa en la primera visita. Con CSR, tu contenido depende de una segunda pasada que Google hace cuando tiene recursos libres, sobre la que no tienes control ni visibilidad, y que no está garantizada para las páginas a las que Google no dé prioridad. Cuando esa segunda pasada no llega, tu página queda indexada tal y como la entregó el servidor, que es en blanco.

Los bots de IA no ejecutan JavaScript#

En diciembre de 2024, Vercel publicó un análisis de tráfico real de crawlers sobre su red: 4.500 millones de peticiones de Googlebot en un mes, 569 millones de GPTBot y 370 millones de ClaudeBot. La conclusión sobre el renderizado es tajante y los análisis posteriores la mantienen: ninguno de los principales crawlers de IA ejecuta JavaScript. Ni GPTBot, ni ClaudeBot, ni PerplexityBot, ni los de Meta o ByteDance.

Y descargan los ficheros JavaScript sin ejecutarlos: el 11,50 % de las peticiones de ChatGPT y el 23,84 % de las de Claude son ficheros .js. Se llevan el código y no lo corren.

Las excepciones son Googlebot, AppleBot y Gemini, que va montado sobre la infraestructura de Googlebot y por eso sí renderiza.

Así que la comparativa de siempre se ha quedado corta. Durante años, «Google acaba renderizando tu JavaScript» era un argumento razonable para no preocuparse demasiado por el CSR. Hoy ese argumento cubre a un solo buscador, mientras crece la parte del tráfico que llega recomendada por un modelo que jamás va a ver tu contenido.

Cómo saber cuál es el caso de tu web#

Hay una comprobación manual que funciona: desactiva JavaScript en tu navegador y recarga. Lo que quede es aproximadamente lo que recibe un bot que no renderiza.

Si prefieres no tocar la configuración del navegador, hay herramientas que hacen la comprobación por ti y devuelven las dos capturas lado a lado; yo mantengo una gratuita, el auditor SSR/SEO. Y si la captura sin JavaScript sale vacía y tu web la montó una herramienta de IA, el caso está contado entero en por qué una web hecha con IA no aparece en Google.

Sea cual sea la herramienta, desconfía del veredicto binario. Una página estática y minúscula puede salir marcada como CSR solo por tener poco texto, y la franja intermedia existe de verdad: sitios que entregan del servidor la mitad del contenido y montan la otra mitad en el navegador. Lo que hay que mirar es cuánto del contenido final ya venía en el HTML, no la etiqueta.

Existe además un caso intermedio que explica veredictos aparentemente contradictorios: el renderizado dinámico. El servidor monta la página entera si quien la pide es un crawler que reconoce, y entrega el shell vacío a todos los demás. Es lo que hacen los proyectos antiguos de Lovable, los de React con Vite; las apps creadas desde el 13 de mayo de 2026 ya usan TanStack Start con renderizado en servidor de verdad. Sobre el papel suena a lo mejor de los dos mundos, y Google lo desaconseja sin rodeos: lo llama «una solución alternativa, no una solución recomendada». El motivo se ve en cuanto lo piensas: funciona solo con los bots que están en la lista. Con Googlebot vas bien, y con los de IA, que rara vez están, sigues entregando la página en blanco.

Y ahí está lo que sí me parece criticable, que no es la técnica sino dónde está contada. Esto vive en la documentación para desarrolladores de la plataforma, en inglés, en una página que solo se lee si ya sabes que el problema existe. Quien le da al botón de publicar no recibe ningún aviso de que su web se va a comportar de una manera con Google y de otra con todo lo demás.

Entonces, ¿cuál elijo?#

Si el contenido tiene que encontrarse, tiene que llegar del servidor. Un blog, una web de empresa, un catálogo, una landing: estático o SSR, y la elección entre esos dos es de coste y de con qué frecuencia cambian los datos, no de SEO.

Si es una aplicación detrás de un login, el CSR está bien y no hay nada que discutir: a Google no le interesa el panel de control de tus clientes.

Lo que ya no se sostiene es lo intermedio, que es donde está casi todo el problema real: la web pública de un negocio, servida en cliente, porque fue lo que salió por defecto de la herramienta con la que se montó. Eso no es una decisión de arquitectura. Es una decisión que nadie tomó, y que se paga en el único canal por el que llega gente que todavía no te conoce.

Si no sabes en cuál de los tres casos estás, pásale tu URL al auditor y míralo. Y si el diagnóstico sale mal y la solución te queda grande, a eso me dedico: en consultoría técnica cuento cómo trabajo.