Agentic Browsing: PageSpeed per a agents IA - Ighenatt Blog

El més enganyós de la nova categoria Lighthouse Agentic Browsing és la paraula “score”. Els equips SEO estan acostumats a obrir PageSpeed, mirar un número, discutir si un 89 és prou bo i passar a una altra cosa. Aquesta categoria no funciona així.

La documentació de Chrome diu que Agentic Browsing és experimental i que es basa en estàndards proposats. També indica que provar la categoria requereix Chrome 150 o posterior, i que les auditories WebMCP requereixen l’origin trial de WebMCP. Això importa perquè no és un informe madur de Search Console, no substitueix els Core Web Vitals i no és un senyal de rànquing que puguis afegir tranquil·lament a una proposta comercial.

És una cosa més pràctica: un conjunt de comprovacions deterministes per veure si els agents poden entendre i interactuar amb una pàgina amb menys conjectures.

Per a equips de SEO tècnic i desenvolupament a Espanya i Europa, l’auditoria és útil d’una manera molt concreta. Pot exposar els mateixos problemes que ja perjudiquen els usuaris: controls sense etiqueta, disposicions inestables, formularis ambigus, resums de lloc poc clars i interaccions gestionades per JavaScript que només tenen sentit per a una persona mirant la pantalla. La diferència és que ara l’observador és un agent.

Què mesura realment Lighthouse Agentic Browsing

Chrome descriu la categoria Agentic Browsing com una manera d’avaluar fins a quin punt un lloc està construït per a la interacció de màquines mitjançant auditories deterministes. Aquesta frase pesa molt. L’auditoria no pregunta si el teu contingut és persuasiu, si la marca és forta o si Google t’hauria de posicionar per sobre d’un competidor. Pregunta si un agent en el navegador pot identificar eines, entendre formularis, llegir l’arbre d’accessibilitat, trobar context llegible per màquines i interactuar amb la interfície sense que els elements es moguin al seu voltant.

La categoria agrupa diversos senyals. La integració WebMCP comprova si la pàgina exposa eines estructurades mitjançant HTML declaratiu o JavaScript. La validesa d’esquema WebMCP revisa si aquestes eines estan descrites de manera coherent. L’auditoria de formularis sense WebMCP declaratiu identifica formularis que es podrien anotar per fer més fiable la interacció d’agents. L’auditoria de llms.txt comprova la disponibilitat d’un resum llegible per màquines a l’arrel del domini. L’auditoria d’accessibilitat per a agents se centra en l’arbre d’accessibilitat. L’auditoria d’estabilitat de la disposició utilitza CLS perquè els elements que es mouen poden trencar accions basades en coordenades o assistides per captures.

Aquesta barreja és el punt. La preparació agèntica no és només “SEO per a IA”. Viu entre la velocitat web i SEO, l’accessibilitat web, el disseny d’interaccions estructurades i la governança de contingut.

Pensa en una pàgina de filtres de producte. Una persona sovint pot deduir que una petita icona d’embut obre els filtres, que un slider personalitzat controla el preu i que una capa que apareix amb retard és només una finestra modal de butlletí. Un agent pot necessitar etiquetes, estat, posició estable i metadades explícites d’eina. Si el botó de filtre no té nom accessible, el formulari té inputs sense nom i un bàner mou el botó 400 mil·lisegons després de carregar, la tasca es torna fràgil.

Això és el que aquesta categoria intenta fer visible. No popularitat. No autoritat. Preparació per interactuar.

Per què no és una puntuació PageSpeed normal

Les categories clàssiques de Lighthouse, com Performance o Accessibility, són familiars perquè redueixen moltes auditories a una puntuació ponderada de 0 a 100. Agentic Browsing és diferent. La documentació de scoring de Chrome diu que actualment no utilitza una mitjana ponderada de 0 a 100 perquè els estàndards del web agèntic encara estan emergint. En comptes d’això, l’informe mostra una puntuació fraccional, estats passa/falla per a auditories concretes i recomptes informatius.

