Auxiliares de IA y Rendering de JavaScript: Lo que SEOs Necesita Arreglar
Andre Alpar probó si los asistentes de IA presentan JavaScript durante la puesta en tierra. Los resultados muestran por qué HTML crudo, registros del servidor y SSR importa para la visibilidad de la búsqueda de AI.
TL;DR: El 16 de junio de 2026, Andre Alpar publicó una prueba de registro de servidores de 12 asistentes de inteligencia artificial. Seis asistentes estadounidenses importantes (ChatGPT, Claude, Gemini, Perplejidad, Meta AI, Microsoft Copilot) respondieron a los avisos de puesta en tierra desde el decoy HTML crudo y nunca utilizaron el valor limitado por JavaScript. Cinco asistentes no estadounidenses (DeepSeek, ERNIE, Qwen, Kimi, Mistral) ejecutaron el guión y reportaron el valor renderizado. Grok corrió el JavaScript y luego respondió desde el decoy de todos modos.
El titular que debe quitar no es "los ayudantes de IA no pueden renderizar JavaScript". Es "sus registros del servidor le dirán lo que cada asistente realmente vio, y su pantalla del chatbot no lo hará".
La frase "Google puede renderizar JavaScript, así que estamos cubiertos" está haciendo mucho daño ahora mismo.
La antigua regla de JavaScript SEO era lo suficientemente simple: asegúrate de que Google pueda renderizar la página. Esa regla sigue siendo verdadera. Es sólo incompleto para la visibilidad de la búsqueda de AI.
Es verdad para Google Search. Las páginas de las colas de Googlebot, las ejecuta a través de una tubería de cromo sin cabeza, e indexa el HTML renderizado. Martin Splitt ha repetido eso récord durante años. Google es propio JavaScript SEO basics la documentación camina a través de la pista, el render, el lazo índice en detalle.
No es cierto para cada asistente de AI que agarra su página cuando un usuario lo hace una pregunta. El camino de recuperación que ChatGPT, Claude, Perplejidad, Copilot o Gemini utiliza para aterrizar una respuesta en vivo puede ser mucho más delgado que Googlebot, y la brecha puede eliminar silenciosamente su contenido de la respuesta.
Esa brecha es lo que Andre Alpar midió un experimento de Search Engine World fechada el 16 de junio de 2026. Su resultado es sobrio, pero la metodología es la parte SEOs debe copiar.
Logros del servidor Beat Chatbot Auto-Informes
Antes de la mecánica de prueba, la lección principal.
En la carrera de Alpar, Perplexity dijo al usuario en chat que no podía acceder a la URL de prueba. El registro del servidor mostró PerplexityBot recogió esa URL exacta y recibió HTTP 200. El rastreador hizo el trabajo. La capa de chat dijo lo contrario.
Ese único desajuste debe cambiar cómo depurar la visibilidad de AI este trimestre.
Si sólo prueba a los asistentes de inteligencia artificial instándoles y leyendo la respuesta, está dejando que el modelo autodescriba su comportamiento. Eso no es evidencia. Es una suposición.
El artefacto confiable es el registro de solicitud en su origen: la URL, el agente de usuario, el código de estado, el tamaño de la respuesta, el tiempo, y si el asistente más tarde citó la página con precisión. Todo lo demás es evidencia más débil.
Ese principio, "confiar el registro, no el chatbot", es el retiro real de esta prueba. El resultado es el gancho de noticias. El resultado de la confianza es la solución operacional.
Cómo funciona la prueba de Decoy
Alpar construyó una página de tres capas para cada uno de los 12 asistentes.
- Una URL secreta que el asistente nunca había visto antes.
- Un valor decoy escrito directamente en el HTML crudo.
- Un archivo JavaScript externo que, cuando se ejecutó, obtuvo un segundo punto final y reemplazó el decoy con el valor real.
La parte inteligente del diseño es el segundo punto final. La respuesta real no estaba sentada en la respuesta HTML. Tampoco fue visible al leer el archivo JavaScript como texto. Para ver el verdadero valor, un sistema tenía que ejecutar el script y hacer una solicitud de seguimiento. Eso divide limpiamente tres comportamientos que se conflan en la mayoría de los debates "does AI render JS":
- ¿El asistente hizo la página HTML?
- ¿El asistente ha conseguido el archivo JavaScript enlazado?
- ¿El asistente ejecutó el JavaScript y utilizó el valor resultante?
Un bot puede hacer el paso uno y parar. Puede hacer pasos uno y dos e ignorar el resultado. Sólo el punto final de ejecución demuestra que el DOM entregado fue realmente consumido. El registro del servidor captó las tres señales a la vez.
Resultado: Seis asistentes estadounidenses importantes se detuvieron en HTML bruto
Así se comportaron los 12 asistentes en la prueba.
| Comportamiento en la prueba | Assistants | Lo que esto significa para tu contenido |
|---|---|---|
| Ejecutado JavaScript y reportado el valor renderizado | DeepSeek, ERNIE, Qwen, Kimi, Mistral | Estos oleoductos vieron el valor que sólo existía después de la ejecución del script. |
| Ejecutado JavaScript pero aún contestado desde el HTML crudo | Grok | Un subsistema alcanzó el punto final de ejecución, pero la respuesta usó el decoy. |
| Respuestas desde HTML crudo solamente | ChatGPT, Claude, Gemini, Perplejidad, Meta AI, Microsoft Copilot | Contenido inyectado por JavaScript no existiría en este camino de recuperación. |
La división geográfica es interesante por sí sola. Cuatro asistentes chinos y un asistente europeo. Los principales ayudantes estadounidenses no lo hicieron. Pero la geografía no es la lección. La lección es que el camino de puesta en tierra impulsado por el usuario en los asistentes que la mayoría de los equipos norteamericanos ya optimizan para es, en esta instantánea, un lector en bruto-HTML.
Esto hace que este sea un problema técnico de SEO, no sólo un problema de contenido de AI. Si el contenido importante no está en la primera respuesta HTML, el asistente puede nunca alcanzarlo.
Algunas cavernas importantes antes de que alguien lo llame una regla universal:
- Esta fue una prueba de un solo paso, en vivo de la puesta en tierra activada por el usuario. No es prueba de que cada rastreador de fondo, cada embrague de entrenamiento, o cada actualización futura del producto se comportará de la misma manera.
- Los vendedores pueden cambiar el comportamiento de recuperación en cualquier momento sin previo aviso.
- "No había renderizado en esta prueba" no es lo mismo que "nunca puede renderizar en ninguna parte".
El propio Vercel análisis de tráfico de rastreadores AI llegó a una conclusión similar desde un ángulo diferente: los rastreadores asistentes pueden buscar activos JavaScript, pero buscar no es ejecutar, y las respuestas auxiliares pueden desviarse silenciosamente de la memoria de caché o entrenamiento. Glenn Gabe documentó un patrón de campo coincidente en su Búsqueda AI Estudio de caso de renderizado JavaScript, donde el cliente-side renderizado contenido fue más difícil para ChatGPT, Perplejidad y Claude a la superficie.
Googlebot no es lo mismo que la tierra
La mala lectura más común de la prueba de Alpar es "Google no puede renderizar JavaScript". Eso está mal, y liderará equipos en la dirección equivocada.
Google Search es un canal de indexación. Puede aplazar la renderización, retratarla, cederla, renderizar con el Servicio de Rendering Web con el tiempo, y utilizar el HTML renderizado para las decisiones de indexación. Google todavía recomienda renderizado lado servidor y pre-rendering para el rendimiento y la fiabilidad, pero su propia documentación es explícita que el contenido generado por JavaScript puede ser indexado.
Live AI Assistant grounding no es el mismo gasoducto. Es una solicitud que ocurre cuando un usuario envía un aviso. Tiene presupuestos de tiempo estrictos, infraestructuras diferentes y decisiones diferentes sobre si ejecutar un navegador vale la pena el costo. Los dos caminos pueden darte respuestas muy diferentes sobre la misma URL.
Aquí está la manera más limpia de expresarlo a un desarrollador o gerente de producto:
Google Search rendering es un proceso de indexación de antecedentes. El ayudante de inteligencia es una lectura en vivo. Pueden estar en desacuerdo con su página incluso cuando ambos tengan éxito.
Cuatro capas de recuperación que necesita para auditar separadamente
"AI gateer" es una categoría inútil para el trabajo de diagnóstico. Hay al menos cuatro capas de recuperación distintas, y cada una se comporta de manera diferente.
| Capa de recuperación | Lo que representa | Modo de falla común |
|---|---|---|
| 1. Navegador humano | Rendered DOM after JS, hydration, CSS, and interaction. | La página se ve perfecta mientras que el HTML crudo está esencialmente vacío. |
| 2. Google Search rendering | Googlebot más el canal de indexación del Servicio de Rendering Web. | Rendering es retrasado, acelerado, o saltado en páginas de recursos pesados. |
| 3. Fundamentos de inteligencia artificial | Ejemplos son GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot. | Cada rastreador tiene su propio alcance y comportamiento de renderización; muchos no ejecutan la JS. |
| 4. Traficantes auxiliares de carga de usuario | Ejemplos incluyen ChatGPT-User, Perplejidad-User, fetchers en vivo similares. | A menudo se lee en crudo-HTML, a menudo ignorar robots.txt, a menudo mal reportar en chat. |
El propio OpenAI documentación de los rastreadores hace que esta división sea explícita. GPTBot es el arrastre de entrenamiento/utilidad. OAI-SearchBot potencia la búsqueda de estilo surfacing dentro de ChatGPT. ChatGPT-User es el fetcher activado por el usuario que visita una página cuando un usuario lo pide, y OpenAI declara que no se utiliza para gatear automático o para decidir si el contenido aparece en Search.
Perplejidad documentación de los rastreadores dibuja la misma línea. PerplejidadBot es para indexar y vincular. Perplejidad-User maneja fetches demandados por el usuario, y debido a que está activado por el usuario, Perplejidad dice que generalmente ignora robots.txt.
Si depuras las cuatro capas con una captura de pantalla de ChatGPT, no estás depurando. Estás adivinando.
Qué contenido desaparece cuando la JS es el único camino de entrega
Aquí es donde la cuestión técnica se convierte en una cuestión de contenido.
Si sus datos importantes son inyectados por JavaScript del lado cliente, los asistentes del grupo de prueba de Alpar no pueden utilizarlos para fundamentar una respuesta. La lista de superficies vulnerables es incómodamente larga para la mayoría de los sitios de producción:
- Títulos de producto, descripciones y especificaciones que hidratan después de la carga de la ruta.
- Precios, descuentos, y disponibilidad de acciones de una API.
- Acuerdos de FAQ que sólo renderizan después de un clic de pestaña.
- Tablas de comparación construidas por un marco cliente-side.
- Opiniones de los clientes y snippets de calificación sacados de un widget de terceros.
- Enlaces internos dentro de componentes hidratados que nunca aparecen en HTML crudo.
- Autor bios, credenciales y señales de confianza inyectadas por un plugin CMS.
- esquema JSON-LD añadido por un gestor de etiquetas después de la carga de página.
- Contenido pulsado o filtrado que sólo existe una vez que un usuario interactúa.
Eso golpea las páginas de productos de comercio electrónico, las páginas de precios de SaaS, las páginas de comparación, los portales de documentación, los mercados y las páginas de servicio local especialmente difíciles. El contenido que es más probable para ganar una cita de AI es el contenido que la mayoría de los equipos esconden detrás de capas de interacción.
Aquí es donde la visibilidad de la IA deja de ser un ejercicio de seguimiento rápido. Su contenido tiene que ser bueno, pero también tiene que ser entregado en una representación que el sistema de recuperación puede leer realmente.
El flujo de trabajo de auditoría que recomiendo esta semana
No necesita un presupuesto de investigación para empezar. Necesita diez minutos por página importante y acceso a los registros del servidor.
Paso 1. Ver Fuente en las páginas citadas
Abra sus páginas comerciales y editoriales de mayor valor. View Source. Busque las oraciones y números reales que desea que los asistentes citen.
Si su H1, párrafo de introducción, precios, especificaciones, puntos de comparación, respuestas de preguntas frecuentes, o esquema faltan desde el HTML crudo, indique la página.
Paso 2. Ejecute el curl y confirme lo que el servidor realmente envía
Utilice un único comando de cualquier terminal:
curl -L -A "Mozilla/5.0" https://www.example.com/your-page/ TEN lessEsto es lo que recibe un lector no revelador. Si un humano inteligente no puede responder una pregunta básica de esta salida, un asistente que no ejecuta JavaScript tampoco puede.
Paso 3. Desactivar JavaScript y recargar
Abra la página en Chrome DevTools, abra el menú de comandos, escriba "Deshabilitar JavaScript", y vuelva a cargar. No estás simulando perfectamente a ningún asistente específico. Usted está buscando el modo de fracaso de un primer lector de texto. Si la página colapsa en un esqueleto, la página está en riesgo.
Paso 4. Segment server logs by user agent
Retire los últimos 30 días de registros de acceso y filtrar por los agentes reales del usuario bot que importan para la visibilidad de AI. Separarlos por intención.
| Vendor | Índice de antecedentes | Fetcher accionado por el usuario |
|---|---|---|
| OpenAI | GPTBot, OAI-SearchBot | ChatGPT-User |
| Anthropic | ClaudeBot, antropic-ai | Traficantes de clase Claude-User |
| Perplexity | PerplexityBot | Perplexity-User |
Para cada capa, registre la URL, el código de estado, si se solicitó el archivo JS enlazado, y si se golpeó cualquier punto final de API de abajo. Eso te dice lo que cada capa de recuperación realmente vio, no lo que un chatbot dijo que vio.
Paso 5. Construya su propio canario
No necesita copiar el diseño exacto de Alpar. Necesitas una URL de prueba segura donde puedes comparar el valor en HTML crudo, el valor en el DOM renderizado, y los valores que aparecen en respuestas de asistente real cuando se solicita con esa URL. Rastrearlo por unas semanas. El patrón que encuentres superará cualquier artículo.
Qué arreglar, y en qué orden
La tentación después de una prueba como esta es construir una versión sólo bot del sitio a través de la renderización dinámica. Google es propio documentación de renderización dinámica lo llama una solución de trabajo en lugar de una solución a largo plazo recomendada porque añade coste de mantenimiento y puede derivar con el tiempo.
Arregla la entrega para los usuarios primero. La misma solución generalmente cubre ayudantes de inteligencia artificial.
| Symptom | Fijación preferida | Por qué esto funciona para la visibilidad de AI |
|---|---|---|
| La copia principal se entrega sólo después de la hidratación | renderizado lado del servidor, generación estática o regeneración estática incremental | Cada capa de recuperación lee HTML significativo en el primer byte. |
| Los precios y el stock se recogen después de la carga de la página | Inyecte el precio canónico y el lado del servidor de disponibilidad, luego refresque el lado del cliente | Los asistentes pueden citar un precio sin ejecutar la aplicación. |
| Preguntas frecuentes y especificaciones de productos viven dentro de los acordeones | Render contenido completo en HTML, utilizar CSS o mejora progresiva para UI | Las respuestas están presentes incluso cuando se saltan capas de interacción. |
| JSON-LD es inyectado por un administrador de etiquetas | Esquema de salida en la respuesta HTML inicial | Las entidades, los productos, las preguntas frecuentes y las migajas de pan son visibles para los lectores sólo de texto. |
| La navegación depende de los controladores de clic JavaScript | Use etiquetas de anclaje reales con valores de href arrastrables | Discovery todavía funciona cuando el controlador de clics nunca se dispara. |
Tratar el renderizado dinámico como un parche de compatibilidad para pilas heredadas, no como el destino.
¿Por qué la visibilidad de AI es ahora un problema de entrega
La mayoría de los programas de visibilidad de AI todavía viven en la capa de contenido: escriba respuestas más estrictas, agregue esquema, construya autoridad, solicite citas, monitoree los avisos. Esas tácticas todavía importan.
Lo que expone Alpar es la capa debajo de todo eso. Si su mejor respuesta nunca llega al asistente en la respuesta HTML inicial, el resto del programa no puede rescatarlo. Un gran párrafo escondido dentro de un componente React es invisible para un lector de HTML crudo. Una gran FAQ detrás de un acordeón es invisible si el acordeón nunca se abre para el fetcher. Una gran especificaciones de producto emitida por una llamada API es invisible si la llamada nunca se hace.
Esto se conecta directamente a otras preguntas de medición y de rastreo que he escrito, incluyendo cómo los agentes de gateer separados de OpenAI cambian las auditorías técnicas de SEO, cómo la visibilidad de Bing de la primera parte de la IA que informa re-forma la medición, y ¿Por qué los rastreadores basados en la rapidez no pueden reemplazar los registros del servidor.
El HTML no es una preocupación heredada. Es el suelo de la visibilidad de AI.
El estándar práctico es simple: si un lector solo de texto no puede entender la página de la primera respuesta, asuma al menos algunos caminos de recuperación asistente luchará también.
Tema
Puedes mantener tu pila React. Puedes mantener tu UI hidratada. Puede mantener su configurador de productos interactivos y sus tablas de comparación filtrables. Nada de eso es el problema.
El problema es tratar la primera respuesta HTML como un shell en lugar de como un documento. Para páginas importantes, la primera respuesta ya debe llevar el titular, los hechos clave, los precios, las especificaciones, el esquema y los enlaces internos. El JavaScript puede entonces mejorar ese documento, no reemplazarlo.
Y cuando un asistente de IA le dice lo que hizo con su página, no escriba eso como evidencia. Abre el registro y mira.
FAQ
¿Todos los asistentes de AI no tienen JavaScript?
No. En la prueba de junio de 2026 de Andre Alpar, cinco asistentes no estadounidenses (DeepSeek, ERNIE, Qwen, Kimi, Mistral) ejecutaron el guión y reportaron el valor renderizado. Seis asistentes estadounidenses importantes (ChatGPT, Claude, Gemini, Perplexity, Meta AI, Microsoft Copilot) respondieron desde el HTML crudo. Grok ejecutó el script y aún respondió desde el HTML crudo. El comportamiento también varía por vía de recuperación y puede cambiar con el tiempo.
¿Devuelve JavaScript Google Search?
Sí. Google Search utiliza una tubería de cromo sin cabeza que puede arrastrar, renderizar y indexar contenido JavaScript. El oleoducto puede retrasarse o tener recursos, por lo que la renderización del lado del servidor sigue siendo recomendada para contenido importante, pero Googlebot no es el mismo que un lector en bruto-HTML.
¿Cómo sé qué asistentes de IA buscaron mi página?
Filtrar los registros de acceso del servidor por el agente de usuario de AI y segmentarlos por propósito. Los rastreadores de fondo de treta (GPTBot, ClaudeBot, PerplexityBot) separados de los fetchers con tracción activada por el usuario (ChatGPT-User, Perplexity-User). Los códigos de estado de registro, las rutas de solicitud y si se han conectado JavaScript o los puntos finales de API.
¿Es dinámica la respuesta correcta a largo plazo?
Normalmente no. Google enmarca la representación dinámica como una solución para los rastreadores que luchan con JavaScript. Para la visibilidad de IA duradera, prefiera la renderización lado del servidor, generación estática, regeneración estática incremental, o mejora progresiva para que el contenido importante ya esté presente en la primera respuesta.
¿Debo confiar en un chatbot cuando dice que podría o no leer mi página?
No. Trate de auto-reportar asistente como pistas, no evidencia. Perplexity reportedly told users it could not access Alpar's test page while server logs showed PerplexityBottched the URL with a 200 response. Use registros, URL canarias y comparaciones de rocío-versus-raw para verificar el comportamiento.
Sobre el autor
Francisco Leon de Vivero es VP de Crecimiento Growing Search, con 15 años de experiencia en SEO en comercio electrónico, búsqueda de adultos, internacionales y empresas. Trabajó como SEO Lead en Shopify durante más de siete años y pasó más de cuatro años trabajando en SEO para Pornhub.