Las últimas semanas han sido ruidosas. Google lanzó algo llamado formato de conocimiento abierto. Luego, los desarrolladores de Google anunciaron la especificación Agentic Resource Discovery (ARD).
Mientras tanto, cada feed de SEO de LinkedIn se ilumina con alguien que declara que Markdown es el futuro de la web o explica por qué debería ignorarlo todo.
La verdad, como siempre, se encuentra en algún lugar más interesante que cualquiera de los dos bandos.
La web está desarrollando una infraestructura paralela legible por máquina (MCP/WebMCP, OKF, ARD, LLMs.txt…) y los SEO que entienden lo que realmente hace cada capa, en lugar de tratarlo todo como “AI SEO” o una solución milagrosa, tomarán mejores decisiones sobre dónde invertir su tiempo.
Primero: el pastel de capas
Hay al menos seis cosas distintas que se están discutiendo bajo el paraguas de “preparar su sitio para la IA”. Se ubican en diferentes capas y sirven para diferentes propósitos:
- Páginas HTML rastreables: Sigue siendo la base. Aquí nada ha cambiado. Todo lo demás queda encima.
- Schema.org/Datos estructurados: Sugerencias semánticas integradas en HTML que le dicen a las máquinas explícitamente de qué trata una página. Es, en esencia, un vocabulario.
- LLM.txt: Esencialmente un archivo de navegación. Básicamente, su propósito es decirle a un agente de inteligencia artificial que ya está en su sitio qué páginas son importantes. Pero como dice John Mueller en el podcast Search Off the Record:
“Si alguien ya está en su sitio web, tal vez algún tipo de sistema automatizado sea útil. ¿Adónde va? Quiero ir a Martin’s Splitt y comprar una fotografía, luego el sistema LLM puede ir a su sitio web y puede mirar a su alrededor, por ejemplo, ¿cómo se compra una fotografía? Tal vez él tenga algunas pautas para mí como agente para la compra de fotografías. Eso tiene sentido”.
- MCP/WebMCP: Antes de que ARD entrara en juego, se nos presentó otra solución para el desafío de la interoperabilidad. Un MCP, en su explicación más simple, es una forma estandarizada para que una IA se conecte a sus servicios para extraer conocimiento o tomar medidas. WebMCP, como su propio nombre indica, ofrece a los sitios web una forma de interactuar directamente con los agentes. WebMCP es para interacciones de navegador en vivo en una página web; MCP es para herramientas y servicios más allá de la página.
- Formato de conocimiento abierto (OKF): Un paquete de archivos de rebajas con contenido frontal YAML.
- Descubrimiento de recursos agentes (ARD): Una nueva especificación abierta sobre cómo los agentes encuentran y verifican herramientas, habilidades y otros agentes en la web. Aquí, el foco no es su contenido; son tus capacidades.
Para el comercio electrónico, hay otra capa que vale la pena nombrar por separado: el feed de productos, muy posiblemente el futuro del descubrimiento minorista.
Cada capa hace algo diferente.
Podría seguir agregando a esta lista; Cada cinco minutos aparece una nueva capa. Me detengo aquí. Está aumentando.
Qué es realmente (y qué no es) OKF
Google publicó la especificación OKF en silencio, unida a un cambio de marca de Dataplex en Knowledge Catalog.
El formato en sí es casi sorprendentemente simple: un directorio de archivos de rebajas, cada uno con un pequeño encabezado YAML que declara un tipo, título, descripción, recurso y algunas etiquetas. Los archivos se vinculan entre sí como lo haría cualquier documento de rebajas. Eso es todo.
Como lo expresa el propio blog de Google, OKF es “solo rebajas, solo archivos, solo contenido YAML”.
SEO Suganthan Mohanadasan tiene un desglose claro de esto. Describe OKF como un piso en una pila que ahora incluye sitemap.xml (qué URL existen), LLMs.txt (qué páginas más desea leer) y OKF (la biblioteca misma). Se acumulan en lugar de competir.
La confusión surge no cuando se mira qué es OKF, sino qué hace y en qué capa del caos de agentes y búsquedas se encuentra.
En mi opinión, OKF no es un sistema de recuperación. No reemplaza el gateo. Y, personalmente, no veo un futuro en el que los sistemas de inteligencia artificial ya no ingieran cantidades masivas de HTML o en el que la búsqueda y el RAG no sean un proceso complejo de varios pasos que consista en señales autoinformadas y “no basadas”.
Cualquier sistema autoinformado puede ser manipulado y será manipulado. Por lo tanto, pensar que puede simplemente colocar un montón de archivos de rebajas en su sitio y ser LA opción preferida en recuperación y descubrimiento es descabellado.
OKF es una fuente de señal más alta entre muchas. Puede reducir el costo de análisis y mejorar la calidad de la señal, pero no reemplaza las tuberías existentes.
También vale la pena ser honesto aquí: OKF fue creado para equipos de datos, no para sitios de marketing.
Llegó como una forma de compartir conocimiento interno, es decir, esquemas de tablas, runbooks y definiciones de métricas, entre agentes de IA dentro de las organizaciones. Apuntarlo a un sitio web público me parece un poco como si estuviéramos reutilizando una vez más.
Francois Vanderseypen hace el comentario más preciso sobre lo que OKF realmente es y no es: un gráfico dirigido de archivos de rebajas es una red de documentos, no un gráfico de conocimiento (al menos no en su sentido más puro). Un KG real tiene relaciones escritas, explícitas y consultables. OKF deja lo que implica un enlace enteramente en manos del productor, y un LLM todavía tiene que inferir la semántica cada vez que lo lee.
Para mí, esto apunta al quid de la cuestión de cómo entiendo la web y lo que hacemos como SEO. OKF no cambia la pila. Agrega una entrada más.
No es un atajo. No hay atajos.
El paralelo de Schema.org y por qué es importante
Uno de los patrones que debemos entender aquí es el que Schema.org ya siguió.
Los datos estructurados siguieron un arco predecible:
Adopción – aumento de clasificación – uso generalizado (y juegos) – aprendizaje de plataforma – dependencia reducida como señal de clasificación.
El esquema de preguntas frecuentes tuvo un momento en las SERP, luego Google suspendió el resultado enriquecido de preguntas frecuentes. Las plataformas aprenden de las señales, incorporan las lecciones al algoritmo y el marcado explícito se vuelve menos necesario.
OKF y LLMs.txt pueden seguir el mismo camino. Son más valiosos en las primeras etapas, como señales claras en un mundo donde los sistemas de inteligencia artificial todavía están aprendiendo a analizar la web.
Con el tiempo, si los formatos funcionan, los sistemas aprenden. El marcado explícito se vuelve redundante o sigue siendo una capa de verificación. Por ejemplo, en el comercio electrónico, en particular, la alineación del esquema y el feed se ha vuelto cada vez más importante. ¡Otro paso en la convocatoria de copropiedad del feed de productos entre SEO y equipos pagos!
También hay un punto más sutil que vale la pena destacar aquí sobre la relación entre esquema.org y descubrimiento. El análisis profundo de Jarno van Driel sobre las variantes de productos en Search Engine Journal lo ilustra bien: durante años, la Búsqueda de Google y Google Merchant Center tuvieron requisitos de datos estructurados contradictorios, lo que obligó a los editores a duplicar el marcado. Schema.org evoluciona para cerrar brechas, pero es lento, complejo y la implementación sigue siendo a menudo un desastre.
Los datos estructurados nunca han sido una palanca de clasificación plug-and-play. El OKF tampoco lo será.
¿Debería convertir su sitio a Markdown?
Es un rotundo no de mi parte. ¡Eso no significa que no lo probaré y aplicaré con cuidado!
Y John Mueller lo dijo en el podcast Search Off the Record:
“Cuando se trata de cosas como un motor de búsqueda o probablemente también en un sistema LLM genérico, tener un sitio web que utilice HTML normal para las páginas es fundamental. Porque un motor de búsqueda o un rastreador puede simplemente ir a esa página. Puede reconocer todos los demás enlaces que están dentro del sitio web”.
La información estructural en HTML (enlaces de navegación, pies de página, jerarquías de encabezados, enlaces internos) es la forma en que los rastreadores entienden la forma de su sitio. Los archivos Markdown eliminan todo eso. Estaría rompiendo el descubrimiento para mejorar marginalmente la legibilidad de la máquina de páginas individuales.
Recientemente, en LinkedIn, incluso vi una investigación que muestra cómo “Su navegación podría estar consumiendo su presupuesto de lectura de LLM (de hecho, es ChatGPT Deep Research)”. Hallazgos interesantes, ¡pero no elimines la navegación para “guardar algunos tokens”!
Jono Alderson expone este punto de manera brillante: “Una página no es sólo un contenedor de palabras. Es un artefacto editorial”. La jerarquía, el énfasis, la ubicación, lo que viene primero, lo que es prominente, lo que está escondido en una nota al pie… no son decoraciones bonitas para los humanos. “Son señales sobre el significado”.
“Cuando aplanas una página para convertirla en rebaja, no solo eliminas el desorden. Eliminas el juicio y eliminas el contexto”. Y en el momento en que publicas una representación solo de máquina, habrás creado una segunda versión candidata de la realidad.
La solución aburrida todavía funciona: HTML semántico, estructura clara, jerarquía sensata, contenido que existe cuando se carga la página.
John Mueller cubre ampliamente el debate sobre las rebajas en el podcast: El problema de las versiones paralelas, las lecciones de renderizado dinámico que ya aprendimos por las malas y por qué mantener una versión oculta de su sitio para IA duplica su carga de mantenimiento y crea una pesadilla de depuración de la que nadie le hablará.
La única excepción que señala Mueller es la documentación para desarrolladores:
“Si tiene algo como documentación para desarrolladores, donde, nuevamente, si el agente o el sistema LLM ya conoce su sitio web y el usuario dice, ¿cómo uso esta API? Entonces, si le da al sistema LLM un archivo Markdown, será mucho más fácil de entender”.
Ahora, definitivamente puedo ver un caso de uso sencillo allí.
¿Qué está haciendo realmente ARD?
La especificación Agentic Resource Discovery, anunciada por Google el 17 de junio de 2026, es una bestia completamente diferente. Llegó sólo un par de días después del OKF, no es una coincidencia, y ya está causando un gran revuelo.
El problema que resuelve ARD es de coordinación. En este momento, un agente debe estar conectado a cada herramienta, servidor MCP o API que utiliza antes de poder hacer algo con él.
Eso funciona cuando conectas un puñado de servicios conocidos. Deja de escalar en el momento en que la cantidad de capacidades disponibles supera lo que cualquier equipo puede preconfigurar manualmente.
ARD saca ese descubrimiento de la configuración y lo lleva al tiempo de ejecución. El agente encuentra lo que necesita cuando lo necesita, en lugar de saber sólo lo que le dijeron de antemano.
Está construido sobre dos primitivas:
- Catálogos: Un archivo ai-catalog.json alojado en su dominio, que describe sus capacidades disponibles (servidores MCP, agentes A2A, herramientas OpenAPI). La propiedad del dominio actúa como base criptográfica para la identidad y la confianza.
- Registros: Motores de búsqueda para la web agente. Rastrean catálogos, los indexan y devuelven capacidades de coincidencia con los metadatos necesarios para verificar el editor antes de conectarse.
Si OKF se trata de empaquetar conocimiento para el consumo, ARD se trata de capacidades publicitarias para la conexión.
Se trata de esfuerzos paralelos en diferentes capas del conjunto de agentes emergentes. Ambos se enviaron a centímetros el uno del otro y ahora fueron adoptados a la velocidad de la luz por algunos jugadores muy importantes en el juego, es decir, Hugging Face y su herramienta Discover.
Posiblemente sea una apuesta más pragmática que la capa lógica formal que la precedió y que nunca alcanzó escala web. El tiempo lo dirá.
Una brecha que vale la pena observar
A los pocos días de enviarse ambas especificaciones, un colaborador abrió problemas complementarios en los repositorios ARD y OKF señalando que faltaba algo básico: no hay un tipo de medio acordado para un paquete OKF, por lo que un catálogo puede enumerar uno pero en realidad no puede reconocerlo como OKF sin olfatear el contenido.
Mientras tanto, los editores ya están publicitando paquetes en producción utilizando sus propios tipos provisionales que, como se indica en el propio número, no concuerdan entre sí.
A primera vista, esto parece una pequeña solicitud, solo una solicitud de una etiqueta compartida.
Después de sumergirnos un poco en esta madriguera de conejo en particular, resulta que es una práctica bastante normal. Esperar a un acuerdo total antes de que alguien envíe algo es exactamente como una especificación muere en el comité, y enviar rápidamente y parchear a medida que surge una adopción real es una estrategia antigua.
Application/json en sí no se registró formalmente hasta 2006, aproximadamente cinco años después de que JSON ya tuviera un uso amplio e informal. A nadie le preocupaba eso, porque el coste de alterar la etiqueta era bajo: un analizador podría rechazar algo o retroceder sin gracia.
Pero OKF es diferente, porque lo que sucede después de la recuperación es diferente. El artefacto detrás de la etiqueta es un paquete que un agente autónomo debe ingerir, verificar y potencialmente actuar dentro de un sistema de descubrimiento creado específicamente para la conexión de agente a agente y de agente a herramienta. Si se equivoca el tipo aquí, o se deja que un agente lo infiera, el riesgo no es un error de análisis; es un sistema que actúa sobre algo en lo que no debería haber confiado, sin que nadie compruebe primero el resultado.
Me pregunto cuál es el riesgo que implica resolver esto más tarde que antes en este caso. Supongo que depende de qué tan rápido se resuelva en relación con qué tan rápido se adelante la adopción.
Qué significa esto si eres un SEO
Algunas conclusiones honestas y mi pensamiento actual:
Para la mayoría de los sitios de contenido y marketing, no ha cambiado mucho. HTML, bien estructurado para humanos, sigue siendo la base adecuada. Un formulario de contacto y una arquitectura de sitio limpia le serán más útiles que cualquier paquete de OKF. El descubrimiento todavía depende de los enlaces, la autoridad, las señales de los usuarios… y la indexación.
LLMs.txt es una señal, no una herramienta de SEO. Es útil para ayudar a un agente a navegar dentro de su sitio una vez que ya está allí. En primer lugar, es muy probable que no haya una gran diferencia en cómo los agentes lo encuentran. Y probablemente nunca lo haga.
MCP/WebMCP. Ninguna de las dos cosas es urgente para la mayoría de los sitios de marketing actuales, pero si está creando algo con interfaces programáticas o flujos de comercio electrónico que desea que naveguen los agentes, esta es la dirección en la que se dirige la infraestructura.
OKF tiene mucho sentido si se cuenta con conocimiento interno estructuradoes decir, documentación, referencias de API, especificaciones de productos… y desea que sea más fácil de consumir para los agentes. El generador OKF gratuito que construyó Suganthan producirá un paquete y le brindará una vista gráfica de su estructura de enlaces internos como beneficio adicional. La auditoría estructural por sí sola parece merecer la pena. Pero primero lo ejecutaré en mi sitio web, no en el sitio web de mi cliente.
Vale la pena observar ARD si está creando servicios con interfaces programáticas. Si tiene herramientas, agentes o API que desea que otros agentes puedan descubrir, ARD es el estándar emergente sobre cómo hacerlo. Solo sepa que la capa de identidad debajo de ella, lo que un agente realmente está mirando cuando encuentra su entrada de catálogo, aún se está resolviendo en tiempo real, por lo que trataría esto como una infraestructura para observar de cerca en lugar de construir rutas críticas por el momento.
El ciclo de adopción del esquema podría repetirse. Estos formatos son más valiosos ahora, como señales tempranas. Implementarlos si puede hacerlo a bajo costo. No construya su estrategia en torno a que mantengan valor para siempre y no confíe en ellos como una solución milagrosa.
En definitiva, ten cuidado con las cosas brillantes. – si su empresa tiene cosas más importantes que hacer, es decir, un sitio web terrible, una marca que nadie conoce o que no le importa, una audiencia que no comprende… entonces ocúpese de esto primero antes de quedar atrapado en cualquiera de estas cosas nuevas y brillantes.
El cambio subyacente
Lo que todo esto apunta es a una web a la que realmente le está creciendo una segunda capa o una tercera capa, una escrita para máquinas junto con otra escrita para navegadores y humanos.
Sitemap.xml indicaba a los rastreadores qué URL existían. Robots.txt les dijo adónde no ir. LLMs.txt, OKF y ARD son infraestructuras similares para sistemas agentes: sugerencias de navegación, empaquetado de contenido y descubrimiento de capacidades.
Nada de esto es obligatorio hoy. Nada de esto reemplaza el HTML sólido, el contenido autorizado, la estructura sensata o lo que realmente se encuentra debajo de todo esto: una marca que vale la pena encontrar.
Pero los SEO que entienden lo que realmente hace cada capa, en lugar de tratarla como una única categoría indiferenciada de “AI SEO”, harán mejores apuestas sobre dónde invertir su tiempo.
Mi dinero está en la segunda capa, una infraestructura paralela escrita para máquinas, no un reemplazo de lo que ya existe.
El tercer escenario principal, en el que los sistemas agentes divergen completamente de la red humana, requeriría un conjunto de apuestas diferente al que cualquiera de nosotros estamos haciendo actualmente.
Muchas gracias a Jarno van Driel, Jono Alderson, Chris Green, Suganthan Mohanadasan, Kristine Schachinger, Gianluca Fiorelli, Victor Pan, Renee Bigelow (y a todos los que me he perdido) por algunas brillantes discusiones sobre este tema durante las últimas semanas.
Más recursos:
Imagen de portada: Collagery/Shutterstock
