Los sitios web han aprendido a comunicarse con los navegadores, y luego comenzaron a interactuar con los motores de búsqueda. Cloudflare ahora cree que los sitios web también deben aprender a comunicarse con las agencias de IA y ofrece una herramienta para ayudar en este aspecto. Esta es una iniciativa ambiciosa, pero plantea más preguntas que soluciones.

Aspectos Destacados:

  • Cloudflare ha lanzado un herramienta gratuita llamada isitagentready.com que evalúa la compatibilidad de los sitios web con las agencias de IA en cuatro dimensiones: descubribilidad, contenido, control de acceso y capacidades.
  • La web aún no está lista: solo el 4% de los 200,000 sitios web analizados reportan preferencias para el uso de IA, y menos de 15 sitios han adoptado los últimos estándares, como las Tarjetas de Servidor MCP o los Catálogos de API.
  • La iniciativa se basa en un ecosistema de estándares en construcción, lo que expone a los primeros adoptantes al riesgo de fragmentación o rápida obsolescencia.
  • Cloudflare se encuentra en una posición de definir la puntuación y ofrecer soluciones para mejorarla, lo que requiere cuestionamiento.

Herramienta de Puntuación para un Problema Real

El punto de partida de Cloudflare es sólido. Una agencia de IA, al intentar acceder a un sitio web, leer documentación, comprar productos o interactuar con una API, se enfrenta a una infraestructura diseñada para humanos: HTML denso, formularios, sesiones, captchas. Como resultado, surgen agencias lentas, costosas en términos de tokens y a menudo erróneas.

Cloudflare midió la magnitud del problema escaneando los 200,000 dominios más visitados y enfocándose en los sitios donde las agencias podrían interactuar razonablemente, filtrando redirecciones, servidores de anuncios y servicios de túneles.

El resultado es impactante: el 78% de los sitios tiene un archivo robots.txt, pero casi todos están escritos para navegadores de motores de búsqueda tradicionales, no para agencias. Solo el 3.9% ofrece contenido en formato Markdown cuando se solicita. Y los nuevos estándares como las Tarjetas de Servidor MCP están disponibles en menos de 15 sitios en todo el conjunto de datos.

La solución promovida por Cloudflare, isitagentready.com, ofrece una puntuación estructurada en torno a cuatro ejes.

  • Descubribilidad, verifica la existencia y calidad de robots.txt, sitemap.xml y los encabezados de enlace.
  • Contenido, evalúa si el sitio proporciona una versión limpia en Markdown adecuada a la solicitud de una agencia.
  • Control de Acceso, observa si el sitio expresa preferencias claras sobre lo que las IAs pueden hacer con su contenido.
  • Finalmente, capacidades, prueba la existencia de estándares más avanzados como las Tarjetas de Servidor MCP, Catálogo de API o descubrimiento OAuth, que permiten a las agencias autenticarse correctamente.

Estándares en Desarrollo y Adopción Casi Inexistente

El entusiasmo de Cloudflare aquí debe ser moderado. Muchos de los estándares destacados en este punto están en fase de borrador en el IETF o son propuestas informales sin garantía de aceptación general. El Catálogo de API (RFC 9727), las Tarjetas de Servidor MCP o Web Bot Auth son algunos de los nuevos estándares que no han alcanzado el estatus de RFC definitivo en la fecha de publicación.

Esta situación no es exclusiva de Cloudflare: es la realidad de una web en evolución. Sin embargo, esto requiere una honestidad que se minimiza en el blog de Cloudflare. Si se considera que un estándar adoptado hoy podría ser reestructurado o abandonado en dieciocho meses, esto podría generar una carga de trabajo que requiera reintegración. Mientras que los grandes jugadores tienen recursos para seguir estas evoluciones, esto puede no ser el caso para equipos más pequeños o desarrolladores independientes.

El ejemplo de llms.txt es notable. 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 es opcional. ¿La razón? El estándar aún está en discusión. Esta es una decisión cautelosa, pero también muestra que Cloudflare aún no sabe qué riesgos debería asumir.

Debate sobre Contenido Markdown: Una Ganancia Real Medida

Uno de los aspectos más concretos de la iniciativa, y probablemente el más urgentemente útil, es la capacidad de un servidor para responder en formato Markdown cuando una agencia envía el encabezado Accept: text/markdown. Cloudflare afirma haber medido una reducción de hasta el 80% en el número de tokens necesarios para leer una página.

El contexto de esta cifra es importante. El HTML de una página de documentación técnica suele ser muy pesado: navegación, menús, scripts, etiquetas anidadas... todo esto crea ruido puro para un LLM. Un archivo Markdown bien estructurado es la esencia del contenido sin envoltura. El resultado directo es una disminución en el costo de las llamadas a la API para las agencias, una reducción en la latencia y una mayor probabilidad de que la agencia obtenga el contexto completo sin interrupciones.

