JavaScript SEO: lo que el bot ve cuando tu sitio es una SPA
JavaScript SEO es la práctica de hacer que sitios construidos con frameworks JS (React, Vue, Angular, Next, Nuxt) sean efectivamente rastreables, indexables y rankeables. No es magia: es entender qué ve el bot en cada modelo de rendering y elegir el correcto para cada tipo de página.
El problema de fondo: HTML vs JS
Cuando un crawler visita una página renderizada en servidor, recibe HTML completo en la primera respuesta — texto, links, schema, todo. Cuando visita una SPA renderizada en cliente, recibe un esqueleto vacío con un <div id=”root”> y un bundle de JavaScript. El contenido aparece después, cuando el navegador ejecuta el JS y monta el árbol.
Googlebot puede ejecutar JavaScript desde 2014. En 2026 lo hace bien — pero no instantáneamente y no con la misma frecuencia que servir HTML estático. La diferencia entre rankear y no rankear muchas veces se reduce a cuánto contenido aparece sin JS.
El segundo crawler crítico es el de los modelos de IA. ChatGPT, Perplexity, Gemini y Claude tienen crawlers que en general no ejecutan JavaScript o lo hacen de forma muy limitada. Si tu contenido aparece solo después de hidratar React, no entra al training set ni al RAG en tiempo real. Esto cambió drásticamente la conversación sobre SSR en 2024-2026.
Rendering: los cuatro modelos
Hay cuatro modelos vivos. Cada uno se decide a nivel de ruta, no de sitio entero. Una buena arquitectura combina varios.
Client-side
Todo se renderiza en el browser. HTML inicial casi vacío. Solo aceptable para áreas internas autenticadas o sin valor SEO.
Server-side
El servidor genera HTML completo en cada request. El bot ve todo en el primer response. Costo: latencia y carga.
Static generation
HTML pre-generado en build time. Lo más rápido para crawler y usuario. El estándar para blogs, docs, glosarios.
Incremental static
HTML estático que se regenera por demanda con TTL. Pattern dominante en Next.js para eCommerce.
La regla práctica: para cualquier página que querés rankear, el HTML del primer response tiene que contener el contenido principal — H1, párrafos, links internos, schema. Si eso solo aparece después de ejecutar JS, dependés del segundo render de Google y de que los crawlers de IA decidan ejecutar tu bundle. Es una apuesta innecesaria.
Hydration: el momento que pocos entienden
Hidratación es el proceso por el que React (o Vue, o Angular) toma el HTML que ya está en pantalla y le engancha event listeners y estado para volverlo interactivo. Existe porque queremos lo mejor de ambos mundos: HTML rápido para SEO + interactividad de cliente para UX.
El problema clásico: el HTML del servidor y el HTML que React quiere generar después de hidratar tienen que coincidir. Si difieren — porque un componente lee localStorage, o Date.now(), o un AB test cookie — React tira el HTML del servidor y re-renderiza desde cero en cliente. Es lo que se llama hydration mismatch y es uno de los bugs más caros en SEO de SPAs: visualmente nadie nota, pero el SEO se rompe.
Validación rápida: comparar la respuesta de curl con lo que se ve en pantalla. Si hay contenido visible que NO está en el curl, ese contenido no está siendo crawleado por nadie que no ejecute JS — y eso incluye a la mayoría de crawlers de IA.
Dynamic rendering: el patch que ya no se recomienda
Dynamic rendering es servir HTML pre-renderizado a bots y JavaScript a usuarios reales, detectando user-agent. Google lo recomendó como solución temporal entre 2018 y 2022 y lo deprecó oficialmente en 2023 — la recomendación actual es SSR o SSG.
Sigue vivo en sitios legacy. Funciona, pero introduce un único punto de falla: el detector de user-agent. Si Googlebot cambia su signature o un crawler nuevo no es reconocido, perdés indexación silenciosamente. Plus: los crawlers de IA no son siempre detectados como bots, así que el dynamic rendering no los protege.
Cómo se aplica en la práctica
El stack típico de una migración a JavaScript SEO bien resuelta combina: SSG para contenido editorial y páginas estáticas, ISR para listados de productos con TTL razonable, SSR para páginas con personalización en tiempo real, y CSR solo para áreas privadas. Lo que no se hace es montar un sitio entero en CSR puro y rezar que Google lo indexe. Si querés ver un caso real, hay un ejemplo en /casos/ y la metodología completa en /servicios/seo-tecnico/.