PageSpeed Insights assegna da anni un punteggio a Prestazioni, Accessibilità, Best practice e SEO. Nel 2026 una quinta voce si è aggiunta in silenzio a quella riga: Agentic Browsing. Risponde a una domanda che le altre quattro categorie ignorano: un agente AI riesce davvero a lavorare con questa pagina?
Questa guida serve a mettere quel controllo al lavoro sul tuo sito: eseguirlo, leggere cosa dice davvero ogni verifica e uscirne con una lista di correzioni.
Cosa avrai alla fine
A chi è rivolto: a SEO, sviluppatori e proprietari di siti che vogliono sapere come si comportano le loro pagine quando a sfogliarle è un agente invece di una persona.
Cosa avrai alla fine: un risultato Agentic Browsing reale per il tuo sito, una lettura verifica per verifica di cosa passa, fallisce o non si applica, e una lista di correzioni già ordinata per priorità.
Prerequisiti: un URL raggiungibile pubblicamente, circa dieci minuti per la prima esecuzione e accesso al codice se prevedi di correggere qualcosa lo stesso giorno.
Definizione di fatto: sai spiegare il tuo punteggio frazionario verifica per verifica e sai dire quali fallimenti bloccano davvero gli agenti dal completare un'attività sulla tua pagina.
Da dove viene questo controllo e perché ora
La categoria Agentic Browsing non esisteva un anno fa. Il rollout è avvenuto in tre passaggi, tutti documentati da Google:
- 7 maggio 2026: Lighthouse 13.3 aggiunge la categoria alla configurazione predefinita, che diventa così parte di un'esecuzione standard.
- 22 giugno 2026: il blog Chrome for Developers la annuncia in "A developer toolkit to make your website agent-ready", insieme a DevTools for agents e alle linee guida WebMCP.
- 20 luglio 2026: Lighthouse 13.4.1 abilita la categoria per il percorso API di PageSpeed Insights e annuncia che il rilascio arriverà su PageSpeed Insights "entro 2 settimane". Il rollout pubblico cade quindi all'inizio di agosto 2026.
Quando ho eseguito il controllo l'11 settembre 2026, il piè di pagina del report diceva "Emulated Moto G Power with Lighthouse 13.4.1", e Agentic Browsing stava proprio accanto a SEO. La funzione è quindi attiva, non solo in canary. Ed è anche esplicitamente incompiuta: la descrizione della categoria nel report lo dice con chiarezza, "This category is still under development and subject to change".
Una nota pratica prima di iniziare: PSI esegue la categoria per te, lato Google. Non ti servono Chrome 150 né un origin trial per i controlli a livello di pagina. Le esecuzioni locali in Chrome DevTools sono quelle con requisiti di versione.
Esegui il controllo sul tuo sito
- Apri pagespeed.web.dev e incolla il tuo URL. Esegui prima per mobile, poi ripeti per desktop: le due esecuzioni di laboratorio vengono valutate separatamente.
- Aspetta che i dati di laboratorio finiscano. I dati sul campo in alto arrivano dal Chrome UX Report e si caricano subito. L'esecuzione Lighthouse sotto richiede più tempo ed è lì che vivono le categorie.
- Trova la riga dei punteggi. Vedrai Prestazioni, Accessibilità, Best practice, SEO e poi Agentic Browsing come frazione invece che come punteggio da 0 a 100.
- Espandi la categoria. L'elenco delle verifiche si raggruppa in Agent Accessibility, WebMCP e nei soliti blocchi di controlli superati e non applicabili.
- Apri ogni verifica fallita. Ogni riga si espande e mostra la regola, l'elemento o il file specifico dietro il fallimento: è esattamente ciò che serve per aprire un ticket di correzione.
La quinta categoria sta nella stessa riga dei punteggi che i team SEO controllano ogni giorno. Catturato in PageSpeed Insights l'11 settembre 2026.
Controllo di qualità: verifica la versione di Lighthouse nei dettagli dell'esecuzione prima di confrontare i risultati con un collega. PSI aggiorna Lighthouse con i suoi tempi, e la categoria cambia ancora da versione a versione.
Se fallisce: PSI ogni tanto restituisce un timeout RPC sulle pagine pesanti. È successo anche a me su un sito grande durante la ricerca. Riprova, oppure prova la pagina con Lighthouse locale.
Leggi correttamente il punteggio frazionario
Agentic Browsing non ha un punteggio pesato da 0 a 100, e la scelta è deliberata. La documentazione di Lighthouse spiega che gli standard del web agentico sono ancora in formazione, quindi l'attenzione è sui segnali azionabili più che su una classifica.
Ecco l'aritmetica che conta davvero:
Visualizzazione | Cosa significa |
|---|---|
3/3 | Tutte le verifiche valutate sono passate. Le verifiche non applicabili sono escluse. |
1/3 | Una passata, due fallite. Il denominatore contiene solo le verifiche passate e fallite. |
0/3 | Nessuna verifica valutata è ancora passata. Comune alla prima esecuzione su una pagina pesante, piena di annunci. |
Nessuna frazione | Tutte le verifiche erano non applicabili oppure la categoria non è stata eseguita. Controlla i dettagli dell'esecuzione. |
La trappola è leggere 1/3 come "pronto per gli agenti al 33 percento". Non è una percentuale di nulla. È un conteggio: una delle tre verifiche che potevano essere valutate su quella pagina è passata, e le verifiche non applicabili sono state escluse del tutto dal calcolo. Nel report che ho catturato sono state eseguite sei verifiche, tre erano non applicabili, e le tre rimanenti hanno prodotto il punteggio 1/3.
I punteggi si muovono anche tra esecuzioni sulla stessa pagina. Le tre cause indicate da Lighthouse sono la registrazione dinamica degli strumenti (gli strumenti WebMCP registrati via JavaScript possono essere catturati o mancati a seconda dei tempi), le modifiche al DOM che ridisegnano l'albero di accessibilità e gli spostamenti di layout causati da annunci, immagini senza dimensioni o contenuti iniettati. Se il tuo numero oscilla, di solito è per questo.
Esamina le sei verifiche
L'attuale build di PSI esegue sei verifiche. Ne arriverà una in più: il ramo di sviluppo di Lighthouse sta già aggiungendo un controllo ai-catalog.json (Agent Resource Discovery) sotto un nuovo gruppo Agent Discoverability, quindi considera questo elenco dipendente dalla versione.
Verifica | Cosa controlla | Cosa significa "non applicabile" |
|---|---|---|
L'albero di accessibilità non è corretto | Un sottoinsieme di regole di accessibilità pensate per gli agenti: nomi ed etichette programmatici, struttura ARIA valida ed elementi che restano interattivi pur essendo nascosti all'albero | Mai; questa verifica viene sempre valutata |
llms.txt non segue le raccomandazioni | Che | Il file ha restituito un 404. Un llms.txt mancante è considerato opzionale, non un fallimento |
Spostamento del layout cumulativo | La stabilità visiva, così che gli agenti che agiscono sulle posizioni degli elementi non clicchino la cosa sbagliata durante uno spostamento | Mai; questa verifica viene sempre valutata |
Strumenti WebMCP registrati | Se la pagina registra strumenti WebMCP tramite l'API dichiarativa o imperativa | Non è stato rilevato alcuno strumento WebMCP |
Copertura dei moduli WebMCP | I moduli dichiarativi a cui mancano le annotazioni degli strumenti | Come sopra |
Validità degli schemi WebMCP | Che gli strumenti registrati pubblichino schemi di input e output validi | Come sopra |
Una vista espansa della categoria: due fallimenti, un superato e tre verifiche non applicabili. L'elenco dei fallimenti è il percorso più breve verso un'attività da fare.
Le tre verifiche WebMCP che mostrano "non applicabile" sono normali nel 2026. WebMCP è uno standard proposto, in origin trial e anteprima iniziale, con due API: una dichiarativa che annota i moduli HTML standard e una imperativa che registra strumenti dal JavaScript. La maggior parte dei siti non ne implementa ancora nessuna, quindi la maggior parte dei report mostra tre cerchi grigi lì. Il grigio non è rosso. Non trattarlo come un fallimento.
Correggi ciò che il controllo segnala
Quattro temi di correzione coprono le sei verifiche. Le tre righe WebMCP richiedono attenzione solo se pubblichi davvero strumenti per agenti.
Rendi l'albero di accessibilità leggibile agli agenti
Gli agenti si appoggiano all'albero di accessibilità come mappa principale della tua pagina. Elenca ruoli, nomi e stati. Un pulsante senza nome accessibile è un vicolo cieco per loro, e anche per chi usa uno screen reader.
Azione: affronta le regole fallite dalla verifica espansa. I sospetti di sempre sono i pulsanti con sola icona, i campi modulo senza etichetta, i link il cui testo è solo "clicca qui", le combinazioni di ruoli ARIA non valide e gli ID duplicati referenziati da ARIA. Preferisci l'HTML semantico, aggiungi gli attributi for alle etichette e dai ai widget personalizzati un ruolo esplicito e un tabindex quando un elemento nativo non è possibile.
Risultato atteso: la verifica passa e di solito migliora anche il tuo punteggio Accessibilità normale, perché la versione di Agentic Browsing è un sottoinsieme mirato degli stessi controlli.
Percorso di recupero: se la lista di correzioni arriva a centinaia di elementi, non inseguirli uno per uno. Correggi il componente condiviso, come il pulsante con sola icona nell'header, poi riesegui. Un componente spesso ripulisce decine di righe.
Pubblica un llms.txt che superi il controllo di formato
Questo ha una trappola che coglie le persone più attente. La verifica non controlla solo che /llms.txt esista. Controlla il contenuto del file, e un file che elenca URL nudi fallisce, perché il controllo cerca link in stile Markdown.
Azione: crea /llms.txt nella radice del tuo dominio con un titolo H1 e veri link Markdown:
# Your Company
Short description of what the site covers and how it should be used.
## Key pages
- [Product overview](https://example.com/product)
- [Pricing](https://example.com/pricing)
- [Documentation](https://example.com/docs)Risultato atteso: la verifica diventa verde. Un 404, al contrario, appare come non applicabile, cosa accettabile oggi. Una risposta della serie 500, o un errore di recupero, è un fallimento vero che richiede una correzione lato server.
Controllo di qualità: scarica il tuo /llms.txt da terminale e conta i link. Se assomigliano a https://example.com/pricing senza parentesi quadre, la verifica fallirà anche se il file è online e leggibile dagli umani.
Un'avvertenza onesta: Google Search non usa llms.txt. La guida di Google all'ottimizzazione per l'AI dice che il file "will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them". Scrivilo per gli strumenti degli agenti che leggono quella convenzione, non per il posizionamento.
Stabilizza il layout perché gli agenti possano mirare
Lo spostamento del layout conta più di prima. Un agente che individua un pulsante e poi clicca le sue coordinate sbaglierà se un annuncio, un banner o un'immagine caricata in ritardo spinge quel pulsante 200 pixel più in basso tra i due momenti.
Azione: imposta larghezza e altezza esplicite (o aspect-ratio) su immagini e embed, riserva spazio fisso per gli slot pubblicitari e i banner di consenso, evita di inserire contenuto sopra contenuto esistente dopo il caricamento e anima con transform invece che con proprietà che innescano il layout.
Risultato atteso: Spostamento del layout cumulativo sotto 0,1 nell'esecuzione di laboratorio, la stessa soglia usata dai Core Web Vitals.
Controllo di qualità: l'approfondimento Layout shift culprits sotto Prestazioni nomina gli elementi esatti responsabili. Parti da lì invece di tirare a indovinare.
Decidi più avanti su WebMCP
Le tre verifiche WebMCP vengono valutate solo se il tuo sito registra strumenti. Se gestisci un flusso di prenotazione, un checkout, un modulo di assistenza o qualsiasi attività strutturata che un agente potrebbe completare, WebMCP vale un prototipo: dice agli agenti esattamente quale strumento chiamare invece di farli indovinare dal DOM. Chrome distribuisce la funzione dietro un origin trial e un flag di test locale, quindi è un'opzione reale, non un esperimento mentale.
Se non hai un'attività che valga la pena automatizzare, lascia stare WebMCP. Tre cerchi grigi non sono un problema. L'unica cosa da non fare è registrare uno strumento decorativo solo per far sembrare migliore la frazione. La categoria è un segnale di prontezza, e bararla ne annulla lo scopo.
Verifica la correzione
Riesegui lo stesso URL in PSI e confronta tre cose, non una: la frazione, gli stati specifici delle verifiche e il tipo di dispositivo. Una correzione può muovere la frazione senza sistemare ciò che ti interessava, e mobile e desktop producono risultati di laboratorio separati.
Per iterare più velocemente, esegui Lighthouse in locale invece di aspettare PSI. La categoria è in Lighthouse 13.3 e successivi, quindi un'installazione locale la include. Se vuoi la versione nel pannello DevTools, la documentazione di Google nota che testare la categoria richiede Chrome 150 o successivo, e le verifiche WebMCP richiedono anche l'origin trial registrato.
Tieni un breve registro del prima e dopo. Una riga datata come "2026-09-11: mobile 1/3, falliti albero a11y + llms.txt" basta. Ti dice se una regressione successiva è reale o solo un'oscillazione tra esecuzioni.
Cosa non è questo controllo
Tre cose che non fa, perché la confusione è diffusa:
- Non è un fattore di posizionamento. L'annuncio di Chrome definisce la categoria informativa e non benchmarkata. Il posizionamento su Google Search non è influenzato dalla tua frazione di Agentic Browsing.
- Non è un punteggio di visibilità AI. Misura se un agente riesce a usare la tua pagina. Non dice nulla sul fatto che ChatGPT o Perplexity ti citino in una risposta.
- Non è un verdetto pass/fail sul tuo sito. Una frazione bassa su una semplice pagina marketing di solito significa che c'era poco da valutare, non che gli agenti siano bloccati fuori.
La lente che aiuta: questa categoria controlla se il tuo sito regge quando il visitatore non è umano. Tutto ciò che premia vale comunque la pena farlo: HTML semantico, layout stabili, controlli etichettati. Le linee guida di Google per i siti agent-friendly chiudono sullo stesso punto: ciò che rende un sito pronto per gli agenti lo rende migliore anche per le persone.
Tienilo nel tuo ciclo di revisione
La prontezza per gli agenti è una di quelle aree in cui la piattaforma si muove più velocemente della checklist. Due abitudini ti tengono aggiornato senza trasformarlo in un progetto:
- Riesegui il controllo dopo ogni modifica a template, navigazione, moduli o checkout. Sono le modifiche che spostano l'albero di accessibilità e la stabilità del layout.
- Monitora la frazione per template, non per URL. Dieci pagine prodotto che segnano tutte allo stesso modo sono un problema di template, e una correzione risolve tutte e dieci.
Il controllo PSI è volutamente stretto: sei verifiche, una pagina alla volta. Se vuoi il quadro più ampio, compreso se regole robots, schede server MCP, discovery OAuth e segnali di commercio agentico sono a posto, Auspia mantiene un controllo di Agent Readiness gratuito che analizza un URL rispetto a quegli standard a livello di protocollo e mostra una classifica per il confronto.
FAQ
Il punteggio Agentic Browsing influisce sul posizionamento su Google? No. Google descrive la categoria come informativa e non fa parte dei sistemi di ranking di Search. Trattala come un controllo di prontezza per gli agenti, non come un punteggio SEO.
Perché la mia frazione è cambiata tra due esecuzioni sulla stessa pagina? La registrazione dinamica degli strumenti, le modifiche al DOM che alterano l'albero di accessibilità e gli spostamenti di layout tardivi causano variabilità tra esecuzioni. Riprova e confronta l'elenco delle verifiche, non solo la frazione.
Perché tutte e tre le verifiche WebMCP risultano non applicabili? Perché la tua pagina non registra strumenti WebMCP. È lo stato atteso per la maggior parte dei siti nel 2026 e non è un fallimento.
Un llms.txt mancante è un problema? Per questa verifica, no. Un 404 è trattato come non applicabile. Un file che esiste ma è malformato fallisce, quindi se ne pubblichi uno, pubblicalo correttamente.
Posso eseguirlo in CI? Sì, quando la categoria è nella tua versione di Lighthouse. Le verifiche sono deterministiche per progettazione, ed è ciò che le rende adatte ai controlli in pipeline. Tieni presente che le parti WebMCP dipendono dal supporto del browser e dall'iscrizione all'origin trial, quindi aspettati che risultino non applicabili nella maggior parte degli ambienti CI.
Serve Chrome 150 per usarlo? No. PageSpeed Insights lo esegue lato server. Il requisito di Chrome 150 riguarda l'esecuzione della categoria in locale in DevTools.
Autore: Alice Monroe, analista di strumenti AI SEO che copre oltre 150 strumenti su Auspia. Alice scrive di SEO e strumenti di ricerca AI, di quali controlli valgono il tuo tempo e di come inserirli in una routine di lavoro.
