Web navegable por agentes de IA: el árbol de accesibilidad que leen ChatGPT, Claude y Gemini

Una web es navegable por agentes de IA cuando un asistente que actúa por ti, como los de ChatGPT, Claude o Gemini, puede saber qué es cada botón, enlace o campo y usarlo. Para eso lee el árbol de accesibilidad, el mismo que usan los lectores de pantalla. Lighthouse lo revisa desde mayo de 2026 con 33 reglas automáticas.

Para comprobarlo en tu web: Auditoría de visibilidad en IA

Hasta ahora, preparar una web para la IA era sobre todo que la leyeran y la citaran: lo cuenta la guía de posicionamiento en IA. Los agentes añaden otra pregunta. No solo leen la página: reservan, comparan, rellenan formularios y pulsan botones en nombre de alguien. Si no saben qué hace un botón, no lo pulsan, o pulsan el que no es.

¿Qué es el árbol de accesibilidad?

El árbol de accesibilidad es el resumen que construye el navegador a partir del HTML: cada elemento con su papel (botón, enlace, campo de texto), su nombre y su estado, sin los estilos. web.dev, el sitio de Google para desarrolladores web, lo describe así y recuerda que puedes verlo en las herramientas para desarrolladores de Chrome1.

Un ejemplo. Este fragmento de una ficha de producto:

<h1>Cafetera italiana de acero, 6 tazas</h1>
<label for="cantidad">Cantidad</label>
<input id="cantidad" type="number" value="1">
<button type="submit">Añadir al carrito</button>
<a href="/envios/">Plazos y gastos de envío</a>

llega a un agente más o menos así, una línea por elemento:

heading "Cafetera italiana de acero, 6 tazas"
spinbutton "Cantidad" 1
button "Añadir al carrito"
link "Plazos y gastos de envío"

Sin colores, tipografías ni posiciones: solo qué es cada cosa y cómo se llama. Si el botón fuera un <div> con un icono y sin texto, en esa lista no habría nada que pulsar.

¿Cómo ven una página los agentes de IA?

Según web.dev, un agente puede percibir una página de tres maneras: con una captura de pantalla que analiza un modelo de visión, leyendo el HTML y su estructura, o con el árbol de accesibilidad. Las capturas son lentas y caras en tokens, así que funcionan mejor como respaldo. Los agentes actuales cruzan el HTML y el árbol, que dan una lista limpia de elementos con los que interactuar, con la imagen renderizada para entender la disposición1.

Las fuentes oficiales coinciden en el papel del árbol:

• Chrome. Su equipo escribió en junio de 2026 que los agentes se apoyan en el árbol de accesibilidad, derivado del DOM, como su modelo de datos principal, y que un árbol bien formado es la forma principal en que entienden una página2.
• Google Search. Su guía para las funciones de IA generativa dice que los agentes de navegador pueden analizar capturas, inspeccionar el DOM e interpretar el árbol de accesibilidad para completar una tarea3.
• Anthropic. La herramienta de navegación de Claude en su API tiene una función, read_page, que devuelve el árbol de accesibilidad como texto, con una referencia para cada elemento, y Claude puede pulsar por referencia en vez de por coordenadas. La documentación recomienda usar referencias cuando la página tiene un árbol utilizable y deja las capturas para lo que no lo tiene, como un <canvas>. También señala que leer el árbol suele costar menos tokens que una captura4.
• OpenAI. En sus preguntas frecuentes para editores, a propósito del agente de su navegador ChatGPT Atlas, explica que usa las etiquetas ARIA, las mismas que usan los lectores de pantalla, para interpretar la estructura y los elementos interactivos, y pide añadir papeles, etiquetas y estados descriptivos a botones, menús y formularios5.

La conclusión práctica es sencilla: el árbol es lo más barato y fiable que tiene un agente. Si está mal, el agente tiene que adivinar con la imagen.

¿Qué revisa Lighthouse para los agentes?

Lighthouse 13.3.0, publicada el 07-05-2026, añadió a su configuración por defecto una categoría nueva de navegación por agentes (Agentic browsing).6 No da una nota de 0 a 100 como las demás: muestra cuántas pruebas pasan del total. Revisa el árbol de accesibilidad, la estabilidad visual (CLS), el archivo llms.txt y varias pruebas de WebMCP7.

