Durante años entendimos Internet de una manera bastante sencilla: una persona abre un navegador, escribe una dirección, visita una página y consume su contenido.
Ese modelo está cambiando.
La inteligencia artificial está introduciendo un nuevo tipo de usuario de Internet: el agente de IA. Ya no hablamos únicamente de personas visitando sitios web, sino de sistemas capaces de buscar información, comparar productos, consultar documentación, ejecutar acciones y, cada vez más, realizar transacciones en nombre de una persona.
Estos días me puse a revisar mis propios sitios con un checker de “agent readiness” (hay varios ya circulando) y me topé con una lista de estándares que hace un año ni existían. La mayoría son de 2025-2026, algunos ya son RFCs consolidados y otros son borradores o propuestas de empresas que están ganando tracción. Este artículo es el recorrido completo: qué evalúan estas herramientas, por qué importa cada punto y cómo resolverlos uno por uno.
El nuevo visitante de tu página ya no es necesariamente una persona
Hasta hace poco, optimizar una página web significaba principalmente hacerla atractiva, rápida y fácil de utilizar para seres humanos.
Después apareció el SEO: había que conseguir que Google entendiera nuestro contenido y lo colocara frente a las personas que realizaban búsquedas.
Ahora aparece una nueva capa.
Los motores de IA y los agentes necesitan descubrir, interpretar y utilizar la información de los sitios web. Para ello utilizan crawlers especializados.
OpenAI, Google, Anthropic, Perplexity, Amazon, Meta y otras compañías tienen sistemas que recorren Internet para obtener información que posteriormente utilizan en sus productos de inteligencia artificial.
El problema es que este tráfico no se comporta necesariamente como el tráfico humano tradicional.
Un agente puede consultar miles de páginas sin que ninguna persona llegue directamente a visitarlas.
Y eso genera una pregunta que hasta ahora no tenía demasiada importancia:
¿Quién controla el acceso de las máquinas a nuestro contenido?
Cloudflare está intentando convertirse en parte de la respuesta.
AI Crawl Control: decidir qué inteligencias artificiales pueden acceder
Una de las novedades más relevantes es AI Crawl Control.
La herramienta permite identificar qué servicios de inteligencia artificial están accediendo a nuestro sitio y establecer políticas para ellos.
Podemos, por ejemplo, decidir qué crawlers permitir y cuáles bloquear, además de observar su actividad y comportamiento. Cloudflare también incorpora seguimiento del cumplimiento de robots.txt y métricas relacionadas con el tráfico de IA.
Esto cambia algo fundamental.
Antes pensábamos en términos de:
“Quiero que Google encuentre mi página.”
Ahora podemos empezar a pensar:
“Quiero decidir qué sistemas de IA pueden utilizar mi contenido, para qué y bajo qué condiciones.”
Para un blog, un medio de comunicación, una empresa que publica documentación o incluso un comercio electrónico, esto puede convertirse en una cuestión estratégica.
No todo crawler necesariamente tiene el mismo valor.
Algunos pueden generar visibilidad y referencias. Otros pueden simplemente consumir enormes cantidades de contenido para alimentar sistemas de IA sin generar tráfico directo hacia el sitio.
Agent Readiness: preparar una web para los agentes
Otra pieza interesante es Agent Readiness.
La pregunta deja de ser únicamente:
¿Mi página está optimizada para Google?
Y empieza a ser:
¿Mi página puede ser correctamente entendida y utilizada por un agente de IA?
Cloudflare está incorporando una puntuación de preparación para agentes que ayuda a evaluar qué tan compatible es un sitio con este nuevo tipo de navegación. La compañía está orientando estas herramientas hacia una web donde los agentes sean ciudadanos de primera clase.
Esto tiene una consecuencia importante para quienes desarrollamos sitios web.
Ya no basta con pensar en diseño, SEO, velocidad y experiencia de usuario.
Tenemos que empezar a considerar también:
- estructura de la información;
- contenido claramente identificable;
- datos de productos correctamente expuestos;
- APIs;
- metadatos;
- instrucciones para agentes;
- autenticación;
- permisos;
- capacidad de ejecutar acciones;
- y mecanismos seguros para realizar transacciones.
La página web empieza a parecerse menos a un documento y más a una interfaz que puede ser utilizada tanto por humanos como por máquinas.
Pay Per Crawl: ¿y si la IA tiene que pagar por leer?
Aquí aparece uno de los cambios más interesantes.
Cloudflare está probando Pay Per Crawl, un sistema que permite a los propietarios de sitios cobrar a determinados crawlers de IA por acceder a su contenido.
Actualmente se encuentra en beta cerrada, pero el concepto es bastante claro: el propietario establece un precio y el crawler puede recibir una respuesta HTTP 402 Payment Required indicando que debe pagar para obtener el contenido.
Incluso existe la posibilidad de configurar precios y reglas más avanzadas. Cloudflare documenta actualmente un precio mínimo de US$0.001 por crawl, así como configuraciones dinámicas mediante reglas o Cloudflare Workers.
Esto representa un cambio de paradigma.
Durante años, una gran parte del contenido disponible en Internet se ofreció gratuitamente a los crawlers de los buscadores.
Ahora podemos imaginar un Internet donde:
la información sigue siendo pública para las personas, pero su consumo automatizado puede tener un costo.
Para un sitio pequeño probablemente esto no cambie demasiado.
Pero para un medio especializado, una base de conocimiento, un proveedor de información financiera, una documentación técnica o un sitio con contenido de alto valor, puede convertirse en una nueva fuente de ingresos.
El problema: si bloqueamos demasiado, también podemos desaparecer de la IA
Aquí aparece la otra cara de la moneda.
Controlar los crawlers es poderoso, pero también peligroso.
Si bloqueamos indiscriminadamente a los sistemas de IA, podemos evitar que nuestros contenidos aparezcan en las respuestas que millones de personas reciben directamente desde ChatGPT, Gemini, Google y otros sistemas.
Es decir:
proteger nuestro contenido puede terminar reduciendo nuestra visibilidad.
Por eso el reto no será simplemente bloquear.
Será decidir:
qué permitir, a quién, cuánto y bajo qué condiciones.
Ese equilibrio probablemente se convierta en una nueva disciplina dentro del marketing digital.
Del SEO al AEO
Aquí aparece otro concepto que vale la pena entender: AEO, Answer Engine Optimization.
El SEO tradicional busca posicionar una página para que una persona haga clic sobre ella.
El AEO busca conseguir que la información de una empresa sea utilizada por los motores y agentes de IA cuando generan una respuesta.
La diferencia es enorme.
En el modelo tradicional:
Google → resultados → usuario → clic → página web
En el nuevo modelo:
Usuario → IA → búsqueda/investigación → información de múltiples fuentes → respuesta
En muchos casos el usuario puede recibir la respuesta sin visitar ninguna de las páginas originales.
Eso significa que una empresa puede estar perdiendo tráfico tradicional y, al mismo tiempo, ganando relevancia dentro de las respuestas generadas por IA.
La métrica ya no será únicamente:
“¿Cuántas personas visitaron mi página?”
También tendremos que empezar a preguntar:
“¿Cuántas veces apareció mi empresa dentro de las respuestas de los sistemas de IA?”
El comercio electrónico se vuelve todavía más interesante
Probablemente esta sea la parte con mayor impacto para quienes tenemos tiendas en línea.
Imaginemos el siguiente escenario:
Una persona entra a ChatGPT y escribe:
“Necesito una laptop para edición de video por menos de $25,000.”
El agente analiza productos, características, precios y disponibilidad.
Hasta ahora probablemente terminaba enviando al usuario a diferentes tiendas.
Pero el siguiente paso lógico es mucho más interesante:
el agente puede seleccionar el producto y ejecutar la compra.
Cloudflare está trabajando precisamente en infraestructura para este nuevo modelo de transacciones entre agentes y sitios web.
El protocolo x402, por ejemplo, utiliza el código HTTP 402 Payment Required como mecanismo para solicitar pagos de manera programática.
Esto puede cambiar radicalmente el comercio electrónico.
El usuario ya no necesariamente tendría que:
- entrar a Google;
- buscar una tienda;
- abrir el producto;
- revisar características;
- agregarlo al carrito;
- iniciar checkout;
- pagar.
Podría simplemente decirle a su agente:
“Cómprame la mejor opción que cumpla estas condiciones.”
El agente realizaría buena parte del proceso.
¿Qué significa esto para una tienda en línea?
Significa que tener una tienda bonita ya no será suficiente.
Una tienda tendrá que ser machine-readable y agent-ready.
Sus productos deberán estar correctamente estructurados.
La información deberá ser clara.
Los precios y disponibilidad tendrán que poder consultarse.
Las políticas de envío y devolución deberán estar correctamente expresadas.
Las APIs tendrán cada vez mayor importancia.
Y, eventualmente, el sitio tendrá que ser capaz de aceptar interacciones iniciadas por agentes de forma segura.
Esto puede ser especialmente importante para plataformas como Shopify y otros sistemas de comercio electrónico que ya poseen una infraestructura estructurada.
Una nueva economía del contenido
Pay Per Crawl plantea además otra posibilidad interesante.
Durante años la economía de Internet funcionó aproximadamente así:
contenido → tráfico → publicidad
Pero si los usuarios dejan de visitar directamente las páginas porque obtienen las respuestas de un agente, ese modelo comienza a tener problemas.
El modelo que se está explorando es otro:
contenido → crawler de IA → pago por acceso
Esto podría crear una economía donde el contenido no necesariamente se monetiza mediante anuncios o suscripciones, sino mediante pequeñas transacciones automáticas.
Y aquí aparece algo especialmente interesante:
micropagos entre máquinas.
Una IA puede pagar una fracción de centavo por consultar información.
Otra IA puede pagar por acceder a una base de datos.
Un agente puede pagar por utilizar una API.
Un sistema puede pagar por consultar disponibilidad.
Todo de forma automática.
Ojo: Cloudflare no está haciendo esto por altruismo
Antes de pasar al checklist, una advertencia que vale la pena tener presente.
Cloudflare no está impulsando todo esto por amor al arte ni por el bien de la humanidad. Está posicionándose como la capa de infraestructura de la web agentiva — y convirtiendo esa transición en un embudo de ventas.
Piénsalo con calma. El checker de “agent readiness” te da un score bajo (a mis sitios les puso 20 de 100), te dice exactamente qué te falta, y cada recomendación te apunta a una feature que vive en su capa de negocio: gestión avanzada de bots, WAF, analytics de IA, Pay Per Crawl, Workers. El mensaje implícito es “tu sitio está desactualizado” y la solución que te ofrecen, casi siempre, pasa por su plataforma.
Lo más elegante —y cuestionable— de la estrategia es el ciclo completo:
Cloudflare participa en los borradores de los estándares (DNS-AID, Web Bot Auth, Content Signals), construye la herramienta que te dice que no los cumples, y vende la solución para cumplirlos.
Define el problema, lo mide, y lo resuelve cobrando.
No digo que el tema no sea real. Los agentes de IA ya están navegando la web y los estándares de descubrimiento y acceso son necesarios. Pero conviene saber quién te está midiendo: el que te vende la cinta métrica también te vende la solución.
Mi recomendación práctica: implementa lo que tenga sentido para tu sitio (robots.txt, sitemap, Content Signals, markdown si tu contenido lo amerita), ignora el resto, y no pagues por features de “agent readiness” solo porque un checker te ponga un score bajo. Esos estándares todavía están madurando — el que corre hoy puede no ser el estándar final mañana.
El checklist de Agent Readiness: los 20 puntos
Las herramientas que califican la “preparación para agentes” no evalúan SEO tradicional: evalúan si un agente puede descubrir tu contenido, leerlo de forma barata, respetar tus reglas de acceso, encontrar tus capacidades programáticas (APIs, MCP, skills) y, cada vez más, transaccionar contigo.
Este es el recorrido completo de los 20 puntos que este tipo de herramientas suele verificar, agrupados en cinco categorías. Todos los ejemplos usan dominios ficticios (tudominio.com, ejemplo.com) — reemplázalos por los tuyos.
Contexto rápido: casi todos estos estándares son de 2025-2026 y están en distintas etapas de madurez. Algunos son RFCs consolidados (robots.txt, sitemaps, OAuth discovery), otros son borradores IETF activos (DNS-AID, Web Bot Auth) y otros son propuestas de empresas concretas que están ganando tracción (Markdown para agentes de Cloudflare, MCP de Anthropic, Agent Skills, UCP de Google). No hace falta implementarlos todos: prioriza según se explica al final.
1. Discoverability (Descubribilidad)
Esta categoría responde una pregunta simple: ¿puede un agente encontrar qué contenido tienes y si puede acceder a él, sin tener que adivinar?
1.1 robots.txt
Qué es: el archivo estándar (RFC 9309) que le dice a cualquier crawler o agente qué partes de tu sitio puede o no puede visitar. Sigue siendo la base de todo lo demás: la mayoría de los estándares nuevos de esta lista se anuncian dentro de robots.txt.
Por qué importa: sin él, un agente no tiene ninguna señal explícita de tus reglas y, en el mejor de los casos, asume que todo es visitable; en el peor, algunos agentes serios directamente evitan sitios sin robots.txt por precaución.
Cómo resolverlo: publica https://tudominio.com/robots.txt con al menos:
User-agent: *
Allow: /
Sitemap: https://tudominio.com/sitemap.xml
Un archivo vacío o con solo Disallow: / en User-agent: * bloquea todo, incluidos los agentes que quieres que te encuentren. Revísalo con cuidado si lo heredaste de una migración vieja.
1.2 Sitemap
Qué es: un XML (protocolo sitemaps.org) que lista las URLs de tu sitio, opcionalmente con fecha de última modificación. Le ahorra al agente tener que rastrear enlace por enlace para saber qué páginas existen.
Por qué importa: los agentes tienen presupuestos de tiempo y tokens limitados; un sitemap les permite ir directo a lo relevante en vez de explorar a ciegas.
Cómo resolverlo: genera https://tudominio.com/sitemap.xml (la mayoría de los CMS y frameworks modernos —Next.js, WordPress, Hugo, etc.— lo hacen automáticamente o con un plugin) y referencíalo desde robots.txt como en el ejemplo anterior. Si el sitio es grande, usa un índice de sitemaps (sitemap_index.xml) que apunte a varios archivos.
1.3 Link response headers
Qué es: el header HTTP Link (RFC 8288) que apunta a recursos relacionados directamente desde la respuesta, sin que el agente tenga que parsear el <head> del HTML. Es el mecanismo que usan tanto el API Catalog como la versión en markdown de una página.
Por qué importa: un agente que solo pide HEAD o que consume una respuesta no-HTML (por ejemplo, un PDF o un JSON) igual puede descubrir recursos relacionados leyendo únicamente los headers, sin descargar el cuerpo completo.
Cómo resolverlo: agrega el header en tu servidor o CDN (no requiere tocar plantillas):
Link: </.well-known/api-catalog>; rel="api-catalog",
</llms.txt>; rel="describedby",
</docs/pagina.html.md>; rel="alternate"; type="text/markdown"
Puedes configurarlo a nivel de servidor web (Nginx add_header, reglas de Cloudflare, etc.) sin cambiar el código de la aplicación.
1.4 DNS-AID (DNS for AI Discovery)
Qué es: un borrador IETF (draft-mozleywilliams-dnsop-dnsaid) que usa registros DNS ya existentes (TXT, SVCB, TLSA) para publicar metadatos de descubrimiento de agentes a nivel de dominio, de forma análoga a cómo SPF/DKIM/DMARC usan TXT para email. No inventa tipos de registro nuevos, solo un espacio de nombres convencional dentro de tu zona DNS.
Por qué importa: es un mecanismo de descubrimiento que vive fuera de tu servidor web — funciona incluso si tu sitio está caído o si el “sitio” en cuestión ni siquiera es HTTP (por ejemplo, un servicio interno). También permite pruebas de control de dominio: quien reclama un registro puede demostrar que controla la zona DNS publicando un token temporal en _agents-challenge.tudominio.com.
Cómo resolverlo: es el punto más nuevo e inmaduro de la lista (borrador activo, aún sin RFC final). Si quieres adelantarte, revisa el draft más reciente en el IETF Datatracker antes de publicar registros, porque el formato puede cambiar. Para la mayoría de los sitios, esto puede esperar hasta que el estándar se estabilice; prioriza los puntos 1.1–1.3 primero.
2. Content Accessibility (Accesibilidad del contenido)
No basta con que el agente encuentre tu contenido: si tiene que descargar HTML completo con menús, scripts y estilos para leer tres párrafos de texto, le cuesta tokens (dinero) y contexto (calidad de respuesta). Esta categoría mide si ofreces una versión “liviana” pensada para máquinas.
2.1 Markdown content negotiation
Qué es: cuando un cliente HTTP pide tu página con el header Accept: text/markdown (en vez de o además de text/html), tu servidor responde con una versión en Markdown limpio, sin navegación, scripts ni estilos. Es content negotiation estándar de HTTP aplicado a un caso de uso nuevo. Cloudflare lo popularizó con su función “Markdown for Agents”, que reporta reducciones de hasta 80% en tokens consumidos, y agrega un header x-markdown-tokens para que el agente sepa cuánto contexto va a ocupar antes de descargarlo.
Por qué importa: agentes de código como Claude Code y otros ya envían Accept: text/markdown por defecto. Si tu servidor lo ignora, reciben HTML pesado y gastan su presupuesto de contexto en ruido en lugar de contenido.
Cómo resolverlo: tres caminos, de menor a mayor esfuerzo:
- Si usas Cloudflare, activa “Markdown for Agents” en el dashboard (zona → Agents) — no requiere cambios de código. Ojo: esta feature también es de las que viven tras la capa de negocio de Cloudflare; verifica si está incluida en tu plan antes de asumir que es gratis.
- Si generas contenido estático (docs, blog), publica también un archivo
.mdparalelo a cada página (/docs/pagina/y/docs/pagina.html.md) y anúncialo con el headerLinkdel punto 1.3. - Si tienes control del servidor de aplicaciones, implementa negociación real: detecta
Accept: text/markdown, convierte el contenido (por ejemplo, con una librería tipoturndowno renderizando el Markdown fuente si ya escribes en Markdown) y devuélvelo conContent-Type: text/markdown.
Complementa esto con un archivo /llms.txt en la raíz (formato de lista de lectura para LLMs, ver llmstxt.org) que resuma tu sitio y enlace tus páginas más importantes en Markdown.
3. Bot Access Control (Control de acceso para bots)
Descubribilidad y accesibilidad asumen que quieres que te lean. Esta categoría es lo opuesto: mecanismos para declarar qué agentes pueden hacer qué con tu contenido, con matices que un simple Disallow no puede expresar.
3.1 AI bot rules en robots.txt
Qué es: reglas específicas por user-agent para los crawlers de IA conocidos (GPTBot, ClaudeBot, Google-Extended, PerplexityBot, CCBot, etc.), en vez de una sola regla genérica para *.
Por qué importa: te permite, por ejemplo, permitir que un asistente conversacional lea tu documentación para responder preguntas de usuarios, pero bloquear que un scraper masivo se lleve todo tu catálogo para entrenar un modelo competidor. Sin reglas específicas, todos los bots quedan bajo la misma política.
Cómo resolverlo:
User-agent: GPTBot
Allow: /docs/
User-agent: ClaudeBot
Allow: /
User-agent: CCBot
Disallow: /
Sitemap: https://tudominio.com/sitemap.xml
Mantén la lista actualizada — es habitual que aparezcan agentes nuevos; revisa periódicamente las listas publicadas por cada proveedor de IA.
3.2 Content Signals
Qué es: una extensión de robots.txt (impulsada por Cloudflare junto con editores de contenido, ver contentsignals.org) que separa el acceso (lo que ya cubre robots.txt) del uso posterior del contenido. Declara preferencias sobre tres usos distintos:
User-agent: *
Content-Signal: search=yes, ai-input=no, ai-train=no
Allow: /
search: indexarte y mostrar resultados de búsqueda (enlaces + fragmentos).ai-input: usar tu contenido como entrada en tiempo real (RAG, respuestas generativas con grounding).ai-train: usar tu contenido para entrenar o afinar modelos.
Por qué importa: hoy la mayoría de sitios no tiene forma de decir “está bien que me cites en una respuesta, pero no uses mi contenido para entrenar tu modelo” — Content Signals da ese vocabulario. Ojo: es una señal de preferencia, no una barrera técnica; un bot que la ignore no será bloqueado por esto solo, hay que combinarlo con control de acceso real (WAF, gestión de bots) si necesitas hacerlo cumplir.
Cómo resolverlo: agrega la línea Content-Signal a cada bloque User-agent relevante de tu robots.txt con los valores que reflejen tu política real.
3.3 Web Bot Auth
Qué es: un borrador IETF (con implementación de referencia de Cloudflare) que permite a un bot demostrar criptográficamente su identidad en cada request, usando HTTP Message Signatures (RFC 9421) en vez de confiar en el User-Agent (que cualquiera puede falsificar). El bot firma la request con una clave privada y manda dos headers: Signature-Input (con el key ID y validez temporal) y Signature-Agent (apuntando a dónde está la clave pública, ej. crawler.search.google.com).
Por qué importa: hoy cualquier scraper puede mentir en su User-Agent y hacerse pasar por un bot legítimo (o por un navegador humano). Web Bot Auth cierra esa brecha: solo puedes verificar la firma si el bot realmente tiene la clave privada correspondiente a la identidad que reclama.
Cómo resolverlo: en el servidor, cuando llegue una request con Signature-Input/Signature-Agent, resuelve el directorio de claves públicas del firmante (convención: /.well-known/http-message-signatures-directory) y valida la firma antes de decidir si confías en la identidad declarada. Es más fácil de adoptar si ya usas Cloudflare (tienen soporte nativo) que si tienes que implementar la verificación RFC 9421 a mano; para eso existen implementaciones de referencia en TypeScript y Go publicadas por Cloudflare.
4. Protocol Discovery (Descubrimiento de protocolos y capacidades)
Hasta acá todo es sobre contenido. Esta categoría es sobre capacidades: cómo un agente descubre que tu sitio no solo tiene páginas para leer, sino APIs, herramientas o flujos de autenticación que puede ejecutar.
4.1 MCP Server Card
Qué es: si expones un servidor MCP (Model Context Protocol — el estándar abierto de Anthropic para conectar agentes con herramientas y datos externos), un “Server Card” es un JSON descriptivo publicado en una URL bien conocida que resume qué herramientas ofrece tu servidor, sin que el agente tenga que abrir una sesión JSON-RPC completa solo para averiguarlo.
Por qué importa: reduce el costo de “probar” si tu servidor MCP es relevante para una tarea — un agente (o un directorio de servidores MCP) puede leer el card y decidir si conectarse, en vez de tener que iniciar sesión con cada servidor candidato.
Cómo resolverlo: si ya tienes un servidor MCP corriendo, publica su descripción en:
/.well-known/mcp/server-card.json
(agrega también /.well-known/mcp.json como alias, hay clientes que buscan ese path por compatibilidad). Contenido mínimo: nombre del servidor, descripción, lista de herramientas expuestas (nombre + descripción corta de cada una), tipo de transporte (Streamable HTTP / SSE) y requisitos de autenticación. Incluye headers CORS (Access-Control-Allow-Origin, etc.) para que clientes basados en navegador puedan leerlo.
4.2 Agent Skills
Qué es: un formato abierto (originado en Anthropic, hoy adoptado por decenas de agentes: Claude Code, Cursor, GitHub Copilot, Gemini CLI, VS Code, y muchos más) para empaquetar conocimiento procedimental que un agente puede cargar bajo demanda. La unidad básica es una carpeta con un archivo SKILL.md (metadatos name/description + instrucciones) y, opcionalmente, scripts, referencias y plantillas.
mi-skill/
├── SKILL.md # obligatorio: metadatos + instrucciones
├── scripts/ # opcional
├── references/ # opcional
└── assets/ # opcional
Los agentes las cargan en tres etapas: descubrimiento (leen solo nombre + descripción de cada skill al iniciar), activación (cuando una tarea coincide, cargan el SKILL.md completo) y ejecución (siguen las instrucciones, opcionalmente corriendo scripts).
Por qué importa: te permite publicar “cómo se hacen las cosas en mi producto” de forma que cualquier agente compatible lo entienda, en vez de escribir documentación que cada agente tiene que reinterpretar desde cero.
Cómo resolverlo: publica un índice en /.well-known/agent-skills/index.json que liste tus skills disponibles y dónde descargarlas, y escribe cada SKILL.md siguiendo la especificación abierta (revisa el repositorio del proyecto para el formato exacto — es pequeño y estable).
4.3 WebMCP
Qué es: una API JavaScript nativa del navegador (document.modelContext) que permite a una página registrar herramientas ejecutables en el cliente para que un agente que esté “asistiendo” a un usuario dentro del navegador las descubra y las use, sin necesidad de un servidor MCP separado.
await document.modelContext.registerTool({
name: "agregar-tarea",
description: "Agrega un elemento a la lista de tareas activa del usuario",
inputSchema: {
type: "object",
properties: { texto: { type: "string" } },
required: ["texto"]
},
async execute({ texto }) {
await agregarTareaALaColeccion(texto);
return { content: [{ type: "text", text: `Tarea agregada: "${texto}"` }] };
}
});
El agente descubre las herramientas con document.modelContext.getTools() y las ejecuta con executeTool(...); el navegador media la ejecución respetando el origen y los permisos de la página. También soporta un modo declarativo que sintetiza herramientas automáticamente a partir de formularios <form> estándar.
Por qué importa: es el equivalente de MCP pero para interacciones del lado del cliente — útil cuando la acción depende del estado actual de la página (un carrito, un formulario a medio llenar) y no tiene sentido modelarla como un endpoint de servidor independiente.
Cómo resolverlo: identifica las acciones más comunes que un usuario (o un agente en su nombre) realiza en tu interfaz y expónlas con registerTool(). Es una propuesta relativamente nueva — revisa el estado actual de soporte en navegadores antes de depender de ella como único mecanismo.
4.4 API Catalog
Qué es: un JSON (RFC 9727) publicado en /.well-known/api-catalog que lista todas tus APIs públicas con enlaces a su especificación (OpenAPI, GraphQL schema, etc.), documentación y endpoint de estado.
Por qué importa: hoy, si un agente quiere saber “¿esta empresa tiene una API para X?”, tiene que buscar en tu sitio de marketing o adivinar URLs comunes (/api/docs, /developers…). El catálogo le da una única URL predecible.
Cómo resolverlo: publica un JSON mínimo así:
{
"linkset": [
{
"anchor": "https://tudominio.com/.well-known/api-catalog",
"service-desc": [
{ "href": "https://tudominio.com/openapi.json", "title": "API principal" }
],
"service-doc": [
{ "href": "https://tudominio.com/docs/api", "title": "Documentación" }
]
}
]
}
y anúncialo con el header Link del punto 1.3 para que se descubra sin tener que adivinar la ruta.
4.5 OAuth discovery
Qué es: metadatos publicados en una URL bien conocida (RFC 8414, /.well-known/oauth-authorization-server) que describen tu servidor de autorización OAuth: endpoints de autorización, token, revocación, algoritmos soportados, etc.
Por qué importa: permite que un agente configure un flujo OAuth completo contra tu servicio de forma automática, sin que un humano tenga que leer tu documentación y copiar URLs a mano.
Cómo resolverlo: si ya implementas OAuth 2.0/2.1, la mayoría de los frameworks de identidad (Auth0, Okta, WorkOS, Keycloak, tu propio Authorization Server) ya generan este documento automáticamente. Verifica que sea accesible públicamente en https://tudominio.com/.well-known/oauth-authorization-server y que esté actualizado.
4.6 OAuth Protected Resource
Qué es: el complemento del punto anterior (RFC 9728), publicado en /.well-known/oauth-protected-resource. Mientras que el discovery de arriba describe el servidor de autorización, este describe el recurso protegido: qué servidor de autorización acepta, qué scopes soporta, y cómo debe presentarse un token para acceder.
Por qué importa: es la pieza que le dice a un agente “para acceder a este recurso necesitas un token de tal tipo, emitido por tal authorization server, con tales scopes” — sin esto, un agente tiene que fallar una petición primero (recibir un 401) y adivinar qué hacer.
Cómo resolverlo: expón el metadata de Protected Resource junto al de tu API, siguiendo RFC 9728. Si usas un proveedor de identidad gestionado, revisa si ya lo genera (muchos lo hacen desde 2025 en adelante, dado que es la base del punto siguiente, auth.md).
4.7 Auth.md
Qué es: un protocolo abierto propuesto por WorkOS: un archivo Markdown simple, publicado en tu dominio (/auth.md), que describe en lenguaje estructurado (pero legible tanto por humanos como por agentes) cómo un agente puede registrarse en tu plataforma en nombre de un usuario — qué flujos soporta, qué scopes existen, cómo se emiten, auditan y revocan credenciales. No depende de infraestructura de WorkOS: compone estándares OAuth ya existentes (Protected Resource Metadata del punto 4.6, más un bloque agent_auth dentro del metadata del Authorization Server del punto 4.5, con campos como register_uri, claim_uri, revocation_uri).
Por qué importa: hoy, para que un agente se autentique “en nombre de” un usuario en tu plataforma, casi siempre hay un humano llenando un formulario de OAuth app o generando un API key a mano. auth.md estandariza ese flujo para que un agente lo lea y lo ejecute solo.
Cómo resolverlo: publica /auth.md en la raíz de tu dominio describiendo tus flujos de registro de agentes (puedes basarte en la especificación abierta del proyecto en GitHub), y asegúrate de que el agent_auth correspondiente esté presente en tu metadata OAuth (puntos 4.5 y 4.6) — el archivo Markdown es la puerta de entrada legible, pero la fuente de verdad “machine-readable” vive en esos dos JSON.
4.8 ARD manifest (Agentic Resource Discovery)
Qué es: un manifiesto JSON, publicado en /.well-known/ai-catalog.json, que actúa como índice general de todos los “artefactos” agentivos que ofreces — server cards de MCP, agent cards de A2A, skills, APIs — en un solo lugar, en vez de que el agente tenga que conocer de antemano cada .well-known específico de esta lista.
Por qué importa: con tantos estándares distintos (MCP, Agent Skills, APIs, OAuth…), ARD busca ser el “índice de índices”: un agente que solo conoce esta URL puede descubrir todo lo demás.
Cómo resolverlo: publica un JSON con esta forma:
{
"specVersion": "1.0",
"host": { "displayName": "Tu Empresa" },
"entries": [
{
"identifier": "urn:air:tudominio.com:tools:soporte",
"displayName": "Herramienta de soporte",
"type": "application/mcp-server-card+json",
"url": "https://tudominio.com/.well-known/mcp/server-card.json",
"description": "Consulta y actualiza tickets de soporte"
}
]
}
Cada entry apunta (via url o embebido en data) a uno de los otros artefactos que ya publicaste en los puntos anteriores — no es una implementación aparte, es un índice de lo que ya tienes.
5. Commerce (Comercio agéntico)
La categoría más nueva y menos estandarizada: protocolos para que un agente compre o pague sin intervención humana en cada paso. Todavía compiten varias propuestas; vale la pena conocerlas aunque no implementes ninguna todavía.
- x402: revive el código de estado HTTP 402 (“Payment Required”). Cuando un agente pide un recurso de pago, el servidor responde
402con instrucciones de pago; el agente firma una transacción (típicamente en stablecoins, ej. USDC) y reintenta la petición con la prueba de pago adjunta. Pensado para micropagos por request (por ejemplo, cobrar por llamada a una API o a un servidor MCP). Gobernado hoy por la x402 Foundation (Linux Foundation). - MPP (Machine Payments Protocol): de Stripe y Tempo. Modelo de “sesiones”: el agente pre-autoriza un límite de gasto y luego puede hacer micropagos continuos (stablecoins o fiat) dentro de ese límite, sin re-autorizar cada transacción.
- UCP (Universal Commerce Protocol): de Google, con Shopify, Etsy, Wayfair, Target y otros. Cubre todo el journey de compra (descubrimiento, checkout, postventa) mediante “Capabilities” que el comercio implementa; el comercio sigue siendo el “merchant of record”. Compatible con A2A, AP2 y MCP.
- ACP (Agentic Commerce Protocol): de Stripe y OpenAI (usado en el Instant Checkout de ChatGPT). Se enfoca específicamente en el paso de checkout dentro de una conversación, sin redirigir al usuario fuera del chat.
Cómo resolverlo: si vendes algo y tu público incluye compradores que usan asistentes de IA (o planeas ese caso de uso), evalúa integrar UCP o ACP según con qué plataformas quieras aparecer (Google vs. ChatGPT, respectivamente); si vendes acceso a una API o a un servidor MCP por uso, x402 o MPP son la opción más directa. No son mutuamente excluyentes: varios de estos protocolos están pensados para interoperar (x402 ya forma parte de AP2, la iniciativa paraguas de Google).
¿Nos ayuda o nos afecta?
La respuesta corta es:
las dos cosas.
Nos ayuda porque…
Cloudflare nos proporciona herramientas para:
- identificar crawlers de IA;
- controlar su acceso;
- bloquearlos cuando sea necesario;
- medir su actividad;
- preparar nuestros sitios para agentes;
- monetizar determinados accesos;
- y comenzar a construir una infraestructura preparada para transacciones máquina-a-máquina.
Para desarrolladores, agencias y propietarios de sitios esto abre un nuevo campo de trabajo.
Ya no hablamos únicamente de hacer SEO.
Podemos hablar de auditorías de preparación para IA, optimización para agentes, integración de APIs, automatización y comercio agentivo.
Pero también nos afecta porque…
El tráfico tradicional puede perder importancia.
Un usuario puede obtener nuestra información sin entrar a nuestra página.
Una IA puede consumir nuestro contenido miles de veces.
Nuestro contenido puede terminar alimentando respuestas de terceros.
Y si no estructuramos correctamente la información, nuestros competidores podrían ser recomendados por los agentes mientras nosotros quedamos fuera.
Por eso hay una nueva batalla por la visibilidad.
Antes queríamos aparecer en Google.
Ahora queremos aparecer en las respuestas de las máquinas.
Por dónde empezar (prioridad recomendada)
No hace falta implementar los 20 puntos de una sola vez. Un orden razonable, de mayor a menor impacto por esfuerzo invertido:
- robots.txt válido + reglas por bot de IA + directiva de sitemap (1.1, 1.3 combinado con 3.1) — es la base, cuesta minutos y ya cubre lo más consultado.
- Sitemap.xml actualizado (1.2).
- Content Signals en robots.txt (3.2) — declarar tu postura sobre entrenamiento vs. uso en tiempo real es cada vez más relevante y es una sola línea por bloque.
- Markdown negotiation / llms.txt (2.1) — si tienes documentación técnica o contenido largo, el ahorro de tokens es el punto con mejor relación esfuerzo/beneficio después de robots.txt.
- Recién después, si tu sitio expone APIs, MCP o flujos de autenticación para agentes: API Catalog, MCP Server Card, OAuth discovery/Protected Resource, Agent Skills y auth.md (todo el bloque 4), en el orden que corresponda a lo que ya tengas construido (no publiques un OAuth discovery si no tienes servidor OAuth, por ejemplo).
- Web Bot Auth, DNS-AID, ARD manifest y comercio (3.3, 1.4, 4.8, categoría 5) son los más nuevos e inmaduros — vale la pena monitorearlos, pero no son todavía un estándar consolidado como para tratarlos como urgentes.
La mayoría de estos hallazgos no requieren rehacer nada: son archivos estáticos, headers de servidor o un bloque de configuración adicional sobre infraestructura que probablemente ya existe.
El verdadero cambio no es Cloudflare
Y aquí está, probablemente, la conclusión más importante.
El cambio no consiste realmente en que Cloudflare haya lanzado algunas herramientas nuevas.
El cambio es que Internet está incorporando un nuevo tipo de usuario.
Primero construimos la Web para leer.
Después construimos la Web para participar.
Ahora estamos construyendo una Web donde las máquinas pueden actuar.
Eso significa que una página web del futuro probablemente tendrá que cumplir dos funciones simultáneamente:
ser una interfaz para humanos y una interfaz para agentes.
Y eventualmente puede que ni siquiera pensemos en ella como una “página”.
Podría ser simplemente una capa de servicios que permite que humanos y agentes consulten información, ejecuten acciones y realicen transacciones.
Cloudflare está apostando precisamente por esa transición.
Y para quienes desarrollamos sitios web, tiendas en línea y sistemas digitales, la señal es bastante clara:
no deberíamos esperar a que la web agentiva sea el estándar para empezar a prepararnos.
Porque, en realidad, ya empezó.
Si te quedó la curiosidad de saber qué tan lista está tu propia página, puedes validarla tú mismo: isitagentready.com/tudominio.com (reemplaza tudominio.com por tu dominio) te da un score y te recorre el checklist completo de agent readiness, punto por punto. Tómalo con pinzas — es una herramienta de Cloudflare y su intención comercial quedó clara en este artículo — pero como punto de partida para ver qué te falta y por dónde empezar, funciona bien. Y recuerda: no necesitas cumplir los 20 puntos, solo los que tengan sentido para tu sitio.