Això canvia com s’ha de llegir. Una ràtio de 6/8 no equival a un 75 de Lighthouse Performance. Només vol dir que sis de les comprovacions actuals de preparació han passat. Una auditoria fallida d’esquema WebMCP pot importar molt més en un formulari de reserva que en un article estàtic. Un llms.txt absent pot aparèixer com a no aplicable perquè el fitxer és opcional ara mateix, mentre que un error de servidor en recuperar-lo sí que és un problema tècnic real.

El bon hàbit és tractar la categoria com una llista de verificació de desplegament. La pàgina registra eines? Els noms i les descripcions de les eines són coherents? Els camps obligatoris tenen name? Els camps opcionals tenen etiqueta o descripció de paràmetre? L’arbre d’accessibilitat exposa el que un agent necessita? El CLS mou controls després que l’agent els hagi identificat?

Per això també importen les comprovacions deterministes. Chrome diu que Lighthouse utilitza senyals deterministes perquè les auditories siguin reproduïbles i aptes per a CI/CD. Una auditoria determinista no és una impressió subjectiva d’un LLM. S’assembla més a un test unitari de les possibilitats d’interacció de la pàgina. Els resultats encara poden variar si JavaScript registra eines tard, si la complexitat del DOM altera l’arbre d’accessibilitat o si els canvis de disposició mouen elements durant la captura. Però l’objectiu de l’auditoria és concret.

La lectura contrària: l’absència d’un 0-100 és bona. Evita comprimir estàndards immadurs en un KPI de vanitat. De moment, la victòria no és “apujar 20 punts el nostre Agentic Browsing”. La victòria és “fer que el formulari de contacte, els filtres, el flux de reserva o la configuració de producte siguin comprensibles per a navegadors que poden actuar en nom dels usuaris”.

WebMCP: eines explícites en lloc d’endevinar la interfície

WebMCP és la part més nova de la pila. Chrome el presenta com una proposta d’estàndard web per exposar eines estructurades a agents d’IA. L’objectiu és ajudar els agents a interactuar amb un lloc declarant quines accions existeixen, quins inputs s’esperen i quin estat està disponible, en comptes d’obligar l’agent a inferir-ho tot a partir de botons, etiquetes i posició visual.

La pàgina de WebMCP de Chrome parla de tres idees suportades: discovery, JSON Schemas i state. Discovery permet que les pàgines registrin eines com pagament, filtratge de resultats o enviament d’una sol·licitud. JSON Schema ajuda a definir inputs i outputs esperats. State dona a l’agent una comprensió compartida dels recursos disponibles a la pàgina actual. A la pràctica, un flux de suport pot exposar una eina submit_ticket en lloc de demanar a l’agent que faci clic per menús niats i endevini què significa cada camp.

Hi ha dues vies d’implementació. L’API declarativa anota formularis HTML estàndard amb atributs com noms i descripcions d’eina. L’API imperativa utilitza JavaScript, incloent-hi navigator.modelContext.registerTool, per registrar eines programàticament. Lighthouse pot llistar eines WebMCP registrades, i Chrome diu que aquesta auditoria és informativa: si no hi ha eines registrades, la llista és buida.

L’auditoria de validesa d’esquema és més estricta. Falla quan un formulari té tooldescription sense toolname, quan té toolname sense tooldescription, o quan un camp obligatori no té atribut name. També pot avisar quan camps opcionals amb nom no tenen ni descripció de paràmetre ni etiqueta associada. No és res exòtic. Molts formularis ja fallen aquesta disciplina sense necessitat de parlar d’IA.

Un bon primer objectiu per a un web B2B europeu no és tot el lloc. Comença pels formularis que creen valor comercial o operatiu: contacte, pressupost, demostració, reserva, suport, cerca, qualificació de clients potencials i filtres de producte. Si un agent no pot distingir “raó social” de “persona de contacte”, o “NIF” de “referència de comanda”, el problema no és la IA. El formulari estava mal especificat.

Amb optimització de JavaScript per al rendiment apareix un altre angle: si el registre d’eines depèn d’hidratació tardana, paquets pesants o estat client fràgil, Lighthouse pot no detectar l’eina durant la captura. WebMCP fa explícita la interacció, però no disculpa una arquitectura front-end lenta, inestable o massa complicada.

L’accessibilitat és el mapa de l’agent

