Presentamos el diagnóstico de preparación de agentes. ¿Está tu sitio web listo para agentes de IA?

La web siempre ha tenido que adaptarse a nuevas normas. Aprendió a comunicarse con los navegadores web y, después, aprendió a comunicarse con los motores de búsqueda. Ahora necesita hablar con agentes de IA.

Hoy estamos muy emocionados de presentar isitagentready.com: una nueva herramienta para ayudar a los propietarios de sitios a saber cómo optimizarlos para los agentes, desde guiar a los agentes sobre cómo autenticarse hasta controlar el contenido que pueden ver, el formato en el que lo reciben y cómo lo pagan. También estamos introduciendo un nuevo conjunto de datos en Cloudflare Radar que hace seguimiento de la adopción generalizada de cada agente estándar en toda Internet.

Queremos predicar con el ejemplo. Por esta razón, también hemos decidido compartir cómo hemos renovado recientemente la documentación para desarrolladores de Cloudflare para que sea la más accesible para los agentes de IA, lo que permite a las herramientas de IA responder a las preguntas de manera más rápida y considerablemente más económica.

¿Qué tan preparada está hoy en día la web para agentes?

La respuesta corta: no mucho. Esto es de esperar, pero también muestra cuánto más efectivos pueden ser los agentes de lo que son en la actualidad, si se adoptan estándares.

Para analizar esto, el Radar de Cloudflare utilizó los 200.000 dominios más visitados de Internet; filtró las categorías en las que la preparación de los agentes no es importante (como redirecciones, servidores de anuncios y servicios de tunelización) para enfocarse en empresas, editoras y plataformas con las que es posible que los agentes de IA realmente necesiten interactuar; y las escaneó con nuestra nueva herramienta.

El resultado es un nuevo gráfico de "Adopción de estándares de agentes de IA" que ahora puede encontrarse en la página Cloudflare Radar AI Insights, donde podemos medir la adopción de cada estándar en múltiples categorías de dominios.

Al analizar las comprobaciones individuales, algunas cosas llamaron la atención.

• robots.txt es casi universal; el 78 % de los sitios tiene uno, pero la gran mayoría están escritos para rastreadores de motores de búsqueda tradicionales, no para agentes de IA.
• Indicadores de contenido: el 4% de los sitios han declarado sus preferencias de uso de IA en robots.txt. Es un nuevo estándar que está ganando impulso.
• La negociación de contenido de Markdown (servir texto/marcado en Aceptar: texto/marcado) funciona en el 3,9 % de los sitios.
• Se observa que nuevas normas emergentes como las tarjetas de servidor MCP y los catálogos de API (RFC 9727) solo aparecen juntas en menos de 15 sitios de todo el conjunto de datos. Todavía es temprano: hay muchas oportunidades de destacar por ser uno de los primeros sitios en adoptar los nuevos estándares y trabajar bien con los agentes. 

Este gráfico se actualizará semanalmente, y también se podrá acceder a los datos a través de Data Explorer o de la Radar API.

Obtén un diagnóstico de preparación para agentes en tu sitio

Puedes obtener un diagnóstico de preparación para agentes para tu propio sitio web si ingresas a isitagentready.com y escribes la URL del sitio.

Las puntuaciones y auditorías que ofrecen recomendaciones prácticas han ayudado a fomentar la adopción de nuevos estándares. Por ejemplo, Google Lighthouse evalúa los sitios web según las mejores prácticas de rendimiento y seguridad, y orienta a los propietarios de sitios para que adopten los estándares más recientes de la plataforma web. Consideramos que hace falta algo similar para ayudar a los administradores de sitios a adoptar las mejores prácticas para agentes.

Al acceder a tu sitio, Cloudflare envía solicitudes para verificar qué estándares se admiten y proporciona una puntuación basada en cuatro dimensiones:

