Web lista para agentes de IA: guía con Cloudflare Radar

Una web lista para agentes de IA es una web que un agente puede encontrar, leer sin ruido y usar sin abrir un navegador: sabe qué hay, lo pide en Markdown y llama a sus herramientas por MCP o WebMCP. Cloudflare lo mide gratis con un escáner que da una nota de 0 a 100 y un nivel de 1 a 5. En esta guía te contamos qué mira, cómo leer el resultado y qué estrategia seguir según la tecnología de tu web. Al final lo aplicamos a un caso real, el medio BeersStorming, con cuyos responsables colaboramos para llevar su web al 100, y repasamos nuestro propio camino del 25 al 100.

Por qué importa que los agentes vean tu web

Parte de las visitas ya no las hace una persona con un navegador, sino un asistente que busca, lee y resume por ella: ChatGPT, Claude o Perplexity abren tu página cuando alguien les pregunta algo. Si esa página es un HTML lleno de menús y scripts, el agente gasta tokens en ruido, entiende peor y cita a otro. Cloudflare comparó su propia documentación, preparada para agentes, con otros grandes sitios de documentación técnica: un agente gastó un 31 % menos de tokens y llegó a la respuesta correcta un 66 % más rápido (blog de Cloudflare).

Hay dos niveles de visibilidad:

• Que te lean bien. Texto limpio en Markdown, un mapa del sitio, reglas claras para los bots de IA. Es lo que decide si te citan.
• Que te puedan usar. Herramientas que un agente llama directamente: buscar en tu web, leer un contenido concreto, apuntarse a algo. Eso es un servidor MCP para agentes que viven fuera del navegador y WebMCP para los que navegan por la página.

Casi nadie lo tiene todavía, y eso es una oportunidad. Sobre los 200.000 dominios más visitados, Cloudflare vio en abril de 2026 que el 78 % tiene robots.txt, pero escrito para los buscadores de siempre; solo el 4 % declara qué permite a la IA, el 3,9 % sirve Markdown a quien lo pide, y las tarjetas de servidor MCP y los catálogos de API aparecían en menos de 15 sitios de toda la muestra (blog de Cloudflare). Radar actualiza esa adopción cada semana en AI Insights.

Cómo usar el escáner de Cloudflare Radar

Tienes tres formas de pasar el examen, y las tres usan las mismas pruebas:

1. En isitagentready.com, escribiendo la URL.
2. En el URL Scanner de Radar, en la pestaña de preparación para agentes, junto al resto del análisis de la URL.
3. Desde código: con la API del URL Scanner (opción agentReadiness) o con el servidor MCP del propio escáner, que tiene una tool scan_site. Así puedes pedirle a tu agente que escanee la web después de cada cambio.

El resultado da un nivel y una lista de pruebas en verde, en rojo o neutrales. Lo más útil es que, por cada prueba fallida, el escáner te da un prompt para tu agente de programación y una skill con la especificación. Las tienes todas en su índice de skills.

Dos detalles para leer bien la nota:

• La nota parece ser el porcentaje de pruebas superadas sobre las que puntúan. Cloudflare no publica la fórmula, pero cuadra en todos nuestros escaneos: con 10 de 16 tuvimos 63, con 14 de 16, 88, y con 15 de 16, 94. Hoy puntúan 17 pruebas.
• Las neutrales no cuentan. Las de comercio (x402, UCP, ACP…) no cuentan para la nota, según Cloudflare, y en una web que no es tienda salen como neutrales. Web Bot Auth es informativa. El llms.txt tampoco puntúa: Cloudflare solo comprueba si sirves Markdown cuando te lo piden.

Qué mira cada prueba

Las pruebas se agrupan en cuatro capas. Esta tabla resume qué pide cada una y dónde se toca:

