Los bots de IA no ejecutan JavaScript: por qué tu web es invisible para ChatGPT

Hay un mito cómodo que conviene romper ya: "si Google me indexa, la IA me lee". Falso. Google renderiza JavaScript. Los bots de IA no. Son dos infraestructuras distintas con dos capacidades distintas, y la mayoría de webs modernas están construidas para la primera, no para la segunda. Este artículo es técnico, con el test que puedes hacer tú solo en 2 minutos y la solución concreta por framework.

El experimento: pídele a ChatGPT que resuma tu web y mira qué ve

Respuesta directa: si le pides a ChatGPT (o Perplexity) que resuma tu web y te devuelve algo genérico, vacío o inventado, es probable que esté viendo un HTML en blanco. Haz la prueba antes de seguir leyendo.

• Abre ChatGPT con búsqueda activada y escribe: "Resume qué ofrece [tu-dominio.com] y sus servicios".
• Abre Perplexity y pregunta lo mismo. Fíjate en las fuentes que cita.
• Compara lo que dicen con lo que realmente pone tu web. ¿Coincide? ¿O se lo está inventando a partir del title y poco más?
• Ahora el test crudo: en tu navegador pulsa Ctrl+U (ver código fuente). Busca (Ctrl+F) una frase de tu página. Si no aparece en el código fuente, tampoco existe para el bot de IA.

Este es el patrón que vemos una y otra vez auditando webs: negocios con producto excelente que la IA describe mal o directamente omite, porque su contenido vive en JavaScript. La IA no busca, valida. Y no puede validar lo que no lee. Para entender el porqué de fondo, la guía completa de posicionamiento en IA pone el contexto estratégico.

Por qué Google sí renderiza JavaScript y los bots de IA no

Respuesta directa: Google mantiene una cola de renderizado secundaria con un motor Chromium headless que ejecuta tu JavaScript horas o días después del primer rastreo. Los bots de IA no tienen esa segunda pasada: hacen una sola petición HTTP, leen el HTML que llega y terminan.

Google rastrea en dos olas. Primero descarga el HTML. Luego, cuando hay presupuesto de renderizado, pasa la página por su Web Rendering Service, que sí ejecuta JS, espera a que el DOM se pinte y entonces indexa el resultado final. Es caro y lento, pero existe.

GPTBot, ClaudeBot y PerplexityBot no hacen eso. Según el análisis de rastreadores de IA de Vercel, GPTBot descarga archivos JavaScript en torno al 11,5% de sus peticiones y ClaudeBot alrededor del 24%, pero ninguno de los dos los ejecuta. PerplexityBot directamente parsea HTML estático. Descargar el fichero .js no es lo mismo que correrlo: sin ejecución, tu React nunca monta el contenido. El bot ve el esqueleto vacío y se marcha.

CSR vs SSR vs SSG explicado para un bot sin JavaScript

Respuesta directa: lo único que importa para un bot de IA es qué hay en el HTML de la primera respuesta del servidor. CSR entrega un contenedor vacío. SSR y SSG entregan el contenido ya escrito. Esa es toda la diferencia.

CSR (Client-Side Rendering) significa que el servidor manda un HTML casi vacío y el navegador construye la página con JavaScript. Perfecto para una app tras login. Suicida para el contenido público que quieres que la IA cite. SSR y SSG (Server-Side Rendering y Static Site Generation) resuelven el problema porque el contenido ya viaja escrito en la respuesta.

Cómo saber si tu web es invisible para los bots de IA en 2 minutos

Respuesta directa: compara el código fuente (lo que ve el bot) con el inspector (lo que ve el navegador). Si tu contenido está en el inspector pero no en el código fuente, eres invisible para los bots de IA.

1. Ver código fuente: Ctrl+U (o clic derecho, "Ver código fuente de la página"). Esto es exactamente lo que recibe GPTBot.
2. Inspector: F12, pestaña Elements. Esto es el DOM ya renderizado, lo que ve el navegador tras ejecutar JS.
3. Busca en el código fuente (Ctrl+F) un párrafo real de tu contenido. Si está, bien. Si no está pero sí aparece en el inspector, tu contenido es client-side y el bot no lo lee.
4. Prueba de terminal, la definitiva: ejecuta curl -A "GPTBot" https://tu-dominio.com y lee lo que devuelve. Ese texto plano es tu web para la IA. Si sale vacío, ya tienes tu respuesta.

