Cloudflare califica su sitio en la era de los agentes IA con la Puntuación de Preparación de Agentes

Los sitios web aprendieron a hablar con los navegadores y luego con los motores de búsqueda. Cloudflare considera que ahora deben aprender a hablar con los agentes de IA, y lanza una herramienta para ayudarles. Es una iniciativa ambiciosa, pero que plantea tantas preguntas como resuelve.

Una herramienta de calificación para un problema real

El punto de partida de Cloudflare es sólido. Cuando un agente de IA como Claude, Cursor u OpenCode intenta acceder a un sitio web para leer documentación, comprar un producto o interactuar con una API, se encuentra con una infraestructura pensada para humanos: HTML denso, formularios, sesiones de navegación, captchas. El resultado son agentes lentos, costosos en tokens y a menudo imprecisos.

Para medir la magnitud del problema, Cloudflare rastreó los 200 000 dominios más visitados de la web, filtrando redireccionadores, servidores publicitarios y servicios de tunelización para centrarse en los sitios con los que los agentes podrían interactuar razonablemente.

El balance es revelador: el 78 % de los sitios tiene un archivo robots.txt, pero la casi totalidad de ellos fue escrito para los rastreadores de buscadores tradicionales, no para agentes. Solo el 3,9 % de los sitios sirven contenido en Markdown cuando se les solicita. Y los estándares emergentes como los Tarjetas de servidor MCP están presentes en menos de 15 sitios en todo el conjunto de datos.

Revelada por Cloudflare, la solución isitagentready.com propone entonces una puntuación estructurada en torno a cuatro ejes.

• La descubribilidad (discoverability) verifica la presencia y la calidad del robots.txt, de un sitemap.xml, y de los encabezados Link.
• El contenido (content) evalúa si el sitio puede servir una versión Markdown limpia a petición de un agente.
• El control de acceso (bot access control) comprueba si el sitio expresa preferencias claras sobre lo que las IA pueden hacer con su contenido.
• Finalmente, las capacidades verifican la presencia de estándares más avanzados como las MCP Server Cards, el API Catalog o el descubrimiento OAuth para que los agentes puedan autenticarse correctamente.

Estándares todavía incipientes y una adopción casi nula

Aquí es donde el entusiasmo de Cloudflare debe moderarse. Varios de los estándares destacados en esta puntuación están o bien en fase de redacción en la IETF, o bien son propuestas informales sin garantía de adopción generalizada. El API Catalog (RFC 9727), las MCP Server Cards o el Web Bot Auth son estándares recientes, algunos de los cuales aún no han alcanzado el estatus de RFC definitiva en el momento de la publicación.

Esta situación no es exclusiva de Cloudflare: es la realidad de una web en fase de evolución. Pero exige una honestidad que el entrada de blog de Cloudflare adoptar hoy un estándar que será revisado o abandonado dentro de dieciocho meses significa, potencialmente, comprometerse con un trabajo de integración que habrá que rehacer. Las grandes empresas, que tienen los recursos para seguir estas evoluciones, se beneficiarán. Los equipos reducidos o los desarrolladores independientes, menos.

El caso de llms.txt es ilustrativo. Propuesto en septiembre de 2024, este archivo estandarizado para presentar un sitio a un LLM no está incluido por defecto en la puntuación de Cloudflare, solo como opción. ¿La razón? El estándar aún está en debate. Es una decisión prudente, pero que indica que ni siquiera Cloudflare sabe aún exactamente qué apuestas hacer.

La negociación de contenido en Markdown: una ganancia real y medible

Uno de los aspectos más concretos de la iniciativa, y probablemente el más inmediatamente útil, concierne la capacidad de un servidor para responder en Markdown cuando un agente envía un encabezado Accept: text/markdownCloudflare afirma haber medido hasta un 80 % de reducción del número de tokens necesarios para leer una página, en comparación con su versión HTML.

Esta cifra merece ser contextualizada. El HTML de una página de documentación técnica suele ser muy prolijo: navegación, menús, scripts, etiquetas anidadas… todo eso es ruido puro para un LLM. Un archivo Markdown bien estructurado, es la esencia del contenido sin el envoltorio. La consecuencia directa es una reducción del coste de las llamadas API para los agentes, una reducción de la latencia y una mayor probabilidad de que el agente disponga del contexto completo sin truncarlo.

Para ilustrar, Cloudflare explica haber probado su propio sitio de documentación (developers.cloudflare.com) apuntando un agente (Kimi-k2.5 vía OpenCode) a varios sitios técnicos. Resultado: 31 % menos de tokens consumidos y respuestas correctas un 66 % más rápidas que con otros sitios no optimizados. Estas cifras deben tomarse con precaución, porque proceden de condiciones de prueba internas no auditadas. Pero el orden de magnitud es coherente con lo que se sabe sobre el sobrepeso estructural del HTML.

La implementación técnica en Cloudflare Docs: pragmática y reproducible

