Le pasé la nueva categoría "Agentic Browsing" de Lighthouse a mi web: esto es lo que salió
Estoy construyendo una herramienta propia de auditoría semántica/GEO desde cero (Node.js + Playwright + Chromium), sin usar nada de ninguna herramienta de terceros con la que haya trabajado antes. La versión 1.1.0 ya corre Lighthouse con su categoría experimental Agentic Browsing, disponible desde Chrome M150. La probé contra mi propia web, kenrusselclaveria.com.
Resultado: 0.67 sobre 1.0.
Qué mide exactamente la categoría Agentic Browsing
Agentic Browsing es una categoría nueva de Lighthouse, no un rumor ni una interpretación mía: Google la documenta en su guía oficial de Lighthouse y la anunció en el blog de Chrome for Developers. Evalúa cuatro áreas con auditorías deterministas:
- Accessibility tree — si está bien formado: nombres accesibles en cada elemento interactivo, jerarquía de roles válida, y que el contenido interactivo no esté oculto al árbol.
- WebMCP — si la web registra herramientas mediante
document.modelContext, el estándar propuesto para que un agente descubra y ejecute acciones sin tener que interpretar visualmente la interfaz. - llms.txt — si existe y sigue el formato recomendado (Markdown con al menos un H1).
- Cumulative Layout Shift (CLS) — estabilidad visual, relevante porque un agente que se apoya en la posición de los elementos se desorienta si estos se mueven.
Importante: esto no tiene relación con el ranking en Google Search. Es una medida de preparación estructural para agentes, independiente del buscador — de hecho, Google ya aclaró por separado que llms.txt no afecta al posicionamiento ni a AI Overviews.
| Check | Resultado | Detalle real |
|---|---|---|
| Accessibility tree bien formado |  Falla (0) | Sin <main>, sin <section>, <footer> duplicado y anidado, 78 de 400 nodos con rol «generic» sin nombre |
| WebMCP — cobertura de formularios | N/A | No aplica: no hay herramientas WebMCP registradas |
| WebMCP — herramientas registradas | N/A | 0 herramientas. document.modelContext no está implementado en mi web |
| WebMCP — validez de schemas | N/A | No aplica, no hay schemas que validar todavía |
| Cumulative Layout Shift |  Pasa (1) | CLS = 0 |
| llms.txt sigue las recomendaciones | Pasa (1) | Existe, 3.064 bytes, con encabezado H1 |
El 0.67 sale casi entero de un único check que falla: el árbol de accesibilidad.
Por qué el árbol de accesibilidad no está bien formado
Con mi propia extracción semántica pude ver el detalle detrás del check binario:
- 0 elementos
<main>en toda la página. No hay forma explícita de decirle a un agente «aquí empieza el contenido real». - 0 elementos
<section>. - 2
<footer>, uno anidado dentro del otro (un contenedor de Elementor con la etiqueta HTML puesta a «footer» dentro de la plantilla de footer, generando un landmark duplicado). - 4
<nav>, dos de ellos ocultos (visible: false) — el patrón típico de Elementor que renderiza menú de escritorio y menú móvil a la vez y oculta uno por CSS. - De los 400 nodos totales del árbol de accesibilidad, 61 están ignorados y 78 tienen rol «generic» sin nombre accesible.
Dato que no esperaba: mi puntuación de accesibilidad «para humanos» (categoría Accessibility de Lighthouse, distinta de Agentic Browsing) es 0.92 — buena. La de Agentic Browsing es 0.67. Son cosas distintas: un check de contraste o de atributos ARIA no penaliza que falte <main> de la misma forma que penaliza a un agente que depende de esa estructura para saber dónde está el contenido.
Hasta aquí, todo como se espera. El problema apareció al entrar al detalle del sitemap.
Qué voy a arreglar
- Añadir
<main>alrededor del contenido real de cada plantilla en Elementor. - Revisar por qué el footer genera un
<footer>anidado y corregir la etiqueta HTML del contenedor duplicado. - Reducir el ruido de nodos «generic» sin nombre donde tenga sentido (no todos son error — hay que revisarlos uno a uno, no de golpe).
Cuando lo tenga corregido, vuelvo a correr la auditoría y publico el resultado — antes/después con el mismo número de Lighthouse.
Lo que Agentic Browsing no demuestra (y no voy a afirmar)
Esto es una señal de preparación estructural, medida de forma determinista por una herramienta de Chrome. No es:
- Una prueba de que un agente real (ChatGPT, Gemini, Perplexity) pueda completar una tarea en mi web — eso solo se comprueba ejecutando la tarea de verdad (agentic browsing «real», no solo de preparación).
- Un factor de ranking en Google Search ni de citación en respuestas de IA. No hay evidencia oficial de eso, y no voy a afirmarlo solo porque el número mejore.
- Una garantía de que WebMCP haga falta para aparecer en respuestas de IA — de momento ni siquiera está claro qué agentes lo soportan de forma amplia.
Lo que sí puedo decir con datos: hoy mi web puntúa 0.67 en esta categoría, y sé exactamente por qué.
Preguntas frecuentes
¿Qué es la categoría Agentic Browsing de Lighthouse?
Una categoría de Lighthouse, disponible desde Chrome M150, que evalúa con auditorías deterministas si una web está preparada para que un agente de IA la lea e interactúe con ella: accessibility tree, WebMCP, llms.txt y Cumulative Layout Shift.
¿Un accessibility score alto garantiza un buen score de Agentic Browsing?
No necesariamente. Son categorías distintas. El accessibility score clásico evalúa cosas como contraste o atributos ARIA; Agentic Browsing evalúa si la estructura (landmarks como <main> o <section>) es lo bastante clara para que un agente entienda la página, algo que puede fallar aunque el accessibility score sea alto.
¿Un score bajo en Agentic Browsing afecta el posicionamiento en Google?
hay evidencia de eso. Es una señal de preparación estructural para agentes, no un factor de ranking documentado por Google.
