Asistentes de IA y JavaScript: cómo probar lo que realmente leen
Una prueba operativa para separar HTML inicial, DOM renderizado y solicitudes de bots de IA. Incluye registros, canarios de ejecución y decisiones de renderizado.
Guía en video
HTML inicial, JavaScript y asistentes de IA
La prueba de señuelo y el diagnóstico con registros, explicados paso a paso.
TL;DR: Que Google pueda renderizar JavaScript no demuestra que una recuperación en vivo de ChatGPT, Perplexity u otro asistente ejecute el mismo código. Una prueba de Andre Alpar encontró comportamientos distintos entre doce asistentes en junio de 2026. Es una fotografía útil, no una regla universal.
Para auditar una URL, compara el HTML inicial con el DOM renderizado y añade un punto final canario que solo se solicite al ejecutar JavaScript. Los registros del servidor deben confirmar cada paso. La respuesta del chatbot, por sí sola, no permite saber cómo obtuvo el contenido.
El fallo aparece cuando una página parece completa en Chrome, pero entrega un contenedor casi vacío en su primera respuesta. El visitante recibe el contenido después de la hidratación. Un sistema que solo recupera HTML puede quedarse con el título, un mensaje de carga o nada útil.
Durante años, la pregunta técnica fue si Google podía procesar la aplicación. Ahora hay varias rutas de recuperación y no comparten necesariamente la misma capacidad ni el mismo presupuesto. Conviene medirlas por separado antes de recomendar un cambio de framework.
Diferencias entre Google Search y la recuperación en vivo
La documentación oficial de Google sobre JavaScript SEO describe un proceso de rastreo, renderizado e indexación. Googlebot puede poner una página en cola para renderizarla con su Web Rendering Service. El resultado puede alimentar el índice.
Una consulta a un asistente tiene otro contexto. El sistema puede usar un índice previo, lanzar una recuperación web, recurrir a un socio de búsqueda o combinar varias fuentes. Incluso dentro del mismo proveedor hay bots con funciones diferentes. Por eso no usaría el éxito de Googlebot como prueba de acceso para todos los asistentes.
| Ruta | Objetivo | Evidencia útil |
|---|---|---|
| Navegador humano | Mostrar la aplicación completa | DOM, red y consola del navegador |
| Google Search | Rastrear, renderizar e indexar | URL Inspection, HTML rastreado y GSC |
| Bot de búsqueda o entrenamiento | Descubrir o recopilar contenido según su función | Documentación del proveedor, robots y logs |
| Recuperación iniciada por un usuario | Responder una solicitud concreta | Logs con hora, URL, IP, agente y respuesta |
Diseño y alcance de la prueba de señuelo
Alpar preparó una URL nueva para cada asistente. La respuesta HTML contenía un valor de señuelo. Un archivo JavaScript externo pedía un segundo recurso y reemplazaba ese valor por otro. El servidor registraba la descarga de la página, la del script y la llamada al punto final.
Ese diseño distingue acciones que suelen mezclarse:
- solicitar el documento HTML
- descargar el archivo JavaScript
- ejecutar el código y llamar al segundo recurso
- usar el valor renderizado en la respuesta.
En esa ejecución, cinco asistentes devolvieron el valor creado después de ejecutar el script. Seis respondieron con el señuelo del HTML inicial. Grok solicitó el recurso de ejecución, pero usó el valor inicial en su respuesta. El resultado más importante no es la clasificación por proveedor. Es la diferencia entre ejecutar una parte del proceso y emplear su resultado.
La muestra cubre doce productos en una fecha y una modalidad de recuperación. No prueba que un proveedor nunca renderice JavaScript, que todos sus bots se comporten igual o que el resultado siga vigente después de un cambio de infraestructura. Para decidir sobre un sitio propio hace falta repetir el patrón con sus páginas y sus registros.
Identidad y función del bot
Un nombre en el agente de usuario no basta para atribuir una solicitud. La documentación de bots de OpenAI separa, entre otros, OAI-SearchBot, GPTBot y ChatGPT-User. Sus controles y propósitos no son intercambiables. Las directrices de Perplexity también distinguen PerplexityBot de Perplexity-User y publican rangos de IP para validación.
Para una auditoría, guardaría al menos estos campos:
- fecha y hora con zona horaria
- método, URL solicitada y query string
- agente de usuario completo e IP validada
- status, bytes enviados y tiempo de respuesta
- referer cuando exista
- solicitudes posteriores a scripts, API o canarios.
Una visita con nombre de bot y una IP no verificada puede ser suplantación. Una descarga de JavaScript no demuestra ejecución. Una cita sin log tampoco demuestra que el sistema visitó la URL en ese momento, porque pudo usar un índice o una copia previa.
Auditoría en cinco vistas
1. Guarda la primera respuesta
Solicita la URL sin ejecutar un navegador y conserva headers y cuerpo. Comprueba que el status sea correcto, que la canonical coincida con la intención y que la respuesta incluya el título, la respuesta principal, datos esenciales y enlaces internos reales.
2. Compara con el DOM renderizado
Abre la misma URL con JavaScript habilitado y extrae el DOM. No busques igualdad de bytes. Busca diferencias que cambien el significado, como precio, disponibilidad, especificaciones, preguntas frecuentes, paginación o enlaces de descubrimiento.
3. Revisa lo que procesó Google
URL Inspection permite comparar la página en vivo con la versión rastreada cuando está disponible. Esta vista responde una pregunta sobre Google. No la presentes como medición de OpenAI, Anthropic o Perplexity.
4. Añade un canario de ejecución
Crea un recurso sin enlaces públicos que el JavaScript solicite al ejecutarse. Asigna una ruta o token distinto por prueba. El canario debe registrar la llamada sin exponer información sensible ni alterar la respuesta para usuarios reales.
5. Repite y registra la versión
Ejecuta la prueba varias veces, anota producto, modalidad, fecha, país y estado de sesión. Una observación aislada sirve para encontrar un fallo. No alcanza para definir una capacidad permanente del proveedor.
Contenido crítico en el HTML inicial
No hace falta convertir toda interacción en HTML estático. El criterio es separar información necesaria de mejora de interfaz. En las páginas que sostienen demanda orgánica, incluiría en la respuesta inicial:
- encabezado principal y resumen de la respuesta
- texto, precios y especificaciones que determinan una decisión
- enlaces rastreables con atributos
href - canonical, robots, hreflang y metadata social
- datos estructurados que coincidan con el contenido visible.
Filtros, ordenamiento, calculadoras y estados personalizados pueden seguir en el cliente. Para el contenido crítico, la generación estática, el renderizado en servidor o una arquitectura híbrida reducen la dependencia de una segunda etapa. En un ecommerce, por ejemplo, entregaría nombre, precio canónico, disponibilidad y variantes principales desde el servidor. JavaScript puede refrescar inventario y personalizar la experiencia después.
También revisaría los acordeones. Ocultar una respuesta con CSS no suele quitarla del HTML. Inyectarla solo después de un clic sí crea una dependencia. La prueba debe mirar el código entregado, no la apariencia del componente.
Prioridad de reparación
Clasifico las diferencias por consecuencia, no por tecnología. Una página de servicio cuyo argumento principal solo aparece después de hidratar merece atención inmediata. Un selector secundario que depende del cliente puede esperar.
| Hallazgo | Riesgo | Respuesta |
|---|---|---|
| HTML inicial sin respuesta principal | Alto | Renderizar el contenido crítico en servidor |
| Enlaces solo mediante eventos de clic | Alto | Usar anclas con destinos reales |
| Schema agregado por un tag manager | Medio | Emitirlo junto al documento cuando sea viable |
| Filtro o calculadora del lado cliente | Bajo si existe contenido base | Mantener como mejora progresiva |
Esta auditoría complementa una revisión técnica de SEO. Si el problema es indexación, también conviene separar rastreo, renderizado, selección canónica y calidad mediante una auditoría SEO técnica y de contenido. Para las funciones de IA de Google, la guía oficial de optimización mantiene los mismos requisitos de acceso e indexación.
Después de más de quince años en SEO, incluidos siete como SEO Lead en Shopify, prefiero una prueba pequeña que pueda repetirse a una lista genérica de compatibilidad. Una tabla de proveedores envejece rápido. El HTML guardado, el canario y el log permiten reconstruir lo que ocurrió en una URL concreta.
Preguntas frecuentes
¿Los asistentes de IA ejecutan JavaScript?
Algunos lo hicieron en la prueba citada y otros respondieron desde el HTML inicial. El comportamiento depende del producto, la ruta de recuperación y la fecha. Repite la prueba en tu sitio antes de asumir una capacidad.
¿Google Search puede indexar contenido generado con JavaScript?
Sí. Google documenta un proceso de renderizado para páginas con JavaScript. Aun así, recomienda que los enlaces y el contenido sean accesibles, y una recuperación de otro asistente no tiene por qué usar el mismo proceso.
¿Cómo compruebo que un bot es auténtico?
Usa los rangos de IP o el procedimiento de validación publicado por el proveedor. No atribuyas una visita solo por el texto del agente de usuario.
¿Debo abandonar React u otra aplicación cliente?
No. Mantén la interacción en el cliente si aporta valor, pero entrega en el HTML inicial la respuesta, metadata y enlaces que una persona o sistema necesita para entender la página.
Sobre el autor
