Preparación del agente: cómo preparar su sitio para la web agente

Por qué la preparación de los agentes es ahora su propio problema

Durante años, el único visitante para el que había que diseñar era un humano con un navegador. Luego apareció el crawler de Google y SEO se convirtió en una disciplina. Luego llegaron los estudiantes de LLM crawl y Answer Engine Optimization se convirtió en lo siguiente de lo que tenía que preocuparse.

Ahora está aquí un tercer tipo de visitante. Los agentes creados sobre los modelos OpenAI, Anthropic y Google navegan por los sitios con intención. Leen páginas de productos, completan formularios, negocian precios y llaman a API. También deciden, en el primer o segundo segundo, si vale la pena el viaje de ida y vuelta a su sitio.

Los agentes se comportan menos como crawlers y más como usuarios avanzados impacientes. Verifican las rutas /.well-known/ antes de tocar su HTML. Envían Accept: text/markdown para saltarse la navegación. Buscan una tarjeta de servidor MCP para poder hablar con su aplicación como una herramienta, no como un documento. Si esas señales faltan, el agente vuelve a raspar su HTML (lento y con pérdidas) o pasa a un competidor que habla su idioma.

Esto es para lo que construimos el Agent Protocol Readiness Checker. No es una auditoría SEO. Es una auditoría de protocolo. Comprueba si su sitio está listo para ser utilizado por un agente en lugar de leído por una persona.

Qué hace el verificador de preparación del protocolo del agente

Dale a la herramienta un URL. Ejecuta más de 20 investigaciones sobre su origen y agrupa los hallazgos en cinco categorías puntuadas:

• Descubribilidad. ¿Pueden los agentes encontrar sus encabezados robots.txt, sitemap y Link?
• Accesibilidad de contenido. ¿Su servidor respeta Accept: text/markdown de la forma que describe la especificación de Acceptmarkdown.com?
• Control de acceso de bots. ¿Ha escrito una política explícita para GPTBot, ClaudeBot, Google-Extended y PerplexityBot? ¿Ha publicado un directorio de claves de autenticación de Web Bot?
• Descubrimiento de protocolo. ¿Expone una tarjeta de servidor MCP, un manifiesto de habilidades del agente, un catálogo de API RFC 9727, metadatos de descubrimiento de OAuth y anotaciones de herramientas WebMCP?
• Agentic Commerce. ¿Puede pagarte un agente? El verificador busca señales x402, ACP, UCP y MPP.

Cada verificación devuelve aprobación, advertencia o falla, con la evidencia del servidor detrás del veredicto. Los fracasos se acumulan en una lista de recomendaciones priorizadas y las categorías se combinan en una calificación ponderada de A a F. El objetivo no es otra puntuación de vanidad. El objetivo es brindarle las seis soluciones que más cambiarán la forma en que los agentes tratan su sitio.

Veamos qué mide realmente cada categoría y por qué es importante.

1. Descubrimiento: los conceptos básicos que aún lo deciden todo

Antes de que un agente pueda utilizar algo más sofisticado, necesita saber qué existe en su origen. Eso comienza con tres archivos simples.

robots.txt

El verificador recupera /robots.txt y confirma que devolvió una respuesta válida. RFC 9309 ha sido el estándar formal desde 2022, y un agente que no puede leer su archivo robots supone lo peor: que no ha pensado en absoluto en el acceso a la máquina. Si solo hace una cosa en esta publicación, publique un robots.txt válido. Nuestro Robots.txt Validator detecta los errores comunes (listas de materiales extraviadas, trampas de comodines, directivas Sitemap sin comillas).

Declaración Sitemap

Un sitemap en /sitemap.xml es agradable. Una línea Sitemap: dentro de robots.txt que apunte a él es mejor, porque los agentes resuelven primero el archivo robots. El verificador recompensa los sitios que hacen ambas cosas.

Encabezados de respuesta de enlace