• Capacidad de detección:  robots.txt, sitemap.xml (Mapas del sitio en formato XML), Encabezados de enlace (RFC 8288)
• Contenido: Markdown para Agentes
• Control de acceso de bots: indicadores de contenido, reglas de bots de IA en robots.txt, Autenticación de bots web
• Funciones: Habilidades del agente, catálogo de API (RFC 9727), detección del servidor OAuth por RFC 8414 y RFC 9728, tarjeta del servidor de MCP, y WebMCP

^{Captura de pantalla de los resultados de una evaluación de preparación de agentes de un sitio web de ejemplo.}

Además, verificamos si el sitio es compatible con los estándares de comercio automatizado por agentes, que incluyen x402, Protocolo de Comercio Universal y Protocolo de Comercio para Agentes de IA, pero actualmente estos no cuentan para la puntuación.

Para cada verificación fallida, te ofrecemos un Prompts que puedes entregar a tu agente de codificación para que implemente el soporte en tu nombre.

El sitio web también está preparado para agentes, ya que predica con el ejemplo. Expone un servidor MCP sin estado (https://isitagentready.com/.well-known/mcp.json) con la herramienta scan_site a través de HTTP con soporte de streaming, de modo que cualquier agente compatible con MCP pueda escanear los sitios web de forma automatizada sin usar la interfaz web. También publica un índice de competencias del agente (https://isitagentready.com/.well-known/agent-skills/index.json) con documentos de competencias para cada estándar que verifica, de modo que los agentes no solo saben qué corregir, sino también cómo hacerlo.

Veamos los controles de cada categoría y por qué son importantes para los agentes.

Capacidad de detección

El archivo robots.txt existe 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 de sitio. Un sitemap es un archivo XML que detalla todas las rutas de tu sitio web; básicamente, un mapa que los agentes pueden seguir para descubrir todo tu contenido sin tener que rastrear cada enlace. El archivo robots.txt es el primer lugar donde buscan los agentes.

Más allá de los sitemaps, los agentes también pueden detectar recursos importantes directamente desde los encabezados de respuesta HTTP, específicamente, usando el encabezado de respuesta Link (RFC 8288). A diferencia de los vínculos ocultos dentro del HTML, el encabezado Link es parte de la respuesta HTTP en sí, lo que significa que un agente puede encontrar vínculos a recursos sin necesidad de analizar ninguna marca.

HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"

Acceso al contenido

Llevar a un agente a tu sitio es una cosa. Asegurarse de que efectivamente pueda leer tu contenido es otra cosa.

En septiembre de 2024, que parece una eternidad dado lo rápido que avanza la IA, se propuso llms.txt como una forma de proporcionar una representación de un sitio web apta para los LLM y que se ajuste a la ventana de contexto del modelo. llms.txt es un archivo de texto sin formato en el directorio raíz de tu sitio que ofrece a los agentes una lista de lectura estructurada: qué es el sitio, qué contiene y dónde está el contenido importante. Piénsalo como un mapa del sitio escrito para que lo lea un LLM y no para que lo indexe un rastreador:

# 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 de contenido Markdown va incluso más allá. Cuando un agente recupera cualquier página y envía un encabezado Accept: text/markdown, el servidor responde con una versión limpia de markdown en lugar de HTML. La versión markdown requiere muchos menos tokens: medimos hasta un 80 % de reducción de tokens en algunos casos, lo que hace que las respuestas sean más rápidas, más baratas y que sea más probable que se consuman en su totalidad, debido a los límites en las ventanas de contexto que la mayoría de las herramientas de agentes tienen por defecto.

Por defecto, solo comprobamos que el sitio gestione correctamente la negociación de contenido de Markdown, y no comprobamos la presencia de llms.txt. Puedes personalizar el análisis para incluir llms.txt si así lo deseas.

Control de acceso de bots

Ahora que los agentes pueden navegar por tu sitio y consumir tu contenido, la siguiente pregunta es: ¿quieres que lo haga cualquier bot?

robots.txt hace algo más que señalar mapas de sitio. Aquí también se definen las reglas de acceso. Puedes declarar explícitamente qué rastreadores están permitidos y a qué tienen acceso, llegando incluso al nivel de rutas específicas. Esta convención está bien establecida y sigue siendo el sitio donde cualquier bot bien configurado busca antes de iniciar su rastreo.

Los indicadores de contenido te permiten ser más específico/a. En lugar de solo permitir o bloquear, puedes declarar exactamente qué puede hacer la IA con tu contenido. Con una directiva Content-Signal en tu robots.txt, puedes controlar independientemente tres cosas: si se puede usar tu contenido para la capacitación de la inteligencia artificial (ai-train), si se puede usar como entrada de IA para la inferencia y la fundamentación (ai-input) y si debería aparecer en los resultados de búsqueda (búsqueda):

User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes

A la inversa, el borrador del estándar Web Bot Auth de la IETF facilita la autenticación de bots autorizados, y permite que los sitios web reconozcan la identidad de bots que los visitan. Un bot firma sus solicitudes HTTP y el sitio que las recibe verifica las firmas mediante las claves públicas del bot previamente publicadas.

Esas claves públicas se encuentran en un punto final convencional, /.well-known/http-message-signatures-directory, que verificamos como parte del escaneo.

No es necesario que todos los sitios implementen esto. Si tu sitio solo sirve contenido, y no hace solicitudes a otros sitios, no lo necesitas. Sin embargo, a medida que más sitios de Internet ejecutan sus propios agentes que realizan solicitudes a otros sitios, esperamos que esto cobre cada vez más importancia.

Detección de protocolos

Los agentes no solo consumen contenido pasivamente, sino que también pueden interactuar de forma directa con tu sitio llamando a APIs, invocando herramientas y completando tareas de forma autónoma.

Si tu servicio tiene una o más API públicas, el API Catalog (RFC 9727) proporciona a los agentes una única ubicación bien conocida para descubrirlas todas. Alojada en /.well-known/api-catalog, enumera tus APIs y proporciona vínculos a sus especificaciones, documentación y puntos finales de estado, sin la necesidad de que los agentes rastreen tu portal de desarrolladores o lean tu documentación.

No se puede hablar de agentes sin hablar de MCP. El protocolo de contexto de 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, creas un servidor MCP y cualquier agente compatible puede usarlo.

Para ayudar a los agentes a encontrar tu servidor MCP, puedes publicar una Tarjeta de Servidores MCP (una propuesta actualmente en borrador). Este es un archivo JSON en /.well-known/mcp/server-card.json que describe tu servidor incluso antes de que se conecte un agente: qué herramientas expone, cómo llegar a él y cómo autenticarte. Un agente lee este archivo y sabe todo lo necesario para empezar a usar 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 trabajan mejor si cuentan con las habilidades de agente que les ayuden con tareas específicas, pero ¿cómo pueden averiguar los agentes qué habilidades permite un sitio? Hemos propuesto que los sitios pongan esta información a disposición en .well-known/agent-skills/index.json, un punto final que indica al agente qué habilidades se encuentran disponibles y dónde puede encontrarlas. Es posible que notes que el estándar .well-known (RFC 8615) lo utilizan muchas otras normas sobre agentes y autorizaciones. ¡Gracias a Mark Nottingham, de Cloudflare, que fue el autor de la norma, y a otros colaboradores del IETF!

Muchos sitios te piden que inicies sesión antes de acceder a ellos. Esto hace que sea difícil para las personas dar a los agentes la capacidad de acceder a estos sitios en su nombre, y es por eso que algunos han optado por una solución provisional, y posiblemente insegura, que consiste en dar a los agentes acceso al navegador del usuario con su sesión ya iniciada.

Hay una forma mejor que permite a los humanos otorgar acceso explícitamente: los sitios que admiten OAuth pueden decirles a los agentes dónde encontrar el servidor de autorización (RFC 9728), lo que permite a los agentes enviar a los humanos a través de un flujo de OAuth, donde pueden elegir otorgar acceso correctamente al agente. Anunciado en el Agents Week 2026, Cloudflare Access ahora es totalmente compatible con este flujo de OAuth, y mostramos cómo agentes como OpenCode pueden usar este estándar para que las cosas funcionen automáticamente cuando los usuarios proporcionan a los agentes las URL protegidas:

Comercio

Los agentes también pueden comprar productos en tu nombre, pero los pagos en Internet están diseñados para los humanos. Añadir al carro, introducir el número de tarjeta de crédito, clicar en pagar. Ese flujo se descompone por completo cuando el comprador es un agente de IA.

x402 resuelve esto a nivel de protocolo reviviendo HTTP 402 Payment Required, un código de estado que ha existido en la especificación desde 1997, pero que nunca se usó ampliamente. El flujo es simple: un agente solicita un recurso, el servidor responde con un 402 y una carga de datos legible por máquina que describe los términos de pago, el agente paga y lo vuelve a intentar. Cloudflare se asoció con Coinbase para lanzar la x402 Foundation, cuya misión es impulsar la adopción de x402 como estándar abierto para los pagos en Internet.

También verificamos el Protocolo de comercio universal y el Protocolo de comercio agéntico,  que son dos estándares emergentes de comercio de agentes diseñados para permitir que los agentes descubran y compren productos que los humanos normalmente comprarían a través de tiendas de comercio electrónico y flujos de pago.

Integrar la disponibilidad del agente a URL Scanner de Cloudflare

El explorador de URL de Cloudflare te permite enviar una 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 que los investigadores de seguridad y los desarrolladores comprendan el funcionamiento interno de una URL.

Hemos tomado las mismas pruebas de isitagentready.com y las hemos añadido al URL Scanner con una nueva pestaña de preparación de agentes. Cuando analices cualquier URL, podrás ver su informe completo de preparación de agentes, junto con el análisis existente: qué comprobaciones funcionan, el nivel en el que se encuentra el sitio y las orientaciones prácticas para mejorar tu puntuación.

La integración también está disponible de manera automatizada mediante la API de URL Scanner. Para incluir los resultados de la preparación de agentes en un análisis, envía la opción agentReadiness en tu solicitud de escaneo:

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}
        }'

