Renderizado dinámico: qué soluciona en un sitio con JavaScript (y qué no)
Por Toy Wen Da, Cofundador · Actualizado · 7 min de lectura
Traducido del original en inglés. Léelo en inglés
El renderizado dinámico consiste en que tu servidor comprueba si quien visita la página es un navegador o un bot de búsqueda, y envía a los bots una versión en HTML estático ya prerenderizada, mientras que las personas reciben la experiencia completa con JavaScript. Soluciona los casos en que Googlebot no puede leer contenido que solo aparece después de ejecutar scripts, pero no resuelve todos los problemas de indexación.
Antes de tocar código del servidor, comprueba qué ve Googlebot en la página en cuestión. El Googlebot Simulator gratuito descarga una URL igual que el rastreador de Google y te muestra el HTML renderizado, así que en un minuto sabrás si tu contenido JavaScript falta en lo que recibe el bot.
Cómo funciona
Detectar al visitante
Tu servidor, o una capa de CDN delante de él, inspecciona la cabecera User-Agent de cada solicitud. Cuando la cabecera coincide con un rastreador conocido, como Googlebot o Bingbot, o cada vez más con un rastreador de IA, la solicitud se enruta de forma distinta a la de un navegador normal.
Servir dos versiones de la misma página
Las personas siguen recibiendo tu aplicación en React, Vue o Angular con toda su interactividad. Los bots reciben una copia prerenderizada en HTML generada con una herramienta de navegador headless como Puppeteer o Rendertron, o con un servicio de terceros como Prerender.io, y como la copia es estática, no hace falta ejecutar ningún script para que el contenido sea visible.
Por qué los sitios necesitan esto
Googlebot puede ejecutar JavaScript, pero el renderizado consume muchos recursos y se hace con retraso, por lo que a menudo las páginas se rastrean una vez y se vuelven a renderizar más tarde, lo que puede frenar la indexación. La mayoría de los motores de respuestas con IA ni siquiera ejecutan JavaScript, así que una página que depende del renderizado en el cliente puede ser invisible para ellos desde el principio. Una página que nunca se indexa no obtiene visibilidad ni porcentaje de clics (CTR) alguno, y mucho menos uno bueno.
Cómo solucionarlo en tu propio sitio, paso a paso
- Confirma que existe una diferencia real: descarga la página como un bot y compárala con lo que carga un navegador normal. Si el contenido coincide, no necesitas nada de esto.
- Decide si el problema afecta a una plantilla, a una sección del sitio o a todo, ya que ese alcance determina cuánto trabajo de infraestructura vas a asumir.
- Añade detección de user agent en el servidor o en la CDN, por ejemplo con un Cloudflare Worker o una regla de Nginx, que compare las solicitudes entrantes con una lista de bots actualizada.
- Dirige el tráfico de bots a un servicio de prerenderizado que genere HTML estático para cada URL y lo guarde en caché, de modo que no se vuelva a renderizar en cada visita de un bot.
- Mantén el contenido equivalente: la versión prerenderizada debe coincidir con lo que una persona acaba viendo, con el mismo texto, los mismos enlaces y los mismos datos estructurados.
- Vuelve a probar tras el lanzamiento y otra vez después de cada despliegue del front-end, porque un cambio en la interfaz puede romper sin avisar lo que captura el servicio de prerenderizado.
- Supervisa la configuración de forma continua. Si el servicio de renderizado se cae, los bots pueden empezar a recibir páginas en blanco o errores, lo que puede provocar la desindexación rápidamente.
Cuándo bastan tus propias herramientas y cuándo no
Comprobar una sola página es un trabajo distinto de arreglar el renderizado de todo un sitio.
| Situación | Qué estás comprobando | Herramienta adecuada | ¿Basta la vía gratuita? |
|---|---|---|---|
| Una URL te parece bien a ti, pero no aparece en el índice de Google | Lo que ve Googlebot en esa página | Googlebot Simulator | Sí, confirma o descarta una diferencia de renderizado en minutos |
| Todo el sitio está hecho con React/Vue/Angular sin renderizado en el servidor | Capacidad de rastreo de todo el sitio | Un rastreo técnico completo y una auditoría de renderizado | No, es un cambio de infraestructura, no una comprobación de una página |
| El diseño móvil de una página parece fallar junto con el problema de indexación | Renderizado móvil, viewport y usabilidad | Prueba gratuita de compatibilidad móvil | Sí, para diagnosticar la parte específica del móvil |
| Las páginas estaban bien indexadas y luego desaparecieron tras un rediseño | Una regresión recurrente, no un caso aislado | Supervisión continua y revisión de la configuración de prerenderizado | No, una sola comprobación no detecta un problema que reaparece tras cada despliegue |
Una comprobación puntual de una sola URL es justo para lo que se crearon las herramientas gratuitas, mientras que un patrón recurrente que afecta a todo el sitio apunta a una solución de infraestructura, que normalmente requiere a un desarrollador y un servicio de prerenderizado.
Comparación con las alternativas
| Enfoque | Cómo funciona | Mejor caso de uso | Carga de mantenimiento |
|---|---|---|---|
| Renderizado dinámico | Sirve HTML estático a los bots y la aplicación JS a las personas | Sitios con mucho JS y problemas de presupuesto de rastreo o de visibilidad en IA que aún no pueden hacer una reescritura completa | Alta, hay que mantener un flujo de renderizado aparte |
| Renderizado en el servidor (SSR, Server-Side Rendering) | El servidor renderiza el HTML en cada solicitud, para todos | Desarrollos nuevos o sitios con recursos para reconstruir su front-end | Moderada, una sola vía de renderizado para todos los visitantes |
| Generación de sitios estáticos (SSG, Static Site Generation) | El HTML se construye de antemano en el momento del despliegue | Contenido que no cambia con cada solicitud, como blogs o páginas de marketing | Baja, se reconstruye cuando cambia el contenido |
| Renderizado en el cliente (sin solución) | El navegador construye la página a partir de JavaScript y los bots reciben lo mismo | Herramientas internas, no páginas públicas pensadas para buscadores | Poco esfuerzo, alto riesgo para el SEO |
La propia guía de Google presenta la técnica como una solución provisional y no como el destino final, y el SSR o el SSG son las soluciones más duraderas cuando puedas permitirte la reconstrucción.
¿Se considera cloaking?
No, siempre que lo hagas de buena fe. La documentación de Google Search Central indica que, por lo general, Googlebot no lo trata como cloaking, siempre que el contenido renderizado que se sirve a los bots sea equivalente a lo que las personas acaban viendo. La infracción no está en que existan dos versiones, sino en mostrar a bots y a personas contenidos realmente distintos, como una página saturada de palabras clave sobre zapatillas de running para los rastreadores mientras los visitantes ven una página sobre algo totalmente distinto. Mantén la misma sustancia en ambas versiones y estarás del lado correcto de la norma.
Errores comunes
- Tratarlo como una solución permanente, cuando solo tapa un problema de rastreabilidad y no elimina la necesidad de una arquitectura más fácil de rastrear.
- Dejar que el servicio de prerenderizado se quede obsoleto, de modo que los bots vean una versión desactualizada o rota de la página cada vez que no recoge un cambio del front-end.
- Confiar en una lista de bots con huecos, ya que la detección por user agent solo funciona con los bots que has incluido, y un rastreador de IA nuevo que tus reglas no reconocen recibe la versión JavaScript sin procesar, que probablemente no puede leer.
- Omitir las nuevas pruebas tras los despliegues, aunque una versión del front-end que nadie ha vuelto a comprobar frente a la versión para bots es la causa más común de que una configuración así se rompa sin que nadie lo note.
- Aplicarlo a un sitio que no lo necesita, porque los sitios pequeños y mayormente estáticos rara vez tienen un problema de renderizado que justifique tanta infraestructura.
Preguntas frecuentes
¿El renderizado dinámico perjudica mi posicionamiento?
Por sí solo, no. El riesgo está en una versión mal configurada que sirve páginas obsoletas o errores y se aleja de lo que ven las personas.
¿El renderizado dinámico es lo mismo que el cloaking?
No. El cloaking consiste en servir a bots y a personas contenidos sustancialmente distintos, mientras que esta técnica sirve el mismo contenido en un formato diferente, algo que los buscadores permiten de forma explícita.
¿Cómo sé si mi sitio necesita renderizado dinámico?
Descarga una página como Googlebot y compárala con la versión del navegador. Si tu contenido principal y tus enlaces no aparecen en lo que ve el bot, ahí tienes la señal.
¿Cuál es la alternativa a largo plazo al renderizado dinámico?
El renderizado en el servidor o la generación de sitios estáticos, que sirven el mismo HTML renderizado a todos en lugar de mantener dos vías separadas.
¿Pueden los sitios de pequeños negocios ignorar por completo el renderizado dinámico?
Normalmente, sí. Importa sobre todo en sitios grandes con mucho JavaScript, cambios de contenido frecuentes o limitaciones de presupuesto de rastreo, y no en un sitio pequeño típico construido con plantillas de página estándar.
Comprueba tu página antes de construir nada
No empieces a montar un flujo de prerenderizado por intuición. Descarga la página en cuestión, mira qué recibe Googlebot e invierte en la infraestructura solo si hay una diferencia real entre lo que ven los bots y las personas. Si quieres una segunda opinión sobre qué frena tu indexación, habla con el equipo y solicita un informe SEO de ejemplo.
Fuentes
Sobre el autor
SearchBlueprint investigó, escribió y puntuó este artículo con el mismo flujo de contenido que nuestros clientes usan en sus propios sitios. La puntuación que aparece junto al autor es la que nuestro motor de contenido dio a esta página antes de publicarla. Nada de esto se revisa a mano, y ese es el punto: es el resultado del producto, publicado donde cualquiera puede comprobarlo.