Agentic Browsing: PageSpeed para agentes IA - Ighenatt Blog

Lo más engañoso de la nueva categoría Agentic Browsing de Lighthouse es la palabra “score”. Los equipos SEO están acostumbrados a abrir PageSpeed, mirar un número, discutir si 89 es suficiente y seguir adelante. Esta categoría no funciona así.

La documentación de Chrome dice que Agentic Browsing es experimental y se apoya en estándares propuestos. También dice que para probar la categoría hace falta Chrome 150 o posterior, y que las auditorías WebMCP requieren el origin trial de WebMCP. Esto importa porque no hablamos de un informe maduro de Search Console, ni de un sustituto de Core Web Vitals, ni de una señal de ranking que puedas añadir sin matices a una propuesta comercial.

Es algo más práctico: un conjunto de checks deterministas para saber si los agentes pueden entender e interactuar con una página con menos suposiciones.

Para equipos técnicos de SEO y desarrollo en España y Europa, la auditoría resulta útil en un punto muy concreto. Puede sacar a la luz problemas que ya perjudican a usuarios reales: controles sin etiqueta, layouts inestables, formularios ambiguos, resúmenes de sitio poco claros e interacciones dependientes de JavaScript que solo tienen sentido para una persona mirando la pantalla. La diferencia es que ahora quien observa es un agente.

Qué mide realmente Lighthouse Agentic Browsing

Chrome describe la categoría Agentic Browsing como una forma de evaluar cómo está construida una web para la interacción automática mediante auditorías deterministas. Esa frase tiene mucha carga técnica. La auditoría no intenta decidir si tu contenido persuade, si tu marca es fuerte o si Google debería posicionarte por encima de un competidor. Intenta comprobar si un agente a nivel de navegador puede identificar herramientas, entender formularios, leer el árbol de accesibilidad, encontrar contexto legible por máquina e interactuar con la interfaz sin que los elementos se muevan bajo sus pies.

La categoría agrupa varias señales. La integración WebMCP comprueba si la página expone herramientas estructuradas mediante HTML declarativo o JavaScript. La validez del schema WebMCP revisa si esas herramientas están descritas de forma coherente. La auditoría de formularios sin WebMCP declarativo identifica formularios que podrían anotarse para que la interacción del agente sea más fiable. El check de llms.txt comprueba la disponibilidad de un resumen legible por máquina en la raíz del dominio. La accesibilidad para agentes se centra en el árbol de accesibilidad. La estabilidad de layout usa CLS porque los elementos que se mueven pueden romper acciones basadas en coordenadas o capturas.

Esa mezcla es el punto. La preparación agéntica no es solo “SEO para IA”. Vive entre velocidad web y SEO, accesibilidad web, diseño de interacción estructurada y gobernanza de contenido.

Piensa en una página de filtros de producto. Una persona puede inferir que un icono de embudo abre filtros, que un slider personalizado controla el precio y que un overlay tardío es solo un modal de boletín. Un agente necesita etiquetas, estado, posición estable y, si procede, metadatos explícitos de herramienta. Si el botón de filtros no tiene nombre accesible, el formulario contiene inputs sin nombre y un banner desplaza el botón 400 milisegundos después de cargar, la tarea se vuelve frágil.

Eso es lo que esta categoría intenta revelar. No popularidad. No autoridad. Preparación para interactuar.

Por qué no es una puntuación PageSpeed normal

Las categorías clásicas de Lighthouse, como Performance o Accessibility, son familiares porque reducen muchas auditorías a una puntuación ponderada de 0 a 100. Agentic Browsing es diferente. La documentación de scoring de Chrome dice que actualmente no usa una media ponderada de 0 a 100 porque los estándares de la web agéntica todavía están emergiendo. En su lugar, el informe muestra una puntuación fraccional, estados de aprobado o fallido para auditorías concretas y recuentos informativos.

Eso cambia cómo debería leerse. Un ratio 6/8 no equivale a un 75 en Lighthouse Performance. Solo significa que seis de los checks actuales de preparación han pasado. Un fallo en la validez del schema WebMCP puede importar mucho más en un formulario de reserva que en un artículo estático. Un llms.txt ausente puede marcarse como no aplicable porque el archivo es opcional por ahora, mientras que un error de servidor al pedirlo sí apunta a un problema técnico real.

