¿Tengo que implementar ARD y OKF en mi WordPress? Te cuento de qué van estos nuevos estándares de IA

En una misma semana de junio de 2026 han caído dos estándares nuevos para la llamada web agéntica (la web pensada para que la ejecuten agentes de IA, programas que actúan por su cuenta y no solo personas), los dos de la mano de Google.

Se llaman ARD y OKF, suenan importantes, y como era de esperar ya empiezan a salir los artículos de turno avisándote de que tienes que implementarlos ya mismo en tu web o te quedas atrás, peroooo…

A ver, tranqui, si tu web es un WordPress de contenido normal, un blog, una web de empresa o una tienda, ahora mismo no tienes que tocar absolutamente nada. Y te lo explico con calma, porque entender qué son estas dos cosas y, sobre todo, qué NO son, te va a ahorrar caer en las prisas de siempre.

Vamos a verlo, sin emocionarnos demasiado y con los datos en la mano.

OKF y ARD: dos estándares que nacen juntos pero ni se tratan

Es raro, pero sí, han salido dos estándares casi a la vez, los dos con olor a Google, y ninguno menciona al otro, como si no supieran que el otro existe, como dos primos cabreados. Y, sin que sirva de precedente, esta vez Joost tiene toda la razón, es justo lo que ha pasado.

Pero como me acabo de dar cuenta de que no te he explicado de qué van aquí va una pequeña explicación:

• OKF (Open Knowledge Format) es una forma de empaquetar una base de conocimiento, un montón de ficheros de texto en formato Markdown con tus contenidos organizados por temas. Pero ojo con el detalle, porque que alguien encuentre ese paquete no es asunto suyo, lo dice la propia especificación. Un OKF montado en tu servidor es, por diseño, invisible.
• ARD (Agentic Resource Discovery) es justo la pieza que le falta al otro, la capa que se encarga de que te encuentren. Publicas un fichero en una ruta fija de tu dominio, /.well-known/ai-catalog.json, donde listas lo que tu web ofrece a los agentes de IA, y desde ahí se puede apuntar incluso a un paquete OKF, o a otra cosa.

O sea, que uno empaqueta y el otro encuentra. Por separado cada uno está cojo, y juntos encajan bien, sea casualidad o no, pero eso no significa que vayas a tener que montar ambas tecnologías, ni de coña.

Las tres capas mezcladas, no agitadas

Para no perderte, quédate con que en todo esto hay tres capas distintas, y el lío viene precisamente de mezclarlas … o agitarlas, ya me he perdido un poco, ustedes me perdonen.

Imagínate tu web como un negocio a pie de calle, tienes un escaparate, que es tu contenido, lo que cualquiera que pasa, persona o bot, puede ver y leer. Detrás puede haber una trastienda con máquinas que hacen cosas, un cajero, una fotocopiadora, lo que sea, y esas serían tus capacidades, funciones que un agente puede activar para que hagan algo por él.

Y luego está la guía de comercios del barrio, donde alguien busca «quién me imprime aquí cerca». ¿Lo has entendido, o me he explicado?, no ¿verdad?, lo pongo con viñetas:

• La capa de contenido (el escaparate): Para las IAs, el cartel de ese escaparate es el llms.txt (un fichero de texto que les dice a los bots qué hay de interesante en tu web y cómo leerlo, una especie de robots.txt pero pensado para inteligencias artificiales).
• La capa de capacidades (la trastienda): El ai-catalog.json de ARD es el listado de máquinas de tu trastienda. Aquí no va tu contenido, van cosas que un agente puede invocar, como un servidor MCP (un conector que le da herramientas a la IA), un agente A2A (agentes que se hablan entre ellos) o una API.
• La capa de descubrimiento (la guía de comercios): Son los registros de ARD, buscadores que rastrean esos catálogos por toda la web y, cuando un agente pregunta «quién sabe hacer X», le devuelven una lista.

