Navegación agéntica: la auditoría que mide si la IA puede usar tu sitio

¿Qué es la navegación agéntica?

Durante veinte años, los sistemas automáticos que leían tu sitio eran crawlers de búsqueda: indexaban texto y seguían links. Hoy una parte creciente del tráfico son agentes (ChatGPT en modo browse, Operator, Project Mariner, Perplexity) que no solo leen: navegan, completan formularios, comparan y compran en nombre de una persona. La navegación agéntica es la respuesta de Google a esa realidad: una categoría de Lighthouse que mide si tu sitio está construido para que un agente pueda operarlo, no solo indexarlo. A estos sistemas se los llama agentes de IA, agentes inteligentes o agentes autónomos, según cuánta supervisión humana necesiten; en esta guía uso el término agentes de IA.

¿Qué audita exactamente?

Cinco señales y siete auditorías, cada una con un porqué concreto. El dato central de la documentación de Google: los agentes usan el árbol de accesibilidad como su modelo de datos primario: la "vista de máquina" de tu página. Cada fila incluye el resultado real de esta guía en PageSpeed Insights (octubre de 2026).

Una precisión sobre la primera fila: el árbol de accesibilidad es de pasa o falla. Según el análisis de la configuración por defecto de Lighthouse de Attract Group, una sola violación de las reglas axe incluidas alcanza para fallar.

¿Cómo se corre el test?

Tres caminos. El más simple: PageSpeed Insights con cualquier URL: desde fines de mayo de 2026 la categoría viene incluida por defecto, y para ver la auditoría de ARD hace falta Lighthouse 13.5 o superior (PageSpeed Insights ya la muestra). En el navegador: Chrome 150 o superior, DevTools, pestaña Lighthouse, botón Analizar. Y para pipelines de CI: lighthouse --only-categories=agentic-browsing desde la CLI. No hace falta configurar nada: si tu herramienta usa Lighthouse 13.3+, la auditoría ya está corriendo, la vean tus desarrolladores o la vea un prospecto evaluándote.

¿Qué cambió desde mayo?

La categoría nació en mayo y ya tuvo una actualización relevante. La cronología se puede verificar en las notas de versión de Lighthouse:

• 1 de mayo de 2026, Lighthouse 13.2.0: se crea la categoría de navegación agéntica junto con las tres auditorías de WebMCP (notas de la versión).
• 7 de mayo de 2026, Lighthouse 13.3: la categoría pasa a la configuración por defecto y aparece en cada reporte, incluido PageSpeed Insights.
• 18 de septiembre de 2026, Lighthouse 13.5.0: se agrega la auditoría ard-schema, que valida catálogos de Agentic Resource Discovery, y se agrupan llms.txt y ARD bajo "agent discovery". Además cambian dos auditorías de WebMCP: la de cobertura de formularios pasa, en vez de marcarse no aplicable, cuando todos los formularios están anotados, y la de herramientas registradas avisa si se supera el límite recomendado (notas de la versión).
• Octubre de 2026: el reporte de PageSpeed Insights ya muestra la auditoría de ARD. En este sitio figuró como No aplicable hasta que se publicó un catálogo (ver la sección de ARD).

¿Por qué mi llms.txt falla en Lighthouse?

Porque Lighthouse revisa el formato del archivo, no solo si existe. Sin archivo (un 404), la auditoría queda como "No aplicable" y no resta. Con un error del servidor se marca, y con un archivo que no cumple, falla. Los criterios de formato, según la documentación de DebugBear y la de Chrome:

• Un encabezado H1 en Markdown: una línea que empiece con "# " seguido de un título.
• Al menos 50 caracteres.
• Al menos un enlace en formato Markdown, [texto](url). Las URL en texto plano no cuentan, aunque funcionen.

Es contraintuitivo: un llms.txt mal armado puede costarte una auditoría que sin el archivo ni siquiera aplicaría. Un ejemplo mínimo que cumple los tres criterios:

# Nombre del sitio

