Última actualización: 28 de julio de 2026
Imagina un agente de IA que entra en tu web con una orden sencilla: «cómprame esto». Lee la página como la lee una máquina, no como la lees tú. Busca el botón de comprar. Y no lo encuentra, porque el botón no tiene nombre programático, solo es un icono bonito. Se rinde y le dice a su usuario que no ha podido. Tú ni te enteras. No hay rebote en Analytics, no hay carrito abandonado, no hay nada. Una venta que no llegó a existir.
Llevo meses oyendo «prepara tu web para los agentes». Vale. ¿Cómo sé si lo he hecho bien? Hasta hace poco la respuesta honesta era «no lo sabes, cruza los dedos». Eso cambió el día que Google metió en Lighthouse un audit que pone número a esto. Se llama Agentic Browsing y es la primera vara de medir concreta que tenemos. Va de qué chequea de verdad, qué no significa, y qué hacer con el resultado esta semana.
Lo que vas a encontrar aquí
- Qué es el audit y de dónde sale
- Qué chequea de verdad: los cuatro bloques
- Qué NO significa (y el lío del llms.txt)
- Qué hacer con el resultado esta semana
- Preguntas frecuentes
Qué es el audit y de dónde sale
Lighthouse es la herramienta de auditoría que Google lleva años metiendo en Chrome: la que te da las notas de rendimiento, accesibilidad, SEO y buenas prácticas. En mayo de 2026 le añadieron una categoría nueva, experimental, llamada Agentic Browsing. Traducido: mide «cómo de bien está construida tu web para que la use una máquina», que es como la propia documentación de Chrome lo define (Chrome for Developers, Lighthouse agentic browsing scoring, actualizada el 5 de mayo de 2026).
Dos cosas antes de que corras a abrirlo. La primera: es experimental y pide Chrome 150 o posterior, y los checks de WebMCP van con el origin trial de WebMCP activado. No es todavía la pestaña de siempre en tu DevTools. La segunda, la importante: no te da una nota de 0 a 100. Te da un ratio, cuántos checks de «preparación para agentes» pasas de los que hay. Como los estándares del web agéntico están todavía a medio cocer, Google prefiere darte señales accionables antes que una nota que fingiría una precisión que no existe. Me parece bien la decisión, la verdad.
Este post es la capa de medición del que ya escribí sobre cómo optimizar tu web para agentes de IA. Aquel enseña qué tocar; este, cómo compruebas si lo has tocado bien. Uno es el mapa, el otro es el termómetro.
Qué chequea de verdad: los cuatro bloques
El audit no es magia ni una caja negra. Son señales deterministas (las mismas entradas dan el mismo resultado, por eso sirven para meterlas en un CI/CD). Se agrupan en cuatro frentes.
1. WebMCP: hablarle al agente en su idioma
WebMCP es un protocolo nuevo del equipo de Chrome. En corto: deja que tu web registre «herramientas» que un agente puede descubrir y llamar directamente, en vez de obligarlo a adivinar tu interfaz a base de clics. Un formulario de reserva, un buscador de producto, un «añadir al carrito»: los expones como acciones que la máquina entiende sin interpretarte. Lighthouse mira si registras esas herramientas, y valida tanto las declarativas (definidas en el HTML) como las imperativas (definidas por JavaScript). Es la parte más nueva y la que más web no tiene ni empezada.
2. Accesibilidad, pero para máquinas
Aquí está la buena noticia, y es doble. El agente lee tu web a través del árbol de accesibilidad (el accessibility tree), el mismo que usa un lector de pantalla para una persona ciega. O sea: lo que haces por accesibilidad humana sirve igual para el bot. Lighthouse filtra el subconjunto de checks de accesibilidad que de verdad importan para una máquina: que cada elemento interactivo tenga un nombre programático (el botón «Comprar» que al agente le aparecía sin nombre), que los roles y las relaciones padre-hijo del árbol sean válidos, y que lo interactivo no esté oculto al árbol mientras sigue siendo clicable. Volvemos a la escena del principio: sin nombre, no hay botón.
3. Estabilidad: que no se mueva el suelo
El CLS (Cumulative Layout Shift), que ya conocías de Core Web Vitals, aquí importa por otra razón. Un agente localiza un elemento, calcula dónde pinchar, y va a pinchar. Si entre medias un anuncio empuja el contenido o una imagen sin dimensiones recoloca media página, el agente pincha donde ya no hay nada. Para un humano es un fastidio; para una máquina que actúa por coordenadas, es un fallo directo. La estabilidad visual deja de ser cosmética y pasa a ser funcional.
4. Descubribilidad: el llms.txt
El cuarto check es la presencia de un llms.txt: un resumen legible por máquina en la raíz de tu dominio. La idea, según Google, es que «sin llms.txt los agentes pueden gastar más tiempo rastreando el sitio para entender su estructura y su contenido principal». Un mapa para el que llega con prisa. Y justo aquí viene el matiz que más ruido ha hecho, que te lo cuento en el bloque siguiente porque merece parada.
Qué NO significa (y el lío del llms.txt)
Aquí es donde separo la señal del humo, porque ya he visto a gente vendiendo esto como «el nuevo factor de ranking». No lo es. Google no ha dicho en ningún sitio que este audit puntúe para posiciones en el buscador. Es un termómetro de usabilidad para agentes, no una palanca de rankings. Sirve para saber si un bot puede operar tu web, no para subir en Google. Confundir las dos cosas es exactamente el tipo de atajo que luego se paga.
Y el llms.txt es el caso perfecto de por qué conviene leer la letra pequeña. Chrome lo chequea en Lighthouse. Pero la propia guía de Google para IA generativa dice, en su sección de mitos, que no necesitas crear ficheros especiales tipo llms.txt para aparecer en su búsqueda con IA (Google Search Central, guía de optimización para IA). ¿En qué quedamos? John Mueller, de Google, lo aclaró cuando se lo preguntaron: publicar un llms.txt «no se hace para search» (Search Engine Land, 20 de mayo de 2026). Una cosa es que te encuentren en el buscador (discovery), otra es que un agente, una vez en tu web, haga su tarea sin tropezar (funcionalidad). El audit va de lo segundo. El SEO clásico va de lo primero. No las mezcles.
Dicho de otro modo: pasar el audit no te hace más visible en Google. Te hace más usable para una máquina que ya llegó. Que es útil, y puede que cada vez lo sea más, pero es otra pregunta. Este territorio lo trabajo en la guía de LLMO (visibilidad de marca en modelos de IA) y en la de optimización para motores agénticos, que es donde de verdad se juega quién aparece cuando le preguntas a la IA.
Qué hacer con el resultado esta semana
Nada de esto sirve si se queda en teoría. Cuatro cosas concretas, por orden de retorno.
- Córrelo y ten la foto. Instala Chrome 150 o posterior, abre Lighthouse y pasa el audit de Agentic Browsing. Apunta el ratio de partida. No para presumir, para tener línea base y medir si mejoras.
- Empieza por la accesibilidad para máquinas. Es el arreglo que rinde doble: cada nombre programático, cada label, cada rol bien puesto sirve a la vez para una persona con lector de pantalla y para el agente. Si solo vas a tocar una cosa, toca esta. Es trabajo que ya deberías tener hecho por otra razón.
- Estabiliza el CLS. Dimensiones fijas en imágenes, reserva de espacio para lo que carga tarde, cuidado con los anuncios que empujan. Ya lo perseguías por Core Web Vitals; ahora tiene un motivo más.
- Decide si el llms.txt te aporta. Aquí sí que piénsalo, no lo pongas por pasar un check. Para una web de documentación o con mucho contenido de referencia, puede tener sentido. Para una tienda de zapatos, como bien dice Mueller, hacer una versión en markdown de la ficha de un zapato no te va a traer ventas (y sí se la pone en bandeja a la competencia). Prioridad según lo que vendes, no según lo que marque una checklist.
Y si el audit te sale flojo y no sabes por dónde meterle mano, el marco completo de qué necesita un bot y qué no le das está en la guía de optimización para agentes, y la estrategia de fondo, en SEO agéntico.
Volvamos al agente del principio, el que no encontraba el botón. Una vara de medir no le pone el botón por ti. Pero sin ella no sabías siquiera que el botón le faltaba. Medir no es la solución. Es dejar de ir a ciegas.
Preguntas frecuentes
¿Qué es el audit de Lighthouse Agentic Browsing?
Es una categoría experimental que Google añadió a Lighthouse en mayo de 2026. Mide cómo de preparada está tu web para que la use un agente de IA, no una persona. En vez de una nota de 0 a 100 te da un ratio de cuántos checks de preparación agéntica pasas, sobre cuatro frentes: WebMCP, accesibilidad para máquinas, estabilidad de la maquetación (CLS) y presencia de un llms.txt.
¿Cómo ejecuto el audit?
Necesitas Chrome 150 o posterior, porque la categoría es experimental. Abres Lighthouse en las DevTools y seleccionas la categoría Agentic Browsing. Los checks específicos de WebMCP requieren además registrarte en el origin trial de WebMCP. Es reproducible, así que puedes integrarlo en tu pipeline de CI/CD para vigilar que no empeora con cada despliegue.
¿Afecta a mi ranking en Google?
No hay nada que lo confirme. Google no ha dicho que este audit puntúe para posiciones en el buscador. Es un termómetro de usabilidad para agentes de IA, no una palanca de rankings. Sirve para saber si un bot puede operar tu web una vez que llega, no para que llegue más gente desde la búsqueda. Son dos preguntas distintas: descubrimiento (SEO) y funcionalidad (este audit).
¿Necesito un llms.txt?
Es uno de los cuatro checks, pero no es obligatorio y Google mismo dice que no hace falta para aparecer en su búsqueda con IA. John Mueller aclaró que publicar un llms.txt no se hace para search. Tiene sentido en webs de documentación o con mucho contenido de referencia, donde ayuda a un agente a orientarse rápido. Para una tienda al uso, aporta poco. Decídelo por lo que vendes, no por pasar el check.