La prueba del árbol se llama Accessibility tree is well-formed. Su código fuente es corto: toma 33 reglas del motor de accesibilidad axe y la página la aprueba solo si no falla ninguna. No hay grados: una regla que falle basta para suspender8. Agrupadas por lo que piden, son estas9:

Casi todas son reglas de la categoría de accesibilidad de siempre. Chrome lo dice tal cual: es un subconjunto de esas pruebas2.

Cómo corregir los fallos más comunes

La mayoría se arregla en la plantilla, una vez, con HTML corriente. La guía de prácticas de ARIA del W3C da el orden: un ARIA incorrecto es peor que no ponerlo, porque falsea lo que se anuncia, y un papel ARIA no da al elemento el comportamiento de teclado de uno nativo10. Primero HTML nativo; ARIA solo donde no llega.

Botones de icono sin nombre (button-name). Es el fallo más típico: la lupa, la hamburguesa, la X de cerrar.

<!-- Mal: el agente ve «button» sin nombre -->
<button class="icono-buscar"><svg>…</svg></button>

<!-- Bien: el nombre está en el árbol aunque no se vea -->
<button aria-label="Buscar"><svg aria-hidden="true">…</svg></button>

Elementos que parecen botones y no lo son. Un <div> con un evento de clic no aparece en el árbol como botón. web.dev lo pone como ejemplo de algo que el agente puede no reconocer como accionable1.

<!-- Mal -->
<div class="btn" onclick="reservar()">Reservar mesa</div>

<!-- Bien -->
<button type="button" onclick="reservar()">Reservar mesa</button>

Campos sin etiqueta (label). Un texto al lado del campo no es su etiqueta si no está asociado a él: en el árbol, el campo se queda sin nombre. El texto de ejemplo (placeholder) cuenta como nombre para la regla, pero desaparece al escribir; mejor una etiqueta de verdad.

<!-- Mal: el texto está al lado, pero no asociado al campo -->
<span>Correo electrónico</span>
<input type="email">

<!-- Bien -->
<label for="correo">Correo electrónico</label>
<input id="correo" type="email" autocomplete="email">

El autocomplete tiene que usar los valores del estándar (email, name, tel, postal-code…). Uno inventado, como autocomplete="correo", hace fallar autocomplete-valid.

Contenido oculto que se puede enfocar (aria-hidden-focus). Pasa con menús y ventanas cerradas que se ocultan con aria-hidden pero dejan sus enlaces activos: el agente no los ve en el árbol, pero el teclado sí llega a ellos.

<!-- Mal: oculto para el árbol, alcanzable con el teclado -->
<nav aria-hidden="true"><a href="/tienda/">Tienda</a></nav>

<!-- Bien: inert lo saca del árbol y del teclado a la vez -->
<nav inert><a href="/tienda/">Tienda</a></nav>

Identificadores repetidos (duplicate-id-aria). Si dos campos usan aria-labelledby="titulo" y hay dos elementos con id="titulo", el nombre que recibe el agente puede ser el equivocado. Pasa mucho al repetir un componente varias veces en la misma página.

tabindex mayor que cero (tabindex). Un tabindex="3" cambia el orden natural de la página. Usa 0 para hacer enfocable algo que no lo es, o mejor, el elemento nativo.

Cómo comprobarlo

1. Chrome DevTools. Con Chrome 150 o posterior, la pestaña Lighthouse incluye la categoría de navegación por agentes7. La auditoría del árbol enseña qué reglas fallan y un elemento de ejemplo de cada una.
2. El panel de accesibilidad de DevTools. En la pestaña Elementos, el panel de accesibilidad enseña el papel y el nombre de cada elemento. Es la forma más rápida de ver lo que verá el agente en un botón concreto.
3. Lighthouse desde la línea de comandos, para revisar varias plantillas o meterlo en un proceso automático:

npx lighthouse https://www.example.com/reservas/ \
  --only-categories=agentic-browsing --view

Revisa las plantillas donde se hace algo: ficha de producto, carrito, formulario de contacto, reserva, buscador. Son las páginas en las que un agente necesita pulsar.

