En mayo de 2026, Lighthouse — la herramienta de auditoría web de Google que lleva años dictando cómo medimos rendimiento — añadió una categoría nueva: Agentic Browsing. Su pregunta no es "¿carga rápido tu web?" ni "¿es accesible?". Es otra: ¿puede un agente de IA usar tu web sin romperse?

Lo contamos desde la experiencia de habérnosla encontrado de frente: dribba.com pasó por ella y suspendió un check. Este post va de qué mide exactamente esa categoría, por qué fallamos nosotros y cómo se arregla.

Qué audita Agentic Browsing

La categoría — aún marcada como experimental — agrupa tres tipos de comprobaciones:

1. Árbol de accesibilidad bien formado. Los agentes no ven tu web: leen su árbol de accesibilidad, la representación semántica que el navegador construye a partir del DOM. Si ese árbol miente — elementos marcados como ocultos que en realidad son interactivos, diálogos sin rol, botones sin nombre — el agente opera sobre un mapa falso.

2. Estabilidad visual (CLS). El Cumulative Layout Shift lleva años en Core Web Vitals, pero aquí cobra un significado nuevo: un layout que se mueve durante la carga no solo molesta a humanos, sino que hace que un agente pulse donde ya no está el botón. Para un humano es un clic fallido; para un agente, una tarea entera que falla.

3. Corrección de integraciones WebMCP. Si tu web expone herramientas vía WebMCP, Lighthouse valida que estén bien formadas: schemas correctos, descripciones útiles, registro sin errores.

El error que cometimos nosotros (y comete casi todo el mundo)

Nuestro audit falló con este mensaje: "ARIA hidden element must not be focusable or contain focusable elements".

El culpable era un patrón utilísimo y aparentemente inocente. Nuestro chat widget, cuando está cerrado, se oculta así:

<div
  aria-hidden={!isOpen}
  style={{ opacity: isOpen ? 1 : 0, pointerEvents: isOpen ? "auto" : "none" }}
>
  {/* ...el panel del chat, con su input y sus botones... */}
</div>

Parece correcto: invisible, no clicable, y aria-hidden le dice a los lectores de pantalla que no existe. El problema: los elementos de dentro siguen siendo enfocables con teclado. Un agente (o un usuario de teclado) puede llegar con Tab a un input que "no existe". El árbol de accesibilidad dice una cosa y el comportamiento real dice otra — exactamente el tipo de mentira que desorienta a un agente.

La solución moderna es el atributo inert, que React 19 soporta como prop booleana:

<div
  aria-hidden={!isOpen}
  inert={!isOpen}
  ...
>

inert hace lo que aria-hidden promete pero no cumple: saca todo el subárbol del orden de tabulación Y del árbol de accesibilidad. Coherencia total entre lo que se declara y lo que pasa. Un atributo, audit en verde.

El mismo problema aparece en variantes: botones flotantes que se esconden con opacity: 0 pero siguen en el tab order, menús móviles deslizados fuera de pantalla con translateX(100%), modales "cerrados" que solo bajan el z-index. Si tu web tiene cualquier overlay, probablemente tiene alguno de estos.

Por qué un audit experimental merece tu atención

La objeción razonable: "es experimental, puede cambiar, ¿por qué invertir ahora?". Tres razones:

Porque mide algo real ya. Gemini está integrado en Chrome, ChatGPT opera webs de terceros y Perplexity navega por sus usuarios. Los agentes ya están en tu web — la única pregunta es si pueden completar tareas o se atascan. Lighthouse solo le ha puesto número a algo que ya estaba pasando.

Porque los arreglos no son "para agentes". Todo lo que pide el audit — semántica honesta, foco bien gestionado, layout estable — es accesibilidad y calidad web de las de siempre. Arreglarlo mejora la experiencia de usuarios de teclado, lectores de pantalla y, de paso, tu SEO. El agente es el beneficiario nuevo de deberes antiguos.

Porque la historia de Lighthouse es predecible. Lo que empieza como categoría experimental acaba influyendo en cómo Google y el ecosistema evalúan la calidad de una web. Los que arreglaron Core Web Vitals en 2020 lo hicieron con calma; los que esperaron a 2021 lo hicieron corriendo.

Cómo auditar tu web hoy

  1. Chrome DevTools → Lighthouse → marca la categoría Agentic Browsing (en versiones recientes de Chrome/Canary).
  2. Revisa los failed audits de Agent Accessibility — los culpables vienen señalados elemento a elemento.
  3. Presta atención especial a: modales y drawers, chat widgets, carruseles con slides clonados, menús móviles y cualquier cosa con aria-hidden dinámico.
  4. Mira el CLS con ojos nuevos: ¿qué se mueve durante la carga? ¿Banners que entran empujando? ¿Imágenes sin dimensiones? ¿Fuentes que bailan?
  5. Si tienes WebMCP, valida los schemas de tus herramientas.

La parte de accesibilidad se arregla normalmente en días, no semanas. Es de las inversiones con mejor ratio esfuerzo/impacto del catálogo técnico actual — precisamente porque casi nadie la ha hecho todavía.

Es también la segunda de las tres capas de una web agéntica: legible (llms.txt, markdown), navegable (esto), operable (WebMCP). En la auditoría agéntica que hacemos en Dribba, esta capa sale gratis: los mismos checks, con plan de arreglo priorizado.