Renderizado Dinámico
El renderizado dinámico es una técnica en la que un sitio sirve dos versiones de cada página: una instantánea de HTML estático prerrenderizado a los rastreadores de los buscadores, y una experiencia completa de aplicación de página única (SPA) de JavaScript a los usuarios humanos. Google lo recomendó públicamente como solución para sitios con mucho JS en 2018, y luego lo degradó discretamente a "solución heredada" hacia 2024, a medida que maduró el renderizado de JS de Googlebot.
El renderizado dinámico es una técnica en la que un sitio sirve dos versiones de cada página: una instantánea de HTML estático prerrenderizado a los rastreadores de los buscadores, y una experiencia completa de aplicación de página única (SPA) de JavaScript a los usuarios humanos. Google lo recomendó públicamente como solución para sitios con mucho JS en 2018, y luego lo degradó discretamente a "solución heredada" hacia 2024, a medida que maduró el renderizado de JS de Googlebot.
Por qué es importante
Los sitios con mucho JavaScript solían entregar carcasas de HTML vacías, confiando en que el rastreador ejecutara el JS y viera el contenido real. Googlebot acabó lográndolo, pero con lentitud, a menudo días después de la obtención inicial del HTML, y otros rastreadores (Bing, bots de AI, la previsualización de Facebook) eran peores. El renderizado dinámico permitía a los equipos de SEO garantizar que los rastreadores vieran de inmediato el HTML totalmente renderizado, sin reescribir la aplicación. Para catálogos de e-commerce, paneles de JS y SPAs con necesidades críticas de SEO, era un puente pragmático. Entenderlo sigue importando porque muchos sitios funcionan hoy con renderizado dinámico y necesitan migrar.
Cómo funciona
1. Llega la solicitud: El edge o el servidor inspecciona el user-agent.
2. Detección del rastreador: Si el user-agent coincide con un bot de búsqueda conocido (Googlebot, Bingbot, Twitterbot, LinkedInBot, rastreadores de AI), la solicitud se enruta a un servicio de prerrenderizado. De lo contrario, llega a la SPA normal.
3. Servicio de prerrenderizado: Un Chrome sin interfaz (a menudo mediante prerender.io, Rendertron, Puppeteer o Playwright) obtiene la página, espera a que el JS termine, captura el DOM y devuelve HTML estático.
4. Caché: El HTML renderizado se almacena en caché para que las visitas posteriores de los rastreadores no vuelvan a renderizar.
5. El bot ve HTML; el usuario ve la SPA: La misma URL, dos experiencias.
Por qué ahora es una "solución heredada"
La guía de Google de 2024 movió el renderizado dinámico de "recomendado" a "una solución temporal y no una solución a largo plazo". Razones:
Googlebot ahora renderiza bien el JS: Google ejecuta un Chrome sin interfaz actualizado y procesa el JS en la mayoría de las páginas con rapidez. El motivo original del renderizado dinámico prácticamente ha desaparecido para Google.
Carga de mantenimiento: Ejecutar en paralelo un segundo pipeline de renderizado es una complejidad operativa que normalmente supera el beneficio.
Riesgo de divergencia: Cuando el servicio de prerrenderizado se rompe o queda desactualizado, los bots ven contenido antiguo y los usuarios ven contenido nuevo, una señal clásica de cloaking.
No es una penalización por cloaking, pero se le acerca: Google dice explícitamente que el renderizado dinámico no es cloaking, pero la divergencia entre las vistas del bot y del usuario puede desencadenar una revisión manual.
El SSR / SSG moderno es mejor: Next.js, Nuxt, SvelteKit, Astro y Remix entregan por defecto páginas renderizadas en el servidor o generadas de forma estática. No se necesita renderizado dinámico.
Cuándo (si acaso) sigue teniendo sentido
SPAs heredadas que no puedes reescribir: Una aplicación madura con mucho JS y sin presupuesto para migrar a SSR. El renderizado dinámico sigue siendo viable como solución provisional.
Rastreadores que no son de Google: Los rastreadores de AI, Bing, Baidu y los bots de nicho aún renderizan el JS peor que Google. Si importan para tu tráfico, el renderizado dinámico puede ayudar.
Widgets e incrustaciones: Contenido que carga mediante JS después del HTML inicial, a veces la única forma de exponerlo a los rastreadores.
Soluciones de renderizado en el edge: Un renderizado dinámico ligero en el edge de la CDN que transforma la SPA en HTML sobre la marcha, sin un servicio de prerrenderizado aparte.
Cómo migrar fuera del renderizado dinámico
1. Audita qué falla realmente en el JS: Usa la inspección de URLs de Search Console y comparaciones de renderizado. Muchos "problemas de SEO de JS" son simplemente la falta de SSR en páginas críticas.
2. Mueve las páginas críticas a SSR o SSG: Primero las páginas de inicio, de aterrizaje, de producto y de artículo. Mantén los paneles y las áreas con sesión iniciada como SPA.
3. Usa un framework moderno: Next.js / Nuxt / SvelteKit gestionan el renderizado híbrido de serie.
4. Verifica la paridad: Tras la migración, rastrea el nuevo sitio con Screaming Frog y confirma que el HTML coincide con lo que producía el antiguo prerrenderizado.
5. Retira el servicio de prerrenderizado: Solo después de varias semanas de informes de cobertura limpios en Search Console.
Errores comunes
Servir contenido diferente de forma intencionada: El renderizado dinámico es "el mismo contenido, distinta forma". Un contenido diferente es cloaking y se penaliza.
No actualizar la caché del prerrenderizado: Los prerrenderizados desactualizados alimentan a los bots con contenido antiguo, posicionando para el producto de ayer.
Confiar en el prerrenderizado para todo: Poner un prerrenderizado delante de un sitio sin una estrategia de SSR significa que siempre estás a una caída de la ceguera del rastreador.
Ignorar las listas de UA que no son de Googlebot: Bing, Yandex, Baidu y los rastreadores de AI tienen UAs diferentes. Olvidar uno te oculta de ese bot.
Usar el renderizado dinámico para construcciones nuevas: No lo hagas. Usa SSR/SSG en un framework moderno en su lugar.
Sources: