Lighthouse Agentic Browsing: cómo pasar la auditoría de Google para agentes

Qué es Lighthouse Agentic Browsing y por qué Google la creó

Lighthouse lleva años siendo el estándar de facto para auditar una web: performance, accesibilidad, buenas prácticas y SEO. Lo nuevo no es la herramienta, sino el visitante: durante 2026 los agentes de IA dejaron de ser una promesa y se convirtieron en usuarios reales de tu sitio. Google-Agent ya reserva y compra por encargo, los operadores de navegación de los modelos comerciales completan formularios, y la búsqueda agentica convirtió a los bots en el mayor segmento de tráfico web.

La categoría Agentic Browsing responde a esa realidad con un set de auditorías deterministas que evalúan qué tan bien está construida tu web para la interacción de máquinas. Es importante entender el encuadre: es una categoría experimental separada de las auditorías SEO y no está atada a Google Search en ninguna parte de sus notas de lanzamiento. No mide si vas a rankear mejor; mide si un agente va a poder usar tu sitio cuando llegue a él.

La base conceptual viene de la guía oficial de Google sobre sitios web agent-friendly: los agentes procesan la web en tres formatos (capturas de pantalla, código HTML y árbol de accesibilidad), y el árbol de accesibilidad es el modelo de datos primario porque es más eficiente de procesar que el HTML completo. De ahí que gran parte de la nueva categoría se apoye en señales que ya existían para accesibilidad web y estabilidad, ahora releídas desde la óptica del agente.

Cómo puntúa: un ratio de aprobación, no una nota de 0 a 100

La diferencia más importante frente al resto de Lighthouse: Agentic Browsing no calcula un promedio ponderado de 0 a 100. La documentación oficial explica que, como los estándares de la web agentica aún emergen, el foco actual es recolectar datos y entregar señales accionables antes que un ranking definitivo. El reporte muestra tres cosas: una fracción que indica cuántos checks de preparación agéntica aprueba tu sitio, estados de pass o fail cuando hay errores técnicos (por ejemplo, un esquema WebMCP inválido), y contadores informativos para observar el progreso.

Un dato tranquilizador para pymes: no repruebas por no adoptar features nuevas. El equipo de DebugBear verificó que example.com, sin ninguna integración de IA, obtiene un verde 2/2. La categoría es informacional: ausencia no es falla; lo que falla son los errores técnicos en lo que sí declaras (un puntero ARD que no carga, un esquema WebMCP que no valida). Las auditorías son deterministas y reproducibles, aptas para integrarse en pipelines de CI/CD, aunque los resultados pueden fluctuar si registras herramientas de forma dinámica con JavaScript, porque el snapshot puede capturar el registro a destiempo.

Para leer tu resultado sin engañarte: el ratio es una fotografía de preparación agéntica, útil para priorizar trabajo técnico. Reportarlo internamente como un puntaje estilo Lighthouse clásico es inventar una métrica que no existe.

Los cuatro frentes que audita (y qué significa cada uno)

La categoría agrupa las auditorías en bloques temáticos. Esta tabla resume qué verifica cada frente y las señales de alerta más comunes que verás en el reporte.

Del árbol de accesibilidad Lighthouse filtra solo el subconjunto crítico para la interacción de máquinas: nombres y etiquetas, integridad del árbol y visibilidad. En WebMCP, el reporte llama al dominio WebMCP del protocolo de Chrome DevTools para monitorear los eventos de registro de herramientas, tanto las declarativas como las imperativas, y las lista todas en el resultado. El límite de 40 herramientas no es arbitrario: registran un exceso de herramientas consumes tokens de contexto del modelo, agregas latencia y aumentas el riesgo de confusión sobre cuál usar, según la documentación oficial. Y la nueva auditoría ARD (13.5) busca el catálogo en tres lugares (línea Agentmap en robots.txt, tag link con relación ai-catalog, cabecera HTTP Link) con fallback a /.well-known/ai-catalog.json.

