Los asistentes de IA más usados en el mundo occidental, como ChatGPT, Claude, Gemini, Perplexity y Copilot, leen únicamente el HTML estático de tu página cuando hacen grounding.
El JavaScript que inyecta productos, precios o contenido crítico es invisible para ellos. Un experimento con 12 modelos y URLs trampa lo confirma mediante registros de servidor, no mediante promesas del fabricante.
¿Por qué el renderizado de JavaScript se convirtió en un problema de visibilidad?
El grounding es el proceso por el que un asistente de IA accede a una URL externa en tiempo real para basar su respuesta en el contenido actual de esa página.
Frameworks como React, Vue o Angular construyen páginas en las que el contenido significativo no existe en el HTML enviado por el servidor; el navegador lo genera después ejecutando JavaScript.
Esta brecha entre el HTML estático y el contenido renderizado no era relevante cuando el único agente no humano que accedía a las páginas era Googlebot.
El problema del renderizado de JavaScript en la búsqueda orgánica ha evolucionado y ya no afecta solo a Googlebot, sino a todos los sistemas que hacen grounding con URLs en tiempo real.
La investigación de SearchEngineWorld ofrece la primera respuesta experimental sistemática sobre cómo resuelven este problema los asistentes de IA más usados.
El diseño del experimento
SearchEngineWorld generó una URL secreta y única para cada uno de los 12 asistentes evaluados. El HTML estático de cada página mostraba un número señuelo incrustado directamente en el código fuente.
Un script externo, al ejecutarse en el cliente, consultaba un segundo servidor y sustituía ese señuelo por el valor real. La única forma de obtener el número correcto era ejecutar ese JavaScript; cualquier modelo que solo descargara el HTML obtendría el valor falso.
El prompt enviado a cada asistente era idéntico y deliberadamente neutral, con instrucción de resumir la página e informar el número de referencia interna.
El equipo validó cada respuesta contra los registros de acceso del servidor para determinar qué archivos había solicitado el modelo y cuáles había procesado.
Incluir una cadena canary única en cada URL descartaba la posibilidad de resultados correctos por coincidencia o por caché compartida.
Doce modelos evaluados, dos respuestas opuestas
Los resultados no ofrecen ambigüedad. De los doce asistentes, siete obtuvieron el valor señuelo y cinco el real. La división no siguió ningún criterio técnico observable; siguió la geografía de origen.
| Asistente | Origen | Ejecutó JavaScript | Resultado |
|---|---|---|---|
| ChatGPT | Estados Unidos | No | Valor señuelo |
| Claude | Estados Unidos | No | Valor señuelo |
| Gemini | Estados Unidos | No | Valor señuelo |
| Perplexity | Estados Unidos | No | Valor señuelo |
| Meta AI | Estados Unidos | No | Valor señuelo |
| Microsoft Copilot | Estados Unidos | No (descargó el archivo; no lo ejecutó) | Valor señuelo |
| Grok | Estados Unidos | Parcialmente (ejecutó; ignoró el resultado) | Valor señuelo |
| DeepSeek | China | Sí | Valor real |
| ERNIE (Baidu) | China | Sí | Valor real |
| Qwen (Alibaba) | China | Sí | Valor real |
| Kimi (Moonshot) | China | Sí | Valor real |
| Mistral | Europa | Sí | Valor real |
El resultado más incómodo para la optimización de contenido orientada a IA occidental es también el más claro. Los siete asistentes con sede en Estados Unidos devolvieron el valor señuelo en todos los casos, confirmando que ninguno ejecutó el JavaScript durante el grounding (SearchEngineWorld).
Los cinco modelos restantes, cuatro chinos y el europeo Mistral, obtuvieron el valor real, lo que confirma que completaron el ciclo de renderizado del lado del cliente.
Esto significa que un sitio construido con React puede ser plenamente legible para DeepSeek y completamente opaco para ChatGPT, independientemente de la calidad del contenido o de cualquier otra optimización aplicada.
Tres comportamientos que merecen análisis propio
Dentro del grupo estadounidense, tres asistentes presentaron variaciones relevantes respecto al patrón de descarga pura de HTML.
Microsoft Copilot descargó el archivo JavaScript, pero no lo ejecutó en ningún momento; el modelo accedió al código como texto plano y lo procesó sin interpretarlo como instrucciones ejecutables.
Los indicios en los registros apuntan al uso de Diffbot como pipeline de extracción de texto estático, que trata todo el contenido descargado como datos textuales independientemente de su tipo.
Grok presentó el caso más llamativo del experimento; el modelo sí ejecutó el código y sí obtuvo el valor real del segundo servidor, pero reportó el señuelo de todas formas en su respuesta.
Ya sea por un error de integración entre el motor de renderizado y el generador de respuesta o por algún mecanismo de priorización del HTML original, el resultado fue idéntico al de los modelos que no ejecutaron nada.
El patrón geográfico y sus posibles explicaciones
La coincidencia entre origen geográfico y comportamiento de renderizado es demasiado consistente para ser accidental, aunque el experimento no permite establecer la causa con certeza.
Una hipótesis apunta a diferencias de infraestructura; ejecutar JavaScript a escala requiere más recursos y tiempo de respuesta que descargar HTML estático, y los grandes modelos occidentales con volúmenes de consulta masivos podrían haber optado por esa austeridad en su pipeline de grounding.
Otra hipótesis apunta a restricciones de seguridad; ejecutar JavaScript de terceros expone al sistema a posibles exfiltraciones de datos o ejecución de código malicioso, un riesgo que sistemas con mayor exposición regulatoria habrían decidido eliminar.
Los modelos chinos, con infraestructuras propias y marcos normativos distintos, habrían tomado una decisión técnica diferente. Ninguna de estas hipótesis es verificable con los datos del experimento; lo que sí es verificable es el patrón en sí, y ese patrón es suficiente para tomar decisiones de optimización.
Lo que los modelos dicen frente a lo que los registros prueban
Perplexity declaró en su respuesta que no había podido acceder a la página. Los registros del servidor mostraron una solicitud completada con HTTP 200, confirmando que el contenido fue entregado sin problema.
El modelo recibió el HTML, no renderizó el JavaScript, obtuvo el señuelo y reportó incapacidad de acceso como justificación del dato incorrecto.
Esta combinación específica de acceso real y declaración de fallo es especialmente problemática para quien diseña estrategias de contenido basadas en lo que los asistentes reportan sobre sus propias capacidades.
Si el comportamiento declarado y el comportamiento real divergen en casos tan observables como este, la confianza en las afirmaciones de los fabricantes sobre los límites técnicos de sus sistemas debe reducirse de forma proporcional. Las instrucciones del fabricante son orientaciones; los registros del servidor son hechos.
¿Qué cambia en la arquitectura de tu contenido?
Si tu sitio utiliza un framework de renderizado en el cliente, los asistentes de IA occidentales no ven el contenido generado por ese framework cuando acceden a tu URL durante el grounding.
Los precios, fichas de producto, reseñas o cualquier dato inyectado vía JavaScript son, en la práctica, inexistentes para ChatGPT, Gemini o Claude en ese modo de acceso.
El server-side rendering resuelve el problema de raíz al garantizar que el servidor entrega el HTML completo antes de cualquier ejecución de scripts en el cliente.
El pre-rendering estático cumple la misma función a menor coste operativo para páginas que no cambian con frecuencia.
Las señales que maximizan la citación en motores generativos parten de este principio; el contenido crítico debe estar presente en el HTML estático y posicionado en los primeros segmentos de la página antes de cualquier inyección dinámica.
Cómo auditar qué ven realmente los asistentes en tu sitio
Los registros de acceso del servidor son el único método fiable para verificar qué descarga cada asistente cuando visita tus páginas. Identificar en los logs las solicitudes de los agentes de usuario registrados por cada fabricante y revisar los códigos de respuesta, los archivos solicitados y el tiempo de procesamiento asociado a cada visita.
Comparar esas solicitudes con el HTML que el servidor entrega para esa URL permite detectar con precisión si el asistente está viendo el contenido renderizado o solo el esqueleto estático.
Para sitios con frameworks de JavaScript, la prueba más directa es comparar el HTML entregado por el servidor con el contenido visible en un navegador tras la ejecución completa del código.
Cualquier diferencia entre ambas vistas es contenido invisible para los asistentes de IA occidentales, con independencia de su calidad, relevancia o autoridad temática.
Preguntas frecuentes (FAQ)
¿ChatGPT y Gemini renderizan JavaScript cuando hacen grounding en una URL?
No. Según el experimento de SearchEngineWorld, ChatGPT, Gemini, Claude, Perplexity y Meta AI descargan únicamente el HTML estático cuando acceden a una URL como fuente de grounding. El JavaScript del lado del cliente no se ejecuta, por lo que cualquier contenido inyectado por frameworks como React, Vue o Angular es invisible para estos sistemas en ese modo de acceso.
¿Qué asistentes de IA sí ejecutan JavaScript al acceder a páginas externas?
Los cuatro modelos chinos analizados en el estudio, DeepSeek, ERNIE de Baidu, Qwen de Alibaba y Kimi de Moonshot, ejecutaron el JavaScript y obtuvieron el contenido real. Mistral, con origen en Europa, también renderizó la página completa. El patrón observado divide los sistemas evaluados por geografía de origen, aunque el estudio advierte que fue una prueba realizada en un momento único y no un análisis longitudinal con múltiples repeticiones.
¿Cómo puedo verificar qué ven los asistentes de IA en mi sitio?
Revisar los registros de acceso del servidor es el método más fiable. Identificar las solicitudes de los agentes de usuario registrados por cada fabricante y verificar qué archivos descargaron en cada visita. Las respuestas de los propios asistentes sobre su comportamiento no son confiables, como demostró el caso de Perplexity en este experimento, donde el modelo reportó imposibilidad de acceso mientras el servidor registraba una entrega exitosa con HTTP 200.
¿Debo migrar a server-side rendering para mejorar mi visibilidad en IA?
La decisión depende de qué contenido necesitas que sea citable. Si los datos clave del negocio llegan al navegador vía JavaScript, esos datos son invisibles para los asistentes occidentales más usados cuando hacen grounding. El server-side rendering o el pre-rendering estático resuelven el problema de raíz. Una alternativa de implementación más rápida es asegurar que todos los elementos críticos para la citabilidad estén presentes en el HTML estático que el servidor entrega antes de cualquier ejecución de scripts.