JavaScript SEO: renderizado e indexación

JavaScript controla hoy gran parte de los sitios web modernos, desde la navegación y los contenidos que se cargan después hasta la estructura completa de las páginas en las aplicaciones de una sola página. Esto abre una brecha entre lo que los usuarios ven en el navegador y lo que los buscadores y los rastreadores de IA encuentran sin renderizar. El JavaScript SEO cierra esa brecha. Este artículo explica cómo procesa Googlebot el JavaScript, qué estrategia de renderizado sirve para ser visible en la búsqueda clásica y en las respuestas de IA, y cómo evitas los errores típicos en el contexto europeo.

Por qué el JavaScript SEO es crítico para el negocio

En Austria, la visibilidad en buscadores coincide casi por completo con Google. El buscador tiene aquí una cuota de mercado del 81,87 %, por delante de Bing con el 9,01 % (Austria, datos de mayo de 2026). El mercado está casi totalmente conectado: a principios de 2025 había 8,69 millones de internautas, con una penetración de internet del 95,3 % (Austria). Si JavaScript impide que los contenidos se indexen bien, una empresa desaparece justo del canal que domina el mercado.

Para los proveedores B2B se suma la palanca económica. Las páginas de productos y servicios construidas con JavaScript suelen influir directamente en la facturación. Si se indexan mal, se resienten el alcance y las ventas.

Al mismo tiempo, la visibilidad se desplaza hacia las respuestas de IA, y este nivel es sensible al JavaScript. Un estudio internacional de Pew muestra hasta qué punto los resúmenes de IA cambian el comportamiento de clic: en una búsqueda con AI Overview, los usuarios solo hacen clic en un resultado clásico en el 8 % de los casos, sin AI Overview en el 15 % (internacional, EE. UU.). Si quieres aparecer como fuente en estas respuestas de IA, tienes que ofrecer tus contenidos a sistemas que, en la mayoría de los casos, ni siquiera ejecutan JavaScript.

Cómo procesa Googlebot el JavaScript: las dos oleadas de indexación

Googlebot divide el procesamiento de las páginas web en varios pasos. Primero, el rastreador descarga el HTML en bruto de una URL. Los contenidos HTML puros pasan de inmediato a la indexación. En cambio, los contenidos que solo surgen mediante JavaScript van a una cola aparte, la cola de renderizado. Allí, el Web Rendering Service, basado en un Chromium headless, ejecuta el JavaScript, completa el DOM y devuelve el HTML renderizado a la indexación. De ahí resultan, en la práctica, dos oleadas de indexación: una inmediata para el HTML en bruto y una segunda, diferida, para el resultado renderizado.

Primero, la buena noticia: Google renderiza de forma fiable. Un análisis muy comentado de Vercel y MERJ, basado en más de 100.000 peticiones de Googlebot, concluyó que el 100 % de las páginas HTML se renderizaron por completo, incluidas interacciones complejas de JavaScript (internacional). También se capturaron los contenidos cargados de forma asíncrona vía API y los contenidos de React Server Components transmitidos por streaming, y frameworks modernos como Next.js se renderizaron por completo. La afirmación de que Googlebot no entiende JavaScript ha quedado, por tanto, superada.

El problema no es el si, sino el cuándo. El mismo análisis cuantifica el retraso de renderizado: la mediana es de 10 segundos, el percentil 75 de 26 segundos y el percentil 90 de unas tres horas (internacional). Para la mayoría de las páginas no es crítico, pero para los contenidos urgentes la cola larga de la distribución supone un riesgo real. Lo agrava el esfuerzo de rastreo: un estudio de Onely mostró que Google necesita bastante más tiempo para las páginas JavaScript. Hasta la séptima página de un directorio JavaScript pasaron 313 horas, frente a solo 36 horas con HTML puro, unas nueve veces más (internacional). Si necesitas que muchos contenidos se indexen rápido, por ejemplo noticias u ofertas que cambian a menudo, con JavaScript pagas un recargo considerable en presupuesto de rastreo.

Estrategias de renderizado comparadas

La estrategia que elige un sitio web determina lo que encuentran los rastreadores en el primer paso.