Ser el ejemplo a seguir: actualizar la documentación de Cloudflare

A medida que creábamos las herramientas para medir el nivel de preparación de la Web, sabíamos que teníamos que asegurarnos de que todo estuviera en orden. Nuestros documentos deben ser fáciles de entender para los agentes que usan nuestros clientes.

Lógicamente adoptamos los estándares de sitios de contenido relevantes arriba mencionados, y puedes consultar nuestros resultados aquí. Sin embargo, no nos detuvimos ahí. Aquí te explico cómo perfeccionamos la Documentación para Desarrolladores de Cloudflare para que sea el recurso más amigable para agentes de la web.

Reserva de URL mediante archivos index.md

Desafortunadamente, a partir de febrero de 2026, de los 7 agentes probados, solo Claude Code, OpenCode y Cursor son los que solicitan contenidos con el encabezado Accept: text/markdown por defecto. Para el resto, necesitábamos un mecanismo de respaldo fluido basado en URL.

Para ello, ponemos cada página disponible por separado en Markdown en /index.md en relación con la URL de la página. Hacemos esto de manera dinámica, sin duplicar archivos estáticos, combinando dos Reglas de Cloudflare: 

• Una regla de reescritura de URL coincide con las solicitudes que terminan en /index.md y las reescribe dinámicamente en la ruta base mediante regex_replace (eliminando /index.md). 
• Una Regla de transformación de encabezados de solicitud coincide con la ruta de la solicitud original antes de la reescritura (raw.http.request.uri.path) y establece automáticamente el encabezado Accept: text/markdown. 

