¿Está tu web preparada para los agentes de IA?

Una web Agent-Ready es aquella cuya información puede ser descubierta, interpretada y consultada por sistemas automáticos, no solo leída por personas, y que cuando corresponde permite interactuar con capacidades concretas bajo permisos explícitos.

La diferencia con una web normal no está en el diseño ni en el contenido, sino en cuántas formas hay de acceder a lo mismo. Una web tradicional publica una representación: HTML. Una web Agent-Ready publica varias representaciones coherentes de la misma información, cada una pensada para quien la va a leer, y todas salidas de la misma fuente de datos.

Conviene decir una cosa desde el principio: Agent-Ready describe un conjunto de capacidades arquitectónicas, no es una certificación. No hay ningún organismo que lo acredite ni ningún sello que se pueda obtener. Cuando alguien ofrezca uno, desconfía.

La web lleva treinta años añadiendo destinatarios sin quitar ninguno. Cada capa se montó sobre la anterior porque apareció alguien nuevo que necesitaba leer lo mismo de otra manera.

1. **HTML para personas.** La capa original y la que sigue mandando

   diseño, navegación, lectura. Nada de lo que viene después la sustituye.

2. Datos estructurados para buscadores. Schema.org y JSON-LD aparecen para que un rastreador no tenga que adivinar si eso es un producto, un curso o un artículo.

3. Contenido y APIs para consumidores automatizados. Integraciones, aplicaciones móviles y sistemas de terceros que necesitan el dato y no la página.

4. **Interfaces para agentes compatibles.** Lo nuevo

   mecanismos para que un sistema de IA descubra qué puede consultar y lo consulte sin interpretar maquetación.

Es útil separar Agent-Ready en cuatro capacidades, porque se implantan por separado, cuestan cosas distintas y no todas hacen falta. Una web puede ser excelente en las dos primeras y no necesitar nunca la cuarta.

Es la confusión más frecuente, y tiene consecuencias prácticas: lleva a comprar lo que no se necesita y a descuidar lo que sí. Los tres enfoques son complementarios y resuelven problemas distintos.

Dicho corto: el SEO trabaja para que te encuentren, el GEO para que te entiendan y te citen bien, y Agent-Ready para que puedan preguntarte. Si tu SEO está roto, esto no lo arregla. Y tener una API no posiciona.

Ninguno de los tres sustituye a los otros. Y conviene repetirlo porque se vende lo contrario: publicar un fichero llms.txt, servir Markdown o levantar un servidor MCP no garantiza aparecer en ChatGPT, Gemini o Copilot. Cada producto decide por su cuenta qué fuentes usa, y eso cambia sin avisar.

Ninguna de estas piezas es obligatoria. Cada una resuelve un problema concreto y conviene entender qué aporta y qué no antes de adoptarla.

• Schema.org y JSON-LD. Vocabulario estándar para decir qué es cada cosa. Sirve para que buscadores y sistemas automáticos no tengan que inferirlo. Aporta en catálogos, fichas y contenido estructurado. No garantiza resultados enriquecidos ni mejor posición.
• Markdown. El mismo contenido sin maquetación, en texto limpio. Sirve para que un modelo procese el artículo o la ficha sin pelearse con el HTML. Aporta en sitios con mucho contenido editorial o documental. No sustituye al HTML ni mejora por sí solo la indexación.
• APIs y OpenAPI. Una interfaz para pedir datos concretos y una descripción legible por máquina de esa interfaz. Aportan cuando hay un catálogo que cambia o integraciones repetidas. No son necesarias en un sitio de veinte páginas estables.
• Model Context Protocol (MCP). Un protocolo abierto para publicar capacidades —consultas, recursos— de forma que cualquier cliente compatible las use sin integración a medida. Aporta cuando varios consumidores distintos quieren lo mismo. No hace que los agentes te descubran solos: alguien tiene que conectar el servidor.
• WebMCP. Propuesta en incubación del grupo de Web Machine Learning del W3C para que una página exponga herramientas al agente que corre en el navegador de la persona. Hoy es una propuesta, no un estándar, y no está activa por defecto en los navegadores estables. Útil para explorar; no para prometer.
• Autenticación, permisos y límites. Lo que convierte lo anterior en algo que se puede poner en producción: quién accede, a qué, cuántas veces y qué queda registrado. Es la parte que suele faltar en las demostraciones.

Estos son escenarios posibles con la tecnología que existe hoy, no capacidades que tenga implantadas cualquier empresa. La diferencia importa: lo primero describe lo que se puede construir; lo segundo, lo que ya funciona. De los cuatro, el único que nosotros tenemos implantado es el primero, y solo en su parte de consulta.

Formación y academias. La pregunta de negocio es «¿qué formación puedo hacer y cuándo empieza?». Para responderla hace falta el catálogo de cursos, las convocatorias con su estado y las modalidades, todo vigente en el momento de la consulta. La mejora razonable es una fuente de datos única detrás de la web y una interfaz de consulta sobre ella, porque las fechas cambian y una copia manual envejece en días. El beneficio potencial es que quien pregunta reciba lo que de verdad hay abierto, en lugar de una versión antigua de la página o del dato de un agregador.

Comercio electrónico. La pregunta es «¿tenéis esto, en esta talla, y a cuánto?». Hace falta el catálogo con sus atributos, el precio y la disponibilidad real. La mejora razonable empieza por datos estructurados coherentes con la ficha y sigue, si el volumen lo justifica, por una interfaz estable de consulta. El beneficio potencial es dejar de depender de que alguien raspe la ficha de producto —una integración que se rompe en el siguiente rediseño— y que el dato que circule fuera sea el tuyo y esté actualizado.

