Significado y alcance
Con CSR, el servidor puede devolver un esqueleto HTML ligero, y JavaScript recupera o compone el contenido relevante en el navegador. Puede ser adecuado en aplicaciones muy interactivas, pero crea una cadena de dependencias adicional: el HTML, los scripts, las APIs y la lógica de renderizado deben funcionar para que un rastreador y un visitante reciban el mismo contenido importante.
Flujo de trabajo práctico
Empieza por lo que necesitan el usuario y el rastreador. Comprueba si el título, el texto principal, la etiqueta canonical, las directivas de robots, los enlaces internos, las imágenes y los datos estructurados están en el HTML inicial o solo aparecen después de ejecutar JavaScript. Si el contenido crítico para el descubrimiento se difiere, elige una arquitectura que lo entregue de forma fiable, como el renderizado en servidor, la generación estática o un enfoque híbrido probado.
Qué revisar
Compara una descarga del HTML sin procesar con una inspección renderizada en una muestra representativa de plantillas. Confirma que los recursos de JavaScript no están bloqueados, que las peticiones de datos funcionan sin sesión privada, que la información canonical se mantiene estable y que los estados de error no sustituyen al contenido principal. Google recomienda probar las aplicaciones JavaScript en lugar de asumir que el nombre de un framework garantiza el rastreo.
Límites y errores habituales
No des por hecho que el CSR es malo para el SEO, ni supongas que el rastreador no ve nada. La pregunta útil es si el contenido y los metadatos necesarios están disponibles de forma coherente tras la ruta de renderizado real. Evita una experiencia separada solo para bots, salvo que siga siendo equivalente y mantenible.
Comprobaciones de renderizado con un ejemplo de ruta concreto
Toma una ruta como /guides/rendering. Descárgala sin estado de navegador y guarda el cuerpo de la respuesta. Después, carga la misma ruta en una sesión de navegador limpia e inspecciona el DOM renderizado, la consola y el panel de red. Las dos vistas no tienen por qué ser idénticas byte a byte, pero el propósito de la ruta debe mantenerse: un título útil, el encabezado principal, el texto principal, la referencia canonical, los enlaces rastreables y cualquier dato estructurado importante deben resolverse sin una llamada a la API autenticada, sin una carrera de temporización ni una excepción en el cliente.
<a href="/guides/rendering">Rendering guide</a>\n<link rel="canonical" href="https://example.test/guides/rendering">En un fallo de app-shell, el HTML inicial puede contener solo un elemento raíz, mientras la petición de datos falla con 401, 403, 404 o una excepción de JavaScript. Una persona podría ver una página en caché tras iniciar sesión, mientras un renderizador limpio ve un esqueleto vacío. El control no consiste en fingir que la ruta responde con un 200 correcto. Consiste en clasificar el error de esa ruta, poner a su disposición los datos públicos necesarios o elegir renderizado en servidor o estático para el contenido que debe entregarse de inmediato.
Google documenta un proceso de rastreo, renderizado e indexación para las páginas con JavaScript. Una respuesta 200 puede entrar en la cola de renderizado, pero las páginas bloqueadas o los recursos JavaScript bloqueados no se renderizan. Google también recomienda la herramienta de inspección de URL o el Rich Results Test para revisar los recursos cargados, la salida de la consola, las excepciones y el DOM renderizado. Usa esas herramientas como evidencia de apoyo y compáralas con una prueba actual en un navegador anónimo: la analítica del lado del cliente no representa del todo la actividad de renderizado de Googlebot.
Evita el renderizado dinámico como solución arquitectónica por defecto. Google lo describe como una solución provisional, no como una solución a largo plazo. No hagas cloaking: el contenido entregado a un rastreador debe seguir siendo equivalente al que recibe una persona. Registra la ruta, el estado del usuario, la respuesta sin procesar, el resultado renderizado y el estado de los recursos fallidos, para que una futura actualización del framework pueda comprobarse con las mismas evidencias.