¿La IA renderiza JavaScript?

#Los asistentes de IA ejecutan JavaScript

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.

#Cómo se hizo la prueba de renderizado JavaScript con IA

La prueba, realizada por Andre Alpar y publicada en junio de 2026 en Search Engine World, 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, y no aparecía en ningún lugar del HTML ni del código del script. Cada uno de los doce asistentes recibió su propia URL, sin enlaces desde ningún sitio e imposible de adivinar, de modo que cada visita al servidor podía atribuirse a un solo asistente, 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.

La obtención la desencadenaba el usuario. Alpar pegó cada URL a mano en el chat y pidió al asistente que resumiera la página e indicara el número de referencia interno. La prueba mide, por tanto, lo que ocurre cuando una persona le pasa un enlace a un asistente, no lo que hace un crawler en segundo plano con su propio calendario. El autor nombra los límites él mismo: es “una prueba de una sola pasada y obtención en vivo: un prompt por asistente, capturado en un único momento”, y los crawlers en segundo plano como GPTBot y ClaudeBot “bien pueden comportarse de otra manera” (traducción propia). Conviene leer el resultado como una instantánea nítida de la ruta de respuesta en vivo en junio de 2026, no como una propiedad permanente de cada producto.

#Qué asistentes de IA leen solo el HTML en bruto

En la prueba de Alpar, 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.

Tres detalles de los logs del servidor afinan el cuadro. Entre los sistemas estadounidenses que no renderizaron, Microsoft Copilot fue el único que descargó el archivo JavaScript, a través del scraper externo Diffbot, pero nunca hizo la llamada posterior para obtener el número y devolvió el señuelo. Gemini, que Alpar califica de sorpresa por venir de Google, tampoco renderizó. La respuesta de Perplexity afirmó que no podía acceder a la página, aunque su crawler la había obtenido con un HTTP 200. De ahí el consejo de Alpar: confía en el log del servidor, nunca en el relato del chatbot sobre lo que hizo.

Glenn Gabe, de GSQi, repitió la pregunta en cinco plataformas y publicó el resultado el 19 de octubre de 2026. ChatGPT, Claude y Perplexity suspendieron las tres pruebas. Gemini y Copilot aprobaron las dos primeras: una página cuyo contenido se carga entero con JavaScript y una página con cabecera y pie estáticos, pero contenido en JavaScript. En la tercera, un sitio con efecto parallax construido sobre WebGL, Gemini leyó el contenido y Copilot no. Gabe lo explica sin rodeos: “Gemini se apoya en los sistemas de búsqueda de Google, así que puede ver contenido renderizado mediante JavaScript” (traducción propia). El acierto de Copilot lo atribuye del mismo modo a los sistemas de búsqueda de Bing.

Los dos resultados pueden ser ciertos a la vez. Alpar dio a cada asistente una URL nueva, sin enlaces desde ningún sitio, que ningún buscador tenía indexada, así que Gemini y Copilot tuvieron que obtener el HTML en bruto como los demás. Gabe probó sitios existentes que Google y Bing ya conocían, de modo que Gemini y Copilot podían recurrir a la versión renderizada por el buscador. Para una página nueva, hasta que un buscador la renderice, vale el resultado de junio. ChatGPT, Claude y Perplexity leyeron solo el HTML en ambas pruebas.

#Qué asistentes de IA sí renderizan 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 DeepSeek de esta lista es el chat. Suganthan Mohanadasan probó otra vía de la misma empresa, la Fetch API del buscador de DeepSeek, y describió la prueba el 19 de octubre de 2026. En la prueba de renderizado, el fetcher cargó el CSS, pero no ejecutó JavaScript, no cargó imágenes ni disparó el beacon XHR, así que el contenido que necesitaba el script no apareció en el resultado. Se identificó como Firefox/149.0 desde la red AS136907 (Huawei Cloud, Hong Kong), sin nada que nombrara a DeepSeek, y obtuvo URLs bloqueadas en robots.txt. La prueba entera, 110 llamadas, costó unos 0,08 USD. El chat de DeepSeek y su API para obtener páginas son sencillamente dos caminos distintos hasta tu HTML, y en estas pruebas solo el chat ejecutó el script.

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 en una obtención en vivo, y Gemini y Copilot solo ven el contenido en JavaScript a través del índice de su buscador. 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.

