Cuando una web construida con React, Vue o cualquier framework moderno de JavaScript carga en el navegador de un usuario, el HTML que llega inicialmente suele estar casi vacío: un <div id="root"></div> que el propio JavaScript rellena después, en el navegador, con el contenido real. Ese patrón (Client-Side Rendering, CSR) funciona perfectamente para el usuario porque su navegador ejecuta el JavaScript en milisegundos, pero introduce un problema real para el SEO que muchos equipos de desarrollo subestiman: los rastreadores no siempre ven lo mismo, ni lo ven en el mismo momento.
Cómo renderiza Google el JavaScript: las dos fases reales
Google no ignora el JavaScript (dejó de ser cierto hace años) pero tampoco lo procesa de forma inmediata como haría un navegador. El proceso interno tiene dos fases separadas en el tiempo. En la primera, Googlebot rastrea la URL y obtiene el HTML inicial tal cual lo sirve el servidor, sin ejecutar ni una línea de JavaScript; ese HTML es lo primero que se indexa provisionalmente y lo que determina, entre otras cosas, los enlaces que Google descubre de inmediato. En la segunda fase, que puede ocurrir minutos, horas o (en sitios con poca prioridad de rastreo) días después, Google encola la página para renderizarla con una versión de Chromium, ejecuta el JavaScript como lo haría un navegador real, y actualiza el índice con el contenido que aparece tras esa ejecución.
La consecuencia práctica de este desfase es que cualquier contenido o enlace que solo exista después de ejecutar JavaScript vive en un limbo temporal: existe para Google, pero no de inmediato. En sitios que publican contenido con mucha frecuencia (noticias, ofertas con caducidad corta), ese retraso puede significar que el contenido relevante ya no lo sea cuando por fin se renderiza.
SSR, SSG e hidratación: qué elegir según el proyecto
La forma más fiable de evitar depender de esa segunda fase es que el servidor entregue ya el HTML completo, con el contenido real presente, antes de que llegue ni una línea de JavaScript al navegador. Hay dos estrategias principales para lograrlo. El Server-Side Rendering (SSR) genera el HTML completo en el servidor en cada petición, combinando siempre datos frescos con el marcado; es la opción adecuada para contenido que cambia por usuario o con mucha frecuencia (resultados de búsqueda internos, precios dinámicos, contenido personalizado). El Static Site Generation (SSG) genera ese mismo HTML completo, pero por adelantado, en tiempo de compilación, y lo sirve luego como archivos estáticos; es la opción más rápida y barata de servir, ideal para contenido que no cambia constantemente (páginas de blog, landing pages, catálogos que se actualizan por lotes).
Ambas estrategias suelen combinarse con hidratación: el HTML llega ya completo y visible, y el JavaScript se ejecuta después únicamente para "engancharse" a ese HTML y añadir la interactividad (clics, formularios, animaciones), sin tener que regenerar el contenido desde cero. Para SEO, lo que importa no es qué framework se use sino que el contenido textual relevante esté presente en el HTML que se sirve antes de cualquier ejecución de JavaScript.
Cómo comprobar qué ve realmente Google, no qué crees que ve
La comprobación más fiable no es abrir el "ver código fuente" del navegador (que muestra el HTML inicial, útil pero incompleto) ni tampoco fiarse de que "en el navegador se ve bien" (eso solo confirma que funciona para usuarios, no para rastreadores). La herramienta correcta es la Inspección de URLs de Search Console, que muestra el HTML renderizado tal como lo procesó Googlebot en su última visita, incluyendo una captura de pantalla de cómo quedó la página tras ejecutar el JavaScript. Si el contenido que te interesa posicionar no aparece ahí, no está llegando a Google con independencia de que se vea perfectamente en tu propio navegador.
// Comprobación rápida desde la consola del navegador:
// deshabilita JavaScript y recarga para ver el HTML "crudo"
// (aproxima, no sustituye, lo que ve la primera fase de rastreo)
document.querySelector('html').outerHTML.lengthEnlaces internos generados por JavaScript: la trampa más común
Un error extendido en sitios con menús o paginación construidos con componentes interactivos: usar elementos <div> o <span> con un onClick en JavaScript para simular la navegación, en vez de un <a href="..."> real. Un navegador ejecuta ese onClick sin problema, pero un enlace sin atributo href no es un enlace rastreable: Google no lo sigue en la primera fase de rastreo (HTML crudo) y, aunque en la fase de renderizado sí ejecute el JavaScript, la extracción de enlaces para seguir descubriendo páginas nuevas es mucho más fiable a partir de href reales que de eventos de clic simulados.
<!-- Mal: no es un enlace rastreable -->
<div onclick="navigate('/productos/silla')">Ver silla</div>
<!-- Bien: href real, funciona igual con JS para la transición SPA -->
<a href="/productos/silla" onclick="navigate(event, '/productos/silla')">Ver silla</a>Contenido que se carga tras un scroll o una interacción
El "infinite scroll" y los contenidos que solo se cargan al hacer clic en "cargar más" plantean el mismo problema desde otro ángulo: Googlebot no hace scroll ni hace clic como lo haría un usuario explorando por curiosidad, así que el contenido que solo aparece tras esas acciones puede no llegar nunca a rastrearse. La solución técnica más robusta es la paginación real con URLs propias para cada bloque de contenido (aunque visualmente, para el usuario, se cargue como scroll infinito mediante JavaScript), de forma que exista siempre una ruta puramente basada en enlaces href que permita a Google llegar a cada tramo de contenido de forma independiente.
Presupuesto de renderizado: por qué también es limitado
Ejecutar JavaScript es computacionalmente mucho más caro para Google que leer HTML estático, así que el renderizado no solo tiene el desfase de tiempo ya explicado sino también un límite de recursos que se reparte, igual que el crawl budget, según la prioridad que Google asigna al sitio. En dominios grandes con miles de páginas dependientes de renderizado, es habitual encontrar en Search Console URLs marcadas como "rastreada, sin indexar actualmente" durante semanas, precisamente porque están en cola de renderizado y nunca llegan a procesarse con la prioridad suficiente.
Preguntas frecuentes
¿Google ya no tiene problemas con JavaScript?
Los tiene mucho menos que hace años, pero el desfase entre la primera fase (HTML crudo) y la segunda (renderizado) sigue existiendo y sigue afectando a la velocidad de indexación, sobre todo en sitios grandes o con poca autoridad donde el renderizado no es prioritario.
¿Es obligatorio usar SSR para que una web con React o Vue posicione?
No es obligatorio si el sitio es pequeño y tiene autoridad suficiente para que Google le dedique renderizado con rapidez, pero es la opción más segura y predecible cuanto mayor es el sitio o más crítico es que el contenido nuevo se indexe rápido.
¿Cómo sé si mi contenido depende de JavaScript para aparecer?
Usa la Inspección de URLs de Search Console y compara el HTML renderizado que muestra con el contenido que esperas ver. Si falta, ese contenido depende de una ejecución de JavaScript que Google puede no estar completando a tiempo o con prioridad suficiente.
¿Los frameworks modernos ya solucionan esto automáticamente?
Los frameworks que ofrecen SSR o SSG como opción (no todos lo hacen por defecto) resuelven el problema si se configura esa opción; usar el modo puramente de cliente (CSR) por defecto, que es lo más común al iniciar un proyecto sin pensar en SEO, no lo resuelve.
¿Afecta el JavaScript a la velocidad de carga además de a la indexación?
Sí, y es un problema relacionado pero distinto: un exceso de JavaScript sin ejecutar todavía retrasa métricas de Core Web Vitals como INP y LCP, que sí son factor de posicionamiento directo, independientemente de si el contenido acaba indexándose correctamente o no.