El bloque de estabilidad reutiliza CLS, la métrica de Core Web Vitals que ya conoces del SEO técnico, con un argumento nuevo: un agente que opera por capturas de pantalla se confunde si el layout cambia bajo sus pies, y además puede interactuar más rápido que un humano, haciendo más disruptivos los desplazamientos de carga.

Cómo pasar la auditoría en WordPress, paso a paso

1. Corre el reporte primero. Instala Chrome Canary (o Chrome 150+), abre tu sitio, entra a DevTools, pestaña Lighthouse, y marca la categoría Agentic Browsing. El resultado inicial marca la línea de salida; no persigas el ratio, prioriza los fails concretos. Como recomienda la consultora Marie Haynes, cualquier persona puede correrlo desde el navegador, sin software externo.

2. Arregla el árbol de accesibilidad, que es el frente de mayor impacto. En WordPress el villano habitual es el tema: menús con roles mal declarados, botones de íconos (carrito, búsqueda, WhatsApp) sin nombre accesible, sliders que ocultan contenido interactivo del árbol. Cada elemento interactivo necesita un nombre programático: aria-label cuando el texto visible no existe, labels reales en formularios. Aquí la auditoría agéntica y la accesibilidad humana van de la mano; es HTML bien hecho.

3. Asegura estabilidad con CLS bajo control: dimensiones explícitas en imágenes (o espacio reservado), fuentes con estrategia de carga que no reflow, y banners que reserven su slot antes de cargar. Es exactamente el trabajo de optimización de Core Web Vitals que ya deberías estar haciendo para Google; ahora tiene un segundo beneficiario.

4. Publica un llms.txt válido en la raíz del dominio: en formato Markdown, con encabezado H1, contenido sustantivo y enlaces. Si usas WordPress, la implementación de llms.txt en WordPress se resuelve con un plugin o un archivo estático, y herramientas como SemanticGEO lo generan de forma automática junto al resto de señales semánticas. Un stub vacío es peor que la ausencia: la auditoría valida estructura.

5. Si tu modelo de negocio tiene acciones que un agente querría ejecutar (reservar una hora, solicitar una cotización de página web, añadir al carrito), expón esas acciones como herramientas WebMCP declarativas en tus formularios: anota cada form con nombre y descripción claros, orientados a la acción (reservar_hora, solicitar_cotizacion), menos de 40 por página y solo las útiles en el estado actual. La propuesta es del W3C y extiende la filosofía de Model Context Protocol al navegador; la guía práctica completa ya la cubrimos en el artículo de WebMCP en WordPress.

Qué significa esto para una empresa chilena en 2026

Primero, la honestidad técnica: Agentic Browsing no es un factor de ranking. Es una categoría separada de las auditorías SEO y Google fue explícito en no atarla a Search. Su valor es otro: es el primer estándar medible de preparación agéntica, y llega justo cuando los agentes de compra empiezan a entrar a los sitios de tus clientes a cotizar y comparar. Pasar estos checks hoy es construir la ventaja temprana que otros deberán improvisar después, igual que pasó con quienes optimizaron modelos de lenguaje y visibilidad en IA antes que su industria.

Segundo, la auditoría te da un lenguaje común con tu proveedor web: en vez de discutir opiniones sobre si tu sitio es moderno, discutes fails concretos y reproducibles (este botón no tiene nombre programático, este form no está anotado, tu llms.txt no tiene enlaces). Eso es oro para una pyme chilena que contrata desarrollo sin poder auditar código.

Tercero, encaja en la estrategia completa: el SEO técnico sigue trayendo demanda humana, el trabajo GEO te hace citable por los motores generativos, y la preparación agentica asegura que cuando un agente llega a tu web (enviado por una recomendación de ChatGPT o de Google-Agent) pueda completar la acción que viniste a vender: reservar, cotizar, comprar. La AEO te trae la respuesta; la web agentica cierra la ejecución.