¿Ves el problema? Si tu web es solo escaparate, que es el caso de la inmensa mayoría de blogs y webs corporativas, tu listado de máquinas está vacío, no tienes trastienda que enseñar. ¿Y vas a montar el catálogo igualmente?, como verás cuando me ponga la gorra de VigIA, te sale peor que no montarlo.

ARD está bien (pero todavía no toca)

ARD no es un experimento de fin de semana, no es EmDash de Cloudflare. Lo firman Google, Microsoft y Hugging Face, está construido sobre el modelo de datos AI Catalog del grupo de trabajo de la Linux Foundation, y detrás andan nada menos que Amazon, GitHub, Salesforce, Snowflake, Nvidia o Cisco.

GitHub ya lo ha metido en Copilot (te recuerdo que ambos son Microsoft) con su Agent Finder, y Hugging Face tiene su propia implementación funcionando. Cuando se junta gente así lo normal es que la cosa acabe siendo el estándar para esto.

Y además es que resuelve un problema real, el de que un agente encuentre la herramienta adecuada entre las miles que va a haber repartidas por mil empresas distintas. Eso es ya un problema en el mundo de las grandes integraciones.

Ahora bien, dos matices, así para nosotros:

• Esto es la capa de capacidades, no la de contenido: Cuando leas por ahí que publicar el ai-catalog.json «pasa a ser lo mínimo exigible», ojo, eso es para quien ofrece capacidades en ese mundo empresarial, no para el blog de recetas ni para la web del fontanero del barrio. Tu WordPress de contenido no tiene nada que catalogar ahí.
• Es una versión 0.9, un borrador que todavía se va a mover: Y no es que pueda cambiar en el futuro, es que ya se contradice consigo misma hoy. La especificación base llama a un campo mediaType y la capa de ARD lo llama type, para exactamente lo mismo. Cuando ni los que la escriben se ponen de acuerdo en cómo se llaman las cosas, montar eso a ciegas en tu web es querer jugar un partido que aún no tiene ni equipos, ni campo, ni fecha.

OKF igual hasta sobra

Y OKF, ¿qué pinta en tu WordPress?, pues todavía menos.

OKF va de empaquetar tu base de conocimiento en ficheros Markdown para que la IA la consuma, suena bien, pero…

1. Está más verde aún que ARD, hasta el punto de que ni siquiera existe un tipo de fichero registrado para un paquete OKF. Cada cual se inventará el suyo y no habrá manera de que coincidan.
2. Lo de «dale a la IA todo mi contenido en bruto» ya está cubierto, y con una convención mucho más extendida, que es elllms-full.txt (la versión del llms.txt que vuelca el contenido completo, no solo el índice). Si ya generas ese fichero adoptar OKF sería cambiar algo que funciona y que todo el mundo entiende (aunque lo lean pocos) por algo más inmaduro que nadie lee, para tapar una necesidad que ya tenías tapada. No le veo el sentido, sinceramente.

¿Tenemos que hacer algo?

Te lo resumo en lo que sí merece tu atención y lo que puedes ignorar tranquilamente.

• Cuida tu llms.txt: Esta es la capa que de verdad te toca como web de contenido, y la que puede que ayude a que las IAs te lean y te citen bien. Si aún no lo tienes, igual es el momento de hacerlo, cuesta cero añadirlo (con VigIA menos que cero), no en ARD ni en OKF.
• No generes un ai-catalog.json «porque sí»: Si tu web no expone capacidades reales déjalo estar. Un fichero vacío en /.well-known/ no te suma nada, y encima esa ruta es delicada, que ahí viven cosas como la validación de los certificados SSL y lo que toquen otros plugins.
• Vigila quién empieza a llamar a tu puerta: Esto sí que puede ser interesante de verdad. A medida que ARD se extienda van a empezar a aparecer por tu web rastreadores nuevos, los de esos registros, pegando a tu /.well-known/ para ver si tienes catálogo. Saber quién te rastrea y para qué siempre ha sido la mejor brújula en todo este lío de la IA, mucho mejor que correr detrás de cada estándar que sale.

¿Y VigIA? ¡¡Una solución queremos!!