Capa	Prueba	Qué pide	Dónde se toca
Descubrimiento	robots.txt y sitemap	Que existan y sean válidos	Archivos en la raíz
Descubrimiento	Cabeceras Link	Link en la portada hacia recursos para agentes	Cabeceras del servidor
Descubrimiento	DNS-AID	Registros DNS que anuncian tus servicios para agentes, con DNSSEC	Proveedor de DNS y registrador
Contenido	Markdown	Responder text/markdown si el agente lo pide con Accept	Código del servidor o Cloudflare
Acceso de bots	Reglas de IA y Content Signals	Reglas por bot y qué permites: buscar, responder, entrenar	robots.txt
Capacidades	Agent Skills	Índice de skills en /.well-known/agent-skills/	Archivos estáticos
Capacidades	API Catalog y ARD	Catálogos de tus APIs y servicios en /.well-known/	Archivos estáticos
Capacidades	MCP Server Card	La tarjeta de tu servidor MCP	Archivo + un servidor MCP real
Capacidades	Personal Agent Protocol (poppy)	Manifiesto de descubrimiento en /.well-known/poppy.json	Archivo estático
Capacidades	A2A Agent Card	La tarjeta de un agente A2A	Archivo + un punto de entrada A2A
Capacidades	OAuth y auth.md	Metadatos OAuth (RFC 8414 y 9728) e instrucciones de alta para agentes	Servidor de autorización
Capacidades	WebMCP	Herramientas registradas con document.modelContext	JavaScript de la página

Primero, detecta la tecnología de la web

Antes de abrir un solo archivo conviene saber con qué está hecha la web y quién controla cada pieza, porque eso decide qué es fácil y qué no. En la tabla de arriba hay cinco tipos de cambio, y cada pila los permite de forma distinta:

1. Archivos estáticos (robots.txt, /.well-known/*.json, llms.txt, auth.md): casi siempre posibles. En un proyecto con carpeta pública basta con añadirlos; en una plataforma cerrada depende de lo que el proveedor te deje publicar en la raíz.
2. Cabeceras (Link): configuración del hosting o un middleware.
3. Negociación de contenido (Markdown): necesitas código en el servidor o un servicio que convierta. Cloudflare lo hace con Markdown for Agents, pero solo en los planes Pro, Business y Enterprise (y para los clientes de SSL for SaaS), y se activa en la zona de Cloudflare que controla el dominio (documentación de Cloudflare).
4. Puntos de entrada vivos (MCP, A2A, OAuth): necesitas un servidor que ejecute código, sea un Worker, una función o tu backend.
5. DNS (DNS-AID y DNSSEC): en tu proveedor de DNS y tu registrador, no en la web.

Para detectar la pila no hace falta acceso al código. Bastan tres miradas:

curl -sIL tudominio.com                  # server, x-powered-by, cookies, Link
curl -sL tudominio.com | head -c 3000    # rutas de los recursos, meta generator
dig +short NS tudominio.com              # quién lleva el DNS

Las rutas de los archivos delatan mucho: /_next/ es Next.js, /_astro/ es Astro, wp-content es WordPress. Los nombres de los módulos JavaScript y las cadenas del bundle principal suelen terminar de confirmarlo.

Caso práctico: BeersStorming

BeersStorming es un medio y una comunidad en español sobre IA, blockchain y computación cuántica, con noticias y eventos presenciales. Estamos colaborando con sus responsables para ayudarles a llegar al 100 % de preparación para agentes. Este análisis es el punto de partida: lo hicimos el 4 de noviembre de 2026 desde fuera, sin acceso a su código, como podría hacerlo cualquiera, y el plan de la sección siguiente es el que trabajamos con ellos.

Su tecnología

• La cabecera server: cloudflare dice que el tráfico pasa por Cloudflare.
• Los recursos son módulos de Vite con nombres de TanStack Router (useRouter, useMatch), y el HTML llega ya renderizado desde el servidor.
• El bundle principal contiene referencias a lovable.dev y un evento llamado lovable.webmcp_tool_invoked: la web está hecha con Lovable. Desde el 13 de mayo de 2026, los proyectos nuevos de Lovable usan TanStack Start, se renderizan en el servidor y se despliegan como un Worker de Cloudflare (Lovable).
• El DNS está en DonDominio, que es también el registrador, y el dominio no tiene DNSSEC. La zona no está en Cloudflare: el paso por Cloudflare lo pone el hosting.
• En su robots.txt aparecen /auth y /_authenticated: hay una zona con cuenta.

Esto ya marca la estrategia. Todo apunta a una app de TanStack Start, así que pueden añadir archivos estáticos y rutas de servidor con código propio; un servidor MCP sería una ruta más. El Markdown ya lo sirven ellos; el de Cloudflare no podrían activarlo por su cuenta, porque la zona de Cloudflare no es suya, y lo que toque al DNS se hace en DonDominio.

Lo que ya tienen

Nivel 4, «Agent-Integrated», con 8 de 17 pruebas superadas, que según la cuenta de antes serían unos 47 puntos. Para un medio, es un punto de partida muy por encima de lo normal:

• robots.txt con reglas para GPTBot, ChatGPT-User, PerplexityBot y otros, y Content Signals search=yes, ai-input=yes, ai-train=no: se dejan buscar y citar, pero no entrenar con sus textos.
• Sitemap con 2.847 URL, 2.820 de ellas noticias.
• Cabecera Link hacia /llms.txt, el sitemap y sus skills.
• Markdown de cada página cuando se pide con Accept: text/markdown.
• Una Agent Skill, beersstorming-news.
• WebMCP con cuatro herramientas: abrir una sección de noticias, abrir los eventos, leer las cotizaciones y abrir el contacto.

Lo que falla y lo que vemos desde fuera

Fallan nueve pruebas: DNS-AID, API Catalog, ARD, Personal Agent Protocol, MCP Server Card, A2A Agent Card, los dos metadatos de OAuth y auth.md. Mirando más allá del escáner encontramos cinco cosas:

1. Responden 406 en vez de 404. Cualquier ruta que no existe, pedida con Accept: application/json, responde 406, también /.well-known/mcp/server-card.json; sin esa cabecera, las mismas rutas sí responden 404. Tres de las pruebas fallan con ese código. Nuestra hipótesis, sin ver el código, es que la capa que sirve el Markdown rechaza los tipos que no conoce. Lo correcto es un 404, y que los JSON de /.well-known/ existan.
2. Un agente no puede buscar ni leer una noticia con una herramienta. No hay servidor MCP, ni buscador, ni RSS. Las herramientas WebMCP abren páginas, pero ninguna busca ni devuelve el texto de una noticia concreta.
3. El Markdown de la portada empieza por «Última hora», una tira de titulares que enlazan a otros medios. Un agente que resuma la portada encuentra primero titulares que enlazan a Business Insider o Xataka, antes que el contenido propio de BeersStorming.
4. El llms.txt es breve (26 líneas): describe las secciones, enlaza a Eventos y a los textos legales, pero no lista noticias ni próximos eventos.
5. El autor de cada noticia es la marca dada de alta como persona (Person con nombre «BeersStorming»). Para un medio, firmar con personas reales o como Organization deja más claro quién responde del contenido a quien lo cita.

Estrategia para llegar juntos al 100

Ordenamos los cambios por lo que aportan, no por lo que puntúan, y cada uno encaja en su pila.

Fase 1: arreglos de días

• Devolver 404 en las rutas que no existen y servir los JSON de /.well-known/ como archivos estáticos.
• Publicar API Catalog, ARD y poppy (tres archivos). Con el 406 arreglado, son tres pruebas más.
• En el Markdown, poner el contenido propio antes de «Última hora».
• Ampliar llms.txt con las últimas noticias y los próximos eventos, y publicar un RSS.
• Firmar con autores reales o con la organización.

Fase 2: un servidor MCP público

Este es el salto que cambia la relación con los agentes. Un servidor MCP de solo lectura en /mcp, sin cuenta, con herramientas como buscar_noticias, leer_noticia, ultimas_noticias, listar_eventos, ver_evento y cotizaciones. En TanStack Start es una ruta de servidor con el SDK oficial de TypeScript, como el que montamos en desarrollomcp.com.

Con él llegan la MCP Server Card, la entrada en el registro oficial de MCP y la posibilidad de que cualquiera los conecte en Claude o ChatGPT. Una tarjeta A2A que apunte a lo mismo cierra otra prueba.

Fase 3: cuentas y acciones

Como tienen zona con cuenta, tiene sentido el resto:

• OAuth con sus metadatos y auth.md (WorkOS), para que un agente pueda actuar en nombre de un colaborador.
• WebMCP con acciones, como apuntarse a un evento, siempre con confirmación de la persona. Lo explicamos paso a paso en nuestro tutorial de WebMCP.
• DNSSEC y DNS-AID en DonDominio, si su panel admite DNSSEC y registros SVCB.

Prueba que falla	Fase	Cambio
API Catalog, ARD, poppy	1	Arreglar el 406 y publicar los archivos
MCP Server Card	2	Servidor MCP + tarjeta
A2A Agent Card	2	Tarjeta y punto de entrada A2A
OAuth (2 pruebas) y auth.md	3	Servidor de autorización para las cuentas
DNS-AID	3	DNSSEC y registros en el DNS

Lo que aprendimos al pasar del 25 al 100

Nosotros hicimos este mismo camino con desarrollomcp.com en dos días. El 16 de octubre por la mañana teníamos nivel 1 y 25 puntos. Por la tarde, con Content Signals, Markdown, el servidor MCP y su tarjeta, ya teníamos nivel 5 y 63. Esa noche llegamos a 94, y al día siguiente, al 100. Hoy seguimos con 17 de 17.

Tres cosas que no esperábamos:

• DNSSEC no se activa solo en la zona. El registrador tiene que publicar su registro en .com. Activado solo en el DNS, pasaron 14 horas sin que apareciera; lo resolvimos desactivándolo y activándolo desde el panel del registrador.
• auth.md exige un método de alta que el verificador entienda. Nuestro primer método, por email, no lo reconocía; hizo falta añadir el registro anónimo con reclamación posterior.
• No todo da el mismo valor. El servidor MCP, la tarjeta y el Markdown son lo que un agente puede usar de verdad. El agente A2A y poppy los montamos sobre todo como ejemplo del curso. Si tu web no tiene cuentas, no inventes un OAuth para sumar puntos.

Qué ganan a futuro con MCP y WebMCP

Para un medio como BeersStorming, y es lo que perseguimos con ellos, la apuesta es pasar de ser una página que un agente lee a ser una fuente a la que pregunta:

• Más opciones de que les citen. Con un MCP, el agente puede pedir la noticia exacta en lugar de adivinar desde un HTML, y tiene a mano su URL para citarla.
• Eventos con un canal nuevo. Con WebMCP y el servidor MCP, un asistente puede encontrar el próximo evento y apuntar a su usuario, con su confirmación.
• Presencia en los directorios. Lo que se publica en el registro oficial de MCP lo recogen los catálogos de servidores: Glama, por ejemplo, lista el nuestro desde ahí.
• Control. Content Signals y OAuth dicen qué se permite y a quién.
• Medición. Con los registros de su servidor, o lo que ofrezca el hosting, pueden ver qué agentes entran y si las visitas desde la IA crecen tras cada fase. Las analíticas de bots de Cloudflare exigen tener la zona en Cloudflare, y hoy su DNS está en DonDominio.

Lo que no sabemos todavía es cuánto pesará cada señal en lo que citan los asistentes. Por eso conviene medir antes y después de cada cambio, en vez de perseguir la nota por sí misma.

En el curso tienes el panorama de lo que viene y cómo llevar un servidor a producción.