• Client-Side Rendering (CSR): El servidor entrega una estructura HTML básica prácticamente vacía y el navegador construye la página mediante JavaScript. Los contenidos solo aparecen después del renderizado. Para Google suele funcionar, aunque con retraso. Para los rastreadores que no ejecutan JavaScript, la página queda prácticamente vacía.
• Server-Side Rendering (SSR): El servidor renderiza el HTML completo en cada petición y lo envía terminado. Los rastreadores y los bots de IA ven el contenido de inmediato en el HTML en bruto, sin depender del renderizado.
• Static Site Generation (SSG): Las páginas se generan de antemano, en tiempo de compilación, como HTML estático. El resultado es la máxima velocidad y un HTML indexable al instante, aunque es adecuado sobre todo para contenidos que no cambian constantemente.
• Renderizado dinámico: Una solución de transición en la que los rastreadores reciben una versión HTML prerrenderizada y los usuarios, la versión JavaScript. Google ha dejado de recomendar expresamente esta vía y la considera una solución provisional obsoleta, porque aumenta el mantenimiento y el riesgo de servir contenidos distintos.

Para la mayoría de los proyectos B2B, SSR y SSG son las opciones fiables. Ofrecen aquello en lo que se apoyan tanto Googlebot como los rastreadores de IA: contenidos completos ya en el HTML inicial. El CSR sigue teniendo sentido para áreas muy interactivas con inicio de sesión, pero no debería aplicarse a contenidos clave que tengan que poder encontrarse públicamente.

Next.js en la práctica

Next.js es un framework muy extendido para aplicaciones en las que el SEO es crítico. El análisis de Vercel, la empresa detrás de Next.js, y MERJ muestra que Googlebot renderizó por completo las páginas Next.js analizadas (internacional). Lo decisivo es cómo se usa el framework.

El App Router con React Server Components permite renderizar los contenidos en el servidor por defecto y entregar como componentes de cliente solo las partes realmente interactivas. SSG e Incremental Static Regeneration generan HTML estático que se actualiza en segundo plano cuando hace falta, sin rehacer el build completo. El streaming entrega los contenidos de forma progresiva, mientras que la hidratación hace interactiva en el navegador la página entregada de forma estática. Para el SEO rige una regla: todo lo que deba indexarse o ser citado por sistemas de IA pertenece al HTML renderizado en el servidor, no a zonas que se cargan después en el cliente.

Buenas prácticas: llevar los contenidos al HTML inicial

El JavaScript SEO funciona cuando los elementos decisivos ya están en el HTML en bruto antes de que se ejecute JavaScript. Las palancas más importantes:

• Renderizar los contenidos clave en el servidor: Los textos, los datos de producto y todos los contenidos que deban posicionar o ser citados tienen que verse sin ejecutar JavaScript. Así también te cubres frente a los rastreadores de IA que no renderizan.
• Enlaces como anclas HTML reales: La navegación y los enlaces internos deben ir en etiquetas de anclaje normales con atributo href. Los controladores de clic generados con JavaScript sin un enlace real a menudo no se reconocen durante el rastreo como rutas que se puedan seguir.
• Definir canonical y meta robots en el servidor: Las etiquetas canonical y las directivas como noindex deben estar en el HTML inicial. Si se inyectan después mediante JavaScript, Google puede procesar en la primera oleada una directiva incorrecta o ninguna.
• Entregar el título y la meta description sin JavaScript: Estos elementos, relevantes para el snippet, no deberían aparecer solo después del renderizado, porque de lo contrario se recogen de forma inconsistente.
• Usar el lazy loading de forma controlada: Es posible que el rastreador no vea los contenidos que solo se cargan al hacer scroll. Los contenidos importantes deberían estar disponibles sin interacción del usuario.

Un análisis del Web Almanac muestra la relevancia de esta disciplina: en las páginas de inicio de escritorio, la mediana de palabras visibles tras el renderizado es de 400 palabras frente a 330 en el HTML en bruto, una diferencia del 17,5 % (internacional). Es decir, una parte considerable del contenido solo surge mediante JavaScript. En las páginas que dependen por completo del renderizado, justo esa parte llega a la indexación con retraso o no llega, y queda totalmente invisible para los rastreadores de IA que no renderizan.

Datos estructurados en entornos JavaScript