La solución por framework: SSR y SSG en Next.js, Astro, Nuxt y WordPress

Respuesta directa: el arreglo es servir el contenido en el HTML inicial. Cada framework tiene su interruptor, y en casi todos es una decisión de configuración, no una reescritura.

• Next.js: usa App Router con Server Components (por defecto renderizan en servidor) o el modo static export para SSG. Evita marcar de más con "use client". El contenido crítico nunca debe depender de un useEffect.
• Astro: es SSG por defecto y envía cero JS salvo que lo pidas (islands architecture). Es de los stacks más amables para bots de IA sin tocar nada.
• Nuxt (Vue): activa SSR (por defecto) o usa nuxt generate para prerenderizar a estático. Huye del modo SPA (ssr: false) en páginas de contenido.
• WordPress headless: el CMS sirve datos por API, pero tu front (a menudo Next.js) debe renderizar en servidor o pre-generar. Si tu headless acaba siendo un SPA, has recreado el problema. Un WordPress clásico ya sirve HTML completo y no tiene esta patología.
• SPA legada (Create React App, Vue CLI): si no puedes migrar, pon delante prerenderizado (prerender.io o similar) que sirva HTML estático a los bots. Es un parche, no la cura.

El principio es transversal al framework: el contenido que quieres que la IA cite tiene que estar en el HTML de la primera respuesta. Todo lo demás son detalles de implementación. Si quieres el mapa completo de la capa técnica, lo desglosamos en estrategias de AEO e implementación técnica.

El error caro: hidratar contenido crítico en el cliente

Respuesta directa: el fallo más común no es una web 100% CSR, es una web SSR bien montada que carga lo importante (precios, FAQs, descripciones) por fetch en el cliente después. Ese contenido llega tarde, y el bot ya se ha ido.

Pasa constantemente: la home renderiza en servidor, pero el bloque de precios, las opiniones o el catálogo se piden con un useEffect a una API tras cargar. En el navegador se ve todo. En el HTML crudo, esos bloques son huecos. El bot descarga el HTML, no encuentra los datos y no espera. Regla dura: si un dato es importante para que te encuentren, va en el HTML inicial, no en una llamada posterior. Nada de lazy-load para el contenido que te posiciona.

Esto conecta con algo más grande: la web accionable frente a la web legible. Los agentes de IA que ya navegan y actúan tienen la misma limitación amplificada, como explicamos en navegación agéntica: optimizar tu web para agentes de IA.

Checklist de visibilidad para bots de IA

Respuesta directa: si marcas estas siete casillas, tu contenido es legible para los bots de IA. Fállalas y da igual lo bueno que sea tu producto: el mejor producto no gana, gana el que se distribuye, y para distribuirte en la IA primero tiene que poder leerte.

• El contenido aparece en "ver código fuente" (Ctrl+U), no solo en el inspector.
• curl -A "GPTBot" devuelve tu texto real, no un shell vacío.
• Precios, FAQs y descripciones van en el HTML inicial, no en fetch de cliente.
• Usas SSR o SSG en todas las páginas públicas de contenido.
• Tu robots.txt permite GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot y Google-Extended.
• Tienes llms.txt para guiar a los modelos hacia tu contenido clave.
• Devuelves 200 (no 403) a los user-agents de los bots de IA: muchos servidores los bloquean por defecto.

Los dos últimos puntos son la otra cara de este mismo problema. Puedes tener el HTML perfecto y aun así cerrarles la puerta con la configuración del servidor. Cubrimos el detalle en robots.txt para bots de IA y el marco completo de rastreo en estrategia de indexación para bots de IA 2026.

La ventana es de meses. Ahora mismo la mayoría de tus competidores tienen exactamente este agujero y no lo saben. El que arregla su HTML primero se convierte en la fuente que la IA cita por defecto en su sector, y esa posición (Entity Authority) es difícil de desbancar una vez tomada. Haz el test de curl hoy. Si sale vacío, ya sabes por dónde empezar.

Preguntas frecuentes