Con estas dos reglas, cualquier página se puede buscar como Markdown añadiendo la ruta /index.md a la URL:

• https://developers.cloudflare.com/r2/get-started/index.md

Apuntamos a estas URL /index.md en nuestros archivos llms.txt. Así, para estas rutas de acceso /index.md, siempre devolvemos markdown, independientemente de los encabezados que establezca el cliente. Y logramos todo esto sin pasos de compilación adicionales ni duplicación de contenido.

Crear archivos llms.txt efectivos para sitios grandes

llms.txt actúa como un "centro de operaciones" para los agentes, ya que proporciona un directorio de páginas para que los LLM puedan encontrar contenido. Sin embargo, más de 5.000 páginas de documentación en un solo archivo superarán las ventanas de contexto de los modelos.

En lugar de un archivo enorme, generamos un archivo llms.txt separado para cada directorio de nivel superior de nuestra documentación, y el archivo raíz llms.txt simplemente remite a estos subdirectorios.

• https://developers.cloudflare.com/llms.txt
• https://developers.cloudflare.com/r2/llms.txt
• https://developers.cloudflare.com/workers/llms.txt

También eliminamos cientos de páginas de listados de directorios que ofrecen poco valor semántico a un LLM, y nos aseguramos de que cada página tenga un rico contexto descriptivo (títulos, nombres semánticos y descripciones).