Los datos estructurados en formato JSON-LD son la base de los resultados enriquecidos y una señal importante para que la IA descubra tus contenidos. En entornos con mucho JavaScript se plantea si el marcado está en el HTML desde el servidor o si se inyecta después mediante JavaScript. La práctica es clara: según el Web Almanac, la mayoría de los sitios ofrecen los datos estructurados en el HTML en bruto, y solo el 2 % de los rastreos móviles y de escritorio añaden datos estructurados mediante JavaScript (internacional).

El JSON-LD entregado desde el servidor está disponible al instante, no depende de la cola de renderizado y también lo pueden leer los rastreadores que no ejecutan JavaScript. En cambio, el marcado inyectado mediante JavaScript depende del renderizado y, por tanto, es más vulnerable. Para obtener resultados enriquecidos fiables y que los sistemas de IA te encuentren, el JSON-LD debería estar en el HTML inicial, entregado desde el servidor.

Rastreadores de IA y GEO en el contexto de JavaScript

La diferencia central entre la búsqueda clásica y la búsqueda generativa está en el renderizado. Mientras Googlebot ejecuta JavaScript, la mayoría de los rastreadores de IA solo procesan el HTML en bruto. Los contenidos que surgen exclusivamente en el cliente simplemente no existen para estos sistemas. Por eso, SSR o SSG no son un extra opcional: son un requisito para la visibilidad en IA.

El volumen de estos rastreadores es considerable. Según Cloudflare Radar, en 2025 los bots de IA (sin contar Googlebot) generaron de media el 4,2 % de todas las peticiones HTML, y Googlebot por sí solo el 4,5 % (internacional). Entre los bots verificados, Googlebot, con más del 28 %, quedó claramente por delante de GPTBot, con alrededor del 7,5 %. La mayor parte del rastreo de IA sirve para entrenar modelos. En el pico, el rastreo para entrenamiento fue entre siete y ocho veces mayor que el que hacen los proveedores de IA para sus propias funciones de búsqueda. Estos bots recogen contenidos de forma masiva, y recogen lo que está en el HTML.

De ahí se derivan medidas concretas para la gestión de los rastreadores de IA. Con el archivo robots.txt puedes controlar qué rastreadores de IA, como GPTBot o ClaudeBot, tienen acceso. Si quieres aparecer como fuente en las respuestas de IA, no deberías bloquear los bots relevantes y, al mismo tiempo, debes asegurarte de que los contenidos estén disponibles desde el servidor. IndexNow lo complementa informando activamente a los buscadores participantes sobre URLs nuevas o modificadas, lo que acelera el descubrimiento y atenúa las desventajas estructurales del renderizado en el cliente a la hora de que te encuentren.

Presupuesto de rastreo, sitemaps e indexación rápida

Como JavaScript ralentiza el rastreo, ganan peso las medidas que garantizan que los contenidos se encuentren con independencia del renderizado. Los sitemaps XML actualizados son aquí la herramienta más importante. Enumeran de forma explícita todas las URLs relevantes y hacen que Google encuentre las páginas nuevas aunque los enlaces internos solo se generen mediante JavaScript. En las páginas renderizadas en el cliente, cuyos enlaces Google solo ve después del renderizado, un sitemap completo reduce así de forma notable la desventaja en el descubrimiento.

El trasfondo es el problema del presupuesto de rastreo mencionado antes: el factor de aproximadamente nueve en el tiempo de rastreo de JavaScript frente a HTML (internacional) significa que cada dependencia evitable del renderizado ahorra presupuesto. Aquí suman fuerzas los sitemaps limpios, una estructura plana y accesible, los enlaces generados en el servidor y la renuncia al JavaScript innecesario.

Core Web Vitals en páginas con mucho JavaScript

JavaScript es una de las principales causas de unas Core Web Vitals flojas. Hay tres palancas clave:

• LCP (Largest Contentful Paint): Un bundle voluminoso y el JavaScript que bloquea el renderizado retrasan el contenido visible más grande. El code splitting, es decir, dividir el JavaScript en paquetes más pequeños, y entregar el contenido principal desde el servidor mejoran el LCP.
• INP (Interaction to Next Paint): Esta métrica mide la rapidez de respuesta a las interacciones. Una hidratación costosa y las tareas largas de JavaScript bloquean el hilo principal y empeoran el INP. Ayudan reducir el JavaScript en el cliente y dividir las tareas largas.
• CLS (Cumulative Layout Shift): Los contenidos que se cargan después mediante JavaScript y desplazan el diseño aumentan el CLS. Reservar espacio para los elementos que se cargan después mantiene estable el diseño.

Hay dos temas transversales: el JavaScript no utilizado y los scripts de terceros. Cada script cargado cuesta rendimiento y tiempo de renderizado, también a Googlebot. Eliminar de forma sistemática el código no utilizado y reducir los scripts externos beneficia directamente a las tres métricas.

RGPD, gestión del consentimiento y renderizado en Europa

En Europa se suma una particularidad: los banners de consentimiento y la carga de etiquetas asociada. Muchos scripts de seguimiento y marketing solo se cargan tras el consentimiento a través de un gestor de consentimiento, y estos funcionan en el cliente mediante JavaScript. Esto afecta al JavaScript SEO en dos puntos.

Primero, la cantidad de scripts que se cargan después influye en el rendimiento y, con ello, en las Core Web Vitals. Segundo, la gestión del consentimiento no debe obstaculizar la indexación. Googlebot no acepta cookies ni cierra banners. Es posible que el rastreador no vea los contenidos que solo aparecen después de dar el consentimiento. La consecuencia está clara: el contenido real de la página debe estar disponible desde el servidor con independencia del estado del consentimiento, y los banners de consentimiento y los scripts opcionales no pueden bloquear el renderizado del contenido principal. Así se compaginan el cumplimiento del RGPD y la indexabilidad.

Pruebas, depuración y medición

El JavaScript SEO no se puede evaluar a ojo: hay que comprobarlo comparando el HTML en bruto con el renderizado. Los pasos de verificación más importantes:

• Inspección de URLs en Search Console: Muestra el HTML que Google ha renderizado realmente para una URL indexada. Aquí compruebas si los contenidos clave, la etiqueta canonical y las meta robots aparecen en el resultado renderizado.
• Comparar el HTML en bruto con el renderizado: Comprueba si los contenidos visibles en el navegador coinciden con el código fuente en bruto. Las grandes diferencias son una señal de alarma de contenidos que dependen del renderizado.
• Prueba de resultados enriquecidos: Comprueba si los datos estructurados se reconocen correctamente, también cuando se entregan mediante JavaScript.
• Lighthouse y CrUX: Aportan datos de laboratorio y de campo sobre las Core Web Vitals y sacan a la luz problemas de rendimiento causados por JavaScript.
• Análisis de logs: Muestra con qué frecuencia y con qué retraso Googlebot rastrea y renderiza las páginas, y revela cuellos de botella en el presupuesto de rastreo.

Como referencia para el retraso sirve el orden de magnitud documentado: el rango que va de una mediana de 10 segundos a un percentil 90 de unas tres horas (internacional) muestra lo distinta que es la velocidad a la que se indexan los contenidos renderizados. Si ves valores atípicos llamativos en los logs, tienes un objetivo de optimización concreto.

Más información y conclusión

El JavaScript SEO decide si los sitios web modernos basados en JavaScript despliegan todo su potencial de visibilidad o si sus contenidos se recogen con retraso, de forma incompleta o no se recogen en absoluto. Googlebot renderiza de forma fiable, pero con retraso y con un alto esfuerzo de rastreo, y la mayoría de los rastreadores de IA no renderizan nada. La respuesta es llevar los contenidos clave, los enlaces, la etiqueta canonical, las meta robots y el JSON-LD al HTML inicial desde el servidor, idealmente mediante SSR o SSG, por ejemplo con Next.js.

Los siguientes pasos lógicos son una inspección de URLs de las páginas más importantes para comparar el HTML en bruto con el renderizado, una revisión de la estrategia de renderizado para los contenidos relevantes para el ranking y la IA, un sitemap XML actualizado para acelerar el descubrimiento y una configuración de consentimiento que deje el contenido principal accesible para Googlebot. Así, la búsqueda clásica y la visibilidad en IA se apoyan en la misma base, disponible desde el servidor.