Lo que la prueba demostró realmente
En junio de 2026 alguien por fin hizo el experimento limpio en lugar de adivinar. El resultado: seis de siete de los principales asistentes de IA occidentales no ejecutan tu JavaScript cuando obtienen una página para fundamentar una respuesta. Leen el HTML en bruto y nada más. Si los datos que necesita un cliente, tu precio, tu especificación, la descripción de tu servicio, solo aparecen después de que se ejecute el JavaScript del lado del cliente, esos asistentes no los pueden ver. Para la capa de respuesta de IA, ese contenido no existe.
Para los ingenieros de búsqueda esto no es una idea nueva, pero hasta ahora era argumento y no prueba. Ahora se ha probado directamente, y la prueba es incómoda para la gran clase de sitios construidos como aplicaciones JavaScript que ensamblan su contenido en el navegador.
El experimento, en un párrafo
La prueba, realizada por Andre Alpar y publicada a través de CitationOne, fue simple y difícil de engañar. La página servía un número de referencia señuelo en el HTML en bruto. El número real solo lo sustituía un JavaScript externo, obtenido de un segundo endpoint. Cada asistente recibió una URL única e imposible de adivinar, y el servidor registró tres eventos por separado: la obtención de la página, la obtención del archivo JavaScript y la llamada al endpoint del número. La lógica es a prueba de errores. Devolver el número real significa que ejecutaste el script. Devolver el señuelo significa que leíste solo el HTML.
Quién leyó solo el HTML
Estos asistentes devolvieron el señuelo, es decir, basaron el grounding en el HTML en bruto y nunca ejecutaron el script:
- ChatGPT
- Claude
- Gemini
- Perplexity
- Meta AI
- Microsoft Copilot
Grok ejecutó el JavaScript en un nodo, pero aun así devolvió el señuelo, así que incluso donde el script se ejecutó, el valor renderizado no llegó a la respuesta.
Quién sí renderizó JavaScript
Cinco asistentes devolvieron el número real, demostrando que ejecutaron el script:
- DeepSeek, ERNIE, Qwen y Kimi, todos de China
- Mistral, de Europa
El renderizado de JS por la IA está ocurriendo de verdad. Lo que pasa es que, para los grandes asistentes occidentales que de verdad importan a las empresas europeas, es la excepción. La división es lo bastante nítida como para planificar en torno a ella: construye para los asistentes que usan tus clientes, y hoy esos leen HTML.
”Pero Google renderiza JavaScript”
Esta es la objeción que descarrila toda la conversación, así que enfréntala de frente. Sí, Googlebot renderiza JavaScript para el índice de búsqueda clásico. Eso es un pipeline distinto del grounding de las respuestas de IA, y la prueba trata del segundo. Una página puede posicionar perfectamente en la búsqueda clásica de Google con contenido que solo existe después de ejecutar JavaScript, y aun así ser invisible cuando ChatGPT o Perplexity la obtienen para componer una respuesta. Tomar “Google renderiza JS” como prueba de que “la IA renderiza JS” es el error. Los dos sistemas se comportan de forma distinta, y es justo en esa brecha donde la visibilidad en IA se escapa en silencio.
Qué rompe esto en la práctica
El riesgo se concentra en un conjunto reconocible de patrones:
- Aplicaciones single-page que envían una cáscara de HTML casi vacía y ensamblan la página en el navegador.
- Precios, estado de stock o especificaciones inyectados por JavaScript desde una API tras la carga.
- Contenido escondido tras pestañas, acordeones o “cargar más” del lado del cliente, que solo se obtiene en la interacción.
- Descripciones de productos o servicios renderizadas por un framework del cliente sin alternativa en el servidor.
- Reseñas, valoraciones y widgets de FAQ incrustados como JavaScript de terceros.
Si alguno de ellos lleva los datos que quieres que una IA repita, estás apostando tu visibilidad en IA a un comportamiento de renderizado en el que seis de siete asistentes occidentales acaban de fallar.
La solución aburrida, ahora confirmada para la IA
El remedio es la regla que el SEO clásico repite desde hace una década: pon los datos esenciales en HTML renderizado en el servidor. La generación de sitios estáticos y el renderizado en el servidor la cumplen ambos. El framework no importa, lo que importa es dónde se ensambla el HTML. Renderiza el contenido en el servidor, sírvelo en la primera respuesta y deja que el JavaScript lo enriquezca en lugar de proporcionarlo.
Puedes comprobar tu propio sitio en un minuto. Obtén una página sin navegador y lee lo que vuelve:
curl -s https://tu-sitio.example/tu-pagina/ | less
Si los encabezados, el texto, los precios, las especificaciones y el Schema.org JSON-LD están todos en esa respuesta en bruto, los asistentes de IA pueden leerlos. Si la página es una cáscara fina que se rellena después de ejecutar el script, ese es tu problema, y ahora lo puedes ver.
Cómo lo gestiona nuestro propio stack
Aquí no somos neutrales, porque hicimos esta apuesta a propósito. wppoland.com funciona con Astro, que renderiza las páginas a HTML estático en tiempo de build y las sirve desde el edge. Todo lo que importa está en la respuesta en bruto: el texto, cada encabezado, las FAQ y el Schema.org JSON-LD. Lo comprobamos igual que la prueba, leyendo el HTML en bruto en lugar de la página renderizada, y el contenido está todo ahí antes de que se ejecute una sola línea de nuestro JavaScript. El JavaScript en nuestras páginas es enriquecimiento, nunca la fuente del contenido.
Es la misma conclusión a la que llegamos por el camino largo en servir contenido a agentes de IA: HTML limpio, renderizado en el servidor y semántico, más Schema, es la única señal que tanto los crawlers clásicos como los sistemas de IA consumen de verdad. Esta prueba es la evidencia más limpia hasta hoy a favor de esa postura. Es también el motivo por el que un programa de GEO y LLMO tiene que empezar por cómo se renderiza la página, y no por metadatos ingeniosos, porque los metadatos que un asistente nunca ejecuta son metadatos que nunca lee.
Glosario
Para lectores que dirigen un negocio y no un pipeline de build:
- Renderizado en el servidor / generación estática - el HTML de la página se ensambla en el servidor (o en tiempo de build) y llega completo en la primera respuesta.
- Renderizado en el cliente - el servidor envía una cáscara casi vacía, y el JavaScript del navegador construye la página después.
- Grounding - cuando un asistente de IA obtiene páginas reales para fundamentar una respuesta en datos y no en la memoria.
- Hidratación - JavaScript que añade interactividad a HTML ya renderizado; seguro, porque el contenido estaba ahí primero.
La conclusión honesta
El renderizado de JavaScript por los asistentes de IA probablemente mejore con el tiempo, y los asistentes chinos más Mistral demuestran que técnicamente es rutina. Pero no puedes publicar para los asistentes que desearías que existieran. Publicas para los que usan tus clientes, y en junio de 2026 los mayores asistentes occidentales leen HTML en bruto y se detienen ahí. La respuesta segura, aburrida y con una década de antigüedad resulta ser la correcta también para la IA: sirve tus datos en HTML que el servidor ya ha renderizado, y trata todo lo que solo aparece después del JavaScript como contenido que la IA no verá.