El hábito útil es tratar la categoría como una checklist de despliegue. ¿La página registra herramientas? ¿Los nombres y descripciones son coherentes? ¿Los campos obligatorios tienen name? ¿Los campos opcionales están descritos con labels o descripciones de parámetros? ¿El árbol de accesibilidad expone lo que un agente necesita? ¿El CLS mueve controles después de que el agente los haya identificado?

Por eso importan los checks deterministas. Chrome explica que Lighthouse usa señales deterministas para que las auditorías sean reproducibles y aptas para CI/CD. No es una valoración subjetiva de un LLM. Se parece más a un test unitario sobre affordances de la página. Los resultados pueden variar si JavaScript registra herramientas tarde, si cambia la complejidad del DOM o si un layout shift mueve elementos durante la captura. Pero el objetivo auditado es concreto.

La lectura contraria: que no haya un 0-100 es buena noticia. Evita convertir estándares inmaduros en un KPI de vanidad. Por ahora, el objetivo no es “subir 20 puntos el score de Agentic Browsing”. El objetivo es que el formulario de contacto, los filtros, el flujo de reserva o la configuración de producto sean comprensibles para navegadores capaces de actuar por cuenta del usuario.

WebMCP: herramientas explícitas en lugar de adivinar la interfaz

WebMCP es la parte más nueva del conjunto. Chrome lo presenta como un estándar web propuesto para exponer herramientas estructuradas a agentes IA. La idea es ayudar a los agentes a interactuar con un sitio declarando qué acciones existen, qué inputs esperan y qué estado está disponible, en vez de obligar al agente a deducirlo todo a partir de botones, etiquetas y posición visual.

La página de WebMCP de Chrome habla de tres ideas: discovery, JSON Schemas y estado. Discovery permite registrar herramientas como pago, filtrar resultados o enviar solicitud. JSON Schema ayuda a definir entradas y salidas esperadas. El estado da al agente una comprensión compartida de los recursos disponibles en la página actual. En la práctica, un flujo de soporte podría exponer una herramienta submit_ticket en lugar de pedir al agente que navegue por menús anidados y deduzca qué significa cada campo.

Hay dos vías de implementación. La API declarativa anota formularios HTML estándar con atributos como nombres de herramienta y descripciones. La API imperativa usa JavaScript, incluido navigator.modelContext.registerTool, para registrar herramientas programáticamente. Lighthouse puede listar herramientas WebMCP registradas, y Chrome indica que esa auditoría es informativa: si no hay herramientas registradas, la lista aparece vacía.

La auditoría de validez del schema es más estricta. Falla cuando un formulario tiene tooldescription sin toolname, cuando tiene toolname sin tooldescription, o cuando un campo obligatorio no tiene atributo name. También puede avisar cuando los campos opcionales tienen nombre pero carecen de descripción de parámetro o label asociado. No es nada exótico. Muchos formularios ya fallan en ese nivel básico de disciplina.

Un buen primer objetivo para una web B2B europea no es todo el sitio. Empieza por los formularios que crean valor comercial u operativo: contacto, solicitud de presupuesto, demostración, reserva, soporte, búsqueda, cualificación de clientes potenciales y filtros de producto. Si un agente no puede distinguir “razón social” de “persona de contacto”, o “NIF” de “referencia de pedido”, el problema no es la IA. El formulario estaba mal especificado.

Con optimización de JavaScript para rendimiento aparece otro ángulo: si el registro de herramientas depende de hidratación tardía, bundles pesados o estado cliente frágil, Lighthouse puede no detectar la herramienta durante la captura. WebMCP hace explícita la interacción, pero no compensa una arquitectura front-end lenta, inestable o innecesariamente compleja.

La accesibilidad se convierte en el mapa del agente