Los agentes modernos también leen el encabezado Link en su página de inicio para obtener sugerencias sobre los recursos en /.well-known/*. Los sitios que prestan servicios, por ejemplo, Link: </.well-known/mcp/server-card.json>; rel="mcp-server-card", le brindan al agente su siguiente paso sin un segundo viaje de ida y vuelta. Si desea ver qué encabezados envía su origen hoy, ejecútelo a través de nuestro HTTP Header Checker.

La capacidad de descubrimiento es una categoría pequeña (15% de la calificación final), pero aquí los fracasos se acumulan en cascada. Si los robots no funcionan, no se puede verificar la categoría de acceso de bots. Si faltan los encabezados de los enlaces, las categorías posteriores deben adivinar.

2. Accesibilidad al contenido: las comprobaciones de la negociación de rebajasEsta es la categoría en la que fallan la mayoría de los sitios. También resulta ser el más fácil de solucionar.

La propuesta de acceptmarkdown.com es simple: cuando un cliente envía Accept: text/markdown, el servidor debería devolver el mismo contenido que Markdown en lugar de HTML. A los agentes les encanta esto porque HTML es ruidoso. Eliminar Chrome, la navegación y JavaScript de una página consume tokens e introduce errores. Una representación Markdown de su artículo tiene la mitad de tamaño y diez veces más fácil de analizar.

El verificador ejecuta cuatro sondas contra su URL:

1. Se respeta Accept: text/markdown. El servidor debería devolver Content-Type: text/markdown; charset=utf-8. Una declaración UTF-8 es importante porque los agentes introducen el cuerpo en un tokenizador que asume la codificación.
2. Vary: Accept está configurado. Sin este encabezado, un CDN que almacenó en caché la respuesta HTML entregará ese HTML al siguiente agente que solicite Markdown. Un encabezado faltante corrompe un origen completo para cada cliente de IA detrás del mismo CDN.
3. Los tipos de aceptación no admitidos devuelven 406. Si un agente envía Accept: application/x-weird-type, la respuesta correcta es 406 Not Acceptable, no un recurso HTML silencioso. El retorno 406 le indica a la lógica de reintento del agente que solicitó algo incorrecto.
4. Se respetan los valores q. Un agente que envía Accept: text/html;q=0.1, text/markdown;q=1.0 dice “Aceptaré HTML si es necesario, pero prefiero Markdown”. El servidor debe respetar esa ponderación.

La mayoría de los orígenes obtienen cero sobre cuatro en esta categoría. Un trabajador de CDN que transforma HTML a Markdown bajo demanda soluciona los cuatro problemas en una tarde. La recompensa se agrava: cada agente que visita su sitio a partir de ese momento obtiene una representación limpia y tokenizada de su contenido. Para obtener una visión más profunda de cómo los agentes leen contenido compatible con IA, consulte nuestro AI Readiness Checker.

3. Control de acceso de bots: decir sí claramenteEl valor predeterminado robots.txt no dice nada sobre los agentes de IA. El silencio se interpreta de dos maneras, según el agente. Algunos asumen que el silencio significa “bien, sigue adelante”. Otros asumen que el silencio significa “este sitio no ha optado por participar”. Ambas interpretaciones te hacen daño, porque ninguna coincide con lo que realmente quieres.

El Comprobador de preparación del protocolo del agente busca tres señales explícitas.

Agentes de usuario de bot AI en robots.txt

El verificador busca en su robots.txt reglas dirigidas a los crawlers que importan hoy: GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot, Claude-Web, anthropic-ai, Google-Extended, PerplexityBot, Usuario Perplexity, Meta-Agente externo, Applebot-Extended, Bytespider, CCBot, cohere-ai, DuckAssistBot, Amazonbot, MistralAI-Usuario. Tres o más agentes nombrados obtienen un pase. Una lista más corta genera una advertencia. Cero obtiene un suspenso, porque en ese punto no tienes ninguna política de IA.

Escribir User-agent: GPTBot seguido de Allow: / no es lo mismo que no decir nada. Es un compromiso público que el agente de una empresa específica pueda leer su sitio bajo una regla específica. Ese compromiso tiene una gran carga cuando el motor de pólizas de un agente decide si lo busca o no.

Si desea probar cómo se comporta actualmente un bot de IA específico en una de sus rutas, nuestro AI Bot Path Tester simulará la solicitud en función de las reglas en su robots.txt en vivo.

Señales de contenido de Cloudflare

Cloudflare propuso Content Signals a finales de 2025: tres directivas (search, ai-input, ai-train) que se encuentran dentro de robots.txt y declaran políticas separadas para crawling, recuperación por respuesta y capacitación. El verificador escanea su archivo de robots en busca de cualquier directiva Content-Signal:. Uno es suficiente para pasar.

Contenido Las señales son importantes porque el “bloque GPTBot” es un instrumento contundente. Bloquea el entrenamiento, la recuperación y las respuestas fundamentadas de un solo golpe. Las señales de contenido le permiten permitir respuestas fundamentadas (para que su marca aparezca en las citas ChatGPT) mientras bloquean el entrenamiento (para que su contenido no se comprima en los pesos de un modelo).

Autenticación de bot web

Web Bot Auth es la pieza más nueva de esta categoría. Los agentes firman sus solicitudes con un par de claves Ed25519. La clave pública se puede descubrir en /.well-known/http-message-signature-directory como JWKS. Cuando un agente accede a su servidor, usted verifica la firma con la clave publicada y sabe con certeza qué agente envió la solicitud.

El verificador explora ese directorio y confirma que devuelve JSON. Si no ha publicado uno, no puede distinguir a un agente legítimo de un raspador que lleva su agente de usuario. El argumento de seguridad por sí solo es convincente. El caso práctico es más amplio: los agentes que admiten Web Bot Auth obtienen límites de tarifas más bajos y acceso a más partes de su sitio. Las claves publicadas se amortizan inmediatamente.

4. Descubrimiento de protocolos: los puntos finales conocidosEste es el corazón de la herramienta y la categoría con mayor peso (25% de la puntuación final). También es la parte de la pila de agentes que cambia mensualmente, por lo que el verificador se apoya en puntos finales bien especificados en lugar de trucos específicos del proveedor.

Tarjeta de servidor MCP

El Model Context Protocol es la forma en que Claude, ChatGPT y una lista cada vez mayor de agentes descubren herramientas invocables en un servidor remoto. La tarjeta de servidor MCP en /.well-known/mcp/server-card.json anuncia el nombre, las capacidades, el transporte y el modelo de autenticación de su servidor. El verificador explora esa ruta y recurre a /.well-known/mcp.json si falta.

Si su producto tiene algún tipo de API, una tarjeta de servidor MCP es el paso que convierte su sitio de un documento a una herramienta. Un agente que encuentra una tarjeta de servidor deja de raspar y comienza a invocar. Esa es una mejor experiencia para el usuario y una interacción más económica para usted.

Habilidades del agente

Agent Skills es un formato de manifiesto más nuevo que reside en /.well-known/agent-skills/index.json. Complementa MCP al describir flujos de trabajo utilizables por agentes, no solo herramientas: “crear un envío”, “presentar un reembolso”, “buscar una reserva”. El verificador explora ese camino y busca una respuesta válida.

Si su sitio ya publica una especificación OpenAPI o una tarjeta de servidor MCP, generar un manifiesto de habilidades del agente es principalmente un ejercicio de traducción. El retorno de la inversión es que Claude Code y clientes similares mostrarán sus habilidades a los usuarios por su nombre.

WebMCP

WebMCP es el primo de MCP en el lado del navegador. En lugar de anunciar herramientas a través de /.well-known/ URL, puede anotar elementos <form> directamente en su HTML con atributos toolname y tooldescription, o declarar herramientas mediante una etiqueta <meta name="webmcp" ...>. El verificador escanea el HTML de su página de inicio en busca de cualquiera de los patrones.

El beneficio es que un agente que use su página en un navegador puede descubrir e invocar esas herramientas sin salir de la pestaña. WebMCP es una pequeña cantidad de marcado para una gran cantidad de fluidez del agente.

Catálogo API (RFC 9727)

RFC 9727 define /.well-known/api-catalog como un puntero a todas las API que expone su origen, servido como application/linkset+json. El verificador confirma que el punto final existe y que su tipo de contenido es correcto. Muchos orígenes reciben aquí una advertencia: sirven el camino, pero con application/json en lugar de application/linkset+json. La fijación del tipo de contenido es un encabezado en una ruta.

Descubrimiento de OAuth

Aquí importan dos especificaciones:

• RFC 8414 describe los metadatos del servidor de autorización OAuth en /.well-known/oauth-authorization-server. Esto le indica al agente cómo iniciar un flujo OAuth contra su emisor.
• RFC 9728 describe los metadatos de recursos protegidos de OAuth en /.well-known/oauth-protected-resource. Esto le dice a un agente, cuando llega a un 401 de su API, con qué emisor autenticarse y qué alcances solicitar.

Un agente que no puede realizar el descubrimiento de OAuth no puede automatizar una acción de inicio de sesión en su sitio sin intervención humana. Si su producto tiene una cuenta de usuario, publique ambas.

5. Comercio a través de agentes: ¿Puede pagarle un agente?Esta es la categoría más nueva y la que recibe el mayor rechazo de los escépticos. La pregunta subyacente es sencilla: cuando un agente quiere comprarle algo en nombre de su usuario, ¿cómo es esa transacción?

El verificador mide cuatro respuestas en competencia.

x402

x402 revive el código de estado 402 HTTP (“Pago requerido”) y agrega un encabezado PAYMENT-REQUIRED con una oferta legible por máquina: precio, moneda, vías de pago aceptadas, punto final de liquidación. Un agente que recibe un 402 firma un pago, vuelve a enviar la solicitud y obtiene el recurso. El verificador busca un estado 402 o un encabezado PAYMENT-REQUIRED en su página de inicio y en cualquier punto final que sondee.

x402 es la opción de menor compromiso. Eliges un punto final pago, devuelves un 402 con los términos y listo. Stripe, Coinbase y varios proveedores de liquidación de criptomonedas respaldan el flujo hoy.

ACP (Protocolo de Comercio Agentico)

ACP es el estándar de OpenAI. Vive en /.well-known/agentic-commerce y describe una superficie de pago más completa: catálogo de productos, precios, impuestos, envío, devoluciones. Si vende productos físicos o digitales y desea que ChatGPT realice transacciones directamente con su tienda, ACP es la vía.

UCP (Protocolo de comercio universal)

UCP se aprovecha de OAuth. Usted declara ámbitos comerciales como ucp:scopes:checkout_session dentro de los metadatos de su servidor de autorización OAuth. El verificador recupera su documento OAuth AS y busca cualquier valor ucp:scopes:*. Un partido gana un pase.

UCP es el protocolo comercial más liviano de los cuatro porque reutiliza la capa OAuth que ya tiene. Si envías tokens para cualquier cosa, ya estás a medio camino.

MPP (Protocolo de pagos automáticos)

MPP, anunciado en /.well-known/machine-payments, es el más general. Se trata menos del flujo de pago y más de anunciar qué tipos de pagos de máquina a máquina acepta su servicio: monedas estables, barreras bancarias de cuenta a cuenta, medición por token.

Una puntuación aprobatoria en comercio no requiere los cuatro. Requiere al menos uno, porque “los agentes pueden pagarle” es una capacidad única con cuatro estándares que compiten por poseerla. Elija el que se adapte a su negocio y envíelo.

Qué significa realmente la puntuación final

La herramienta combina las puntuaciones de las cinco categorías en una calificación general ponderada.

Categoría	Peso
Descubribilidad	15%
Accesibilidad al contenido	20%
Control de acceso de robots	15%
Descubrimiento de protocolo	25%
Comercio Agentico	25%

Las puntuaciones superiores a 85 obtienen una A. Entre 70 y 84, una B. Las calificaciones inferiores caen rápidamente, y eso es a propósito. Un sitio que obtiene una puntuación en el rango D no sólo es imperfecto para los agentes; es funcionalmente invisible para ellos. No anuncia herramientas, no ofrece Markdown, no declara una política de bots, no admite pagos agentes. Para la fracción del tráfico que ya está impulsado por agentes, ese sitio se lee como un dominio estacionado.

La mayoría de los sitios que hemos auditado obtienen una puntuación de entre 10 y 30 en su primera ejecución. Eso está bien. La herramienta está diseñada para encontrarse con usted donde se encuentre y mostrar los seis cambios de mayor influencia. Reparar tres de ellos normalmente mueve un sitio de F a C en menos de un día.

Cómo ejecutar la verificación

Vaya al Agent Protocol Readiness Checker, pegue un URL y espere unos diez segundos. La página de resultados incluye:

• Su puntuación general y calificación con letras.
• Las cinco categorías puntúan con un estado coloreado por verificación.
• La evidencia sin procesar (encabezados, códigos de estado, subcadenas coincidentes) detrás de cada verificación, para que pueda verificar la lectura de la herramienta con sus propios registros.
• Una lista de recomendaciones priorizadas de las principales correcciones.

Puede ejecutar la verificación en dominios provisionales, orígenes internos y producción. Respeta las reglas de seguridad salientes de URL y limita las lecturas del cuerpo a 512 KB, por lo que un servidor mal configurado no puede quemar su límite de velocidad.

Una orden práctica para arreglar las cosasSi desea un levantamiento rápido, haga lo siguiente en orden:

1. Publique un robots.txt válido con reglas User-agent: explícitas para GPTBot, ClaudeBot, Google-Extended y PerplexityBot, además de una directiva Sitemap:. Validarlo con nuestro Robots.txt Validator.
2. Agregue negociación de contenido Markdown en su borde CDN. Verifique el encabezado Accept, convierta HTML a Markdown sobre la marcha, configure Content-Type: text/markdown; charset=utf-8 y Vary: Accept. Devuelve 406 para tipos no admitidos.
3. Publique un llms.txt en su raíz con indicaciones a las páginas que más desea que citen los agentes. Generarlo y validarlo con nuestro LLMs.txt Generator and Validator.
4. Exponga una tarjeta de servidor MCP en /.well-known/mcp/server-card.json. Incluso una tarjeta mínima (nombre, descripción, versión, transporte) desbloquea el descubrimiento de agentes.
5. Agregue señales de contenido a robots.txt. Una línea que declare ai-input: yes, ai-train: no es suficiente para pasar la verificación y publicar una política real.
6. Publique un Web Bot Auth JWKS para que los agentes legítimos puedan firmar solicitudes con su origen.

Esa lista equivale aproximadamente a dos días de trabajo de ingeniero para un equipo con un CDN normal y un servidor de autenticación normal. Mueve un sitio de F a B y prepara el origen para el futuro frente al próximo año de rotación de protocolos de agentes.

Cómo se ve la preparación de los agentes en un año

La lista exacta de comprobaciones que la herramienta ejecuta hoy no será la lista que ejecutará dentro de doce meses. MCP ratificará una especificación formal de negociación de capacidad. Agent Skills se fusionará o reemplazará partes de OpenAPI. ACP, UCP y MPP se consolidarán en menos estándares y más fuertes. Agregaremos sondas a medida que aterricen y las retiraremos a medida que se vuelvan predeterminadas.

Lo que no cambiará es la forma del problema. Los agentes deciden en las primeras solicitudes si vale la pena usar su sitio. Tu trabajo es exponer, de forma rápida y clara, lo que tu sitio puede hacer y cómo utilizarlo. Cada señal que busca el verificador es un atajo que permite a un agente comprometerse con su origen en lugar de darse por vencido.

Ejecute Agent Protocol Readiness Checker en su página de inicio. Corrija las tres recomendaciones principales. Ejecútalo de nuevo. Observe cómo los agentes tratan su sitio de manera diferente después de que se realizan esos tres cambios.

Lectura relacionada

• The Complete Guide to Answer Engine Optimization (AEO) and GEO
• AI Readiness Checker para estructura de contenido y puntuación LLM crawl
• LLMs.txt Generator and Validator para publicar un mapa limpio de su sitio en modelos de lenguaje
• HTTP Header Checker para verificar Vary, Link y los agentes de encabezados de tipo de contenido dependen de