Inicio/Glosario/JavaScript SEO
SEO técnicoJavaScript SEO
JavaScript SEO es la disciplina del SEO técnico que asegura que el contenido, los enlaces y los metadatos que dependen de JavaScript sean rastreables, renderizables e indexables. Su clave es que los buscadores procesan el JS en tres fases desacopladas —rastreo, renderizado e indexado— y que la mayoría de crawlers de IA no ejecutan JavaScript.
Qué es
JavaScript SEO trata cómo los buscadores procesan el JavaScript de una página y qué hace falta para que el contenido, los enlaces y los metadatos que dependen de él sean rastreables, renderizables e indexables.
Google lo hace en tres fases desacopladas. Primero rastrea: Googlebot pide la URL, comprueba robots.txt y parsea el HTML inicial buscando enlaces. Después renderiza: toda página que devuelve un 200 (salvo noindex) entra en una cola de renderizado donde el Web Rendering Service (WRS) ejecuta el JS con un Chromium headless y evergreen —la versión actual del navegador, no una congelada— para ver el contenido inyectado. Por último indexa el HTML ya renderizado y vuelve a extraer enlaces. Es una variante con coste extra del ciclo general de Rastreo e indexación, que es el proceso por el que un buscador descubre, procesa y guarda una página.
Esa cola es asíncrona. El modelo histórico de las "dos olas" describía esperas de hasta semanas; Martin Splitt (Google) matizó en 2024-2025 que hoy el renderizado suele ocurrir en minutos. Sigue consumiendo recursos y sigue desacoplado del rastreo. De ahí nacen las estrategias de renderizado —CSR, SSR, prerender/static e hidratación— que deciden cuánto contenido llega ya en el HTML servido y cuánto depende del cliente.
Por qué importa
Si el contenido crítico, los enlaces internos o los metadatos solo aparecen tras ejecutar JavaScript, dependes de que el renderizado ocurra y funcione. Cuando el JS falla, el usuario —y el buscador— no ven nada. Eso golpea de lleno al Enlazado interno, que es la red de enlaces entre tus propias páginas y la vía por la que Google descubre y reparte autoridad: si esos enlaces solo existen tras renderizar, parte de tu Arquitectura web puede quedar fuera del alcance del rastreo. Google indexa contenido renderizado por JS, pero lo hace en una segunda pasada asíncrona: cualquier fragilidad en ese paso retrasa o impide la indexación.
El cambio de 2025-2026 endurece el listón. La mayoría de crawlers de modelos de lenguaje (GPTBot, ClaudeBot, PerplexityBot) no ejecutan JavaScript: solo leen el HTML estático. Un contenido que Google sí indexa tras renderizar puede ser invisible para la búsqueda con IA (GEO · Generative Engine Optimization, la disciplina de hacerte visible y citable en respuestas generativas, y sus AI Overviews y AI Mode). Servir el contenido crítico en el HTML inicial deja de ser solo una buena práctica de SEO clásico y pasa a ser la condición para existir en ambos canales; también afecta a tus Datos estructurados, el marcado que ayuda a buscadores y modelos a entender la página, si los inyectas por JS.
Google es neutral en ranking respecto al método de renderizado. El efecto de cambiar de estrategia es indirecto —una indexación más fiable y un contenido accesible para más crawlers—, no una mejora de posiciones garantizada. La decisión correcta depende de tu stack y de tu tipo de contenido, y se toma con criterio, no con receta.
En profundidad
Las tres fases y la cola de renderizado
El rastreo y el renderizado no ocurren a la vez. Googlebot parsea primero el HTML inicial; cualquier página con 200 que no sea noindex entra en una cola donde el WRS la renderiza con Chromium evergreen cuando hay recursos. Tras renderizar, Google vuelve a parsear el HTML resultante en busca de enlaces y los encola para rastreo. El modelo de las "dos olas" describía este desfase como esperas que podían ir de segundos a semanas. Según Martin Splitt (Google), hoy el renderizado suele ocurrir en minutos, pero sigue siendo asíncrono y consume recursos. Google no publica cifras de cuántos recursos o páginas limita el WRS; cualquier número concreto de "presupuesto de renderizado" que circule en la comunidad no está confirmado oficialmente —es un concepto distinto del Crawl budget (presupuesto de rastreo), que sí describe cuántas URLs rastrea Google y solo pesa de verdad en sitios muy grandes.
CSR, SSR, static e hidratación: cuándo conviene cada una
En CSR el HTML inicial llega casi vacío y todo depende del JS: máximo riesgo si el script falla, apropiado para apps muy interactivas, no para sitios de contenido. SSR y prerender/static entregan HTML completo desde el primer byte —SSR puede responder a estado de sesión o acciones; static es más robusto pero encaja con contenido que cambia poco. La hidratación es el enfoque híbrido que recomienda Google: el servidor pinta el contenido inicial y el cliente toma el control para las interacciones. Google recomienda explícitamente SSR, static o hidratación y declara que el dynamic rendering "era un workaround y no una solución a largo plazo". La elección también repercute en los Core Web Vitals, las métricas de experiencia de carga, interactividad y estabilidad visual: un CSR pesado suele penalizar la interactividad, mientras SSR/static adelantan el contenido al primer byte.
| Enfoque | Qué entrega el primer byte | Cuándo conviene |
|---|---|---|
| CSR | HTML casi vacío; todo depende del JS | Apps muy interactivas; máximo riesgo si el script falla. No para sitios de contenido |
| SSR | HTML completo, generado por petición | Contenido que responde a sesión o acciones; HTML robusto desde el inicio |
| Static / prerender | HTML completo precompilado | Contenido que cambia poco; el enfoque más robusto |
| Hidratación (híbrido) | HTML del servidor + JS que toma el control en cliente | Recomendado por Google: pinta contenido y habilita interacción |
Errores frecuentes en SPAs
Cuatro patrones documentados por Google rompen la indexación. Uno: usar fragmentos con hash (#/products) para el routing en vez de la History API —Googlebot no resuelve esas URLs de forma fiable. Dos: inyectar noindex vía JS —Google puede ver la directiva y saltarse el render, sin llegar a ejecutar el script. Tres: cambiar la URL canónica con JS —debe fijarse en el HTML original, una precaución que entronca con la Canonicalización y duplicados, el modo de indicar a Google cuál es la versión preferente de una URL. Cuatro: soft 404 —rutas inexistentes que devuelven 200 con un mensaje de error pintado por JS, que terminan indexándose; hay que devolver códigos de estado reales o un noindex de verdad. El diagnóstico canónico se hace con la URL Inspection Tool de Search Console (HTML renderizado y captura) y el Rich Results Test para validar los Datos estructurados tras el render.
JavaScript y búsqueda con IA
Aquí está el cambio de paradigma de 2025-2026. Los tests de Vercel sobre crawlers de IA concluyen que la mayoría no ejecuta JavaScript y ninguno renderiza contenido de cliente: GPTBot (ChatGPT) y ClaudeBot (Claude) leen solo HTML estático. El contenido inyectado por JS puede ser invisible para GEO/AIO aunque Google sí lo indexe —ahí se juega la Citabilidad en respuestas de IA, que es la capacidad de que un modelo extraiga y cite tu contenido, y que arranca por tenerlo en el HTML servido. La excepción reportada es Gemini: según declaraciones de Martin Splitt recogidas por terceros, renderiza JS como Googlebot —conviene tratarlo como afirmación de portavoz, no como documentación oficial. La implicación es la misma para SEO clásico y para IA: el contenido crítico, los enlaces internos, los datos estructurados y los metadatos deben estar en el HTML servido, no depender del cliente.
La mayoría de crawlers de IA no ejecuta JavaScript y ninguno renderiza contenido de cliente: GPTBot (ChatGPT) y ClaudeBot (Claude) leen solo el HTML estático fuente. El contenido inyectado por JS puede ser invisible para GEO/AIO aunque Googlebot sí lo indexe. La excepción reportada es Gemini, que según declaraciones de portavoz renderizaría JS como Googlebot fuente —tratar como afirmación de portavoz, no documentación oficial. Implicación común para SEO clásico e IA: el contenido crítico, los enlaces internos, los datos estructurados y los metadatos deben estar en el HTML servido, no depender del cliente.
En vídeo y audio
Qué observar
Las señales que importan.
Contenido y enlaces en el HTML inicial vs. inyectados por JS
El HTML servido (view-source) y el DOM renderizado pueden diferir. El primero determina qué texto y qué enlaces internos llegan ya en la respuesta del servidor; el resto depende del cliente y solo aparece tras ejecutar JS.
Estrategia de renderizado y su ajuste al tipo de sitio
Existen varios enfoques: CSR, SSR, static e hidratación. La elección debe encajar con el contenido del sitio. Las apps muy interactivas y los sitios de contenido no tienen las mismas necesidades.
Metadatos sensibles servidos en el HTML original
Title, canonical, hreflang y la directiva noindex deben viajar en el HTML inicial. Cuando Google ve un noindex puede saltarse el render y nunca ejecutar el JS que lo cambia.
Routing y códigos de estado correctos
Las rutas deben usar la History API en lugar de fragmentos con hash. Las rutas inexistentes deben devolver estados reales, no un 200 con un error pintado por JS, que se indexa como soft 404.
Accesibilidad para crawlers de IA
Solo parte del contenido sobrevive sin ejecutar JavaScript. Importa porque la mayoría de crawlers de LLM no renderizan y leen únicamente el HTML estático.
Conceptos clave
El vocabulario del término.
- Web Rendering Service (WRS)
- Servicio de Google que renderiza las páginas ejecutando su JavaScript con un Chromium headless y evergreen para ver el contenido y los enlaces que se inyectan en el cliente.
- Cola de renderizado
- Lista de espera asíncrona donde Google encola cada página con HTTP 200 (salvo noindex) hasta que hay recursos para renderizarla; hoy suele resolverse en minutos, pero sigue desacoplada del rastreo.
- CSR (renderizado en cliente)
- Estrategia en la que el HTML inicial llega casi vacío y el contenido se construye con JavaScript en el navegador; si el script falla, ese contenido no se ve.
- SSR (renderizado en servidor)
- Estrategia en la que el servidor genera el HTML completo de la página antes de enviarlo, de modo que el contenido llega desde el primer byte sin depender del cliente.
- Hidratación
- Enfoque híbrido en el que el servidor entrega el HTML inicial ya renderizado y el JavaScript del cliente toma después el control para gestionar las interacciones; es el método que Google recomienda.
- Dynamic rendering
- Servir HTML pre-renderizado a los bots y la versión con JS a los usuarios; Google lo describe como un workaround temporal, no como una solución a largo plazo.
- Soft 404
- Página que devuelve un código 200 pero muestra contenido de error o vacío —frecuente en SPAs que pintan el error con JS—, lo que puede llevar a que se indexe una ruta que no existe.
Dónde lo aplicamos
Aún no mostramos casos.
No inventamos resultados. Cuando tengamos casos reales —anonimizados y medibles— donde este concepto marcó la diferencia, vivirán aquí.
Fuentes
- Understand JavaScript SEO Basics · 2025
- Dynamic rendering as a workaround · 2025
- How Rendering Affects SEO: Takeaways From Google's Martin Splitt · 2025
- JavaScript Rendering Q&A With Google's Martin Splitt · 2025
- No-JavaScript fallbacks in 2026: Less critical, still necessary · 2026
- Server-side rendering (SSR) — Glossary · 2025
Una pieza del glosario.
Forma parte del glosario de SEO, analítica e IA de InnovaOrigen Tech: un mapa de conceptos definidos con criterio y fuentes. Si quieres llevarlo a tu caso, lo vemos sin compromiso.