JavaScript y crawlers de IA: por qué una web que solo se ve con JS puede ser invisible

Una web puede verse perfecta en el navegador y llegar casi vacía a un crawler. Ocurre cuando el texto, los enlaces o los datos importantes no están en el HTML que envía el servidor, sino que aparecen después, cuando el navegador ejecuta JavaScript. Para un usuario no hay diferencia. Para un bot que no ejecuta ese JavaScript, la página es una cáscara.

Este artículo explica qué se sabe sobre cómo tratan los crawlers de IA el JavaScript, cómo comprobar qué ve un bot en tu web y qué opciones técnicas existen.

La diferencia entre HTML inicial y HTML renderizado

Hay dos versiones de una misma página:

• HTML inicial: lo que devuelve el servidor en la primera respuesta. Es lo que ves con “Ver código fuente” en el navegador.
• HTML renderizado (DOM): lo que queda después de que el navegador ejecuta los scripts. Es lo que ves en el inspector de elementos.

En una web con renderizado en servidor, ambas versiones contienen el contenido. En una aplicación que se renderiza solo en el cliente (el patrón clásico de muchas SPA hechas con React, Vue o Angular), el HTML inicial suele ser poco más que un <div id="root"></div> y un puñado de scripts.

Qué se sabe sobre los crawlers de IA

El análisis público más citado es el de Vercel, basado en el tráfico de un mes en su red. Sus conclusiones:

Un matiz que el propio análisis señala: ChatGPT y Claude descargan archivos JavaScript (el 11,5 % y el 23,8 % de sus peticiones, respectivamente), pero no los ejecutan. Que un bot pida un .js no significa que lo interprete.

Conviene leer esos datos con cuidado:

• Es una medición de una red concreta, no una auditoría del comportamiento de cada motor, y las empresas no publican de forma sistemática si sus bots renderizan. Por eso la recomendación práctica es no depender de que lo hagan y comprobarlo en tu propia web.
• No todos los accesos son iguales. GPTBot, ClaudeBot y el resto tienen funciones distintas: unos recopilan datos para entrenamiento, otros alimentan la búsqueda y otros acuden cuando un usuario pide una página concreta.

La explicación habitual, que es una interpretación y no un dato publicado por las empresas, es que renderizar JavaScript a gran escala es caro y lento, y que un bot que consulta la web para responder en segundos no puede esperar a que cargue una aplicación.

Con Google la situación es otra. Su documentación describe un proceso en tres fases (rastreo, renderizado con un Chromium sin interfaz e indexación), aunque el renderizado puede pasar por una cola. Aun así, Google recomienda que el renderizado en servidor o el prerender siguen siendo una buena idea porque hacen la web más rápida para usuarios y crawlers.

Qué contenido se pierde si el bot no ejecuta JavaScript

No hace falta que toda la página dependa de JS para que haya un problema. Con los crawlers que no renderizan, suelen perderse:

• El texto principal, si se inyecta desde una API tras la carga.
• Los enlaces internos que no son un <a href> real (por ejemplo, un onclick que cambia la ruta). Google tiene la misma limitación: solo descubre enlaces que sean elementos <a> con atributo href.
• Los bloques que se cargan al hacer scroll o al pulsar un botón: pestañas, acordeones de FAQ o fichas de producto cargadas bajo demanda.
• Los datos estructurados añadidos con JavaScript. Google puede procesarlos, pero un crawler que no ejecuta scripts no los verá. Más sobre este punto en Schema.org y GEO.
• Los metadatos (título, descripción, canonical) generados en el cliente.
• Los precios, la disponibilidad o los datos de contacto que se pintan con scripts.

Esto enlaza con lo que ya vimos en los errores que hacen que una IA ignore una web: una web dinámica no es mala por sí misma, pero lo esencial tiene que estar disponible para quien no ejecuta la parte dinámica.

Cómo comprobar qué recibe un bot

No necesitas herramientas especiales. Tres comprobaciones, de la más rápida a la más completa:

1. Ver código fuente. En el navegador, Ctrl+U (o Cmd+Option+U en Mac). Busca una frase importante de la página. Si no aparece, no está en el HTML inicial.
2. Desactivar JavaScript. Desde las herramientas de desarrollo, desactiva JavaScript y recarga. Lo que se ve es, aproximadamente, lo que ve un crawler que no renderiza.
3. Pedir la página sin navegador. Con curl obtienes exactamente la respuesta del servidor:

curl -s https://tudominio.com/pagina | grep -i "frase importante"

Si quieres simular a un bot concreto, añade un user-agent con -A. Ten en cuenta que algunos servidores o WAF responden distinto según el user-agent, y que un bot real puede tener restricciones que curl no reproduce (por ejemplo, rangos de IP verificados). Si una comprobación con curl falla, el problema no es necesariamente JavaScript: también puede ser un bloqueo del cortafuegos o de robots.txt.

Conviene revisar al menos la home, una página de servicio o producto y un artículo. Comprueba que en el HTML inicial estén el <h1>, el texto principal, los enlaces de navegación, el título, la meta description y el JSON-LD.

Opciones técnicas

Si descubres que el contenido esencial no está en el HTML inicial, estas son las vías habituales:

Los frameworks modernos (Next.js, Nuxt, SvelteKit, Astro, Remix) permiten SSR o SSG sin renderizar toda la aplicación en el navegador. Lo que importa no es la herramienta, sino que el contenido que quieres que se lea esté en la respuesta del servidor.

Una precaución con el prerender dirigido solo a bots: servir a los crawlers un HTML distinto del que ven los usuarios puede acabar siendo cloaking si el contenido no es equivalente. Si lo usas, mantén el mismo contenido en ambas versiones.

Lo que sigue siendo JavaScript sin problema

No se trata de eliminar JavaScript. Todo lo que mejora la experiencia sin ser contenido esencial puede seguir en el cliente: filtros, comparadores, animaciones, chats, formularios interactivos o paneles. La regla de trabajo es sencilla: si una persona o un sistema de IA necesita leerlo para entender qué eres y qué ofreces, que esté en el HTML inicial.

Preguntas frecuentes

¿Todos los crawlers de IA ignoran JavaScript?

No hay una respuesta única. Según el análisis de Vercel, los crawlers de OpenAI, Anthropic y Perplexity no lo ejecutan, y los de Google y Apple sí. Como el comportamiento puede cambiar sin aviso, lo prudente es no depender de ello.

Si Google indexa mi web, ¿también la verán ChatGPT o Claude?

No necesariamente. Que Googlebot renderice tu aplicación no implica que otros bots hagan lo mismo. Son sistemas distintos con prioridades distintas.

¿Es suficiente con tener un sitemap?

Un sitemap ayuda a descubrir URLs, pero no resuelve que el contenido de cada URL llegue vacío.

¿Cómo sé si mi web tiene este problema sin revisar página por página?

Una auditoría automatizada puede comparar el HTML inicial con el contenido visible y señalar páginas con poco texto sin JavaScript. Análisis GEO incluye comprobaciones de este tipo en su diagnóstico técnico gratuito, pero la verificación manual con los pasos de arriba te da la misma información para páginas concretas.

Resumen

• Según los datos públicos disponibles, algunos crawlers de IA no ejecutan JavaScript. Googlebot sí lo hace.
• Si el contenido solo existe tras ejecutar scripts, esos bots pueden recibir una página casi vacía.
• Comprueba tu web con “Ver código fuente”, con JavaScript desactivado o con curl.
• Si falta contenido esencial, usa SSR, SSG o prerender. El resto de interactividad puede seguir en el cliente.
• Después de esta revisión, el checklist práctico de GEO te ayuda a ordenar el resto de mejoras.

Fuentes: Vercel, “The rise of the AI crawler” (17/12/2024) · Google Search Central, “JavaScript SEO basics” · OpenAI, documentación de sus crawlers