Glosario Renderizado en cliente (CSR)
En el renderizado en cliente el servidor envía una página casi vacía y es el navegador quien construye el contenido con JavaScript. La página que ve la persona nunca ha existido como HTML en el servidor.
Google puede renderizar JavaScript, pero en un segundo paso y sin garantía de cuándo. Lo que sólo existe tras ejecutar código llega más tarde al índice, o no llega.
El servidor entrega un armazón: un <div> vacío y una referencia a un script. Sólo en el navegador se carga el JavaScript, se piden los datos y se escribe el contenido en la página. Para el servidor la respuesta está completa antes de que exista ningún texto.
Es la construcción habitual de una aplicación de página única clásica. Detrás de un inicio de sesión no plantea problemas: nadie tiene que encontrarla. En una página pública de contenido, la situación cambia.
Google procesa una página en dos pasadas. Primero lee el HTML entregado. Lo que no está ahí entra en una cola de renderizado y se procesa más tarde, cuando hay recursos.
La segunda pasada ocurre —Google lo dice expresamente—, pero no de inmediato y sin compromiso sobre el intervalo. Para una noticia, un cambio de precio o una nueva página de categoría, ese intervalo es justo el problema. Si además falla algo al renderizar (un script bloqueado, un tiempo agotado, una petición de datos fallida), el contenido no aparece en absoluto.
Los tres se diferencian en cuándo se genera el HTML.
Para los buscadores, SSR y SSG son equivalentes: el contenido está en la primera respuesta. La diferencia entre ambos es operativa: qué tan frescos son los datos y cuánto cuesta una petición.
No es una decisión de todo o nada para el sitio entero. Lo habitual es la mezcla: el contenido visible desde el servidor y las partes interactivas en el navegador.
La prueba más rápida: pedir la página sin JavaScript y mirar qué queda. Si queda una superficie vacía, el contenido depende del CSR.
Más fiable es comparar dos versiones de la misma página: el HTML en bruto de la respuesta del servidor frente al texto renderizado en el navegador. Lo que sólo aparece en la segunda versión no existe para la primera pasada. A eso se suma la inspección de URL en Search Console, que muestra qué renderizó Google realmente.
Un error frecuente al medir: comprobarlo con una herramienta que ejecuta JavaScript y verlo por tanto todo. Eso mide el navegador, no el rastreador.
El CSR no es una decisión equivocada, sino una elección con un precio. Está bien donde el contenido no necesita ser encontrado: detrás de un inicio de sesión, en un configurador, en un carrito, en un área de administración.
Sale caro donde la tarea es que te encuentren: páginas de producto, de categoría y de contenido. Para esas vale una regla sencilla: lo que deba posicionar tiene que estar en la primera respuesta.
Una auditoría técnica revisa esto y el resto en un solo paso.
Solicitar auditoríaSí, Google ejecuta JavaScript. Pero lo hace en una segunda pasada, sin plazo comprometido, y cualquier fallo al renderizar deja el contenido fuera. La pregunta útil no es si puede, sino cuándo y con qué fiabilidad.
Pide la página sin ejecutar JavaScript y compara ese HTML con el texto renderizado. Un curl simple ya sirve. Si compruebas con una herramienta que ejecuta scripts, estarás midiendo el navegador y no el rastreador.
Casi nunca. Lo habitual es mover al servidor sólo lo que debe encontrarse: textos, títulos, datos estructurados y enlaces internos. Las partes interactivas pueden seguir en el navegador.
Google lo describe como una solución alternativa y transitoria, no como una recomendación a largo plazo. Servir dos versiones distintas añade una fuente de error propia: que ambas se separen sin que nadie lo note.
Suele afectar al LCP: el elemento principal no puede pintarse hasta que el JavaScript ha cargado y ejecutado. No es una regla automática, pero el camino hasta el primer contenido visible es más largo por construcción.