#Qué encontró el estudio de Vercel sobre los crawlers de IA y JavaScript

La prueba de junio de 2026 no es la primera medición que apunta en esta dirección. En diciembre de 2024, Vercel, junto con MERJ, publicó un análisis del tráfico de crawlers de IA en su red y concluyó que “ninguno de los principales crawlers de IA renderiza JavaScript en la actualidad” (traducción propia). ChatGPT y Claude sí solicitaban archivos JavaScript, el 11,50% y el 23,84% de sus peticiones respectivamente, pero no los ejecutaban. En el mes medido, GPTBot hizo 569 millones de peticiones, Claude 370 millones y PerplexityBot 24,4 millones, frente a 4.500 millones de Googlebot sumando Gemini y la búsqueda. ChatGPT dedicó el 34,82% de sus peticiones a páginas 404 y Claude el 34,16%.

Vercel citó dos crawlers que sí renderizan: AppleBot, mediante un crawler basado en navegador parecido a Googlebot, y Gemini, porque usa la infraestructura de Googlebot. Ese segundo punto choca con el resultado de Alpar de 2026, en el que Gemini devolvió el señuelo. Las dos mediciones miran rutas distintas, el rastreo en segundo plano en la red de Vercel frente a una obtención en vivo provocada por el prompt de un usuario, y esa diferencia es la lección: que Google renderice tu página para su índice dice poco sobre lo que Gemini lee mientras responde a una pregunta. La recomendación de Vercel coincide con el resto de este artículo: renderiza en el servidor el contenido principal, la metainformación y la navegación, y deja el renderizado en el cliente para las funciones que solo enriquecen la página.

#Renderiza Google JavaScript igual que los asistentes de IA

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é dice la documentación de Google sobre SEO y JavaScript

Google describe su propio proceso en los conceptos básicos de SEO para JavaScript: las aplicaciones web con JavaScript pasan por tres fases, rastreo, renderizado e indexación. Las páginas esperan en una cola de renderizado antes de que un Chromium sin interfaz ejecute su JavaScript, y Google indica que una página “puede permanecer en esta cola unos segundos, pero puede tardar más” (traducción propia). La misma página sigue recomendando el renderizado en el servidor o el prerenderizado, porque es más rápido para usuarios y crawlers y porque “no todos los bots pueden ejecutar JavaScript” (traducción propia).

Esa frase es el puente hacia los asistentes de IA. Google explica que se puede generar JSON-LD con JavaScript e inyectarlo en la página, y Googlebot lo lee tras el paso de renderizado. Alpar probó un número en texto visible, no datos estructurados, pero el schema inyectado por un script llega a un asistente por el mismo mecanismo, así que un asistente que nunca ejecuta el script nunca lo ve. La documentación de Google está escrita para Googlebot. La capa de respuestas de IA es el caso de “no todos los bots”.

La página de Google sobre renderizado dinámico, actualizada por última vez el 10 de diciembre de 2025, descarta el atajo de detectar bots y servirles una copia renderizada en el servidor mientras los usuarios reciben la versión renderizada en el navegador. Google lo llama una solución provisional y no lo recomienda, porque añade complejidad y exige más recursos, y propone en su lugar el renderizado en el servidor, el renderizado estático o la hidratación. El prerenderizado en tiempo de compilación, descrito más abajo, entra en el renderizado estático, así que todos los clientes, bots o navegadores, reciben el mismo HTML.

#Problemas de renderizado JavaScript que ocultan contenido a la IA

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.

#Cómo hacer que la IA lea tu contenido JavaScript

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.

#Qué user agents usan los asistentes de IA para obtener páginas

Los proveedores documentan agentes distintos para entrenamiento, indexación de búsqueda y obtenciones desencadenadas por el usuario, y las reglas de robots.txt difieren entre ellos:

• OpenAI: GPTBot rastrea contenido que puede usarse para entrenar modelos fundacionales, OAI-SearchBot decide si un sitio puede aparecer en las respuestas de búsqueda de ChatGPT, y ChatGPT-User obtiene páginas para acciones del usuario. ChatGPT-User no se usa para rastrear la web de forma automática y, como sus acciones las inicia el usuario, puede que las reglas de robots.txt no se apliquen. Cada ajuste es independiente, y OpenAI indica que un cambio en robots.txt puede tardar unas 24 horas en llegar a los resultados de búsqueda.
• Anthropic: ClaudeBot recopila datos de entrenamiento, Claude-SearchBot indexa para mejorar la calidad de la búsqueda, y Claude-User obtiene páginas cuando una persona le hace una pregunta a Claude. Anthropic afirma que sus bots respetan robots.txt y publica la lista de IP de sus crawlers.
• Perplexity: PerplexityBot muestra sitios en la búsqueda de Perplexity y no se usa para entrenar modelos. Perplexity-User da soporte a acciones del usuario y, como la obtención la pidió un usuario, por lo general ignora robots.txt.
• Google: Google-Extended es un token de producto para robots.txt, no un crawler aparte. Controla el uso para el entrenamiento de Gemini y para el grounding, no tiene user agent HTTP propio y no afecta a la inclusión ni al posicionamiento en la búsqueda de Google.

Ninguna de estas páginas promete renderizar JavaScript. En un segundo experimento, sobre robots.txt, Alpar comprobó que solo 3 de 12 asistentes dejaron en paz una URL bloqueada: ChatGPT como ChatGPT-User, Claude como Claude-User y Perplexity como Perplexity-User. Gemini llegó con un user agent pelado, “Google”, Copilot a través de Diffbot con una cadena de Chrome corriente, y Grok, DeepSeek, Qwen y Kimi con user agents de navegador falsificados. La consecuencia práctica para el renderizado: no puedes entregar de forma fiable una versión prerenderizada especial a los asistentes de IA detectando el user agent, así que el HTML que reciben todos tiene que llevar los datos.

#Cómo sirve WordPress contenido a la IA sin JavaScript

Un tema clásico de WordPress está del lado seguro por defecto: PHP construye la página en el servidor, así que las entradas, las descripciones de producto y los precios de la base de datos están en el HTML antes de que se ejecute cualquier script. El riesgo aparece cuando el contenido pasa a widgets del lado del cliente, a bloques que obtienen datos por la REST API después de la carga o a un frontend headless que solo renderiza en el navegador.

Para la interactividad, WordPress tiene una respuesta que mantiene el contenido en el servidor. La Interactivity API, introducida en WordPress 6.5, usa directivas en el marcado de un bloque, y su procesamiento de directivas en el servidor permite a WordPress generar el HTML inicial con el estado correcto. La función wp_interactivity_process_directives localiza las directivas y usa la HTML API para reescribir el marcado a partir del estado inicial y el contexto. En el ejemplo de la documentación, una lista construida con data-wp-each y data-wp-text sale del servidor como elementos de lista normales, con los nombres de las frutas ya escritos y sin directivas. La página llega completa, el JavaScript añade el comportamiento después y un asistente que lee el HTML en bruto ve la misma lista que un visitante. La documentación da el motivo con sus palabras: el enfoque conserva “las ventajas de SEO y rendimiento del renderizado tradicional de WordPress en el servidor” (traducción propia).

#HTML estático con Astro y visibilidad en IA

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.

#Renderizado en el servidor y en el cliente explicado

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.
• Prerenderizado - ejecutar una aplicación de cliente en tiempo de build para capturar su estado inicial como HTML estático, según la definición de la guía de web.dev Rendering on the Web. La misma guía señala que los crawlers entienden JavaScript, “pero a menudo tienen limitaciones en cómo renderizan” (traducción propia).

#Conviene esperar a que la IA renderice JavaScript

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á.