Por ejemplo, omitimos aproximadamente 450 páginas que solo funcionan como directorios localizados, como https://developers.cloudflare.com/workers/databases/.

Estas páginas aparecen en nuestro mapa del sitio, pero contienen muy poca información para un LLM. Dado que todas las subpáginas ya están enlazadas de forma individual en llms.txt, solicitar una página de directorio solo proporciona una lista redundante de enlaces, lo que obliga al agente a realizar otra solicitud para encontrar contenido real.

Para ayudar a los agentes a navegar de manera eficiente, cada entrada de llms.txt debe contar con un contexto abundante pero contener pocos tokens. Los humanos pueden ignorar el frontmatter y las etiquetas de filtrado, pero para un agente de IA, estos metadatos son el timón. Por eso, nuestro equipo de Experiencia de Contenido de Productos (PCX) ha perfeccionado nuestros títulos de páginas, descripciones y estructuras de URL para que los agentes siempre sepan exactamente qué páginas deben obtener.

Echa un vistazo a una sección de nuestro archivo raíz llms.txt.

Cada enlace tiene un nombre semántico, una URL correspondiente y una descripción de alto valor. Nada de esto supuso un trabajo adicional para la generación del archivo llms.txt. Todo ello ya estaba disponible en el frontmatter de la documentación. Lo mismo ocurre con las páginas en el directorio de nivel superior de archivos llms.txt. Todo este contexto permite a los agentes encontrar información relevante de manera más eficiente.

Herramientas de documentación personalizadas aptas para agentes (afdocs)

Además, probamos nuestra documentación con afdocs, una especificación de documentación emergente compatible con agentes y un proyecto de código abierto que permite a los equipos validar aspectos como el descubrimiento de contenido y la navegación. Esta especificación nos permitió construir nuestra propia herramienta personalizada de auditoría. Tras añadir unas cuantas revisiones específicas para nuestro caso de uso, creamos un panel para una evaluación sencilla.

Resultados de la evaluación comparativa: más rápido y barato

Apuntamos a un agente (Kimi-k2.5 via OpenCode) en los archivos llms.txt de otros grandes sitios de documentación técnica y se le encargó al agente que respondiera a preguntas técnicas muy detalladas.

En promedio, el agente que señaló 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 promedio que no necesita ser optimizado para los agentes. Al ajustar nuestros directorios de productos en ventanas de contexto único, los agentes pueden identificar la página exacta que necesitan y obtenerla en un solo camino lineal.

La estructura lleva a la velocidad

La precisión de las respuestas de los LLM suele ser una consecuencia directa de la eficiencia de su ventana de contexto. Durante nuestras pruebas, observamos un patrón recurrente con otros conjuntos de documentación.