Lo que esta prueba no te dice

Conviene leerla con tres límites claros.

Está en desarrollo. La propia descripción de la categoría en Lighthouse dice que sigue en desarrollo y puede cambiar11, y Chrome la llama experimental, basada en estándares propuestos7. Ya ha cambiado: la versión 13.5.0, del 18-09-2026, añadió otra auditoría y la agrupó con la de llms.txt12.

No es un factor de posicionamiento. Ninguna documentación de Google la presenta así. Chrome la describe como informativa y sin valores de referencia2, y la guía de Google Search trata los agentes como algo que explorar si te importan y tienes tiempo3.

Aprobar no garantiza que el agente termine la tarea. Los agentes también miran la pantalla y a veces encuentran el botón sin nombre por su aspecto. Y un árbol perfecto no arregla un proceso de compra confuso.

Tampoco es una auditoría de accesibilidad completa: no mira el contraste, el tamaño del texto ni si se puede usar todo con el teclado. Para eso, la guía de accesibilidad web y SEO. La buena noticia es que lo que arreglas para el agente lo arreglas también para las personas que usan un lector de pantalla.

¿Y WebMCP y llms.txt?

Son piezas relacionadas, pero responden a otras preguntas:

WebMCP puede ahorrar al agente muchos clics, pero solo funciona con los agentes que lo soporten; el árbol lo usan todos. Sobre llms.txt, qué es y qué dicen los datos sobre si alguien lo lee, está la guía de llms.txt.

Qué comprueba SmoothSeen

Este blog es de SmoothSeen, así que conviene decir qué hace la herramienta. SmoothSeen pasa a cada página analizada las mismas 33 reglas en su pasada de Lighthouse y lo muestra en la mitad de Posicionamiento IA como «Navegable por agentes de IA»: aprobado si no falla ninguna y, si falla alguna, qué reglas fallan con el fragmento de HTML afectado. También sale en el informe en PDF.

No sustituye a probar tu formulario con un agente de verdad, pero te dice en qué plantilla empezar. Lo que hace que un asistente te cite, más allá de manejar la página, es otra cosa: el texto tiene que llegar en el HTML, como se explica en contenido que solo se ve con JavaScript.

Preguntas frecuentes

¿Qué significa que una web sea navegable por agentes de IA?

Que un agente de IA que actúa por una persona puede entender qué es cada elemento de la página y usarlo: pulsar el botón correcto, rellenar cada campo y seguir los enlaces. Para eso necesita que botones, enlaces y campos tengan nombre, que la página tenga título y que el ARIA sea válido, porque lo que lee es el árbol de accesibilidad.

¿La navegación por agentes de Lighthouse afecta al posicionamiento en Google?

No hay ninguna documentación de Google que lo diga. Lighthouse marca la categoría como en desarrollo, Chrome la describe como informativa y la guía de Google Search presenta los agentes como algo opcional que explorar. Su utilidad es otra: que los agentes que reservan o compran por tus clientes puedan hacerlo en tu web.

¿Es lo mismo que cumplir las pautas de accesibilidad WCAG?

No. Las 33 reglas son un subconjunto de las pruebas automáticas de accesibilidad, centrado en nombres, ARIA e identificadores. WCAG pide además contraste suficiente, uso completo con el teclado, texto ampliable y mucho más que ninguna prueba automática puede comprobar. Aprobar esta prueba es un buen comienzo, pero no significa que tu web sea accesible.

¿Necesito WebMCP o un llms.txt para que los agentes usen mi web?

No. Los agentes de navegador trabajan con el HTML y el árbol de accesibilidad de cualquier página. WebMCP es un estándar propuesto que permite declarar tareas para los agentes que lo soporten, y llms.txt es un resumen que ningún buscador de IA ha documentado que lea. Lo primero, y lo que sirve a todos, es un árbol bien formado.

Qué hacer ahora

Pasa la categoría de navegación por agentes de Lighthouse por tu página de reserva, de contacto o de producto y corrige primero los botones y campos sin nombre: suelen ser pocos y están en una sola plantilla. Después sigue con el resto de la guía de posicionamiento en IA.