Cloudflare explica que probó su propio sitio de documentación (developers.cloudflare.com) y redirigió a una agencia (a través de Kimi-k2.5 OpenCode) a varios sitios técnicos. Resultado: un 31% menos de consumo de tokens y respuestas correctas un 66% más rápidas en comparación con otros sitios no optimizados. Estas cifras deben ser tratadas con cautela ya que provienen de condiciones de prueba internas no auditadas. Sin embargo, el orden de magnitud es consistente con lo conocido sobre la excesiva estructura del HTML.

Aplicación Técnica en Cloudflare Docs: Práctica y Repetible

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

La solución elegida combina dos reglas de Cloudflare:

  • Una reescritura de URL convierte la solicitud /r2/get-started/index.md en /r2/get-started/,
  • Y automáticamente agrega el encabezado Accept: text/markdown a estas solicitudes reescritas.

Resultado: Cualquier agencia puede acceder a la versión Markdown de cualquier página simplemente agregando /index.md a la URL, sin necesidad de gestionar un encabezado especial.

Otra decisión notable: en lugar de un único archivo gigante llms.txt (la documentación de Cloudflare contiene más de 5,000 páginas), cada directorio de primer nivel tiene su propio archivo y el archivo raíz apunta a estos subdirectorios. Esto evita el bucle grep descrito en el artículo: una agencia que se enfrenta a un archivo demasiado largo comienza a perder el hilo, busca palabras clave, aumenta las llamadas y disminuye la calidad de las respuestas.

La granularidad también fue abordada con cuidado: Aproximadamente 450 páginas que solo contienen listas de enlaces (páginas de índice) fueron excluidas de llms.txt porque ya no aportan valor semántico a un LLM para las subpáginas listadas individualmente.

Un Jugador que Puntúa y Vende Preparación de Puntuación

La posición de Cloudflare requiere un examen cuidadoso. La empresa publica la puntuación de referencia para la preparación de agencias, la integra en el Navegador de URL, ofrece plantillas listas para corregir cada punto de fallo... y vende productos (Workers, Rules, Access) para implementar estas correcciones. isitagentready.com también es ofrecido por Cloudflare y alberga un servidor MCP.

Esto no es necesariamente problemático: Google hizo lo mismo con Lighthouse y Core Web Vitals y se convirtió en un proveedor que es tanto juez como proveedor de herramientas para mejorar el rendimiento (a través de Google Cloud, Firebase, etc.). Sin embargo, esto significa que los criterios de puntuación pueden evolucionar tanto según los intereses comerciales de la empresa como según las necesidades reales de las agencias. Un estándar respaldado por una sola empresa, incluso con buenas intenciones, puede influir en las directrices.

Además, es notable que Cloudflare esté promoviendo activamente estándares relacionados con los pagos de agencias (x402, Protocolo de Comercio Universal); algunos de estos estándares incluyen socios directos como Coinbase. Estos estándares aún no están incluidos en la puntuación, pero su presencia en la herramienta ya indica una dirección.

Cosas que los Desarrolladores Pueden Hacer Realmente Hoy

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

  • Ofrecer Markdown bajo demanda es técnicamente simple, reduce costos para los consumidores de API y mejora la calidad de las respuestas para las agencias. Esta es una prioridad.
  • Modificar el robots.txt para agencias de IA (por ejemplo, agregando directrices para navegadores como GPTBot, ClaudeBot, CCBot) es una buena higiene y sin costo, aclara los derechos de acceso.
  • Configurar llms.txt por sección para sitios con mucho contenido es una buena práctica de documentación tanto para agencias como para personas que desean comprender rápidamente la arquitectura de un sitio.

Por otro lado, implementar Tarjetas de Servidor MCP o Catálogos de API para un sitio que aún no tiene una API pública o un caso de uso claro para agencias es equivalente a construir una sala de espera sin visitantes.

Adopción como Indicador de Mercado, No como Obligación

El verdadero valor de la iniciativa de Cloudflare puede estar en el conjunto de datos Radar: un conjunto de datos que rastrea semanalmente la adopción de cada estándar en los 200,000 sitios más visitados, segmentado por categorías de dominio. Este tipo de datos permitirá medir si los estándares realmente están generando beneficios o si la mayoría de los sitios permanecen pasivos, esperando que las agencias se adapten a ellos, como ya lo han hecho durante treinta años con HTML.

La respuesta a esta pregunta dirá mucho sobre la dinámica de poder entre los editores de sitios y los desarrolladores de agencias. A medida que las agencias más populares adquieran capacidades de análisis de HTML lo suficientemente sólidas, la presión sobre los sitios para adaptarse disminuirá. Por el contrario, si los costos y tiempos de consumo de HTML no optimizado se convierten en una ventaja competitiva medible para los sitios que se adaptan, la adopción aumentará naturalmente.