> Resumen de una o dos líneas: qué es el sitio y para quién.

## Secciones clave

- [Servicios](https://tudominio.com/servicios): qué ofrecés
- [Guía](https://tudominio.com/guia): lo primero que debería leer un agente

Dos aclaraciones para no sobrevender. Primero, Google Search no necesita llms.txt para aparecer en AI Overviews ni en AI Mode. Segundo, el estudio de SE Ranking sobre casi 300.000 dominios no encontró relación entre tener llms.txt y ser citado con más frecuencia por la IA. El archivo sirve para la capa de agentes que operan tu sitio, no para posicionarte. Si te falla sin motivo aparente, existe un reporte en el repositorio de Lighthouse donde el mensaje "Fetch of llms.txt failed" apareció aunque el servidor había entregado el archivo: revisá el formato y los logs, y compará con ese caso.

¿Qué es ARD y por qué aparece en Lighthouse?

No es lo mismo que llms.txt. El llms.txt le cuenta a un agente qué hay en tu sitio cuando ya llegó. ARD apunta a otra pregunta: qué recurso invocar para resolver una tarea cuando el agente todavía no sabe dónde buscar. Cada entrada del catálogo declara un identificador, un nombre, un tipo y una URL (o los datos en línea), y se recomienda sumar entre dos y cinco consultas de ejemplo que describan cuándo usar el recurso.

Lighthouse 13.5 audita ese catálogo, y hay un desajuste que conviene conocer. La especificación v0.91 define /.well-known/ard.json y rel="ard" como la forma normativa de publicarlo. En cambio, el código de la 13.5.0 busca, en este orden, una directiva Agentmap en robots.txt, un enlace rel="ai-catalog" en el HTML, el mismo enlace en el header HTTP Link y, por último, /.well-known/ai-catalog.json. Si no encuentra nada, la auditoría queda como No aplicable. Corriendo esa auditoría contra un catálogo válido publicado solo en ard.json, el resultado es No aplicable.

El validador de esa versión espera el formato anterior del manifiesto: un objeto con specVersion en "1.0", un host opcional y un arreglo entries, sin otros campos de primer nivel. Cada entrada necesita identifier (con forma urn:air:...), displayName, type y url o data, pero no ambos. Para obtener el aprobado completo, el type tiene que estar en su lista de tipos conocidos: el ejemplo de skill de la especificación v0.91, application/ai-skill+md, no está, y el catálogo pasa con advertencias y un puntaje de 0,9. Para una skill en Markdown sirve text/markdown; profile="urn:air:agent-skills". Un ejemplo mínimo que cumple todo:

{
  "specVersion": "1.0",
  "host": { "displayName": "Tu nombre o marca" },
  "entries": [
    {
      "identifier": "urn:air:tudominio.com:skill:mi-skill",
      "displayName": "Nombre de la skill",
      "type": "text/markdown; profile=\"urn:air:agent-skills\"",
      "url": "https://tudominio.com/skills/mi-skill/SKILL.md",
      "representativeQueries": [
        "pregunta que haría una persona que necesita esto",
        "otra forma de pedir lo mismo"
      ]
    }
  ]
}

Qué hacer: la mayoría de los sitios de servicios no tiene nada que publicar, porque ARD describe recursos invocables y no una página comercial. Sin catálogo, la auditoría no aplica y no resta. Si tenés un servidor MCP, una API, una skill o una herramienta pensada para agentes, publicá el catálogo en /.well-known/ai-catalog.json y también en /.well-known/ard.json, validalo con la herramienta de conformidad de la especificación y probalo en Lighthouse antes de dejarlo en producción, porque un catálogo mal formado falla.

Este sitio publica un catálogo con tres skills, cada una un archivo Markdown real que un agente puede cargar: el AI Score (diagnóstico inicial gratis, versión completa USD 49), el diagnóstico de posicionamiento digital (desde USD 500) y el plan de optimización de rendimiento Lighthouse (desde USD 300). Cada skill le indica al agente qué puede revisar por su cuenta y cuándo derivar a la persona, y ninguna envía datos ni paga sin confirmación humana. Es el uso más liviano de ARD, skills en Markdown y no un servidor MCP ni un agente. El catálogo está en /.well-known/ai-catalog.json y, con el validador de Lighthouse 13.5.0, da cero errores y cero advertencias.

¿Por qué no da un puntaje de 0 a 100?

Decisión deliberada de Google, y honesta: los estándares del agentic web todavía están madurando (la adopción de llms.txt ronda el 10% de los dominios según el relevamiento de SE Ranking sobre 300.000 sitios), así que un número único sugeriría una madurez que no existe. En su lugar, la categoría entrega un ratio de auditorías superadas (6/6, 5/6) con el detalle accionable de cada chequeo. La categoría está marcada como experimental: es un tablero de preparación, no una calificación final. Y el ratio cuenta solo las auditorías que aplican: las marcadas "No aplicable" quedan fuera, por eso un sitio puede mostrar 3/3 con varias auditorías sin aplicar.

¿Es un factor de ranking?

No confirmado, y conviene decirlo sin vueltas: Google no declaró la navegación agéntica como factor de posicionamiento. Hay incluso una tensión documentada que vale entender: Google Search Central aclaró que no necesitás llms.txt para aparecer en AI Overviews o AI Mode, mientras Chrome lo audita en esta categoría. No es contradicción sino dos capas distintas: el buscador extrae contenido de tu HTML indexado; los agentes necesitan operar tu sitio en vivo, con presupuestos de contexto limitados. La navegación agéntica mide la segunda capa. Y esa capa es donde ocurre el comercio agéntico: un agente que no puede navegar tu sitio no puede completar una compra en él: se va al competidor que sí puede.

Dónde encaja: encontrar, entender, usar

Tres preguntas distintas, tres disciplinas que se apoyan entre sí:

Una web puede resolver las dos primeras y fallar la tercera. En el framework GEO-ABCD, la navegación agéntica es la dimensión D (Data & Structure): lo que vuelve operable a la entidad que las otras tres dimensiones hacen reconocible.

¿Qué es el comercio agéntico y qué tiene que ver con tu sitio?

El comercio agéntico (agentic commerce) es el modelo en el que un agente de IA actúa en nombre de una persona durante parte o todo el proceso de compra: busca, compara y completa el checkout sin que la persona navegue el sitio. Detrás hay agentes inteligentes y autónomos que ya no se limitan a recomendar: ejecutan.

Hay dos caminos por los que un agente puede comprarle a un negocio. El primero es operar tu sitio como lo haría una persona: navegar, completar formularios y llegar al pago. Ese camino es el que mide la navegación agéntica de Lighthouse. El segundo es a través de protocolos que exponen el catálogo y el checkout directamente: el Agentic Commerce Protocol (ACP), de OpenAI y Stripe, publicado como estándar abierto en septiembre de 2025, y el Universal Commerce Protocol (UCP), que Google anunció en enero de 2026 (guía de protocolos de iubenda).

Conviene no vender humo: el panorama todavía se está acomodando. En marzo de 2026 OpenAI dejó de ofrecer Instant Checkout como experiencia nativa dentro de ChatGPT y pasó a derivar las compras a los propios comercios (análisis de WAIA). La infraestructura avanza más rápido que las reglas.

Qué significa para tu sitio: Lighthouse no audita ACP ni UCP; ninguna de sus auditorías revisa esos protocolos. Lo que mide es la base común, que un agente pueda navegar y operar tu web. Y en este tipo de compra pesan menos los elementos visuales y más el dato estructurado, la claridad de las políticas y un checkout compatible con procesos automatizados, según un análisis de Empresa Actual. Un sitio que un agente no puede recorrer no llega ni a la etapa del checkout.

¿Cómo está la web hoy?

Mal, y eso es la oportunidad. En un relevamiento sobre los sitios más populares de la web, 2 de cada 3 fallaron el chequeo del árbol de accesibilidad: el corazón de la auditoría. Y de los pocos sitios que publican un llms.txt, la mayoría lo tiene con errores de formato. Traducción práctica: pasar esta auditoría hoy te pone en una minoría medible, con un test reproducible que cualquiera puede correr sobre tu dominio en treinta segundos.

Un caso verificable: esta guía

Esta guía saca 6/6 en la categoría de navegación agéntica de PageSpeed Insights (octubre de 2026): seis auditorías puntuadas, todas aprobadas, más una informativa que lista las herramientas WebMCP registradas. No hace falta creerlo: corré el test sobre esta misma guía y después corré el de tu sitio.

Qué significa y qué no. El 6/6 cuenta las seis auditorías puntuadas; la de herramientas registradas es informativa y no suma ni resta. Prueba que el HTML, el formulario anotado, los esquemas de WebMCP, el llms.txt y el catálogo ARD pasan la validación de Lighthouse. No prueba que un agente real use bien esas herramientas: WebMCP sigue en origin trial y la validación mide la forma, no el uso. Un sitio estático parte con ventaja y es justo decirlo: el 6/6 es el piso que un sitio bien construido y con WebMCP declarado debería alcanzar, y la prueba de que el método funciona.

Antes de sumar WebMCP y el catálogo, la página de inicio medía 3/3 con cuatro auditorías sin aplicar. Y en las cuatro categorías clásicas de Lighthouse móvil, la última medición publicada es de julio de 2026: 100 en Rendimiento, Accesibilidad, Prácticas recomendadas y SEO, como muestra la captura de abajo.

Probalo con un agente: dos herramientas WebMCP en esta guía

Para no quedarnos en la teoría, esta guía registra dos herramientas WebMCP reales. Una es de solo lectura: consultar_servicios devuelve los servicios con su precio y cómo pedirlos. La otra es el formulario de más abajo, declarado con la API declarativa: solicitar_diagnostico.

Ninguna actúa por su cuenta. El formulario puede ser completado por un agente compatible, pero el botón lo presiona la persona, y lo único que ocurre es que se abre WhatsApp con un mensaje armado para que lo revise y lo envíe. La herramienta de lectura no modifica nada. Es el criterio que recomienda Chrome para acciones con consecuencias: que la persona confirme.

WebMCP sigue en origin trial desde Chrome 149. Para verlas en acción en tu navegador, activá chrome://flags/#enable-webmcp-testing y probalas con la extensión Model Context Tool Inspector. Con ellas, esta guía pasa en PageSpeed Insights la cobertura de formularios y la validez de los esquemas de WebMCP, y el reporte lista las herramientas registradas: corré el test sobre esta misma guía.

Pedí tu diagnóstico

Sitio web

Nombre

Qué te interesa Diagnóstico de posicionamiento digital Preparación para agentes AI Score, versión completa Plan de optimización de rendimiento Otra consulta

Mensaje (opcional)

Preparar mensaje en WhatsApp

¿Qué significa esto para una empresa?

Imaginá que un cliente le pide a un agente: "buscame tres proveedores, compará y contactá al mejor". Para quedar en esa lista, el agente tiene que encontrarte, entender qué ofrecés y poder usar tu sitio para llegar a la acción. Una web bien posicionada puede fallar en ese último paso, y no se nota en un informe de rankings: se nota en el reporte de esta auditoría.

Preparar el sitio para agentes es un capítulo del diagnóstico de posicionamiento digital, la auditoría completa de SEO y GEO: junto con la visibilidad en motores de IA, el SEO técnico y los datos estructurados, se revisan el árbol de accesibilidad, el llms.txt, la estabilidad de layout y, si aplica, WebMCP y ARD. El diagnóstico parte desde USD 500, compara tu situación con los 5 principales competidores e incluye un tablero dinámico entregable con todos los datos organizados, para decidir a nivel negocio y no solo de posicionamiento.