La documentació d’accessibilitat per a agents de Chrome fa una observació simple: els agents revisen l’arbre d’accessibilitat per identificar elements interactius. Els estàndards d’accessibilitat estan escrits per a humans, però molts dels mateixos principis de disseny ajuden els agents a entendre un web. Les etiquetes absents poden bloquejar tant usuaris amb discapacitat visual com agents que intenten completar una tasca.

Això hauria de sonar familiar a qualsevol persona que hagi fet una auditoria SEO tècnica seriosa. L’arbre d’accessibilitat no és una capa decorativa. És el model llegible per màquines de la interfície. Si el text visible d’un botó se substitueix per una icona sense nom accessible, el DOM pot semblar correcte per a disseny i opac per a un agent. Una finestra modal que gestiona malament el focus pot deixar l’agent atrapat igual que un usuari de teclat. Si un selector personalitzat recrea malament el comportament nadiu del navegador, el navegador té menys semàntica per exposar.

Aquí els equips SEO han de vigilar amb la propietat del problema. Agentic Browsing no és només una qüestió de desenvolupament. Travessa decisions de sistema de disseny, etiquetes de contingut, API de components i QA. Un component de botó reutilitzable sense una regla fiable de nom accessible pot crear centenars de punts febles d’interacció. Un constructor de formularis que permet etiquetes buides pot trencar en silenci fluxos de conversió en diversos idiomes. En llocs multilingües, les etiquetes en català, castellà i anglès necessiten la mateixa cura semàntica, no només una traducció visible.

Un patró de revisió pràctic funciona bé. Obre la pàgina amb Chrome DevTools, inspecciona l’arbre d’accessibilitat i compara’l amb el recorregut que esperes que completi un agent. Pot identificar el camp de cerca? El botó d’enviament? Els camps obligatoris? Els errors de validació? El filtre seleccionat actual? Si no, arregla la semàntica abans d’escriure cap capa WebMCP.

Això connecta directament amb AI Mode i les cerques conversacionals. A mesura que les interfícies de cerca i navegació es tornen més conversacionals, els llocs que expressen bé la seva estructura seran més fàcils d’interpretar. No és el mateix que impacte de rànquing. És llegibilitat tècnica.

L’estabilitat visual ajuda a evitar clics erronis

El CLS se sol explicar com una mètrica d’experiència d’usuari: el contingut salta, l’usuari perd el punt de lectura i algú acaba tocant el botó equivocat. L’auditoria d’estabilitat de la disposició d’Agentic Browsing reformula el mateix problema per als agents. Sovint depenen de captures de pantalla o d’interacció basada en coordenades. Si un botó es mou després que l’agent l’hagi identificat, la interacció pot fallar.

La llista de causes és coneguda: imatges sense dimensions, bàners injectats, anuncis carregats tard, embeds, fonts web, canvis d’hidratació i components UI que reserven massa poc espai. La diferència és el mode de fallada. Una persona pot compensar mirant una altra vegada. Un agent automatitzat pot clicar la coordenada antiga, escriure al camp equivocat o abandonar el flux.

Per als equips que ja treballen els Core Web Vitals 2026, aquesta alineació és útil. Millorar CLS no és només una qüestió de Page Experience. També redueix la incertesa d’interacció. La remediació continua sent la mateixa: declarar dimensions, reservar espai per a components dinàmics, evitar animacions que canvien la disposició, gestionar els bàners de cookies sense empènyer controls principals i provar formularis després que carreguin scripts de tercers.

Un exemple de comerç electrònic ho deixa clar. Imagina una pàgina de pagament on un giny de finançament es carrega damunt del botó de pagament al cap d’un segon. L’usuari veu un petit salt. Un agent que havia seleccionat el botó de pagament per posició ara pot estar apuntant a un element diferent. El canvi de disposició ja no és només molest; corromp el camí d’acció.

Per això Agentic Browsing hauria d’entrar al QA dels fluxos d’alt valor. Executa’l en plantilles, no només a la pàgina inicial. Pàgines de categoria, fitxes de producte, formularis de clients potencials, pàgines de reserva i formularis de suport importen més que un hero de màrqueting polit. Si un agent pot navegar la pàgina inicial, però no pot completar una sol·licitud de pressupost, la implementació és sobretot aparença.

llms.txt és opcional, però els errors de servidor no

