SEO técnico
Capítulo 09 / 09
JavaScript SEO
Google ya renderiza JavaScript, pero el modo y los límites con que lo hace deciden si tu SPA, tu tienda en React o tu contenido dinámico llegan al índice: las reglas para renderizar o morir en 2026.
JavaScript SEO es la disciplina de asegurar que los buscadores y los buscadores con IA puedan ver, renderizar e indexar páginas que dependen de JavaScript para mostrar contenido. El Google de hoy puede renderizar la mayoría del JavaScript, pero cómo renderiza, qué tolera y qué hacen los buscadores con IA (que en su mayoría no renderizan en absoluto) decide si un sitio pesado en JS indexa bien o sangra tráfico en silencio.
“El HTML renderizado en el servidor es la ruta más rápida a la indexación, para Google, para cada buscador con IA y para cualquier otro rastreador que exista. El renderizado del lado del cliente funciona para Google, despacio. Los rastreadores de buscadores con IA por lo general no pueden renderizar en absoluto. El árbol de decisión es: renderiza del lado del servidor a menos que tengas una razón específica para no hacerlo.”
Cómo renderiza JavaScript Googlebot de verdad
Google usa un proceso de indexación de dos pasadas para las páginas renderizadas con JS:
- Pasada 1: rastreo inicial. Googlebot trae el HTML crudo y extrae las URLs y cualquier contenido que no requiera JS. La página entra a la cola de indexación.
- Pasada 2: renderizado. Horas o días después, Googlebot pasa la página por un motor de renderizado reciente basado en Chromium (Web Rendering Service). El DOM renderizado es lo que se analiza para contenido, enlaces y señales.
Implicaciones prácticas:
- Las páginas renderizadas en servidor reciben el rastreo y la extracción completos en la pasada 1. Se indexan más rápido.
- Las páginas renderizadas con JS esperan a la pasada 2: por lo general horas, a veces días. Se indexan más lento.
- La pasada 2 tiene límites de recursos: tiempos de renderizado largos, llamadas a API lentas y scripts de terceros pueden hacer que el renderizado falle o se quede sin tiempo.
- Los enlaces internos que solo se descubren a través del DOM renderizado con JS no aparecen hasta la pasada 2; la propagación completa del rastreo tarda más.
Los cuatro patrones de renderizado y lo que cuestan
| Patrón | Cuándo se construye el HTML | Impacto en SEO |
|---|---|---|
| SSG: Static Site Generation | Al momento del deploy | El mejor: HTML preconstruido, TTFB más rápido, se indexa de inmediato |
| ISR: Incremental Static Regeneration | Construido en deploy + regenerado periódicamente | Excelente: contenido fresco con beneficios de SEO al nivel de SSG |
| SSR: Server-Side Rendering | En cada petición, en el servidor | Excelente: HTML completo en cada petición, se indexa en pasada 1 |
| Edge SSR | En cada petición, en el edge del CDN | Excelente: beneficios de SSR + TTFB bajo a nivel global |
| CSR: Client-Side Rendering | En el navegador, después de que carga el JS | El peor: HTML inicial vacío, depende del renderizado de la pasada 2 |
Los frameworks modernos (Next.js, Nuxt, Remix, Astro, SvelteKit) admiten todos SSG, ISR y SSR. El árbol de decisión:
- SSG para contenido que no cambia entre deploys: artículos de academia, páginas de marketing, blog de formato largo.
- ISR para contenido que se actualiza con frecuencia pero no necesita frescura en tiempo real: catálogos de producto, sitios de noticias con actualizaciones diarias.
- SSR para contenido personalizado, datos en tiempo real y cualquier cosa que varíe en cada petición.
- Edge SSR para sitios globales en los que el TTFB importa y el renderizado puede correr en isolates de V8.
- CSR para dashboards autenticados de la app, herramientas internas y cualquier cosa que no necesite indexarse.
La realidad de los buscadores con IA: la mayoría no renderiza
Restricción nueva en 2026 que no existía en 2022: la mayoría de los rastreadores de buscadores con IA no ejecuta JavaScript.
| Rastreador | Renderizado de JS |
|---|---|
| Googlebot | Sí (basado en Chromium, dos pasadas) |
| Bingbot | Sí (basado en Chromium) |
| GPTBot (OpenAI) | Limitado: trae HTML; soporte de JS en evolución |
| ChatGPT-User (navegación en vivo) | Limitado: se apoya en Bing para algunas consultas |
| ClaudeBot (Anthropic) | Limitado: trae HTML; soporte de JS en evolución |
| PerplexityBot | Limitado: principalmente HTML |
| Google-Extended (entrenamiento de Gemini) | Hereda el renderizado de Googlebot |
| Common Crawl (CCBot) | No: solo HTML |
La implicación: un sitio CSR que envía HTML vacío y construye el contenido en el navegador es invisible para la mayoría de los buscadores con IA. Las menciones de marca, las comparaciones de producto y el contenido informativo renderizados solo a través de JS no se citarán en las respuestas de ChatGPT, Claude o Perplexity. El arreglo es el mismo que para Google: renderiza el contenido del lado del servidor dentro del HTML inicial.
Fallas comunes en JavaScript SEO
- Contenido que solo se renderiza tras la interacción del usuario. Secciones que se revelan al hacer clic, pestañas y acordeones que no hidratan sin clic: Googlebot puede no interactuar y el contenido se pierde.
- Scroll infinito sin history.pushState. Las páginas 2 en adelante de un feed de scroll infinito no tienen URL única, así que no se pueden indexar de forma individual.
- Fallas de API durante el renderizado. Si el contenido de la página viene de una API de backend y esa API está lenta, caída o bloqueada, el renderizado falla y Google indexa una página vacía.
- Tiempos de espera agotados de JavaScript. La hidratación pesada sumada a scripts de terceros lentos puede empujar el renderizado más allá del presupuesto de Google. El DOM renderizado queda incompleto.
- Recursos bloqueados por robots.txt. Si los bundles de JS, CSS o APIs críticas están bloqueados al rastreo, Google no puede traerlos y el renderizado falla.
- Contenido visible solo en renderizado condicional por user-agent. Cercano al cloaking: los bots ven una cosa y los usuarios otra. Arriesgado y detectable.
- Contenido con lazy-load sin fallback. El contenido por debajo del fold que requiere hidratación disparada por scroll puede no cargar durante el renderizado.
Depurar JavaScript SEO
- 1. Search Console > Inspección de URL > Probar URL en vivo. Compara la pestaña “HTML” (renderizado) con la pestaña “Recursos de la página” (recursos cargados). Contenido faltante = falla de renderizado. Recursos fallidos = problema en la ruta de rastreo.
- 2. Ver código fuente vs. Inspeccionar elemento. Ver código fuente muestra el HTML crudo; Inspeccionar elemento muestra el DOM renderizado. La diferencia es tu superficie de dependencia de JS: cualquier cosa que aparezca en Inspeccionar y no en el código fuente necesita JS para renderizar.
- 3. Curl sin ejecución de JS.
curl -L https://www.ejemplo.com/pagina/muestra lo que ven los bots que no renderizan. Si tu contenido no está ahí, los rastreadores que solo leen HTML no pueden indexarlo. - 4. Chrome DevTools > Network > throttling = Slow 3G + CPU 4× más lento. Simula el entorno de renderizado restringido de Googlebot. Las páginas que fallan aquí pueden fallar también en el motor de renderizado real.
- 5. Desactiva JavaScript en Chrome. Mira exactamente lo que vería Googlebot en la pasada 1. El contenido crítico debería seguir visible.
Patrones de migración
De CSR a SSR/SSG
Para los sitios de contenido que hoy corren sobre SPAs puramente renderizadas en cliente, la migración a SSR o SSG es una de las inversiones de SEO que más rinden. Los frameworks modernos la hacen incremental: la migración página por página es posible sin reescribir toda la app. Orden de prioridad:
- Páginas de marketing (home, precios, páginas de funcionalidad): el mayor impacto comercial.
- Páginas de contenido (academia, blog, base de conocimiento): la mayor superficie de tráfico orgánico.
- Páginas de categoría y de listado: el mayor impacto en presupuesto de rastreo.
- Páginas de producto o detalle: la mayor escala y el mayor riesgo de duplicación.
- Dashboards autenticados al final: no necesitan indexarse.
Renderizado híbrido
La mayoría de los sitios terminan en un esquema híbrido: SSG para contenido perenne, ISR para contenido que se actualiza con frecuencia, SSR para páginas personalizadas y CSR para las superficies de app autenticadas. Los frameworks modernos manejan esta decisión a nivel de enrutamiento por página; lo único que hay que evitar es elegir el predeterminado equivocado para contenido que necesita indexarse.
El veredicto
Google puede renderizar JavaScript, pero el HTML renderizado en servidor sigue indexando más rápido, con más fiabilidad, y es visible para todos los buscadores con IA (la mayoría de los cuales no renderiza JS). El árbol de decisión para contenido que necesita tráfico de SEO y citación de IA: SSG para contenido perenne, ISR para actualizaciones periódicas, SSR para contenido personalizado y CSR solo para superficies que no necesitan indexarse. Los frameworks modernos (Next.js, Nuxt, Remix, Astro, SvelteKit) facilitan los tres patrones compatibles con SEO. El único patrón que conviene evitar de manera activa: CSR puro en contenido que necesita posicionar.
Preguntas frecuentes
Preguntas frecuentes
Respuestas rápidas a lo que nos preguntan antes de cada prueba.
Sí, Googlebot renderiza JS con un motor reciente basado en Chromium. Salvedades prácticas: el renderizado ocurre en una segunda pasada después del rastreo inicial, así que el contenido renderizado por JS tarda más en indexarse que el HTML renderizado en el servidor. El motor de renderizado tiene límites de tiempo y recursos: las páginas que tardan demasiado, fallan a media renderización o requieren interacción del usuario para cargar contenido pueden perder contenido en silencio. La lectura honesta: Google puede renderizar JS, pero el HTML servido desde el servidor sigue indexando más rápido, con más fiabilidad y posicionando mejor en nichos competidos.
En este clúster