Durante décadas, las webs han estado (o deberían estar) centradas en los humanos: cómo buscan, cómo hacen clic, cómo se mueven por una página. Todo medido desde una unidad simple, la URL. Pero este modelo está empezando a cambiar. ¿Por qué? Porque hoy, parte del tráfico web ya no proviene de personas, sino de agentes: sistemas de IA que actúan en nombre de los usuarios y que acceden al contenido, lo interpretan y lo reutilizan sin verlo como una web, sino como un grafo de datos. Bienvenidos al tráfico agéntico.
Índice de contenidos:
El tráfico agéntico trata de visitas, rastreos o llamadas a tu contenido realizadas por agentes de IA, no por humanos ni por crawlers clásicos. A diferencia de un bot tradicional, que recorre páginas en masa, un agente actúa por delegación del usuario, se mueve por la web para completar tareas concretas y lo hace de forma contextual, puntual y orientada al resultado. El intercambio de valor es directo y medible.
Existen dos grandes tipos de agentes que generan tráfico agéntico:
Esta distinción es clave para entender cómo acceden al contenido, cómo se identifican y qué margen tienes para gestionarlos.
Aunque la promesa es enorme, la ejecución sigue estando muy verde. Donde mejor encajan hoy los agentes es en herramientas de código pero en tareas web "complicadas", la fiabilidad aún cojea. Llevo meses trabajando con ellos y, en general, resultan bastante decepcionantes. El benchmark de TheAgentCompany lo confirma: incluso el mejor agente probado (Gemini 2.5 Pro) falló el 70% de las veces al ejecutar tareas reales. Y eso contando también las tareas parcialmente completadas.
Las principales causas de fallo son:
Esto repercute directamente para cualquier negocio que dependa de tareas online estructuradas, como compras, formularios, CRM, consultas médicas... Si el contenido no está bien estructurado o si requiere demasiada interacción no estandarizada, es probable que el agente no lo entienda, o lo haga mal. Tal y como veremos a continuación.
Ya no importa tanto que una URL posicione para "precio lavadora X", sino que la máquina pueda entrar, entender cómo navegar por la web, recuperar y validar que "la lavadora X cuesta 399€".
Para que eso funcione, el contenido tiene que ser legible para humanos, pero también accesible y procesable por máquinas.
Agent Experience es User Experience para agentes. Si los agentes no pueden completar sus objetivos, los usuarios tampoco. Una mala AX se traduce en mala UX = usuarios insatisfechos o perdidos. Creo que esto da pie a abrir un nuevo debate como el del SEO vs GEO 😛
En mis pruebas con browser agents, he visto cómo el agente abandonaba la web de un cliente DTC y se iba a un marketplace, simplemente porque allí sí podían completar la tarea que le había pedido.
Os lanzo un reto. Pedidle al agente de ChatGPT, Operator, que complete una tarea en vuestra web, cualquiera que sea razonable para lo que ofrecéis. Veréis la cantidad de errores que se va a encontrar. ¿Qué problemas me he encontrado yo?
Y no hablo de webs pequeñas. He visto todos estos problemas en webs de clientes que están entre los principales ecommerce del país. Aquí podemos ver un ejemplo en Leroy Merlin (no es cliente, pero ya están avisados):
Más allá del SEO técnico, creo firmemente que el HTML semántico ya no es solo un tema de accesibilidad. Es el punto de anclaje para agentes, navegadores inteligentes, scraping ético y modelos de lenguaje. Cuanto más claro y coherente sea tu marcado, menos errores le causarás a este nuevo tipo de tráfico. No es opinión, me baso en evidencia y en un buen puñado de papers que demuestran cómo los sitios que siguen estándares de accesibilidad y usan HTML semántico ayudan a los agentes en grounding y en tareas de navegación agéntica.
Además, ya estamos viendo asociaciones entre agentes y empresas para acceder a sus datos via API y mejorar así la fiabilidad y velocidad de las respuestas. Ahí están los acuerdos de OpenAI y Perplexity con Tripadvisor, Booking o Uber. Justo como ya comenté hace meses, que se pondría de moda ofrecer alternativas al scraping de estos bichos ya sea mediante APIs, feeds o datos estructurados (JSON, XML).
En este punto entra en juego la especificación OpenAPI que sirve para describir y validar cómo se usan las APIs: qué endpoints hay, qué parámetros admiten, qué devuelven y qué errores pueden dar. Para los agentes, tener un contrato OpenAPI bien publicado significa poder ejecutar acciones de forma fiable y segura, más allá de simplemente leer el contenido de la página.
De hecho, OpenAPI ya lo usan en producción empresas como ChatGPT (en sus plugins y GPTs personalizados, donde el modelo necesita un esquema OpenAPI para saber qué endpoints puede llamar), Google (Gemini + APIs de Workspace ) o Anthropic (Claude con Tools / APIs externas). Y en paralelo, compañías como Stripe, Twilio, Shopify, Slack, Booking o Uber publican sus APIs en OpenAPI para que sean consumidas de forma segura, documentada y predecible.
Pero hay otra dimensión, porque AX también implica seguridad. No sirve de nada que un agente complete bien una tarea si al mismo tiempo abre la puerta a un ataque mediante prompt injection. Brave lo ha demostrado con Comet (Perplexity), con un simple post en Reddit han podido engañar al agente para robar mails, OTPs y más. El otro día descubrí que ChatGPT podría estar empezando a protegerse de ello.
A día de hoy, la mejor forma de protegerse de estos ataques es no usar este tipo de navegadores. Están muy verdes todavía.
Detectar el tráfico agéntico hoy es un reto técnico bastante serio. Los métodos clásicos (user-agent, IP, ASN) no son fiables, porque muchos agentes:
Este descontrol ya está generando conflictos, como el reciente caso Cloudflare vs Perplexity. Cloudflare los acusó de evadir robots.txt y simular ser tráfico humano. Perplexity respondió que esas llamadas eran realizadas por usuarios reales a través de servicios en la nube. ¿Quién tiene razón? Técnicamente, los dos. Y eso deja al descubierto el verdadero problema, que es que no existe un estándar fiable para autenticar bots y agentes.
Para ilustrarlo, os dejo un extracto de un log que deja un navegador de IA (Operator) en la web de un cliente, es un usuario normal:
2025-08-19T11:06:15.005Z
client_ip=2001:db8:85a3::8a2e:370:7334
geo_country=spain
geo_city=barcelona // Se conecta desde un lugar cercano a mi ubicación
domain=<borrado>
conn_speed=broadband
conn_type=wired
fastly_server=cache-ams21037-AMS
file_type=HTML-Page
bot_type=Not-Bot
mobile=0 // Desktop
request_method=GET
request_protocol=HTTP/1.1
request_user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36"
response_body_size=39455
response_reason=OK
response_state=MISS
response_status=200
status_category=2xx-Success
time_elapsed=1435
url="/en/<borrado>/?id=test_chatgpt_operator"Además de optimizar webs individuales (AX), la web en su conjunto va evolucionando hacia una Agent-Oriented Web, por lo que hace falta un marco de nuevos estándares para que los agentes operen de forma nativa, segura y predecible.
El debate técnico y ético que ha empezado:
Si vamos hacia motores de finalización de tareas que tratan la web como una base de datos abierta, falta entonces estandarizar acceso/consentimiento/salida. Aquí entrarían nuevos protocolos:
Han empezado a aparecer propuestas más explícitas para dar instrucciones a los agentes dentro del propio HTML. Desde Vercel, se plantea incrustar estas instrucciones mediante un bloque inline <script type="text/llms.txt"> en la respuesta HTTP (por ejemplo, en un error 401). De esta forma, los humanos no verían nada, pero los agentes sí pueden leerlo y entender cómo continuar (autenticación, acceso a un MCP...).
El IETF está desarrollando Web Bot Auth, un estándar de autenticación criptográfica que permitiría identificar con fiabilidad qué agente está accediendo, si está autorizado y con qué propósito.
Iniciativas como esta buscan soluciones técnicas que permitan identificar a los agentes de forma segura, sin comprometer la privacidad del usuario y sin bloquear el acceso legítimo a la información. El equilibrio es delicado, como veremos en el siguiente punto, porque si lo cierras todo, pierdes visibilidad y si lo abres sin control, pierdes negocio.
Desde Google reconocen que bloquear el acceso a la IA sin entender cómo funciona el ecosistema puede salir caro.
Gary Illyes ha señalado que muchos editores están optando por bloquear Google Extended, pero que eso no afecta a AI Overviews ni a AI Mode, porque estos se alimentan del índice de Google Search y no hacen fetch en vivo (comprobado), al menos por ahora. Es decir, aunque cierres el grifo a Google Extended, sigues siendo "visible" si tu contenido ya está indexado.
Gary también participa en el grupo de trabajo del IETF que está desarrollando AI Preferences, un estándar que permitiría a los editores definir con más precisión para qué usos puede emplearse su contenido (entrenamiento, inferencia...). Dice que la propuesta tiene impulso, pero que aún está por ver si llegará a implementarse. Y avisa que hay demasiados conceptos erróneos sobre cómo funciona la IA, incluso entre perfiles técnicos. Bloquear sin entender puede no solo dañar tu visibilidad, sino frenar la innovación. Y aclara que esto no es una “cosa de Google”, sino un problema más amplio del ecosistema web.
Pero el matiz importante es otro: al bloquear crawlers de IA, también puedes estar bloqueando agentes, ya que muchos agentes operan a través de servicios intermedios que acaban cayendo en listas de bloqueo. Y, como decíamos, no hay una forma estándar de diferenciarlos.
Por eso desde Google piden prudencia. La IA podría ser una fuente de visibilidad y de ingresos si se gestiona bien. Pero si cierras el acceso a ciegas, podrías estar cerrando la puerta al tráfico agéntico que viene delegado por usuarios reales. Y la Gen Z adora estas nuevas interfaces, ya está usando este tipo de herramientas para navegar, buscar o comprar y el caso de uso principal de ChatGPT es el de buscador, ¿vas a quedarte fuera por miedo?
El reto de todo esto es controlar, identificar qué entra, quién lo envía y con qué propósito. Y para eso, iniciativas como Web Bot Auth y las propuestas AI Preferences podrían marcar el camino. Mientras tanto, lo que está claro es que el tráfico agéntico no lo vas a frenar con un robots.txt.
Relacionado:
La reciente filtración del system prompt de GPT-5 por el hacker Elder Plinius the Liberator, la publicación de su configuración de búsqueda de GPT-5 por el SEO Metehan Yesilyurt, el descubrimiento que hice sobre el flujo de orquestación y búsqueda en GPT-4 y las recientes declaraciones del CEO de OpenAI, Sam Altman, quizá no aporten […]
Leer másCada vez que un nuevo concepto o sigla asoma en el mundo del marketing digital, GEO, AEO, LLMO, GAIO, LSO, LEO, etc. el debate gira en torno a si estamos ante una verdadera revolución o si es la misma estrategia de siempre con otro nombre. Mi experiencia es que la optimización para grandes modelos de […]
Leer más