L’auditoria de llms.txt de Chrome és deliberadament prudent. Descriu llms.txt com una convenció emergent per publicar un resum llegible per màquines del contingut d’un lloc per a LLM i agents d’IA. L’auditoria intenta recuperar el fitxer des de l’arrel del domini. Si el servidor retorna un 404, l’auditoria es marca com a no aplicable perquè oferir aquest fitxer és opcional ara mateix. Si hi ha un error de servidor, Lighthouse ho marca.

És el nivell de pressió correcte. Un llms.txt absent no s’hauria de tractar com una catàstrofe. Un endpoint trencat a /llms.txt és diferent perquè apunta a una mala configuració: routing, desplegament, capçaleres, generació de fitxer o comportament del CDN.

Per a equips SEO, llms.txt és més útil com a governança editorial. Ha d’explicar el propòsit del lloc i enllaçar recursos clau en Markdown concís. No ha de ser un segon sitemap amb totes les URL. En un lloc de SEO tècnic, un bon fitxer podria apuntar agents cap a guies canòniques sobre llms.txt i SEO per a IA, Core Web Vitals, accessibilitat, visibilitat IA i pàgines de servei. Cada enllaç hauria de tenir una raó per existir.

El parany és exagerar. Que l’auditoria de Chrome comprovi llms.txt no demostra que Google Search l’utilitzi per al rànquing. No demostra que ChatGPT, Claude, Perplexity o Gemini et citaran. Demostra que el fitxer pot ajudar agents compatibles a entendre el lloc més ràpidament, i que Lighthouse pot comprovar si el fitxer arrel respon bé.

Utilitza el fitxer com un índex públic d’allò que vols que les màquines llegeixin primer. Mantén-lo curt, canònic i revisat. Si publiques en diversos idiomes, no barregis versions idiomàtiques sense criteri. Declara seccions amb claredat, usa URL canòniques i revisa’l després de migracions, canvis de serveis, actualitzacions importants de contingut i modificacions de robots.txt.

Com utilitzar l’auditoria sense reaccionar en excés

Un desplegament sensat comença per tipus de pàgina. No executis Agentic Browsing una vegada a la pàgina inicial i declaris el lloc “preparat per a agents”. Tria un conjunt representatiu: pàgina inicial, pàgina de servei, article de blog, categoria, cerca interna, formulari de contacte, formulari de clients potencials, filtre de comerç electrònic, fitxa de producte i pagament si aplica. Per a cada tipus de pàgina, registra la ràtio d’aprovació, les auditories fallides i els resultats informatius.

Després classifica els problemes pel valor per a l’usuari. Les etiquetes d’accessibilitat i els problemes de CLS han d’entrar al backlog normal de qualitat web perquè ajuden humans i agents. WebMCP s’hauria de prioritzar on les accions estructurades d’agents tenen sentit. Un formulari de butlletí pot necessitar només metadades declaratives bàsiques. Un flux de reserva, un panell de diagnòstic o un configurador de producte poden requerir eines imperatives, gestió d’estat i una revisió de seguretat més forta.

Chrome també documenta limitacions de WebMCP. Les crides d’eines requereixen una pestanya de navegador o webview amb context visible; no hi ha suport de tool calling en mode headless. Els llocs complexos poden necessitar JavaScript addicional o refactorització per gestionar l’estat de la interfície. Els clients i navegadors han de visitar el lloc per descobrir eines cridables. Les API WebMCP també estan condicionades per origin isolation i permissions policy. Aquestes restriccions el converteixen en una millora progressiva, no en una capa universal per enganxar a tot el web d’un dia per l’altre.

La seguretat mereix una passada pròpia. Si una eina pot enviar un formulari, canviar configuració de compte, reservar una cita o iniciar una compra, l’usuari ha de mantenir el control. La visió general de WebMCP de Chrome assenyala que les accions sensibles poden incloure una ordre que demani interacció de l’usuari amb un diàleg de confirmació. En contextos europeus, afegeix revisió de privacitat: fluxos de consentiment, camps de dades personals, retenció i analítica han de continuar sent comprensibles per a l’usuari.