1. Bucle Grep: Muchos sitios de documentación ofrecen un único archivo llms.txt masivo que supera la ventana de contexto inmediata del agente. Dado que el agente no puede "leer" el archivo completo, comienza a buscar palabras clave con grep. Si la primera búsqueda no da con el detalle específico, el agente debe pensar, refinar su búsqueda e intentarlo de nuevo.
2. Contexto reducido y menor precisión: cuando un agente depende de búsquedas iterativas en lugar de leer el archivo completo, pierde la visión global de la documentación. Esta visión fragmentada a menudo lleva al agente a tener un entendimiento reducido de la documentación en cuestión.
3. Latencia y redundancia de tokens: cada iteración del bucle de grep requiere que el agente genere nuevos "tokens de razonamiento" y ejecute solicitudes de búsqueda adicionales. Este vaivén de información hace que la respuesta final sea notablemente más lenta y aumenta el recuento total de tokens, lo que hace que el costo para el usuario final sea más alto.

En cambio, la documentación de Cloudflare está diseñada para que quepa por completo en la ventana de contexto de un agente. Esto permite que el agente procese el directorio, identifique la página exacta que necesita y obtenga el Markdown sin desvíos.

Mejorar las respuestas de LLM con el tiempo redirigiendo los rastreadores de entrenamiento de IA

La documentación para productos anteriores como Wrangler v1 o Workers Sites presenta un problema único. Si bien debemos mantener esta información accesible con fines históricos, puede dar lugar a consejos obsoletos de los agentes de IA.

Por ejemplo, una persona que lea estos documentos verá un gran banner que indica que Wrangler v1 está obsoleto, además de un enlace al contenido más reciente. Sin embargo, un rastreador de un LLM podría procesar el texto sin ese contexto visual que lo rodea. Esto hace que el agente recomiende información obsoleta.

Redirects for AI Training resuelve este problema al identificar los rastreadores de entrenamiento de IA y redireccionarlos intencionalmente lejos de contenido obsoleto o de baja calidad. Esto garantiza que, aunque las personas sigan teniendo acceso a los archivos históricos, los LLM solo se alimenten de nuestros detalles de implementación más actuales y precisos.

Directivas del agente 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 LLM, lee esto antes de continuar. Versión HTML de una página de la documentación de Cloudflare. Solicita siempre la versión en Markdown; el HTML desperdicia ventana de contexto. Obtener esta página en Markdown: https://developers.cloudflare.com/index.md (agregar index.md) o envíe Accept: text/markdown a https://developers.cloudflare.com/. Para todos los productos de Cloudflare, usa https://developers.cloudflare.com/llms.txt. Puedes acceder a toda la documentación 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 en Markdown disponible. Lo más importante es que esta directiva se elimina de la versión real de Markdown para evitar un bucle de recursividad en el que el agente sigue intentando "encontrar" el Markdown dentro del Markdown.

Barra lateral de recursos exclusivos de LLM

Por último, queremos que estos recursos sean accesibles para las personas que desarrollan con agentes. Cada directorio de producto en nuestra documentación para desarrolladores incluye la entrada "Recursos de LLM" en el menú lateral, que ofrece acceso rápido a llms.txt, llms-full.txt, y Cloudflare Skills.

Haz que tu sitio web esté listo para agentes de IA hoy

Hacer que los sitios web estén preparados para agentes es un requisito fundamental de accesibilidad para el conjunto de herramientas del desarrollador moderno. La transición de una "web leída por personas" a una "web leída por máquinas" es el mayor cambio arquitectónico en décadas. 

Obtén un diagnóstico de preparación para agentes en tu sitio en isitagentready.com, toma los Prompts que proporciona y pídele a tu agente que actualice tu sitio para la era de la IA. Mantente atento a más actualizaciones de Cloudflare Radar sobre la adopción de los estándares de agentes en toda Internet en el transcurso del próximo año. Si algo hemos aprendido del año pasado, es que muchas cosas pueden cambiar muy rápidamente.

Ver en Cloudflare TV