PageSpeed Insights lleva años puntuando rendimiento, accesibilidad, prácticas recomendadas y SEO. En 2026 se unió discretamente un quinto elemento a esa fila: Agentic Browsing. Responde a una pregunta que las otras cuatro categorías ignoran: ¿puede un agente de IA trabajar de verdad con esta página?
Esta guía trata de poner esa comprobación a trabajar en tu propio sitio: ejecutarla, entender qué dice cada auditoría y salir con una lista de correcciones.
Qué tendrás al terminar
Para quién es: para profesionales de SEO, desarrolladores y responsables de sitios que quieren saber cómo se comportan sus páginas cuando las recorre un agente en lugar de una persona.
Qué tendrás al terminar: un resultado real de Agentic Browsing para tu sitio, una lectura auditoría por auditoría de lo que pasa, falla o no aplica, y una lista de correcciones priorizada.
Requisitos: una URL accesible públicamente, unos diez minutos para la primera ejecución y acceso al código si vas a corregir algo el mismo día.
Criterio de éxito: puedes explicar tu puntuación fraccionaria auditoría por auditoría y distinguir qué fallos bloquean de verdad a un agente a la hora de completar una tarea en tu página.
De dónde viene esta comprobación y por qué ahora
La categoría Agentic Browsing no existía hace un año. El despliegue se produjo en tres pasos, todos documentados por Google:
- 7 de mayo de 2026: Lighthouse 13.3 añade la categoría a su configuración predeterminada, así que pasa a formar parte de una ejecución estándar.
- 22 de junio de 2026: el blog de Chrome for Developers la anuncia con el artículo sobre el conjunto de herramientas para preparar tu web para agentes, junto a las DevTools para agentes y las guías de WebMCP.
- 20 de julio de 2026: Lighthouse 13.4.1 habilita la categoría en la ruta de la API de PageSpeed Insights y señala que el lanzamiento llegará a PageSpeed Insights en un plazo de dos semanas. Eso sitúa el despliegue público a principios de agosto de 2026.
Cuando ejecuté la comprobación el 11 de septiembre de 2026, el pie del informe indicaba una ejecución emulada con Lighthouse 13.4.1, y Agentic Browsing aparecía justo al lado de SEO. Es decir, la función está activa, no solo en un canal experimental. Y también está explícitamente sin terminar: la descripción de la categoría en el informe lo dice sin rodeos, que sigue en desarrollo y sujeta a cambios.
Una nota práctica antes de empezar: PSI ejecuta la categoría por ti, en el lado de Google. No necesitas Chrome 150 ni un origin trial para las comprobaciones a nivel de página. Las exigencias de versión aplican a las ejecuciones locales en Chrome DevTools.
Ejecuta la comprobación en tu propio sitio
- Abre pagespeed.web.dev y pega tu URL. Ejecútala primero en móvil y repite luego en escritorio, porque las dos ejecuciones de laboratorio se puntúan por separado.
- Espera a que terminen los datos de laboratorio. Los datos de campo de la parte superior vienen del Chrome UX Report y cargan rápido. La ejecución de Lighthouse que aparece debajo tarda más y es donde viven las categorías.
- Localiza la fila de puntuaciones. Verás rendimiento, accesibilidad, prácticas recomendadas, SEO y, después, Agentic Browsing en forma de fracción en lugar de una puntuación de 0 a 100.
- Despliega la categoría. La lista de auditorías se agrupa en Agent Accessibility, WebMCP y los habituales bloques de aprobadas y no aplicables.
- Abre cada auditoría que falle. Cada fila se despliega y muestra la regla, el elemento o el archivo concretos detrás del fallo, que es justo lo que necesitas para abrir una tarea de corrección.
La quinta categoría ocupa la misma fila que las puntuaciones que los equipos SEO revisan a diario. Capturada en PageSpeed Insights el 11 de septiembre de 2026.
Comprobación de calidad: confirma la versión de Lighthouse en los detalles de la ejecución antes de comparar resultados con un compañero. PSI actualiza Lighthouse según su propio calendario y la categoría sigue cambiando entre versiones.
Si falla: PSI devuelve de vez en cuando un tiempo de espera RPC en páginas pesadas. A mí me ocurrió en un sitio grande a mitad de la investigación. Vuelve a intentarlo o prueba la página con Lighthouse en local.
Lee correctamente la puntuación fraccionaria
Agentic Browsing no tiene una puntuación ponderada de 0 a 100, y es deliberado. La documentación de Lighthouse explica que los estándares de la web agéntica todavía están emergiendo, así que el foco está en señales accionables y no en una clasificación.
Esta es la aritmética que de verdad importa:
Visualización | Qué significa |
|---|---|
3/3 | Todas las comprobaciones puntuadas han pasado. Las no aplicables quedan excluidas. |
1/3 | Una ha pasado y dos han fallado. El denominador solo incluye las auditorías que pasan o fallan. |
0/3 | Todavía no ha pasado ninguna de las puntuadas. Es habitual en una primera ejecución sobre una página pesada con publicidad. |
Sin fracción | Todas las auditorías no aplicaban o la categoría no se ejecutó. Revisa los detalles de la ejecución. |
La trampa está en leer 1/3 como «33 por ciento listo para agentes». No es un porcentaje de nada. Es un recuento: de las tres comprobaciones que podían puntuarse en esa página, una pasó, y las auditorías que no aplicaban quedaron fuera del cálculo por completo. En el informe que capturé se ejecutaron seis auditorías, tres no aplicaban y las tres restantes produjeron el 1/3.
La puntuación también se mueve entre ejecuciones sobre la misma página. Lighthouse señala tres causas: el registro dinámico de herramientas (las herramientas WebMCP registradas desde JavaScript pueden capturarse o perderse según el momento), los cambios en el DOM que reconfiguran el árbol de accesibilidad y los cambios de diseño provocados por anuncios, imágenes sin dimensiones o contenido inyectado. Si tu número oscila, suele ser por esto.
Recorre las seis auditorías
La compilación actual de PSI ejecuta seis auditorías. Viene una más: la rama de desarrollo de Lighthouse ya añade una comprobación de ai-catalog.json (Agent Resource Discovery) dentro de un nuevo grupo Agent Discoverability, así que trata esta lista como dependiente de la versión.
Auditoría | Qué comprueba | Qué significa «no aplicable» |
|---|---|---|
El árbol de accesibilidad no es correcto | Un subconjunto de reglas de accesibilidad centrado en agentes: nombres y etiquetas programáticos, estructura ARIA válida y elementos que siguen siendo interactivos aunque estén ocultos en el árbol | Nunca; esta siempre puntúa |
llms.txt no sigue las recomendaciones | Que | El archivo devolvió un 404. Que falte llms.txt se considera opcional, no un fallo |
Cambio de diseño acumulado | La estabilidad visual, para que los agentes que actúan según la posición de los elementos no pulsen lo que no es durante un desplazamiento | Nunca; esta siempre puntúa |
Herramientas WebMCP registradas | Si la página registra herramientas WebMCP mediante la API declarativa o la imperativa | No se detectó ninguna herramienta WebMCP |
Cobertura de formularios WebMCP | Formularios declarativos a los que les faltan anotaciones de herramientas | Igual que arriba |
Validez de los esquemas WebMCP | Si las herramientas registradas publican esquemas de entrada y salida válidos | Igual que arriba |
Vista desplegada de la categoría: dos fallos, una aprobada y tres comprobaciones no aplicables. La lista de fallos es la lista de tareas más corta.
Que las tres auditorías WebMCP aparezcan como «no aplicable» es normal en 2026. WebMCP es un estándar propuesto, en origin trial y vista previa temprana, con dos API: una declarativa que anota formularios HTML estándar y otra imperativa que registra herramientas desde JavaScript. La mayoría de los sitios todavía no implementa ninguna de las dos, así que la mayoría de los informes muestran ahí tres círculos grises. El gris no es rojo. No lo trates como un fallo.
Corrige lo que marca la comprobación
Cuatro temas de corrección cubren las seis auditorías. Las tres filas de WebMCP solo requieren atención si de verdad publicas herramientas para agentes.
Haz que el árbol de accesibilidad sea legible para los agentes
Los agentes se apoyan en el árbol de accesibilidad como mapa principal de tu página. Enumera roles, nombres y estados. Un botón sin nombre accesible es un callejón sin salida para ellos y también para quienes usan lectores de pantalla.
Acción: recorre las reglas que fallan en la auditoría desplegada. Los sospechosos habituales son los botones que solo tienen icono, los campos de formulario sin etiqueta, los enlaces cuyo texto es solo «haz clic aquí», las combinaciones de roles ARIA inválidas y los identificadores duplicados a los que hace referencia ARIA. Prioriza HTML semántico, añade atributos for a las etiquetas y da a los componentes personalizados un rol y un tabindex explícitos cuando no sea posible usar un elemento nativo.
Resultado esperado: la auditoría pasa a aprobada y tu puntuación habitual de accesibilidad suele subir a la vez, porque la versión de Agentic Browsing es un subconjunto enfocado de las mismas comprobaciones.
Si te atascas: cuando la lista de correcciones llega a cientos de elementos, no vayas uno por uno. Corrige el componente compartido, como el botón que solo tiene icono en la cabecera, y vuelve a ejecutar. Un solo componente suele despejar decenas de filas.
Publica un llms.txt que supere la comprobación de formato
Aquí hay una trampa que atrapa a la gente cuidadosa. La auditoría no comprueba solo que /llms.txt exista. Revisa el contenido del archivo, y un archivo con direcciones sueltas falla, porque la comprobación busca enlaces en formato Markdown.
Acción: crea /llms.txt en tu dominio raíz con un encabezado H1 y enlaces Markdown de verdad:
# Nombre de la empresa
Descripción breve de lo que cubre el sitio y de cómo debería usarse.
## Páginas clave
- [Descripción del producto](https://example.com/product)
- [Precios](https://example.com/pricing)
- [Documentación](https://example.com/docs)Resultado esperado: la auditoría se pone en verde. Un 404, en cambio, aparece como no aplicable, lo cual hoy es aceptable. Una respuesta de la serie 500 o un error de descarga sí es un fallo real que necesita arreglo en el servidor.
Comprobación de calidad: descarga tu propio /llms.txt en un terminal y cuenta los enlaces. Si aparecen como https://example.com/pricing sin corchetes, la auditoría fallará aunque el archivo esté publicado y sea legible para las personas.
Una advertencia honesta: Google Search no usa llms.txt. La propia guía de optimización para IA de Google dice que el archivo «no perjudicará ni ayudará a la visibilidad o al posicionamiento de tu sitio en Google Search, porque Google Search los ignora». Escríbelo para las herramientas de agentes que leen esta convención, no por posicionamiento.
Estabiliza el diseño para que los agentes puedan apuntar
El cambio de diseño importa más que antes. Un agente que localiza un botón y luego pulsa sus coordenadas fallará si un anuncio, un banner o una imagen de carga tardía empuja ese botón 200 píxeles hacia abajo entre esos dos momentos.
Acción: define ancho y alto explícitos (o aspect-ratio) en imágenes e integraciones, reserva espacio fijo para los huecos de publicidad y los banners de consentimiento, evita insertar contenido por encima del contenido existente después de la carga y anima con transform en lugar de con propiedades que provocan recálculo de diseño.
Resultado esperado: un cambio de diseño acumulado por debajo de 0,1 en la ejecución de laboratorio, que es el mismo umbral que usan las Core Web Vitals.
Comprobación de calidad: el bloque de causas del cambio de diseño en la sección de rendimiento del informe nombra los elementos exactos. Empieza por ahí en vez de adivinar.
Decide sobre WebMCP más adelante
Las tres auditorías WebMCP solo puntúan si tu sitio registra herramientas. Si tienes un flujo de reservas, un proceso de pago, un formulario de soporte o cualquier tarea estructurada que un agente podría completar, WebMCP merece un prototipo: le dice al agente exactamente qué herramienta llamar en lugar de obligarle a adivinarlo a partir del DOM. Chrome ofrece la función detrás de un origin trial y un indicador de prueba local, así que es una opción real y no un experimento mental.
Si no tienes ninguna tarea que merezca automatizarse, deja WebMCP en paz. Tres círculos grises no tienen nada de malo. Lo único que no conviene hacer es registrar una herramienta decorativa solo para que la fracción se vea mejor. La categoría es una señal de preparación, y engañarla le quita el sentido.
Verifica la corrección
Vuelve a ejecutar la misma URL en PSI y compara tres cosas, no una: la fracción, el estado concreto de cada auditoría y el tipo de dispositivo. Una corrección puede mover la fracción sin arreglar lo que te importaba, y móvil y escritorio producen resultados de laboratorio distintos.
Para iterar más rápido, ejecuta Lighthouse en local en lugar de esperar a PSI. La categoría está en Lighthouse 13.3 y posteriores, así que una instalación local la recoge. Si quieres la versión del panel de DevTools, la documentación de Google indica que probar la categoría requiere Chrome 150 o posterior, y las auditorías WebMCP necesitan además el origin trial registrado.
Lleva un registro breve del antes y el después. Basta con una línea fechada del tipo «2026-09-11: móvil 1/3, fallan el árbol de accesibilidad y llms.txt». Te dirá si una regresión posterior es real o solo una oscilación entre ejecuciones.
Qué no es esta comprobación
Hay tres cosas que no hace, porque la confusión está muy extendida:
- No es un factor de posicionamiento. El anuncio de Chrome describe la categoría como informativa y fuera de cualquier referencia comparativa. Los rankings de Google Search no se ven afectados por tu fracción de Agentic Browsing.
- No es una puntuación de visibilidad en IA. Mide si un agente puede operar tu página, y no dice nada sobre si ChatGPT o Perplexity te citan en una respuesta.
- No es un veredicto de apto o no apto sobre tu sitio. Una fracción baja en una página de marketing sencilla suele significar que había poco que puntuar, no que los agentes estén bloqueados.
La perspectiva que ayuda: esta categoría comprueba si tu sitio aguanta cuando el visitante no es humano. Todo lo que premia merece la pena de todos modos: HTML semántico, diseños estables, controles etiquetados. La propia guía de Google sobre sitios amigables para agentes cierra con la misma idea: lo que hace que un sitio esté listo para agentes también lo hace mejor para las personas.
Mantenla en tu ciclo de revisión
La preparación para agentes es una de esas áreas donde la plataforma se mueve más rápido que la lista de comprobación. Dos hábitos te mantienen al día sin convertirlo en un proyecto:
- Vuelve a ejecutar la comprobación después de cualquier cambio de plantilla, navegación, formulario o proceso de compra. Esos son los cambios que mueven el árbol de accesibilidad y la estabilidad del diseño.
- Sigue la fracción por plantilla, no por URL. Diez páginas de producto que puntúan igual son un problema de plantilla, y una sola corrección resuelve las diez.
La comprobación de PSI es deliberadamente estrecha: seis auditorías, una página a la vez. Si quieres la imagen más amplia, incluida la presencia de reglas de robots, tarjetas de servidores MCP, descubrimiento OAuth y señales de comercio para agentes, Auspia mantiene una comprobación gratuita de Agent Readiness que analiza una URL frente a esos estándares de protocolo y muestra una tabla comparativa.
Preguntas frecuentes
¿La puntuación de Agentic Browsing afecta al posicionamiento en Google? No. Google describe la categoría como informativa y no forma parte de los sistemas de posicionamiento de Search. Trátala como una comprobación de preparación para agentes, no como una puntuación SEO.
¿Por qué cambió mi fracción entre dos ejecuciones de la misma página? El registro dinámico de herramientas, los cambios en el DOM que alteran el árbol de accesibilidad y los cambios de diseño tardíos provocan variación entre ejecuciones. Vuelve a probar y compara la lista de auditorías, no solo la fracción.
¿Por qué las tres auditorías WebMCP aparecen como no aplicables? Porque tu página no registra herramientas WebMCP. Es el estado esperado en la mayoría de los sitios en 2026 y no es un fallo.
¿Es un problema que falte llms.txt? Para esta auditoría, no. Un 404 se trata como no aplicable. Un archivo que existe pero está mal formado sí falla, así que si publicas uno, publícalo correctamente.
¿Puedo ejecutar esto en CI? Sí, en cuanto la categoría esté en tu versión de Lighthouse. Las auditorías son deterministas por diseño, y eso es lo que las hace aptas para comprobaciones de canalización. Ten en cuenta que las partes de WebMCP dependen del soporte del navegador y de la inscripción en el origin trial, así que en la mayoría de entornos de CI aparecerán como no aplicables.
¿Necesito Chrome 150 para usar esto? No. PageSpeed Insights lo ejecuta en el servidor. El requisito de Chrome 150 aplica a ejecutar la categoría en local dentro de DevTools.
Autora: Alice Monroe, analista de herramientas de AI SEO en Auspia, donde cubre más de 150 herramientas. Escribe sobre SEO y herramientas de búsqueda con IA, sobre qué comprobaciones merecen tu tiempo y cómo incorporarlas a la rutina de trabajo.