Déjame ponerme la gorra de VigIA un momento, que para algo es mi plugin de visibilidad para IA. Lo fácil, lo que vas a leer por todas partes en cuanto ARD coja algo de impulso, es que montes tú también tu catálogo en /.well-known/ai-catalog.json.

Y oye, tiene su lógica, porque la idea de que un agente descubra solo lo que tu web ofrece es buena, y porque generar ese fichero es de lo más sencillo, y además VigIA ya se sabe todas tus URLs.

Pues precisamente por eso no lo voy a hacer (todavía), generar el fichero es lo barato, ser el responsable de que esté bien en miles de webs, para siempre, es lo caro.

Estamos hablando de una norma que está en pañales (versión 0.9) y que se contradice a sí misma, pues hay un campo que en un sitio se llama de una manera y en otro de otra, y ni siquiera está registrada la etiqueta que dice qué clase de archivo es esto.

El día que arreglen ese lío, la mudanza de todas esas webs no la hace quien escribió la norma, la hago yo, mientras no, gracias.

Y hay un error más de fondo, que es el más importante, el hecho de que un catálogo ARD es la carta de un restaurante, lista lo que puedes pedir, no lo que hay en la despensa. O sea, lista capacidades, cosas que un agente llama para que pase algo, pero tiene que haber ese «algo».

De todo lo que hace VigIA, eso solo lo es el servidor MCP. El llms.txt y los .md para agentes son la despensa, o sea, contenido para leer, no platos que pedir.

Si los metes en la carta, te toca inventarte una etiqueta de archivo que no existe en ningún registro. Y si no los metes, en una web normal y corriente, de puro contenido, el catálogo se te queda casi vacío, y un catálogo vacío es peor que no tener ninguno, porque le pones al agente un cartel de «mírame» pero luego resulta que no hay nada.

Así que lo que voy a hacer con VigIA es lo contrario de fabricarte el fichero, medirlo. El analizador de visibilidad mirará si tu web (o la del vecino, para el caso) publica un ai-catalog.json válido y qué expone, y te lo dirá. Sin escribir una sola línea en el .well-known de nadie, que para colmo es un cajón compartido donde ya andan metiendo mano el certificado SSL y medio plugin de seguridad.

¿Que el día de mañana esto cuaja de verdad, con la norma cerrada y algún agente leyéndola de verdad? Pues entonces VigIA podrá generarlo, faltaría más, pero como una opción que activas tú a conciencia y solo con lo que de verdad es una capacidad, sin colarte el contenido por el medio.

Mientras tanto, prefiero un VigIA que te dice la verdad sobre tu web a uno que te llena el disco de ficheros que no lee nadie. Tú verás lo que te encaja, pero esa es mi apuesta y te la cuento tal cual.

Cuándo sí tendrán sentido OKF y ARD en WordPress

Y para que veas que no te digo «pasa de esto para siempre», te lo concreto. ¿Cuándo deja tu WordPress de ser solo escaparate y tiene una trastienda de verdad que catalogar?

Pues cuando expongas capacidades reales, y en WordPress eso es tener un endpoint MCP, o sacar tu REST API o la nueva Abilities API (la que permite registrar capacidades (abilities) que un agente puede usar) como herramientas para agentes. Ese día tu trastienda deja de estar vacía y la conversación cambia.

Hasta entonces, lo dicho.

Mi opinión, por si te sirve

En toda esta ola de la IA, en la que yo soy ya surfista apasionado, casi profesional, el que gana no es el que corre a montar cada estándar el día que sale, es el que entiende qué capa le afecta y pone el esfuerzo donde pasan cosas de verdad que puedes aplicar.

Para tu web de contenido, esa capa hoy es el contenido y vigilar quién te lo rastrea, no canales para agentes que todavía no te visitan.

Así que ya tienes los datos y un poco de mi visión, lo que hagas con tu web, como siempre, lo decides tú. Si quieres seguir el hilo, tengo más cosas escritas sobre IA y WordPress donde seguro que aprendes algo. Y si quieres debatirlo, o contarme que tú lo ves de otra manera, me tienes ahí abajo, en la sección de comentarios.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!