La documentación de Chrome sobre accesibilidad para agentes plantea una idea sencilla: los agentes revisan el árbol de accesibilidad para identificar elementos interactivos. Los estándares de accesibilidad están escritos para personas, pero muchos de los mismos principios ayudan a los agentes a entender una web. Las etiquetas ausentes pueden bloquear tanto a usuarios con discapacidad visual como a agentes que intentan completar una tarea.

Esto debería sonar familiar a cualquiera que haya hecho una auditoría SEO técnica seria. El árbol de accesibilidad no es una capa decorativa. Es el modelo legible por máquina de la interfaz. Si el texto visible de un botón se sustituye por un icono sin nombre accesible, el DOM puede parecer correcto para diseño y opaco para un agente. Si un modal gestiona mal el foco, el agente puede quedarse atrapado igual que un usuario de teclado. Si un select personalizado replica mal el comportamiento nativo del navegador, el navegador tiene menos semántica que exponer.

Aquí los equipos SEO deben tener cuidado con la propiedad del problema. Agentic Browsing no es solo un asunto de desarrollo. Atraviesa decisiones de sistema de diseño, etiquetas de contenido, APIs de componentes y QA. Un componente reutilizable de botón sin una regla fiable de nombre accesible puede crear cientos de puntos débiles de interacción. Un constructor de formularios que permita labels vacías puede romper silenciosamente flujos de conversión en varios idiomas. En sitios multilingües, las etiquetas en español, inglés y catalán necesitan el mismo cuidado semántico, no solo traducción visible.

Hay un patrón de revisión bastante práctico. Abre la página con Chrome DevTools, inspecciona el árbol de accesibilidad y compáralo con el recorrido que esperas que un agente complete. ¿Puede identificar el buscador? ¿El botón de envío? ¿Los campos obligatorios? ¿Los mensajes de error? ¿El filtro seleccionado? Si no puede, corrige la semántica antes de escribir ninguna capa WebMCP.

Esto conecta directamente con AI Mode y las búsquedas conversacionales de Google. A medida que la búsqueda y la navegación se vuelven más conversacionales, los sitios que expresan bien su estructura serán más fáciles de interpretar. No es lo mismo que impacto en ranking. Es legibilidad técnica.

La estabilidad visual ayuda a evitar clics erróneos

CLS suele explicarse como una métrica de experiencia de usuario: el contenido salta, la persona pierde el punto de lectura y alguien toca el botón equivocado. La auditoría de estabilidad de layout de Agentic Browsing reencuadra el mismo problema para agentes. Los agentes suelen apoyarse en capturas de pantalla o interacción por coordenadas. Si un botón se mueve después de que el agente lo haya identificado, la acción puede fallar.

Las causas son conocidas: imágenes sin dimensiones, banners inyectados, anuncios que cargan tarde, embeds, fuentes web, cambios de hidratación y componentes que reservan poco espacio. Lo distinto es el modo de fallo. Una persona puede mirar otra vez y corregir. Un agente automatizado puede clicar la coordenada antigua, escribir en el input incorrecto o abandonar el flujo.

Para equipos que ya trabajan en Core Web Vitals 2026, la alineación es útil. Mejorar CLS no sirve solo para el informe de Page Experience. También reduce incertidumbre de interacción. Las soluciones siguen siendo las mismas: declarar dimensiones, reservar espacio para componentes dinámicos, evitar animaciones que cambien layout, gestionar banners de cookies sin empujar controles principales y probar formularios después de que carguen scripts de terceros.

Un ejemplo de comercio electrónico español lo deja claro. Imagina un pago donde un widget de financiación carga encima del botón de pago después de un segundo. La persona ve un pequeño salto. Un agente que había seleccionado el botón por posición quizá ahora apunta a otro elemento. El layout shift deja de ser una molestia visual y pasa a corromper la ruta de acción.

Por eso Agentic Browsing debería entrar en QA de flujos de alto valor. Ejecútalo en plantillas, no solo en la home. Páginas de categoría, fichas de producto, formularios de clientes potenciales, reservas y soporte importan más que un hero de marketing muy pulido. Si un agente puede navegar la portada pero no completar una solicitud de presupuesto, la implementación tiene mucho escaparate y poca utilidad.

llms.txt es opcional, pero los errores de servidor no

