La web entra en una nueva fase. Ya no solo la visitan personas y los rastreadores clásicos: agentes de IA navegan, leen, comparan, compran y completan tareas por encargo del usuario. Ese “tráfico agéntico” crece con fuerza y obliga a replantear cómo se diseñan, miden y monetizan los sitios. La tesis es clara: del SEO centrado en la URL se pasa a la Agent Experience (AX), una capa que permite a los agentes entender, decidir y ejecutar con seguridad y previsibilidad, sin romper la experiencia humana. En su ponencia “Del SEO al AX: preparar tu web para el tráfico agéntico” en el WordPress Tech Congress, Natzir Turrado condensó datos, riesgos y una hoja de ruta operativa para sitios de contenido, e-commerce y SaaS.
El “tsunami agéntico”: menos tráfico humano, más agentes
Los indicadores ya se mueven. En el último año, el tráfico desde navegadores GenAI y servicios de chat hacia sitios de retail en EEUU se disparó un +4.700 %, mientras las visitas humanas a medios cayeron un −9,4 % en un trimestre. Además, los usuarios que llegan “vía agente” pasan un 32 % más de tiempo, ven un 10 % más de páginas y rebotan un 27 % menos que el visitante tradicional. En paralelo, la relación de hits IA/humanos saltó de 1/200 a 1/50 en pocos meses, señal de que la web empieza a tratarse —para estas herramientas— como un grafo de datos más que como páginas estáticas.
Qué es el tráfico agéntico (y quién lo genera)
El tráfico agéntico son visitas, rastreos o llamadas a tu contenido realizadas por agentes de IA que actúan por delegación de un usuario o una aplicación. No son crawlers masivos “a ciegas”, sino accesos contextuales y orientados a tareas (leer, contrastar, comprar, verificar). Esos agentes se presentan en varias capas:
- Agentes con “Computer Use” (consumo): operan un navegador real, renderizan, hacen clic, rellenan formularios y completan flujos como lo haría una persona. En logs imitan a un Chrome de escritorio, con descargas de recursos y sesiones de segundos/minutos.
- “Computer Use” vía API (desarrolladores): modelos como Gemini/Claude/OpenAI controlan navegadores headless mediante bucles de observación-acción; ejecutan pasos iterativos hasta acabar una tarea.
- Agentes con renderizado de JavaScript: usan Playwright/Puppeteer para ejecutar JS, esperar XHR/lazy-load y extraer el DOM completo, sin razonar sobre la UI.
- Fetch HTTP simple: peticiones rápidas sin JS (HTML inicial → Markdown/DOM plano). Útiles para grounding y pipelines ligeros.
En la práctica, tu sitio puede ser alcanzado por cualquiera de los cuatro, a veces en el mismo flujo. De ahí la necesidad de pensar en AX como un diseño multi-persona: humano, crawler y agente.
Rendimiento real de los agentes: promesa alta, fiabilidad irregular
La curva de adopción aún es inmadura. En pruebas publicadas, incluso modelos punteros muestran tasas de fallo elevadas al ejecutar tareas web: navegación frágil, bucles, límites de sesión, problemas con formularios, logins o recursos pesados. En un muestreo reciente, el 63 % de los intentos falló en el primer clic (errores 4XX/5XX, CAPTCHAs, timeouts o cargas lentas) y el 46 % de las visitas comenzaron en modo lectura simple (solo HTML, sin CSS/JS), lo que subraya el valor del HTML semántico y de un DOM estable. Conclusión: si la web depende de trucos de maquetación, pop-ups agresivos o JS bloqueante, los agentes se pierden y el usuario delegado también.
Nace la AX: cuando la UX se encuentra con el DX
Turrado propone formalizar AX como el punto de cruce entre UX (humano) y DX (desarrollador):
- UX prioriza accesibilidad, jerarquía, claridad y tiempos de tarea para personas.
- DX aporta determinismo y observabilidad: contratos OpenAPI, errores predecibles, tooling y status codes coherentes.
- AX une ambas: estructuras, protocolos y vistas pensadas para delegación segura, de forma que un agente pueda extraer precios, stock y CTAs; filtrar y comparar; y devolver el control al usuario cuando este quiere explorar por sí mismo (flujos híbridos, no “todo autónomo”).
Medición y bloqueos: por qué tu WAF confunde agentes con humanos
Identificar agentes hoy es difícil: cambian IPs, rotan cabeceras, usan ASNs de terceros y imitan navegadores reales, con descargas completas e incluso “pausas humanas”. De ahí conflictos como Cloudflare vs. Perplexity: unos denuncian evasión de robots.txt y otros alegan que es tráfico legítimo de usuarios a través de nubes intermedias. Sin estándares claros, ambos pueden tener “razón” técnica. Bloquear a lo bruto (CDN, WAF, rate-limit) puede echar a perder tareas válidas delegadas por tus propios clientes.
De la señalización al cobro: hacia una Agent-Oriented Web
La ponencia dibuja un stack en cuatro capas —leer, señalizar, autenticar, licenciar/ejecutar— con protocolos nuevos y viejos conocidos:
- Lectura: HTML semántico, datos estructurados, feeds/APIs abiertas, contratos OpenAPI, endpoints NLWeb (
/askpara Q&A y/mcppara agentes de confianza) y buenas prácticas de crawling CBCP (IETF). - Señalización: Content Signals (robots.txt) para declarar usos permitidos (búsqueda, inferencia, entrenamiento) y AI Preferences (vía HTTP) para que las políticas viajen con el recurso.
- Autenticación: Web Bot Auth (IETF), base para distinguir agentes legítimos de scraping furtivo.
- Licenciar y ejecutar: RSL (licencias simples en robots.txt) y Pay-Per-Crawl (HTTP 402) para cobrar a bots que acepten el marco; y, en comercio, ACP (Agentic Commerce Protocol) y AP2/Visa TAP/Mastercard Agent Pay para autorización, autenticidad y responsabilidad en pagos hechos por agentes.
La idea de fondo: dejar de depender del scraping frágil y ofrecer contratos explícitos para consultas y acciones, con una vía técnica y económica para quienes quieran usar (y remunerar) tu contenido.
Seguridad y privacidad: el “talón de Aquiles” del prompt injection
Los agentes no distinguen entre instrucciones legítimas del usuario e instrucciones maliciosas escondidas en páginas, correos o calendarios. Para el agente, todo texto puede ser código ejecutable. Las defensas clásicas (SOP, CORS, antivirus, firewalls) no aplican porque la ejecución ocurre en la infraestructura del proveedor. Se impone un “firewall semántico” y cambios de diseño: no exponer comandos en UGC, aislar contextos, reducir permisos por origen (least privilege) y auditar llamadas a herramientas. Mientras maduran las mitigaciones, conviene evitar superusuarios, separar perfiles y probar los flujos con agentes reales para descubrir inyecciones o bloqueos inesperados.
Guía práctica: qué puedes hacer hoy
La presentación cierra con una lista accionable. Resumen por capas:
Estructura (que el agente entienda):
- Jerarquía clara (H1…H6) y HTML5 limpio.
- Datos estructurados, listas y tablas bien formadas (schema útil también para consultas sobre contenido ya indexado).
- Contenido crítico ATF (above the fold): en e-commerce, precio, talla, stock y CTA visibles sin scroll.
- WPO: carga rápida y DOM estable < 2 s; menos JS bloqueante y menos plugins que rompen el render.
Interacción (que el agente opere):
- Botones reales (
<button>) en lugar de divs clicables. - Formularios accesibles (cada campo con
label). - ALT en imágenes clave; diálogos accesibles (
role="dialog",aria-modal,inert). - No tapar CTAs con pop-ups; evitar que filtros, tallas o “añadir al carrito” queden ocultos tras hover o tabs.
Configuración (que no le cierres la puerta):
- No bloquees agentes válidos por defecto (revisa CDN/WAF/robots).
- Minimiza CAPTCHAs y interstitials en la primera carga.
- Evalúa estándares según tu negocio (contenido, tienda o SaaS): OpenAPI/NLWeb/ACP/RSL/Pay-Per-Crawl.
- Prueba de fuego: pídele a un agente que complete una tarea real (p. ej., “añadir producto X de talla Y y precio Z al carrito”) y registra dónde falla.
Por qué esto también es negocio (no solo técnica)
AX no consiste en “abrir la valla” sin control, sino en crear caminos seguros para agentes y usuarios, con señales claras, autenticación, licencia y, si procede, pago. La recompensa es doble: más conversiones de la mano de agentes que reducen el coste cognitivo del usuario, y menos dependencia de interfaces “pixel perfect” que cada vez pintan menos en flujos conversacionales y de tareas.
Preguntas frecuentes
¿Qué diferencia hay entre SEO y AX?
El SEO conecta contenido con audiencia (humanos y bots), optimizando estructura, velocidad y relevancia; AX añade determinismo y ejecución para agentes: contratos OpenAPI/NLWeb, vistas accesibles y reglas que permiten delegar tareas con seguridad.
¿Debo bloquear a los bots de IA en robots.txt?
Bloquear “a ciegas” puede impedir que agentes legítimos —usados por tus propios clientes— completen tareas. Mejor señaliza usos permitidos (Content Signals/AI Preferences), autentica (Web Bot Auth) y licencia/cobra donde tenga sentido (RSL/Pay-Per-Crawl).
¿Por dónde empiezo si tengo un e-commerce?
Primero estructura (precio/stock/CTA ATF, datos estructurados, WPO < 2 s), luego OpenAPI/NLWeb para consultas/acciones, y pruebas con agentes en tareas reales de carrito y checkout. Considera ACP/AP2 para pagos agénticos en cuanto esté disponible para tu stack.
¿Cómo reduzco el riesgo de prompt injection?
Aísla orígenes (no mezcles UGC con datos sensibles), limita permisos por herramienta, añade controles semánticos antes de ejecutar acciones y audita eventos de scripting/funciones. Evita perfiles con superpoderes y separa navegación agéntica de la habitual.
vía: Presentación Natzir
Fuente: Presentación “Del SEO al AX: preparar tu web para el tráfico agéntico” (WordPress Tech Congress, WCVLC 2025).