La parte más instructiva del artículo es quizá la que describe cómo Cloudflare reestructuró su propia documentación. El enfoque es interesante porque elude un problema real: en febrero de 2026, solo tres herramientas de las siete probadas (Claude Code, OpenCode y Cursor) envían automáticamente el encabezado Accept: text/markdown. Para las demás, hace falta una alternativa.

La solución elegida combina dos reglas de Cloudflare:

• Una reescritura de URL que transforma una solicitud a /r2/get-started/index.md en una solicitud a /r2/get-started/,
• Y una transformación de encabezado que añade automáticamente Accept: text/markdown a esas solicitudes reescritas.

Resultado : cualquier agente puede acceder a la versión Markdown de cualquier página simplemente añadiendo /index.md a la URL, sin tener que gestionar un encabezado especial.

Otra decisión notable: en lugar de un único archivo llms.txt gigante (la documentación de Cloudflare cuenta con más de 5.000 páginas), cada directorio de primer nivel dispone de su propio archivo, y el archivo raíz apunta a esos subdirectorios. Esto evita el “grep loop” descrito en el artículo: un agente ante un archivo demasiado largo para caber en su ventana de contexto empieza a buscar por palabras clave, pierde la visión de conjunto, multiplica las llamadas y degrada la calidad de sus respuestas.

También se ha cuidado la granularidad : alrededor de 450 páginas que son solo listas de enlaces (páginas de directorio) fueron excluidas de llms.txt, ya que no aportan ningún valor semántico a un LLM cuyas páginas hijas ya están listadas individualmente.

Un actor que califica y vende la preparación para las calificaciones

La posición de Cloudflare merece un examen atento. La empresa publica la puntuación de referencia para la «preparación del agente», integra esa puntuación en su URL Scanner, ofrece prompts listos para usar para corregir cada punto de fallo… y vende los productos (Workers, Rules, Access) que permiten implementar esas correcciones. El isitagentready.com está él mismo servido por Cloudflare y expone un servidor MCP.

Eso no es necesariamente problemático: Google hizo lo mismo con Lighthouse y los Core Web Vitals, convirtiéndose a la vez en juez del rendimiento y proveedor de herramientas para mejorarlo (a través de Google Cloud, Firebase, etc.). Pero eso significa que los criterios de la puntuación pueden evolucionar en función de los intereses comerciales de la empresa tanto como de las necesidades reales de los agentes. Un estándar promovido por una única empresa, incluso con buenas intenciones, sigue siendo un estándar cuyas orientaciones pueden verse influenciadas.

También es notable que Cloudflare impulsa activamente estándares relacionados con los pagos agénticos (x402, Universal Commerce Protocol), algunos de los cuales implican socios directos como Coinbase. Esos estándares aún no cuentan en la puntuación, pero su presencia en la herramienta ya señala una dirección.

Lo que los desarrolladores pueden hacer concretamente hoy

A pesar de estas reservas, varias acciones tienen un retorno de inversión claro e inmediato, independientemente de la evolución de los estándares:

• Servir Markdown bajo demanda es técnicamente simple, reduce los costes para los consumidores de la API y mejora la calidad de las respuestas de los agentes. Es la prioridad.
• Cuidar el robots.txt para los agentes IA (añadiendo directivas para los rastreadores como GPTBot, ClaudeBot, CCBot, etc.) es una buena higiene que no cuesta nada y aclara los derechos de acceso.
• Estructurar un llms.txt por secciones para los sitios con mucho contenido es una buena práctica documental que beneficia tanto a los agentes como a las personas que buscan entender rápidamente la arquitectura de un sitio.

En cambio, implementar MCP Server Cards o API Catalogs para un sitio que aún no tiene una API pública o un caso de uso agéntico claramente definido equivaldría a construir una sala de espera antes de tener visitantes.

La adopción como indicador de mercado, no como obligación

El verdadero valor de la iniciativa de Cloudflare quizá esté en el Conjunto de datos Radar que introduce: un seguimiento semanal de la adopción de cada estándar por los 200.000 sitios más visitados, segmentado por categoría de dominio. Este tipo de datos permitirá medir si los estándares realmente “ganan”, o si la mayoría de los sitios permanecen pasivos a la espera de que los agentes se adapten a ellos, como ya se han adaptado al HTML durante treinta años.

La respuesta a esta pregunta dirá mucho sobre la dinámica de poder entre los editores de sitios y los desarrolladores de agentes. Si los agentes más populares terminan por integrar capacidades de análisis de HTML lo bastante robustas, la presión sobre los sitios para adaptarse disminuirá. Si, por el contrario, los costes y los plazos vinculados al consumo de HTML no optimizado se convierten en una ventaja competitiva medible para los sitios que se adaptan, la adopción seguirá de forma natural.

El artículo «Cloudflare califica su sitio en la era de los agentes IA con la Puntuación de Preparación de Agentes» fue publicado en el sitio Abondance.