La regla de treball és simple: arregla primer els fonaments avorrits. HTML semàntic, etiquetes, disposicions estables, formularis nets, errors accessibles i jerarquia de contingut clara milloraran Agentic Browsing i l’experiència d’usuari normal alhora. WebMCP ve després, allà on eines explícites aporten fiabilitat mesurable.

Llista de verificació pràctica per a equips SEO i dev

Fes servir aquesta llista de verificació en la primera passada d’auditoria:

• Confirma que l’entorn de prova utilitza Chrome 150 o posterior per a la categoria Agentic Browsing.
• Tracta les auditories relacionades amb WebMCP com a experimentals i comprova si l’origin trial de WebMCP s’aplica a la prova.
• Executa l’auditoria en plantilles importants, no només a la pàgina inicial.
• Registra per separat la ràtio fraccional d’aprovació, els resultats passa/falla i els recomptes informatius.
• En formularis, revisa toolname, tooldescription, atributs name dels inputs, etiquetes i context de camp.
• Inspecciona l’arbre d’accessibilitat per a accions principals, camps obligatoris, errors, navegació i filtres.
• Comprova CLS a les mateixes pàgines amb Lighthouse i el teu flux habitual de Core Web Vitals.
• Recupera /llms.txt directament i verifica si retorna 200, 404 o un error de servidor.
• No comuniquis troballes d’Agentic Browsing com a millores de rànquing llevat que Chrome o Google Search ho documentin explícitament en el futur.
• Afegeix comprovacions repetibles a CI només quan l’equip hagi acordat quins tipus de pàgina i quines fallades importen.

El primer guany comercial probablement no serà una “puntuació agèntica” abstracta. Serà un formulari que agents i tecnologies assistives poden entendre, un pagament que no mou controls a mitja acció, o una pàgina de suport que exposa clarament la tasca correcta. Això és útil encara que els estàndards canviïn.

Executa l’auditoria, però mantén el cap fred. La categoria és experimental. Els requisits de navegador són específics. WebMCP encara viu en territori d’origin trial. El model de scoring evita expressament el número clàssic de Lighthouse de 0 a 100.

El que sí que és estable és la direcció: els navegadors comencen a avaluar si els llocs web poden ser accionats per programari, no només renderitzats per a persones. Els llocs amb semàntica clara, disposicions estables, formularis ben descrits i context llegible per màquines seran més fàcils d’operar. Val la pena arreglar-ho ara, sense fingir que ja és una palanca de rànquing.

Preguntes freqüents sobre Lighthouse Agentic Browsing

Lighthouse Agentic Browsing forma part de PageSpeed Insights?

És una categoria de Lighthouse documentada per Chrome per a auditories de navegació agèntica. La disponibilitat en un flux concret de PageSpeed o Lighthouse pot dependre de la versió de Chrome, del suport experimental i dels requisits de l’origin trial de WebMCP. Per fer proves fiables, segueix el requisit actual de Chrome: Chrome 150 o posterior per a la categoria i registre a l’origin trial per a les auditories WebMCP.

Una ràtio baixa d’Agentic Browsing és dolenta per al SEO?

No directament segons la documentació actual de Chrome. Els documents descriuen preparació tècnica per a interacció de màquines, no un factor de rànquing de Google Search. Tracta les fallades com a senyals d’enginyeria i UX. L’accessibilitat, el CLS i la claredat dels formularis ja poden importar als usuaris i a les conversions, però no afirmis un impacte directe de rànquing d’aquesta categoria.

Què haurien de fer primer els llocs centrats en contingut?

Comença per llms.txt, HTML semàntic, claredat d’encapçalaments, enllaços accessibles i disposicions estables. WebMCP és més útil quan la pàgina exposa accions. Un article de blog no necessita la mateixa capa d’eines agèntiques que un motor de reserves, però ha de ser llegible, ben estructurat, ben enllaçat internament i fàcil de resumir.

Què haurien de fer primer els llocs transaccionals?

Audita els fluxos on un agent actuaria: cerca, filtres, opcions de producte, carret, pagament, sol·licituds de pressupost, demostracions, reserves i suport. Aquestes pàgines necessiten etiquetes, controls estables, errors de validació clars, estat predictible i possiblement eines WebMCP. Prova després que carreguin bàners de cookies, scripts de personalització i ginys de tercers, perquè aquí apareixen moltes fallades de disposició i interacció.