La auditoría de llms.txt de Chrome es deliberadamente prudente. Describe llms.txt como una convención emergente para ofrecer un resumen legible por máquina del contenido de una web a LLMs y agentes IA. La auditoría intenta recuperar el archivo desde la raíz del dominio. Si el servidor devuelve 404, el check queda como no aplicable porque ofrecer el archivo es opcional por ahora. Si aparece un error de servidor, Lighthouse lo marca.

Ese es el nivel de presión correcto. No tener llms.txt no debería tratarse como una catástrofe. Tener roto /llms.txt es distinto, porque apunta a una mala configuración: routing, despliegue, headers, generación del archivo o comportamiento de CDN.

Para equipos SEO, llms.txt tiene más valor como gobernanza editorial. Debería explicar el propósito del sitio y enlazar a recursos clave en Markdown conciso. No debería ser un segundo sitemap con todas las URLs. En una web de SEO técnico, un buen archivo puede apuntar a guías canónicas sobre llms.txt y SEO para IA, Core Web Vitals, accesibilidad, visibilidad en IA y páginas de servicio. Cada enlace necesita una razón para estar ahí.

La trampa es sobreprometer. Que Chrome audite llms.txt no demuestra que Google Search use el archivo para ranking. Tampoco demuestra que ChatGPT, Claude, Perplexity o Gemini vayan a citarte. Demuestra que el archivo puede ayudar a agentes compatibles a entender antes el sitio, y que Lighthouse puede comprobar si el archivo raíz responde limpiamente.

Úsalo como índice público de lo que quieres que las máquinas lean primero. Mantenlo corto, canónico y revisado. Si publicas en varios idiomas, no mezcles versiones sin criterio. Declara secciones con claridad, usa URLs canónicas y revísalo tras migraciones, cambios de servicio, actualizaciones grandes de contenido y cambios en robots.txt.

Cómo usar la auditoría sin sobrerreaccionar

Un despliegue sensato empieza por tipos de página. No ejecutes Agentic Browsing una vez en la home para declarar que el sitio está “preparado para agentes”. Selecciona una muestra representativa: home, servicio, artículo de blog, categoría, búsqueda interna, formulario de contacto, formulario de clientes potenciales, filtros de comercio electrónico, ficha de producto y pago si aplica. Para cada tipo, registra ratio de aprobados, auditorías fallidas y resultados informativos.

Después clasifica los problemas por valor de usuario. Las labels de accesibilidad y los problemas de CLS deberían entrar en el backlog normal de calidad web porque ayudan a personas y agentes. WebMCP debe priorizarse donde las acciones estructuradas de agentes tengan sentido. Un formulario de boletín quizá solo necesita metadatos declarativos básicos. Un flujo de reserva, un panel de diagnóstico o un configurador de producto pueden necesitar herramientas imperativas, gestión de estado y revisión de seguridad más fuerte.

Chrome también documenta limitaciones de WebMCP. Las llamadas a herramientas requieren una pestaña de navegador o webview con contexto visible; no hay soporte headless para llamadas de herramientas. Los sitios complejos pueden necesitar JavaScript adicional o refactorización para gestionar estado de interfaz. Clientes y navegadores deben visitar la web para descubrir herramientas invocables. Las APIs de WebMCP también dependen de origin isolation y permissions policy. Esas restricciones lo convierten en una mejora progresiva, no en una capa universal que puedas atornillar a cualquier página de la noche a la mañana.

La seguridad merece una revisión aparte. Si una herramienta puede enviar un formulario, cambiar ajustes de cuenta, reservar una cita o iniciar una compra, el usuario debe conservar el control. La documentación general de WebMCP de Chrome menciona que las acciones sensibles pueden incluir un comando que solicita interacción del usuario mediante un diálogo de confirmación. En contextos europeos, añade revisión de privacidad: consentimiento, campos de datos personales, textos de retención y analítica deben seguir siendo comprensibles para la persona.

