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.
Y tenemos los números que lo demuestran. Según datos de Tollbit en Q2-2025, las visitas humanas a webs de publishers cayeron un 9,4% versus el trimestre anterior, mientras que las peticiones de bots de IA se dispararon y ya representan 1 de cada 50 visitas, frente a 1 de cada 200 a inicios de año.
Í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:
Los experimentos que se están haciendo hoy en comercio electrónico lo dejan clarinete. Perplexity, por ejemplo, todavía tiene varios problemas con sus funciones de compra. Solo se pueden adquirir productos de uno en uno (no hay carrito) y muchos vendedores ni siquiera tienen forma de actualizar directamente la información de sus artículos, así que los datos suelen quedar desfasados porque se obtienen por scraping. Estas limitaciones tan básicas muestran que todavía falta bastante para que los agentes puedan manejar transacciones complejas de manera realmente fiable.
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.
Además, según análisis de Forrester, las experiencias de compra basadas en chat actuales son inmaduras y están "más en fase asistiva que agéntica". En sus pruebas con soluciones de comercio conversacional, encontraron que las conversaciones son poco intuitivas, el alcance del bot suele ser poco claro y los resultados a veces son completamente sin sentido. El problema fundamental es que estos sistemas asumen que los compradores no quieren realmente comprar, cuando la realidad es que para productos de alta consideración (ropa, electrónica, productos especializados), la experiencia de navegación sigue siendo preferida, divertida o necesaria.
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€".
Es importante entender que estamos ante un cambio fundamental en el modelo de búsqueda. Google podría perder el 95% de su volumen de búsqueda y aún así crecer en ingresos, siempre que mantenga las consultas valiosas para ellos (principalmente las comerciales). La IA se está comiendo primero las consultas informacionales de bajo valor monetario (tipo "¿cuántos protones tiene el cesio?"), mientras que las búsquedas con intención de compra ("mejor raqueta de pádel"), donde se genera el dinero real, están seguras de momento.
En cualquier caso, para que todo esto 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.
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), Google (Gemini + APIs de Workspace) o Anthropic (Claude con Tools). 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.
En el ámbito específico del comercio electrónico, OpenAI y Stripe han co-desarrollado el Agentic Commerce Protocol (ACP), el estándar abierto que alimenta la funcionalidad de compras Instant Checkout en ChatGPT. Este protocolo resuelve precisamente los problemas que veíamos con Perplexity: define cómo los agentes deben gestionar carritos multiproducto, procesar pagos mediante tokens seguros (como el Shared Payment Token de Stripe), manejar inventarios en tiempo real y completar transacciones complejas sin depender de scraping o simulación de clics.
El ACP establece un contrato estandarizado entre agentes y plataformas de comercio que incluye descubrimiento de productos, gestión de sesiones de compra, autorización de pagos y confirmación de pedidos. Actualmente ya está en producción con merchants de Etsy y próximamente con más de un millón de comercios de Shopify (Glossier, SKIMS, Spanx, Vuori...).
El protocolo es de código abierto bajo licencia Apache 2.0, lo que permite a cualquier comercio integrarlo para vender a través de agentes de IA, y a cualquier payment processor adoptarlo sin necesidad de cambiar la infraestructura existente del merchant.
Más allá de los protocolos técnicos, hay un debate sobre cómo debería ser realmente la experiencia de compra agéntica. Según Forrester, el futuro no será simplemente "meter un chat en la web", sino guided selling aumentado con IA generativa: una experiencia híbrida que combina interfaces visuales tradicionales (browse/search) con capacidades conversacionales en lenguaje natural.
La clave está en integrar ambas experiencias sin forzar al usuario a quedarse atrapado en una conversación interminable. Por ejemplo, al buscar "mochila", el agente puede preguntar "¿cómo la vas a usar?" mostrando filtros sugeridos y resultados que se refinan en tiempo real con cada respuesta, pero siempre permitiendo al usuario salir de la conversación y navegar manualmente los productos. No es chat O navegación, es chat Y navegación trabajando juntos.
Este enfoque resuelve un problema fundamental: no todos los usuarios quieren delegar completamente la decisión de compra. Para productos de baja consideración, sí. Pero para ropa, electrónica o productos especializados, la gente todavía quiere ver, comparar y decidir. El agente debe asistir, no sustituir la exploración.
Mientras esperamos que maduren los protocolos mencionados, ya existe NLWeb, un protocolo abierto impulsado por Microsoft que define dos endpoints estándar para que tanto personas como agentes consulten tu sitio en lenguaje natural:
/ask: endpoint conversacional para preguntas/respuestas./mcp: endpoint MCP (Model Context Protocol) para agentes de confianza y herramientas.La ventaja es que dejas de depender del scraping frágil para exponer respuestas estructuradas y acciones a los agentes, sin obligarles a emular un humano navegando por el UI. Cloudflare lo implementa con AutoRAG + NLWeb Worker: crawlea tu sitio renderizado, indexa y despliega automáticamente esos endpoints en tu dominio (ej. ask.tudominio.com/ask). Incluso incluye un snippet embebible para añadir búsqueda conversacional en tu web.
Con esto, AX deja de ser solo "hacer legible el DOM" y pasa a ser ofrecer un contrato explícito para consultas y acciones. Los agentes necesitan mucho más que HTML bien estructurado, sobre todo para funciones comerciales: necesitan APIs unificadas para moverse entre plataformas, capacidad de memoria para recordar preferencias y umbrales de precio, y acceso a datos fiables y actualizados.
Sin estos elementos, los LLMs seguirán siendo meros "resumidores inteligentes" en lugar de agentes comerciales. Tal y como hemos visto con los problemas de Perplexity en comercio electrónico, incluso funciones básicas como un carrito de compras múltiple requieren una infraestructura que aún no existe o que está empezando a madurar con protocolos como los mencionados.
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.
El problema de fondo es que muchos de estos agentes se camuflan como tráfico humano. Los datos de Tollbit muestran que el crecimiento de bots que ignoran robots.txt aumentó más del 40% en el último trimestre, y muchos se presentan con user-agents de Chrome, cargan anuncios e incluso resuelven CAPTCHAs. Por eso los logs tradicionales ya no sirven para distinguirlos.
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, necesitamos un stack de nuevas reglas en la web. Ese stack tiene cuatro capas básicas: señalizar qué usos del contenido están permitidos, licenciar bajo qué condiciones, autenticar a los agentes que acceden y ejecutar pagos cuando corresponda.
Veamos cómo se está empezando a construir cada una de ellas.
Antes incluso de hablar de licencias y cobros, hace falta aclarar para qué puede usarse tu contenido. Aquí entran dos iniciativas distintas:
robots.txt para distinguir entre tres propósitos de uso: search, ai-input (para salir como respuesta en inferencia tipo AIO) y ai-train. No obliga a nadie, pero deja constancia pública de tu política y ayuda a que los bots que quieran cumplir sepan qué está permitido y qué no. Cloudflare ya lo incluye en su managed robots.txt.robots.txt.En la práctica parece que esto sería el primer paso, primero señalizas/formalizas la política (Content Signals o AI Preferences), y a partir de ahí decides si bloqueas, licencias o cobras con algo como el RSL y Pay-Per-Crawl que veremos ahora.
Para abordar el problema de la monetización han surgido dos aproximaciones complementarias:
robots.txt para permitir a los editores definir términos de licencia y pago. De esta forma, una web puede especificar un coste por rastreo (pay-per-crawl) o incluso un pago cada vez que un modelo de IA utiliza su contenido para generar una respuesta (por ejemplo, ¿podría haber un pay-per-inference para salir en una AIO?). El objetivo es crear un modelo de negocio escalable que compense a los creadores por el uso de su trabajo para el entrenamiento de IA, simplificando las negociaciones que hasta ahora eran caso por caso.Sería como si el RSL definiera el contrato y Pay-Per-Crawl lo ejecutara en la práctica.
También 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.
Más allá de la autenticación y la monetización del contenido, el paso final y más crítico, la transacción, también requiere de un nuevo framework. Aquí es donde entraría el Agent Payments Protocol (AP2), un estándar abierto anunciado por Google junto a gigantes de los pagos como Mastercard, American Express y PayPal. Su objetivo es resolver los tres grandes problemas de las compras hechas por agentes: la autorización (demostrar que el usuario dio permiso), la autenticidad (asegurar que la petición del agente es legítima) y la responsabilidad (saber quién responde si algo sale mal). Para ello, utiliza "Mandatos", contratos digitales criptográficos que crean una prueba verificable de las instrucciones del usuario, estableciendo un rastro auditable y seguro desde la intención de compra hasta el pago final.
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.
Mientras se desarrollan los protocolos de monetización y autenticación, el IETF está trabajando en el draft-illyes-aipref-cbcp (Crawler Best Practices), que establece las obligaciones mínimas que deberían cumplir todos los crawlers y agentes bien comportados. Este borrador complementa iniciativas como RSL o Web Bot Auth, definiendo lo que se espera que hagan los operadores de crawlers, no solo lo que los sitios web pueden señalizar. Ha sido redactada por Gary Illyes (Google, aunque sale como independiente), Mirja Kühlewind (Ericsson) y AJ Kohn (Blind Five Year Old).
Las prácticas clave incluyen:
Este estándar es importante porque establece un contrato bidireccional: los sitios señalizan sus preferencias (Content Signals, AI Preferences) y los crawlers se comprometen a comportarse de forma predecible y respetuosa.
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 antes mencionado arriba. 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 RSL, Content Signals, 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:
Foursquare anunció su asociación con OpenAI hace 4 meses para alimentar las búsquedas locales en ChatGPT a través de su Places API. Desde entonces, su base de datos, que incluye más de 100 millones de puntos de interés en más de 200 países, se ha convertido en una de las principales fuentes utilizadas por el […]
Leer másLa Inteligencia Artificial ha dejado de ser una promesa futurista para convertirse en una fuerza transformadora en el presente y, el SEO, tenía que subirse también a la ola. Problema: nadar por el estado actual de herramientas, workflows y agentes de IA para SEO puede ser complicado, y el hype existente nubla la realidad práctica. […]
Leer más