La web siempre ha tenido que adaptarse a nuevos estándares. Aprendió a hablar con los navegadores web, y luego con los motores de búsqueda. Ahora necesita hablar con los agentes de IA.
Hoy nos complace anunciar isitagentready.com, una nueva herramienta para ayudar a los propietarios de sitios web a entender cómo pueden optimizar sus sitios para los agentes, desde guiar a los agentes sobre cómo autenticarse hasta controlar qué contenido pueden ver, el formato en el que lo reciben y cómo lo pagan. También vamos a añadir un nuevo conjunto de datos a Cloudflare Radar que mide la adopción generalizada para cada estándar de agente en Internet.
Queremos predicar con el ejemplo. Por eso también queremos contarte cómo hemos renovado recientemente la documentación para desarrolladores de Cloudflare para convertirla en el sitio de documentación más fácil de usar para los agentes, lo que permite que las herramientas de IA respondan a las preguntas más rápido y a un coste mucho menor.
¿Está preparada la web actual para los agentes?
La respuesta corta es: no mucho. Esto era de esperar, pero también muestra lo mucho más eficaces que pueden ser los agentes hoy en día, si se adoptan unos estándares.
Para analizar esta cuestión, Cloudflare Radar seleccionó los 200 000 dominios más visitados de Internet, descartó las categorías en las que la preparación de los agentes no es importante (como redireccionamientos, servidores de anuncios y servicios de tunelización) para centrarse en las empresas, los editores y las plataformas con las que los agentes de la IA podrían necesitar interactuar de forma realista, y los analizó utilizando nuestra nueva herramienta.
El resultado es un nuevo gráfico titulado "Adopción de estándares para agentes de IA", que ahora puedes encontrar en la página "Información sobre la IA de Cloudflare Radar", donde podemos medir la adopción de cada estándar en múltiples categorías de dominios.
Si miramos cada uno de los aspectos, hay algunas cosas que llaman la atención:
robots.txt es casi universal, el 78 % de los sitios web tiene uno, pero la gran mayoría está diseñado para rastreadores de motores de búsqueda tradicionales y no para agentes de IA.
Señales de contenido: el 4 % de los sitios ha declarado sus preferencias de uso de la IA en robots.txt. Se trata de un nuevo estándar que está ganando terreno.
La negociación de contenido Markdown (servir "text/markdown" cuando se acepta "text/markdown") funciona en el 3,9 % de los sitios web.
Los nuevos estándares emergentes, como las tarjetas de servidor MCP y los catálogos de API (RFC 9727), aparecen en menos de 15 sitios de todo el conjunto de datos. Todavía es pronto. Hay muchas oportunidades para destacar si te conviertes en uno de los primeros sitios en adoptar nuevos estándares y trabajar bien con los agentes.
Este gráfico se actualizará semanalmente y los datos también se pueden consultar a través de Data Explorer o la API de Radar.
Puntuación de preparación de agentes para tu sitio
Puedes obtener una puntuación de preparación para agentes de tu propio sitio web entrando en isitagentready.com e introduciendo la URL del sitio.
Las puntuaciones y las auditorías que ofrecen comentarios útiles ya han contribuido anteriormente a impulsar la adopción de nuevos estándares. Por ejemplo, Google Lighthouse evalúa los sitios web en base a las prácticas recomendadas sobre rendimiento y seguridad, y ayuda a los propietarios del sitio a adoptar los estándares de la última plataforma web. Creemos que algo similar debería existir para ayudar a los propietarios de sitios a adoptar prácticas recomendadas para agentes.
Cuando entras en tu sitio web, Cloudflare le envía solicitudes para comprobar qué estándares admite y te da una puntuación basada en cuatro aspectos:
Captura de pantalla de los resultados de una comprobación de compatibilidad con agentes para un sitio web de ejemplo.
Además, comprobamos si el sitio es compatible con los estándares de comercio agéntico, como x402, el Protocolo de comercio universal y el Protocolo de comercio Agéntico, pero estos no se tienen en cuenta actualmente a la hora de calcular la puntuación.
De cada comprobación fallida, ofrecemos una instrucción que puedes dar a tu agente de codificación para que implemente lo que necesitas.
La propia web también está preparada para los agentes, lo que demuestra que predicamos con el ejemplo. Expone un servidor MCP sin estado (https://isitagentready.com/.well-known/mcp.json) con scan_site, una herramienta con acceso HTTP Streamable, para que cualquier agente compatible con MCP analice sitios web de forma programada sin utilizar la interfaz web. Además, publica un índice de aptitudes de los agentes (https://isitagentready.com/.well-known/agent-skills/index.json) con documentos sobre aptitudes de cada estándar que verifica, de modo que los agentes no solo sepan qué hay que corregir, sino también cómo hacerlo.
Veamos las comprobaciones de cada categoría y su importancia para los agentes.
El archivo robots.txt está disponible desde 1994, y la mayoría de los sitios tienen uno. Tiene dos funciones para los agentes: define las reglas de rastreo (quién puede acceder a qué) y señala tus mapas del sitio. Un mapa del sitio es un archivo XML que recoge todas las rutas de tu sitio web; básicamente, es un mapa que los rastreadores pueden seguir para descubrir todo tu contenido sin tener que rastrear cada enlace. El archivo robots.txt es lo primero que miran los agentes.
Más allá de los mapas del sitio, los agentes también pueden detectar recursos importantes directamente de los encabezados de la respuesta HTTP, concretamente, mediante el uso del encabezado de respuesta Link (RFC 8288). A diferencia de los enlaces ocultos en HTML, el encabezado Link forma parte de la propia respuesta HTTP, lo que significa que un agente puede encontrar enlaces a recursos sin tener que analizar ningún código de marcado:
HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"
Accesibilidad del contenido
Conseguir que un agente esté en tu sitio web es una cosa. Asegurarse de que realmente pueda leer tu contenido es otro tema.
Allá por septiembre de 2024, que parece que fue hace una eternidad teniendo en cuenta lo rápido que avanza la IA, se propuso llms.txt como una forma de ofrecer una representación de un sitio web adaptada a los modelos de lenguaje de gran tamaño (LLM) y que encajara en la ventana de contexto del modelo. llms.txt es un archivo de texto sin formato situado en el directorio raíz de tu sitio web que ofrece a los agentes una lista de lectura estructurada: qué es el sitio, qué contiene y dónde se encuentra el contenido importante. Es como un mapa del sitio hecho para que lo lea un LLM, no un índice:
# My Site
> A developer platform for building on the edge.
## Documentation
- [Getting Started](https://example.com/docs/start.md)
- [API Reference](https://example.com/docs/api.md)
## Changelog
- [Release Notes](https://example.com/changelog.md)
La negociación del contenido de Markdown va aún más lejos. Cuando un agente obtiene una página cualquiera y envía un encabezado Accept: text/markdown, el servidor responde con una versión de markdown limpio en lugar de HTML. La versión en Markdown requiere muchos menos tokens, en algunos casos hemos medido una reducción de hasta el 80 % en el número de tokens, lo que hace que las respuestas sean más rápidas, más económicas y que sea más probable que se lean en su totalidad, teniendo en cuenta los límites de las ventanas de contexto que la mayoría de las herramientas de agentes tienen por defecto.
De forma predeterminada, solo comprobamos si el sitio gestiona correctamente la negociación de contenido de markdown y no comprobamos llms.txt. Puedes personalizar el análisis para que incluya llms.txt si lo deseas.
Control de acceso de bots
Ahora que los agentes pueden navegar por tu sitio y consumir tu contenido, la pregunta es: ¿quieres que cualquier bot lo haga?
robots.txt no solo redirige al mapa del sitio. También es donde defines tus reglas de acceso. Puedes declarar específicamente cuáles son los rastreadores que permites y qué pueden consultar, con detalles sobre rutas específicas. Esta norma está bien establecida y sigue siendo lo primero que consulta cualquier bot que se precie antes de empezar a rastrear.
Las señales de contenido te permiten ser más específico. En lugar de simplemente permitir o bloquear, puedes declarar exactamente qué puede hacer la IA con tu contenido. Si usas una directiva Content-Signal en tu archivo robots.txt, podrás controlar de forma independiente tres cosas: si tu contenido se puede utilizar para el entrenamiento de la IA (ai-train), si puede utilizarse como entrada de la IA para inferencias y fundamentos (ai-input) y si debe aparecer en los resultados de búsqueda (search):
User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes
Por el contrario, el borrador de norma IETF Web Bot Auth permite que los bots benignos se autentiquen, y permite que los sitios web que reciben solicitudes de bots los identifiquen. El bot firma sus solicitudes HTTP y el sitio de recepción verifica esas firmas con las claves públicas publicadas del bot.
Las claves públicas se encuentran en un punto final conocido, /.well-known/http-message-signatures-directory, que comprobamos como parte del análisis.
No todos los sitios necesitan implementarlo. Si tu sitio solo sirve contenido y no realiza peticiones a otros sitios, no lo necesitas. Pero, dado que cada vez más sitios web utilizan sus propios agentes para enviar solicitudes a otros sitios, creemos que esto cobrará cada vez más importancia con el tiempo.
Más allá del consumo pasivo de contenido, los agentes también pueden interactuar directamente con tu web mediante llamadas a las API, la invocación de herramientas y la ejecución de tareas de manera autónoma.
Si tu servicio tiene una o más API públicas, el Catálogo de API (RFC 9727) ofrece a los agentes una única ubicación conocida para detectarlas todas. Alojado en /.well-known/api-catalog, enumera tus API y enlaza con sus especificaciones, documentación y puntos finales de estado, sin que los agentes tengan que rastrear tu portal de desarrolladores o leer tu documentación.
No podemos hablar de agentes sin mencionar a MCP. El Protocolo de contexto del modelo es un estándar abierto que permite a los modelos de IA conectarse con fuentes de datos y herramientas externas. En lugar de crear una integración personalizada para cada herramienta de IA, solo tienes que crear un servidor MCP y cualquier agente compatible podrá usarlo.
Para ayudar a los agentes a encontrar tu servidor MCP, puedes publicar una tarjeta de servidor MCP (propuesta que se encuentra actualmente en borrador). Se trata de un archivo JSON en /.well-known/mcp/server-card.json que describe tu servidor antes de que un agente siquiera se conecte: qué herramientas expone, cómo acceder a él y cómo autenticarlo. Un agente lee este archivo y sabe todo lo que necesita para empezar a utilizar tu servidor:
{
"$schema": "https://static.modelcontextprotocol.io/schemas/mcp-server-card/v1.json",
"version": "1.0",
"protocolVersion": "2025-06-18",
"serverInfo": {
"name": "search-mcp-server",
"title": "Search MCP Server",
"version": "1.0.0"
},
"description": "Search across all documentation and knowledge base articles",
"transport": {
"type": "streamable-http",
"endpoint": "/mcp"
},
"authentication": {
"required": false
},
"tools": [
{
"name": "search",
"title": "Search",
"description": "Search documentation by keyword or question",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string" }
},
"required": ["query"]
}
}
]
}
Los agentes obtienen mejores resultados cuando poseen Aptitudes de agente que les ayudan a estar a la altura de tareas específicas. Sin embargo, ¿cómo pueden saber qué aptitudes le ofrece un sitio web? Hemos propuesto que los sitios puedan proporcionar esta información en el punto final .well-known/agent-skills/index.json, que informa a los agentes sobre las aptitudes disponibles y su ubicación. Es posible que observes que .well-known estándar (RFC 8615) es utilizado por muchas otras normas de agentes y autorización. Gracias a Mark Nottingham, de Cloudflare, que redactó este estándar, y a otros colaboradores del IETF.
Muchos sitios te piden que accedas con tus credenciales para poder acceder a ellos. Esto dificulta que los humanos otorguen a los agentes la capacidad de acceder a estos sitios en su nombre, y es por eso que algunos han adoptado la solución alternativa, posiblemente insegura, de dar a los agentes acceso al navegador web del usuario, con su sesión iniciada.
Hay una manera mejor en la que los humanos podrían conceder el acceso de forma explícita: los sitios que admiten OAuth pueden decir a los agentes dónde encontrar el servidor de autorización (RFC 9728), lo que permite a los agentes guiar a los humanos a través de un flujo de autorización de OAuth en el que pueden elegir conceder acceso al agente. En Agents Week 2026 anunciamos que Cloudflare Access ahora admite de forma completa este flujo de OAuth, y mostramos cómo agentes como OpenCode pueden aprovechar este estándar para que todo funcione sin problemas cuando los usuarios facilitan a los agentes URL protegidas:
Los agentes también pueden comprar cosas en tu nombre, pero los pagos en la web estaban concebidos para humanos. Añade al carrito, introduce una tarjeta de crédito y haz clic en pagar. Este flujo se interrumpe por completo cuando el comprador es un agente de IA.
x402 resuelve esto a nivel de protocolo recuperando el código de estado HTTP 402 Pago requerido, que existe en la especificación desde 1997 pero que nunca se utilizó de forma generalizada. El proceso es sencillo: un agente solicita un recurso, el servidor responde con un 402 y una carga útil legible por máquina que describe las condiciones de pago, el agente paga y vuelve a intentarlo. Cloudflare se asoció con Coinbase para crear la x402 Foundation, cuya misión es fomentar la adopción del sistema x402 como estándar abierto para los pagos en Internet.
También comprobamos el Protocolo de Comercio Universal y el Protocolo de Comercio Agéntico —dos estándares de comercio basados en agentes emergentes, diseñados para permitir a los agentes encuentren y compren productos que los humanos comprarían normalmente a través de tiendas de comercio electrónico y procesos de pago.
Incorporación de la disponibilidad de los agentes en Cloudflare URL Scanner
URL Scanner de Cloudflare te permite enviar cualquier URL y obtener un informe detallado: encabezados HTTP, certificados TLS, registros DNS, tecnologías utilizadas, datos de rendimiento y señales de seguridad. Es una herramienta fundamental para los investigadores de seguridad y los desarrolladores que quieren entender qué está haciendo realmente una URL internamente.
Hemos tomado las mismas verificaciones de isitagentready.com y las hemos añadido a URL Scanner con una nueva pestaña de preparación para agentes. Cuando analices una URL, ya verás todo su informe de preparación para agentes, además del análisis existente: qué comprobaciones se han superado, en qué nivel se encuentra el sitio y consejos prácticos para mejorar tu puntuación.
La integración también está disponible programáticamente a través de la API de URL Scanner. Para incluir los resultados de la preparación del agente en un análisis, incluye la opción agentReadiness en tu solicitud de análisis:
curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/urlscanner/v2/scan \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
-d '{
"url": "https://www.example.com",
"options": {"agentReadiness": true}
}'
Predicamos con el ejemplo | Actualización de la documentación de Cloudflare
Cuando creamos las herramientas para medir el grado de preparación de Internet, sabíamos que teníamos que asegurarnos de que nuestra propia casa estuviera en orden. Nuestros documentos deben ser fáciles de entender para los agentes que utilizan nuestros clientes.
Naturalmente, adoptamos los estándares relevantes del sitio de contenido mencionados anteriormente y puedes comprobar nuestra puntuación aquí. Pero no nos quedamos ahí. Aquí te explicamos cómo mejoramos los documentos para desarrolladores de Cloudflare para que sean el recurso más fácil de usar para los agentes en la web.
URL de contingencia con el uso de archivos index.md
Desgraciadamente, a partir de febrero de 2026, de los siete agentes probados, solo Claude Code, OpenCode y Cursor solicitan contenidos con el encabezado Accept: text/markdown por defecto. Para el resto, necesitábamos un sistema de respaldo basado en URL sin interrupciones.
Para hacerlo, ponemos todas las páginas a disposición por separado a través de Markdown en /index.md en relación con la URL de la página. Para hacerlo de forma dinámica, sin duplicar archivos estáticos, combinamos dos reglas de Cloudflare:
Con estas dos reglas, cualquier página puede obtenerse como Markdown al añadir la ruta /index.md a la URL:
Apuntamos a estas URL /index.md en nuestros archivos llms.txt. De manera efectiva, para estas rutas /index.md, siempre retornamos markdown, independientemente de los encabezados que el cliente establezca. Lo hacemos sin ningún paso de compilación adicional ni duplicación de contenido.
Crear archivos llms.txt efectivos para sitios grandes
llms.txt sirve de "base principal" para los agentes, proporcionando un directorio de páginas para ayudar a los LLM a encontrar contenido. Sin embargo, 5000 páginas de documentación en un único archivo superarán las ventanas de contexto de los modelos.
En lugar de un único archivo masivo, generamos un archivo llms .txt separado por cada directorio de nivel superior en nuestros documentos, y la raíz llms .txt simplemente apunta a estos subdirectorios.
También eliminamos cientos de páginas de listas de directorios que aportan poco valor semántico a un LLM y garantizamos que cada página tenga un contexto descriptivo enriquecido (títulos, nombres semánticos y descripciones).
Por ejemplo, omitimos unas 450 páginas que solo sirven como listas de directorios localizadas, por ejemplo, https://developers.cloudflare.com/workers/databases/.
Esas páginas aparecen en nuestro mapa del sitio, pero contienen muy poca información para un LLM. Dado que todas las páginas secundarias ya están enlazadas individualmente en llms.txt, la recuperación de una página de directorio solo proporciona una lista redundante de enlaces, obligando al agente a realizar otra solicitud para encontrar el contenido real.
Para ayudar a los agentes a navegar de manera eficiente, cada entrada del llms.txt debe estar bien contextualizada pero ser ligera en cuanto a unidades de información. Puede que los humanos pasemos por alto los datos preliminares y las etiquetas de filtrado, pero para un agente de IA, estos metadatos son como el volante. Por eso nuestro equipo de Experiencia de Contenido de producto (PCX) ha optimizado los títulos, las descripciones y las estructuras de las URL de nuestras páginas, para que los agentes siempre sepan exactamente qué páginas deben recuperar.
Echa un vistazo a una sección de nuestro llms.txt en el directorio raíz.
Cada enlace tiene un nombre semántico, una URL asociada y una descripción de gran valor. Nada de esto requirió trabajo adicional para la generación de llms.txt. Todo ya estaba disponible en los metadatos iniciales de los documentos. Lo mismo sucede con las páginas de los archivos llms.txt del directorio de nivel superior. Todo este contexto facilita a los agentes encontrar información relevante de manera más eficiente.
Además, ponemos a prueba nuestros documentos con la especificación afdocs, una emergente especificación de documentación concebida para facilitar su uso por parte de agentes y un proyecto de código abierto que permite a los equipos probar sus sitios de documentación para aspectos como descubrimiento de contenido y navegación. Esta especificación nos ha permitido crear nuestras propias herramientas de auditoría personalizadas. Al añadir algunas revisiones específicas para nuestro caso de uso, creamos un panel de control para facilitar la evaluación.
Resultados de la comparativa: más rápido y más barato
Apuntamos un agente (Kimi-k2.5 a través de OpenCode) en los archivos llms.txt de otros grandes sitios de documentación técnica, y le pedimos al agente que respondiera preguntas técnicas muy específicas.
De media, el agente que utiliza la documentación de Cloudflare consumió un 31 % menos de tokens y llegó a la respuesta correcta un 66 % más rápido que el sitio medio no optimizado para agentes. Como nuestros catálogos de productos se muestran en ventanas de contexto únicas, los agentes pueden identificar la página exacta que necesitan y acceder a ella siguiendo una ruta única y lineal.
La estructura facilita la velocidad
La precisión de las respuestas de los LLM suele ser un subproducto de la eficacia de la ventana de contexto. Durante nuestras pruebas, observamos un patrón recurrente en otros conjuntos de documentación.
El bucle de grep: muchos sitios web de documentación ofrecen un archivo llms.txt único e inmenso que supera la ventana de contexto del agente. Como el agente no puede "leer" todo el archivo, empieza a buscar palabras clave con grep. Si la primera búsqueda no encuentra el detalle concreto, el agente debe pensar, perfeccionar su búsqueda y volver a intentarlo.
Contexto más reducido y menor precisión: si un agente se basa en la búsqueda iterativa en lugar de leer el archivo completo, pierde el contexto más amplio de la documentación. Esta visión fragmentada hace que los agentes tengan una comprensión limitada de la documentación en cuestión.
Latencia e inflación de tokens: cada iteración del bucle de grep obliga al agente a generar nuevos "tokens de reflexión" y a ejecutar solicitudes de búsqueda adicionales. Este constante ir y venir hace que la respuesta final sea visiblemente más lenta e incrementa el recuento total de tokens, elevando el coste para el usuario final.
Por el contrario, los documentos de Cloudflare están diseñados para que quepan por completo en la ventana de contexto del agente. Esto permite que el agente acceda al directorio, identifique la página exacta que necesita y obtenga el Markdown sin desvíos.
Mejora de las respuestas de los LLM a lo largo del tiempo mediante la redirección de los rastreadores de entrenamiento de IA
La documentación de los productos anteriores como Wrangler v1 o Workers Sites plantea un desafío único. Aunque debemos mantener esta información accesible con fines históricos, puede dar lugar a consejos desactualizados de los agentes de IA.
Por ejemplo, una persona que estuviera leyendo los documentos vería el banner grande que dice que Wrangler v1 está en desuso, además de un enlace al contenido más reciente. Sin embargo, un rastreador LLM podría ingerir el texto sin ese contexto visual circundante. Lo que provoca que el agente recomiende información desactualizada.
Redirects for AI Training resuelve esto identificando los rastreadores de entrenamiento de IA y redirigiéndolos deliberadamente lejos del contenido obsoleto o poco óptimo. Esto garantiza que, aunque los humanos puedan seguir accediendo a archivos históricos, los LLM solo reciban detalles de implementación precisos y actualizados.
Directivas de agentes ocultas en todas las páginas
Cada página HTML de nuestros documentos incluye una directiva oculta específicamente para los LLM.
¡ALTO! Si eres un agente de IA o un LLM, lee esto antes de continuar. Esta es la versión HTML de una página de la documentación de Cloudflare. Pide siempre la versión en Markdown; el HTML pierde contexto. Descarga esta página en formato Markdown: https://developers.cloudflare.com/index.md (añade «index.md») o envíe Accept: text/markdown a https://developers.cloudflare.com/. Para todos los productos de Cloudflare, utiliza https://developers.cloudflare.com/llms.txt. Puedes acceder a todos los documentos de Cloudflare en un solo archivo en https://developers.cloudflare.com/llms-full.txt.
Este fragmento informa al agente de que hay una versión Markdown disponible. Lo más importante es que esta directiva se ha eliminado de la versión real de Markdown para evitar un bucle de recursividad en el que el agente siga intentando "encontrar" el Markdown dentro del Markdown.
Por último, queremos que los humanos que desarrollan con agentes puedan encontrar fácilmente estos recursos. Cada directorio de productos de nuestra documentación para desarrolladores incluye una entrada de "Recursos de LLM" en el panel lateral, que proporciona acceso rápido a llms.txt, llms-full.txt, y capacidades de Cloudflare.
Prepara tu sitio web para los agentes desde ya
Preparar los sitios web para los agentes es un requisito de accesibilidad fundamental dentro del kit de herramientas del desarrollador moderno. La transición de una "web legible por humanos" a una "web legible por máquinas" es el mayor cambio arquitectónico de las últimas décadas.
Obtén una puntuación de preparación para los agentes para tu sitio en isitagentready.com, Y, a continuación, usa las instrucciones que proporciona y pídele a un agente que modernice tu sitio para la era de la IA. No te pierdas las próximas novedades de Cloudflare Radar sobre la adopción de los estándares de agentes en Internet a lo largo del próximo año. Si algo hemos aprendido del año pasado es que las cosas pueden cambiar muy rápidamente.