La regla de trabajo es simple: arregla primero los fundamentos aburridos. HTML semántico, labels, layouts estables, formularios claros, errores accesibles y jerarquía de contenido limpia mejoran Agentic Browsing y la experiencia normal de usuario al mismo tiempo. WebMCP llega después, donde las herramientas explícitas aporten fiabilidad medible.

Checklist práctica para equipos SEO y desarrollo

Usa esta checklist en la primera pasada de auditoría:

• Confirma que el entorno de prueba usa Chrome 150 o posterior para la categoría Agentic Browsing.
• Trata las auditorías relacionadas con WebMCP como experimentales y comprueba si el origin trial de WebMCP aplica al test.
• Ejecuta la auditoría en plantillas importantes, no solo en la home.
• Registra por separado ratio fraccional de aprobados, resultados pass/fail y recuentos informativos.
• En formularios, revisa toolname, tooldescription, atributos name en inputs, labels y contexto a nivel de campo.
• Inspecciona el árbol de accesibilidad para acciones principales, campos obligatorios, errores, navegación y filtros.
• Comprueba CLS en las mismas páginas con Lighthouse y tu flujo habitual de Core Web Vitals.
• Pide /llms.txt directamente y verifica si devuelve 200, 404 o error de servidor.
• No informes hallazgos de Agentic Browsing como mejoras de ranking salvo que documentación futura de Chrome o Google Search lo diga explícitamente.
• Añade checks repetibles a CI solo cuando el equipo acuerde qué tipos de página y fallos importan.

La primera ganancia comercial probablemente no será un “score agéntico” abstracto. Será un formulario que agentes y tecnologías asistivas pueden entender, un pago que no mueve controles a mitad de acción o una página de soporte que expone la tarea correcta con claridad. Eso ya es útil aunque los estándares cambien.

Ejecuta la auditoría, pero mantén la cabeza fría. La categoría es experimental. Los requisitos de navegador son concretos. WebMCP sigue en terreno de origin trial. El modelo de scoring evita adrede el número clásico de Lighthouse de 0 a 100.

Lo estable es la dirección: los navegadores empiezan a evaluar si las webs pueden ser accionadas por software, no solo renderizadas para personas. Los sitios con semántica clara, layouts estables, formularios bien descritos y contexto legible por máquina serán más fáciles de operar. Merece la pena arreglar eso ahora, sin fingir que ya es una palanca de ranking.

Preguntas frecuentes sobre Lighthouse Agentic Browsing

¿Lighthouse Agentic Browsing forma parte de PageSpeed Insights?

Es una categoría de Lighthouse documentada por Chrome para auditorías de navegación agéntica. Su disponibilidad en un flujo concreto de PageSpeed o Lighthouse puede depender de la versión de Chrome, el soporte experimental y los requisitos del origin trial de WebMCP. Para pruebas fiables, sigue el requisito actual de Chrome: Chrome 150 o posterior para la categoría y registro en el origin trial para auditorías WebMCP.

¿Un ratio bajo de Agentic Browsing es malo para SEO?

No directamente según la documentación actual de Chrome. Los documentos hablan de preparación técnica para interacción automática, no de factor de ranking de Google Search. Trata los fallos como señales de ingeniería y UX. Accesibilidad, CLS y claridad de formularios ya pueden importar para usuarios y conversiones, pero no atribuyas impacto directo en ranking a esta categoría.

¿Qué deberían hacer primero los sitios intensivos en contenido?

Empieza por llms.txt, HTML semántico, claridad de headings, enlaces accesibles y layouts estables. WebMCP aporta más cuando la página expone acciones. Un artículo de blog no necesita las mismas herramientas agénticas que un motor de reservas, pero debe ser legible, estar bien estructurado, enlazado internamente y ser fácil de resumir.

¿Qué deberían hacer primero los sitios transaccionales?

Audita los flujos donde un agente actuaría: búsqueda, filtros, opciones de producto, carrito, pago, solicitudes de presupuesto, demostraciones, reservas y soporte. Estas páginas necesitan labels, controles estables, errores de validación claros, estado predecible y posiblemente herramientas WebMCP. Prueba después de que carguen banners de cookies, scripts de personalización y widgets de terceros, porque ahí aparecen muchos fallos de layout e interacción.