JavaScript Rendering SEO: Pre-rendering vs Server-Side Rendering
Si tu web está construida con React, Angular, Vue o cualquier framework JavaScript moderno, tienes un problema potencial que muchos directores de marketing ignoran hasta que ya han perdido posiciones en Google: el renderizado de JavaScript puede invisibilizar tu contenido para los motores de búsqueda. Entender qué es el JavaScript rendering SEO y elegir entre pre-rendering y server-side rendering (SSR) no es una decisión técnica menor; es una decisión de negocio con impacto directo en tu tráfico orgánico y tus ingresos.
En este artículo analizamos en profundidad ambas aproximaciones, sus ventajas e inconvenientes reales, y cómo elegir la estrategia adecuada según el tipo de proyecto y los objetivos SEO de tu empresa.
---
Por qué el JavaScript rendering afecta al SEO
Googlebot tiene capacidad para ejecutar JavaScript, pero no lo hace igual que un navegador convencional. Según datos publicados por Google, existe una segunda ola de indexación para el contenido renderizado con JavaScript que puede demorarse días o semanas respecto a la indexación del HTML estático. Esto significa que las páginas cuyo contenido depende de JavaScript para mostrarse corren el riesgo de indexarse tarde, de forma incompleta o, en los peores casos, de no indexarse en absoluto.
Un estudio de Searchmetrics estimó que alrededor del 45% de las URLs que dependen de JavaScript para mostrar contenido crítico presentan algún problema de indexación en Google. No es un número menor si tu sitio es un e-commerce con miles de páginas de producto o un portal de contenidos con artículos de largo aliento.
Cómo rastrean los motores de búsqueda las webs con JavaScript
El proceso de Googlebot frente a una web JavaScript tiene dos fases:
- Primera fase: Googlebot descarga el HTML inicial. Si el contenido está ahí, lo indexa de inmediato.
- Segunda fase: Googlebot encola la página para renderizarla con su motor de JavaScript (Chromium). Esta fase puede tardar días.
El problema aparece cuando todo el contenido relevante —textos, imágenes con alt, enlaces internos, datos estructurados— solo existe después de que JavaScript ha ejecutado. En ese escenario, tu posicionamiento web con JavaScript rendering queda a merced de los tiempos de cola de Googlebot, que no controlas.
Bing y otros motores tienen capacidades de renderizado JavaScript aún más limitadas que Google, lo que agrava el problema si tu audiencia llega también desde esos buscadores.
---
Qué es el pre-rendering y cuándo usarlo
El pre-rendering consiste en generar el HTML de cada página de forma anticipada —en tiempo de construcción o bajo demanda— y servirlo ya renderizado al rastreador. Cuando Googlebot visita una URL, recibe un HTML completo sin necesidad de ejecutar JavaScript.
Cómo funciona el pre-rendering
Existen dos variantes principales:
Pre-rendering estático (Static Site Generation, SSG): Las páginas se generan durante el proceso de build y se sirven como ficheros HTML desde un CDN. Herramientas como Next.js (con getStaticProps), Gatsby o Astro siguen este modelo. El tiempo de respuesta es mínimo y el coste de infraestructura es muy bajo.
Pre-rendering dinámico: Un servicio intermedio (como Prerender.io, Rendertron o soluciones propias basadas en Puppeteer) detecta si la petición proviene de un bot o de un usuario real. Si es un bot, sirve una versión prerenderizada del HTML. Si es un usuario, sirve la aplicación JavaScript normal. Este enfoque se usa frecuentemente en SPAs (Single Page Applications) sin necesidad de refactorizar el código base.
Ventajas del pre-rendering para el SEO técnico
- El HTML llega completo en la primera respuesta HTTP: Google indexa el contenido en la primera fase, sin esperar la segunda ola.
- Ideal para contenido que no cambia con frecuencia: fichas de producto con actualizaciones periódicas, artículos de blog, páginas corporativas.
- Menor carga en servidores porque el HTML se genera una sola vez y se cachea.
- Con SSG, los Core Web Vitals suelen mejorar de forma notable, especialmente LCP (Largest Contentful Paint), ya que el HTML llega inmediatamente desde CDN.
Limitaciones del pre-rendering
- En sitios con contenido muy dinámico (dashboards en tiempo real, precios que cambian cada minuto, resultados de búsqueda personalizados), el pre-rendering estático genera HTML desactualizado.
- El tiempo de build puede dispararse en sitios con decenas de miles de páginas. Un e-commerce con 50.000 productos puede tardar horas en regenerar todo el sitio.
- El pre-rendering dinámico con detección de bots puede clasificarse como cloaking si se sirve contenido diferente al usuario y al rastreador. Google lo tolera cuando el HTML prerenderizado es fiel al contenido que vería el usuario, pero cualquier diferencia relevante puede acarrear penalizaciones manuales.
---
Qué es el Server-Side Rendering (SSR) y cuándo usarlo
El server-side rendering genera el HTML en el servidor en el momento de cada petición. Cuando un usuario o un bot solicita una página, el servidor ejecuta el JavaScript, construye el HTML completo y lo devuelve. El cliente recibe un documento ya listo para leer y para indexar.
Cómo funciona el SSR en la práctica
Frameworks como Next.js (con getServerSideProps), Nuxt.js o Remix implementan SSR de forma nativa. El servidor —Node.js habitualmente— recibe la petición, obtiene los datos necesarios (de una API, base de datos, CMS headless), renderiza el componente React o Vue y devuelve el HTML. El navegador del usuario puede mostrar el contenido de forma inmediata mientras el JavaScript se "hidrata" en segundo plano para hacer la página interactiva.
Ventajas del SSR para el JavaScript rendering SEO
- El contenido siempre está actualizado en el momento de la petición: perfecto para precios dinámicos, inventarios, contenido personalizado.
- Googlebot recibe el HTML completo en la primera respuesta, igual que con el pre-rendering, lo que elimina la segunda ola de indexación.
- Permite personalizar el HTML según el usuario (aunque hay que gestionar bien el caché para no afectar al rastreo).
- Mejores métricas de Time to First Byte (TTFB) perceptibles para el usuario comparado con una SPA pura que carga todo en cliente.
Limitaciones del SSR
- Requiere infraestructura de servidor activa: no se puede servir desde un CDN estático. Esto incrementa los costes de hosting y la complejidad operativa.
- Cada petición genera carga en el servidor. Un pico de tráfico (un lanzamiento de producto, una mención en prensa) puede saturar el sistema si no está bien escalado.
- El TTFB puede ser más alto que con SSG porque el servidor necesita tiempo para generar el HTML antes de responder. Si la base de datos o la API tarda, el usuario espera.
- La hidratación del JavaScript en el cliente puede generar problemas de CLS (Cumulative Layout Shift) si el HTML del servidor no coincide exactamente con lo que renderizaría el cliente.
---
Comparativa directa: pre-rendering vs SSR para SEO
| Criterio | Pre-rendering (SSG) | SSR |
|---|---|---|
| Indexación por Google | Inmediata (HTML completo) | Inmediata (HTML completo) |
| Actualización del contenido | Requiere rebuild | Siempre actualizado |
| Core Web Vitals (LCP) | Excelente | Bueno (variable) |
| Coste de infraestructura | Bajo (CDN) | Medio-alto (servidor) |
| Escalabilidad ante picos | Alta | Requiere configuración |
| Complejidad técnica | Baja-media | Media-alta |
| Ideal para | Blogs, landings, catálogos estables | E-commerce dinámico, portales de noticias |
Ambas opciones resuelven el problema central del JavaScript rendering SEO respecto a una SPA pura: entregan HTML completo a los motores de búsqueda sin depender de la segunda ola de indexación de Googlebot.
---
Casos de uso reales para empresas españolas
E-commerce de moda con catálogo variable
Una tienda online con 8.000 referencias de producto y stock que varía diariamente necesita que el precio y la disponibilidad estén siempre actualizados en la página que indexa Google. SSR es la opción natural: cada visita genera el HTML con datos frescos. Para mejorar el rendimiento, se puede añadir una capa de caché con tiempo de vida corto (5-15 minutos) que absorba el volumen de rastreo de Googlebot sin saturar la base de datos.
Portal de contenidos B2B
Una empresa de consultoría que publica artículos técnicos, casos de estudio y whitepapers tiene contenido que apenas cambia una vez publicado. SSG con Next.js o Gatsby genera HTML estático en el build, se despliega en Vercel o Netlify y Googlebot indexa todo el contenido de forma inmediata. El rebuild se lanza automáticamente cuando se publica un nuevo artículo desde el CMS. Resultado: velocidad máxima, costes mínimos, SEO técnico impecable.
SPA corporativa heredada sin posibilidad de refactorizar
Una empresa con una aplicación Angular construida hace cinco años, sin presupuesto para migrar a SSR, puede implementar pre-rendering dinámico con Prerender.io. El servicio detecta el user-agent de Googlebot y sirve una versión prerenderizada del HTML. La inversión es mínima comparada con una reescritura completa y el impacto en indexación es inmediato. Se han observado mejoras de hasta un 30-40% en el número de páginas indexadas en los primeros 30 días tras implementar pre-rendering dinámico en sitios previamente servidos como SPA puras.
---
Errores críticos que debes evitar
1. Bloquear el rastreo de JavaScript en robots.txt
Es un error más común de lo que parece. Si en robots.txt tienes Disallow: /*.js, Googlebot no puede ejecutar los scripts y solo ve el HTML vacío. Revisa tu fichero robots.txt y asegúrate de que los recursos JavaScript y CSS son accesibles para los rastreadores.
2. Lazy loading de contenido crítico sin alternativa
Si tus títulos H1, textos principales o enlaces internos aparecen solo después de un scroll o de una interacción del usuario gestionada por JavaScript, ese contenido puede no indexarse. El contenido crítico para el SEO debe estar presente en el HTML inicial, no cargado de forma diferida.
3. Datos estructurados generados únicamente en cliente
Si tus rich snippets (Schema.org para productos, artículos, FAQs) se inyectan via JavaScript en el cliente, pueden no estar disponibles en la primera respuesta. Google recomienda incluir los datos estructurados en el HTML del servidor, no generarlos exclusivamente en cliente.
4. Ignorar los errores de hidratación
Cuando el HTML que genera el servidor no coincide con lo que renderizaría React o Vue en el cliente, se producen errores de hidratación que generan parpadeos visuales (CLS) y pueden causar que el contenido que ve el usuario final sea diferente al que indexa Google. Monitoriza los errores de hidratación en tus logs de servidor.
---
Cómo auditar el estado actual de tu web
Antes de decidir si migras a SSR o implementas pre-rendering, necesitas entender qué está indexando Google ahora mismo. Estos son los pasos básicos de una auditoría de JavaScript rendering SEO:
- Inspecciona URLs en Google Search Console con la herramienta de inspección de URL. Compara el HTML de la primera respuesta con el HTML renderizado. Si hay diferencias significativas en contenido textual, tienes un problema.
- Usa Screaming Frog con JavaScript rendering activado y desactivado. Compara los resultados: URLs que aparecen solo con JS activado son URLs en riesgo de no indexarse o de indexarse con retraso.
- Comprueba el tiempo de indexación comparando la fecha de publicación de nuevas páginas con la fecha en que aparecen en los resultados de Google (puedes usar el operador
site:o Search Console).
- Analiza los Core Web Vitals en Search Console. Un LCP elevado en páginas JavaScript puede indicar que el contenido crítico no está en el HTML inicial y el navegador necesita tiempo extra para renderizarlo.
---
Conclusión: la decisión correcta depende de tu modelo de negocio
No existe una respuesta universal a la pregunta de si usar pre-rendering o SSR para mejorar el JavaScript rendering SEO de tu web. La respuesta correcta depende de la frecuencia con que cambia tu contenido, el tamaño de tu catálogo, tu presupuesto de infraestructura y la madurez técnica de tu equipo.
Lo que sí es universal es que servir una SPA pura sin ninguna estrategia de renderizado en servidor es asumir un riesgo SEO innecesario. Google puede renderizar JavaScript, pero no lo hace de forma inmediata ni garantizada, y cada día de retraso en la indexación es tráfico orgánico que no llega a tu negocio.
Si tu web está construida sobre un framework JavaScript y no tienes claro qué estrategia de renderizado estás usando actualmente ni cómo afecta a tu posicionamiento, es el momento de hacer una auditoría técnica en profundidad.
---
¿Quieres saber exactamente cómo está indexando Google las páginas de tu web y qué impacto tiene el renderizado JavaScript en tu tráfico orgánico? En Comunicua realizamos auditorías SEO técnicas completas en las que analizamos el estado de indexación de tu sitio, detectamos problemas de renderizado y diseñamos un plan de acción concreto. Contacta con nosotros en comunicua.com/contacto y cuéntanos tu caso.