La pregunta que deberíamos hacernos no es solo:
¿Qué funciona hoy en Google?.
La pregunta más interesante es otra:
¿Qué arquitectura no queda obsoleta si Google cambia la interfaz de descubrimiento?
Hoy el SEO sigue teniendo una base bastante clara: contenido útil, HTML rastreable, enlazado interno, sitemaps, datos estructurados cuando aportan valor, Search Console y una arquitectura técnica limpia.
Pero el mundo está cambiando rápido. Google ya no es solo una caja de búsqueda con diez enlaces azules. Tenemos AI Overviews, AI Mode, Gemini, agentes, protocolos de comunicación entre agentes y formatos emergentes para representar conocimiento.
Por eso quiero plantear una tesis. No como verdad cerrada. Más bien como una hipótesis estratégica para empezar a teorizar.
El sitemap es la señal eficiente para Googlebot. El `log.md` puede ser la memoria eficiente para agentes. A futuro, quien tenga una capa de cambios estructurada estará mejor preparado que quien solo tenga HTML + sitemap
Lo que sabemos hoy sobre el SEO
Antes de imaginar el futuro, conviene separar bien el presente.
Hoy, para Google Search, la base sigue siendo el índice. Google explica en su guía oficial para optimizar webs en experiencias generativas que sus funciones de IA en Search, como AI Overviews y AI Mode, están apoyadas en los sistemas principales de ranking y calidad de Google Search.
Esto es importante porque desmonta una mala interpretación: no parece que Google Search necesite ahora mismo un archivo mágico para IA.
De hecho, Google dice que las buenas prácticas SEO fundamentales siguen siendo relevantes para las funciones de IA en Search. También dice que, para aparecer en AI Overviews o AI Mode, una página debe estar indexada y ser elegible para mostrarse en Google Search con snippet. No hay requisitos técnicos adicionales ni optimizaciones especiales obligatorias para esas funciones.
Por tanto, si hablamos de SEO actual, el sitemap sigue teniendo sentido.
Una URL bien enlazada, rastreable, indexable y correctamente incluida en un sitemap con un lastmod fiable sigue siendo una señal operativa útil para descubrimiento y recrawl. Google también ha explicado que los sitemaps pueden servir para comunicar contenido nuevo que se quiere rastrear y para gestionar mejor la relación con el rastreo.
El sitemap responde a una pregunta simple:
“Estas URLs existen y algunas han cambiado"
Eso es exactamente lo que Googlebot necesita para mejorar la eficiencia del rastreo.
Pero esa no es necesariamente la única pregunta que existirá en una web más agentica.
El sitemap informa de URLs; el log.md informa de cambios
Un sitemap XML es una gran pieza de infraestructura, pero es pobre semánticamente.
Puede decir esto:
<loc>https://example.com/recursos/nueva-pagina/</loc>
<lastmod>2026-06-18</lastmod>
</url>
Eso está bien. Pero no explica demasiado.
No dice si la URL es nueva, si se ha fusionado con otra, si ha cambiado su entidad principal, si se ha actualizado el schema, si se ha deprecado una versión anterior, si el cambio afecta al enlazado interno, si hay una nueva relación entre entidad y categoría, si se ha corregido un canonical o si el cambio es editorial, técnico o comercial.
Un agente no solo necesita saber que algo cambió.
Necesita saber qué cambió, cuándo cambió, por qué cambió y qué debería hacer con ese cambio.
Ahí aparece la idea del log.md.
En Open Knowledge Format, OKF, Google Cloud propone un formato portable de conocimiento basado en Markdown y YAML frontmatter. No lo presenta como SEO clásico, sino como una forma de representar metadata, contexto y conocimiento curado para que pueda ser escrito por humanos, generado por agentes, intercambiado entre organizaciones y consumido por ambos.
La especificación de OKF en GitHub incluye log.md como archivo opcional para registrar un historial cronológico de cambios. Las entradas se agrupan por fecha y pueden reflejar creación, actualización, deprecación u otros tipos de cambio.
Esto abre una posibilidad interesante: quizá el futuro no consista solo en que un crawler descubra una página, sino también en que un agente entienda el delta, es decir, qué ha cambiado, por qué importa y qué debería hacer con esa información.
Google ya está construyendo piezas de un mundo agéntico
Google no está construyendo solo una función nueva de búsqueda con IA. Está empezando a dibujar piezas de un stack más amplio para una web agéntica.
En la web clásica, el flujo era relativamente claro:
Googlebot → HTML → sitemap → índice → resultados de búsqueda → AI Overviews / AI Mode
Ese modelo sigue siendo importante. De hecho, para el SEO actual no desaparece: seguimos necesitando páginas rastreables, indexables, bien enlazadas, con contenido útil y señales técnicas consistentes.
Pero en paralelo empiezan a aparecer piezas que apuntan a otro tipo de arquitectura:
- ARD → descubrimiento de recursos agénticos
- A2A → coordinación y colaboración entre agentes
- MCP / WebMCP → conexión entre agentes, herramientas, APIs y sitios web
- OKF → conocimiento portable y contexto estructurado para agentes
- UCP / AP2 → comercio y pagos agénticos con autorización verificable
- A2UI / AG-UI → interfaces generadas o transmitidas por agentes
Aquí conviene separar bien las capas.
- ARD no es un sitemap nuevo. ARD responde a otra pregunta: cómo puede un agente descubrir recursos accionables, verificar quién los publica y entender cómo conectarse a ellos.
- A2A tampoco es un sitemap nuevo. A2A responde a la pregunta de cómo pueden coordinarse agentes de distintos proveedores una vez que necesitan colaborar.
- OKF tampoco es un protocolo de crawling. OKF apunta a otra necesidad: cómo representar conocimiento, contexto y documentación de forma portable para humanos y agentes.
Ese cambio es importante para SEO porque desplaza la pregunta de fondo. En la web clásica, la preocupación principal era cómo conseguir que Google descubriera, rastreara, indexara y entendiera nuestras páginas. Esa pregunta sigue siendo válida. No desaparece. Pero en una web más agéntica puede quedarse corta.
La nueva pregunta podría ser más amplia: cómo hacer que un agente descubra nuestros recursos, entienda qué hacen, verifique si puede confiar en ellos, acceda al contexto correcto, ejecute una acción y devuelva una experiencia útil al usuario.
Aquí es donde aparece la posible función del log.md, pero no como sustituto de ARD, A2A o sitemap. El log.md pertenecería a otra capa: la memoria de cambios. Su función no sería descubrir recursos ni coordinar agentes, sino explicar qué ha cambiado, qué recurso afecta, qué entidad está implicada, qué acción debería revisarse y qué contexto necesita otro sistema antes de actuar.
La tesis, por tanto, no es que el futuro del SEO vaya a ser simplemente log.md. La tesis es más amplia: si Google está construyendo piezas que apuntan a una web de recursos descubribles, verificables y accionables por agentes, el SEO tendrá que pensar menos en páginas aisladas y más en arquitectura de conocimiento, cambios, capacidades, confianza e interfaces.
Conviene no exagerar.
No afirmo que Google vaya a leer mañana un log.md y usarlo como factor SEO**.
Sería una afirmación demasiado fuerte. Lo que sí podemos observar es una dirección: el sitemap organiza URLs para crawlers:
- ARD empieza a organizar recursos accionables para agentes
- A2A facilita colaboración entre agentes;
- OKF apunta a conocimiento portable; y el
log.md, dentro de esa lógica, podría funcionar como una memoria estructurada de cambios.
En ese mundo, un sitemap se queda corto. No porque deje de ser útil, sino porque responde a una pregunta más limitada: qué URLs existen y cuáles han cambiado. Una web agéntica puede necesitar, además, superficies donde los agentes entiendan capacidades, cambios, recursos, restricciones, relaciones, contexto y confianza.
La tesis
Mi tesis es que el sitemap seguirá siendo una señal eficiente para Googlebot, pero el log.md puede convertirse en una memoria eficiente para agentes. No como un archivo bruto donde el agente deja frases del tipo “he hecho tal cosa”, porque eso sería demasiado narrativo, ambiguo y difícil de procesar. El verdadero valor estaría en diseñar una capa de cambios estructurada, capaz de explicar qué se ha creado, actualizado, eliminado, fusionado o deprecado, qué recurso afecta y qué acción debería disparar en otros sistemas.
Algo así:
# Site Update Log
## 2026-06-18
Creation: Created new canonical page for “Nombre del recurso”.
- url: https://example.com/recursos/nombre-del-recurso/
- entity_type: Resource
- entity_id: resource:12345
- change_type: created
- change_scope: content, schema, internal_links
- sitemap_action: add
- lastmod: 2026-06-18T10:30:00+02:00
- structured_data: Article
- canonical: self
- hreflang: es-ES
- validation: passed
- agent: seo-publication-agent
Update: Updated relationship between resource and topic.
- url: https://example.com/recursos/nombre-del-recurso/
- entity_type: Resource
- related_entity: https://example.com/temas/nombre-del-tema/
- change_type: updated
- change_scope: entity_relationship
- sitemap_action: update_lastmod
- validation: passed
Deprecation: Deprecated old duplicate URL.
- old_url: https://example.com/recurso/nombre-antiguo/
- new_url: https://example.com/recursos/nombre-del-recurso/
- change_type: deprecated
- redirect: 301
- canonical_target: https://example.com/recursos/nombre-del-recurso/
- sitemap_action: remove
- validation: pending
Cómo podría diseñarse un log.md para SEO agéntico
Empezaría de forma sencilla. No hace falta sobrediseñar.
La estructura mínima podría ser:
index.md
log.md
pages/
recurso-x.md
servicio-y.md
entities/
products/
services/
organizations/
topic/
taxonomies/
categorias.md
El archivo index.md serviría para que una persona o un agente entienda qué hay dentro del bundle.
El archivo log.md serviría para entender qué ha cambiado.
Y cada entidad o página podría tener su propio Markdown con frontmatter:
type: SEO Page
title: Nombre del recurso
description: Página canónica del recurso.
resource: https://example.com/recursos/nombre-del-recurso/
tags: [resource, topic, seo]
timestamp: 2026-06-18T10:30:00+02:00
---
# Resumen
Página canónica para una entidad o recurso concreto.
# Entidades relacionadas
- Tema: /entities/topics/nombre-del-tema.md
- Categoría: /taxonomies/categoria-principal.md
- Organización: /entities/organizations/nombre-organizacion.md
# Señales SEO
- Canonical: self
- Structured data: Article
- Hreflang: es-ES
- Sitemap: included
La idea es que sea procesable
Un agente debería poder leerlo y responder:
- qué URLs nuevas se han creado;
- qué URLs se han eliminado;
- qué entidades han cambiado;
- qué páginas necesitan recrawl;
- qué cambios afectan al sitemap;
- qué cambios afectan a structured data;
- qué cambios afectan al enlazado interno;
- qué cambios están pendientes de validación;
- qué cambios pueden impactar tráfico, indexación o visibilidad en experiencias de IA.
El flujo ideal
La arquitectura que imagino no sustituye el SEO actual.
Lo ordena.
→ entrada en log.md
→ actualización del documento OKF de la entidad
→ actualización del HTML público
→ actualización del structured data
→ actualización del sitemap.xml
→ validación SEO automática
→ monitorización en Search Console, logs y analytics
En este modelo, el log.md no compite contra el sitemap: lo alimenta.
El sitemap sigue siendo la señal eficiente hacia Googlebot. Pero el log.md se convierte en la fuente semántica desde la que se generan señales para buscadores, agentes, QA interno, documentación, feeds y sistemas de grounding.
Una hipótesis, no una predicción
Quizá no sea exactamente así.
Pero quizá sí.
Y si el futuro de la web es agent-to-agent, el SEO no debería limitarse a publicar páginas. Debería empezar a publicar contexto, cambios y conocimiento operativo de forma que humanos, buscadores y agentes puedan entenderlo.
Como diría Richard Rumelt, conviene preguntarse si esto es estrategia o simplemente fluff con fuentes. Mi respuesta provisional: será fluff si nos limitamos a citar siglas nuevas; deja de serlo cuando separa capas, identifica qué problema resuelve cada una y obliga a rediseñar cómo publicamos conocimiento, cambios, capacidades y confianza en la web.
¿Qué teoría tienes tú sobre esto? Si la web empieza a moverse hacia agentes que descubren recursos, verifican confianza y ejecutan acciones, ¿qué capa crees que tendrá que construir el SEO que hoy todavía no estamos viendo?
Fuentes para pensar en una web agent-to-agent
- Google Developers Blog: Announcing the Agentic Resource Discovery specification
Google presenta ARD como una especificación abierta para publicar, descubrir y verificar capacidades de IA en la web. Es una pieza clave para imaginar una web donde los agentes no solo rastrean páginas, sino que descubren herramientas, skills, agentes, servidores MCP, APIs y catálogos verificables. - Search Engine Journal: Google Cloud Announces The Open Knowledge Format
Search Engine Journal enfoca OKF en la misma dirección: no como una táctica SEO, sino como una capa de contexto para agentes. La clave no está en “rankear mejor mañana”, sino en preparar conocimiento estructurado para sistemas que ya no solo rastrean páginas, sino que necesitan entender procesos, entidades, cambios y relaciones. - Google Cloud: Open Knowledge Format
OKF aparece como formato portable de conocimiento para humanos y agentes, basado en Markdown y YAML. - OKF Specification en GitHub
La especificación incluyeindex.md, frontmatter ylog.mdcomo historial cronológico opcional de cambios. - A2A Protocol Specification
A2A ayuda a explicar la parte de interoperabilidad entre agentes: comunicación, tareas y colaboración entre sistemas agénticos.