Servicios B2B. La pregunta es «¿hacéis esto y cómo trabajáis?». Hace falta el catálogo de servicios, el alcance de cada uno y la documentación técnica que lo respalda. La mejora razonable es contenido legible por máquina y fichas con estructura explícita; la interacción, si se llega a ella, se queda en preparar una solicitud que revisa y envía una persona. El beneficio potencial es aparecer con precisión cuando alguien compara proveedores, que es justo el momento en el que una descripción vaga descarta.

Software y SaaS. La pregunta es «¿cómo hago esto con vuestra herramienta?» y, a veces, «hazlo». Hace falta la documentación y el catálogo de funcionalidades; para lo segundo, operaciones acotadas con los permisos del usuario que las pide. La mejora razonable es exponer primero la documentación de forma consultable y dejar las acciones para cuando haya autenticación, autorización y registro de lo que se hace. El beneficio potencial es menos carga de soporte en preguntas repetidas y una integración que no depende de que cada cliente la construya por su cuenta.

Lo más fácil de decir en este terreno es que algo «está preparado para la IA». Nosotros preferimos enseñarlo, y por eso lo implantamos primero en nuestra propia web antes de ofrecerlo a nadie.

La idea central es que no hay un catálogo aparte para las máquinas. La misma fuente de datos que pinta la web alimenta todas las demás representaciones, así que una convocatoria con plazas es la misma para la persona que la lee y para el sistema que la consulta.

Puedes ver la arquitectura completa, con cada interfaz enlazada y lo que puede y no puede hacer un agente, en la página Agent-Ready de DatIACode. Y si te interesa cómo funciona MCP por dentro, lo contamos en MCP, el protocolo que conecta agentes con los sistemas de tu empresa.

• HTML y JSON-LD en la misma página: lo que lee una persona y lo que interpreta un buscador no se contradicen porque salen del mismo sitio.
• Markdown bajo demanda: cualquier contenido se sirve en texto limpio si se pide con la cabecera Accept: text/markdown.
• API pública versionada, descrita con OpenAPI, para consultar cursos, convocatorias, servicios y artículos.
• Mecanismos de descubrimiento —índices para modelos y descripción de las interfaces— para que no haga falta que nadie los explique.
• Servidor MCP remoto en https://www.datiacode.com/mcp, público y de solo lectura, con ocho herramientas de consulta sobre el catálogo vivo.
• WebMCP experimental en formularios concretos: puede ayudar a rellenar y validar, pero el envío lo hace siempre la persona.

Vale la pena ver el recorrido completo, porque es donde se entiende qué aporta todo lo anterior. Supongamos que alguien le pregunta a su asistente: «¿qué cursos de IA tiene DatIACode y qué convocatorias hay?».

Lo primero, y es la parte que más se malinterpreta: el asistente no aparece por su cuenta. Alguien ha tenido que configurar nuestro servidor MCP en ese cliente, igual que se configura cualquier otra integración. A partir de ahí, el recorrido es este.

1. El cliente, ya conectado, consulta qué herramientas publica el servidor y con qué parámetros.

2. Llama a search_courses con el tema que le interesa y recibe los cursos que encajan, con su slug y su URL.

3. Llama a search_cohorts —o a get_cohort si ya tiene una en mente— para saber qué convocatorias hay y en qué estado están.

4. Construye la respuesta con eso. Son los mismos datos que pinta la web, porque salen de la misma fuente: no hay un catálogo paralelo que se quede desactualizado.

Es la pregunta que más veces nos llega y casi siempre con la respuesta ya puesta. Conviene separarla del resto, porque MCP es la pieza más visible y la que menos falta hace en la mayoría de los casos.

Esto es orientación inicial, no un diagnóstico. La fila que más se malinterpreta es la última: añadir MCP no habilita acciones seguras por sí mismo, y el trabajo que hay detrás —quién puede hacer qué y quién lo confirma— es el mismo con MCP que sin él.

No hace falta una auditoría para hacerse una idea. Ocho preguntas dan bastante señal, y las que se responden con un «no sé» suelen ser las interesantes.

• ¿La información de tus productos y servicios está estructurada, o vive dentro del diseño de cada página?
• ¿Hay una única fuente de datos detrás, o la web dice una cosa y el sistema interno otra?
• ¿Tu contenido principal está en el HTML, o aparece solo después de que el visitante interactúe?
• ¿Existe alguna forma de consultar tus datos que no sea raspar la web?
• ¿Tus catálogos reflejan el estado real hoy, o se actualizan a mano cada cierto tiempo?
• ¿Sabes qué información puede salir y cuál no debería salir nunca?
• ¿Has probado alguna vez qué ve un sistema automático cuando entra en tu web?
• ¿Tienes claro qué acciones exigirían la confirmación de una persona?

Es una orientación cualitativa, no una nota. No hay una escala de madurez Agent-Ready validada por nadie, y cualquiera que te dé una puntuación sobre cien se la está inventando. Responder que sí a las ocho tampoco acredita nada: indica que la información de tu empresa está ordenada, que es lo que de verdad aprovecha cualquier sistema, humano o no.

Casi siempre se trabaja sobre lo que ya hay. Rehacer una web para esto es desproporcionado, y además innecesario: el primer tramo del camino es ordenar información que ya existe.