SEO técnico
Capítulo 09 / 09
JavaScript SEO
El Google de hoy renderiza JavaScript, pero cómo lo hace y con qué límites decide si tu SPA, tu tienda en React o tu contenido dinámico se indexa siquiera: las reglas de renderizar o morir para 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 crawler que exista. El renderizado del lado del cliente funciona para Google, despacio. Los crawlers 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 renderer 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 render 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 request, en el servidor | Excelente: HTML completo en cada request, se indexa en pasada 1 |
| Edge SSR | En cada request, 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 render de la pasada 2 |
Los frameworks modernos (Next.js, Nuxt, Remix, Astro, SvelteKit) soportan 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 request.
- Edge SSR para sitios globales en los que el TTFB importa y el render 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 crawlers de buscadores con IA no ejecuta JavaScript.
| Crawler | 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 click-to-reveal, tabs 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 render. Si el contenido de la página viene de una API de backend y esa API está lenta, caída o bloqueada, el render falla y Google indexa una página vacía.
- Timeouts de JavaScript. La hidratación pesada sumada a scripts de terceros lentos puede empujar el render 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 render 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 render.
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 render. 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 crawlers que solo leen HTML no pueden indexarlo. - 4. Chrome DevTools > Network > throttling = Slow 3G + CPU 4× más lento. Simula el entorno de render restringido de Googlebot. Las páginas que fallan aquí pueden fallar también en el renderer 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, pricing, páginas de feature): 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 crawl budget.
- 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 routing 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 renderer 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