PageSpeed Insights e da anni uno dei punti di riferimento per chi fa SEO tecnica, performance engineering e audit di qualita. Google lo presenta come uno strumento che unisce dati reali del Chrome User Experience Report e dati di laboratorio generati da Lighthouse, quindi non misura solo la velocita percepita ma anche la leggibilità operativa del sito in un contesto controllato.
La novita piu interessante delle ultime settimane non e un nuovo Core Web Vital, ma una nuova famiglia di controlli in Lighthouse e nella UI di PSI dedicata alla navigazione agentica. In pratica Google e il team Chrome stanno iniziando a verificare se una pagina e comprensibile, stabile e azionabile anche da agenti AI, non soltanto da un browser tradizionale o da un utente umano.
Cosa cambia davvero in PageSpeed Insights
La base di PageSpeed Insights non cambia: il report continua a mostrare i dati sul campo di CrUX e i dati di laboratorio di Lighthouse. Questo significa che la nuova sezione non sostituisce LCP, INP, CLS o gli audit SEO classici, ma si aggiunge come nuovo strato di lettura del sito.
La release note ufficiale di PSI conferma che il servizio e stato aggiornato a Lighthouse 13 il 20 ottobre 2025, mentre la documentazione Chrome pubblicata il 5 maggio 2026 descrive una nuova categoria chiamata Agentic Browsing. In altre parole, il terreno tecnico era gia pronto con Lighthouse 13, ma la narrativa pubblica sugli audit per agenti e diventata esplicita solo dopo.
Per chi pubblica contenuti o gestisce un e-commerce, il cambiamento concettuale e importante: non stai più verificando solo se una pagina carica in fretta, ma anche se un agente capisce dove cliccare, cosa leggere, quali campi compilare e con quali regole. E un passaggio da performance pura a operabilita per agenti, cioe la capacita del sito di farsi interpretare correttamente da software che agiscono al posto dell utente.
Come viene valutata la nuova categoria agentica
La documentazione ufficiale chiarisce un punto che molti leggeranno male al primo colpo: la categoria Agentic Browsing non usa un punteggio pesato da 0 a 100. Il motivo e semplice: gli standard del web agentico sono ancora emergenti, quindi Google e Chrome preferiscono fornire segnali operativi e non una classifica definitiva da ottimizzare a colpi di vanity metric.
Al posto del voto classico, il report mostra un rapporto fra controlli superati e controlli previsti, piu eventuali stati pass/fail e conteggi informativi. Questo spiega perche nella UI puoi vedere valori come 0/3, 3/3 o simili: non e un nuovo score SEO, ma un indicatore di readiness rispetto a una batteria di verifiche specifiche per agenti.
La stessa pagina di scoring avvisa anche che la categoria e il supporto WebMCP sono sperimentali e basati su standard proposti. Per questo ha senso usare questi audit come bussola tecnica e non come metrica assoluta: oggi servono a capire dove il sito puo confondere un agente, domani potrebbero evolvere o diventare piu granulari.
- Non c’è un punteggio 0-100 dedicato alla navigazione agentica.
- Conta quanti controlli passi e quali controlli falliscono.
- Gli audit sono sperimentali e soggetti a modifica.
I quattro blocchi che PageSpeed Insights sta iniziando a controllare
La documentazione ufficiale divide di fatto questa nuova area in quattro blocchi pratici: integrazione WebMCP, accessibilita per agenti, discoverability tramite llms.txt e stabilita del layout. Insieme formano una checklist molto piu concreta di quanto sembri, perche toccano elementi già noti a chi fa audit: markup semantico, file in root, gestione dei form, stabilità visiva e affidabilità dell’interfaccia.
Per leggere bene questi audit bisogna cambiare prospettiva. Un agente non ha il buon senso visivo di una persona che capisce un pulsante dal contesto grafico. Se il nome accessibile manca, se un campo e ambiguo, se la pagina si sposta mentre l agente decide dove cliccare o se la logica del form non e esposta in modo strutturato, l errore non e cosmetico: e funzionale.
| Controllo | Che cosa verifica | Perche conta per un agente | Problema tipico |
|---|---|---|---|
| llms.txt | Presenza o recuperabilità del file nella root del dominio. | Riduce il lavoro di crawling esplorativo e chiarisce struttura e link chiave. | Errore server sul file oppure file assente se il team voleva usarlo. |
| Albero di accessibilita | Completezza dei nomi e dei ruoli esposti nella accessibility tree. | L’agente usa questa vista per capire gli elementi interattivi. | Pulsanti senza etichetta o struttura ARIA incoerente. |
| Layout stability / CLS | Stabilità visiva e spostamenti di layout. | Gli agenti possono basarsi su coordinate o screenshot. | Un bottone si sposta mentre l agente sta per cliccare. |
| WebMCP | Registrazione e validita di tool dichiarativi o imperativi. | Espone in modo esplicito form, azioni e stato della pagina. | Form complessi senza tool o schema poco chiaro. |
llms.txt non e obbligatorio, ma ora e diventato visibile negli audit
La pagina ufficiale dedicata all audit llms.txt spiega che si tratta di una convenzione emergente per offrire una sintesi machine-readable del sito pensata per LLM e agenti AI. L’idea non e sostituire sitemap o navigazione, ma dare una mappa corta: cosa fa il sito, quali sono le sezioni principali e quali link meritano attenzione.
C’è un dettaglio operativo importante: se il file non esiste e il server restituisce 404, Lighthouse considera il controllo non applicabile, perche oggi il file resta opzionale. Se invece il tool prova a recuperarlo e incontra un errore server, l’audit viene segnalato come problema. Quindi il messaggio non e devi avere llms.txt a tutti i costi, ma se hai deciso di esporlo, deve essere servito bene.
Per un sito editoriale questo cambia l’approccio. Non serve pubblicare un manifesto lungo o autoreferenziale: basta una sintesi concisa in Markdown con la funzione del sito, le aree principali e i percorsi utili. Un esempio semplice e un blog SEO che indica homepage, archivio guide, categoria audit, pagina contatti e risorsa piu importante del momento. La convenzione e giovane, ma il costo di implementazione e basso e l utilita come segnale di discoverability e concreta.
- Il file va nella root del dominio, ad esempio /llms.txt.
- Se torna 404, il controllo puo finire in N/A perche oggi e opzionale.
- Se torna errore server, l audit viene segnalato come problema.
Accessibilita e stabilità visiva non sono solo temi UX
La pagina Accessibility for agents dice chiaramente che molti principi di accessibilita, nati per le persone, sono utili anche agli agenti che vogliono capire un sito. Il punto chiave e l’accessibility tree: se ruoli, etichette e relazioni non sono completi, sia un utente assistito sia un agente software possono perdere il contesto dell azione da compiere.
Questo significa che errori apparentemente minori, come un bottone senza nome accessibile o una relazione ARIA incoerente, smettono di essere solo warning da audit e diventano ostacoli all esecuzione di task. Un agente puo vedere un elemento cliccabile, ma non sapere se sia Cerca, Invia, Prosegui o Acquista, e quindi fermarsi o scegliere male.
La pagina sulla layout stability aggiunge un altro tassello: molti agenti si appoggiano a screenshot o a interazioni basate su coordinate. Se il layout si sposta, il rischio non e solo un CLS peggiore nel report, ma il click nel posto sbagliato. E il caso tipico di banner, immagini senza dimensioni, widget che entrano tardi o box pubblicitari che spingono in basso il contenuto proprio mentre un agente ha gia localizzato il target.
Esempio reale facile da immaginare
Pensa a un form di richiesta preventivo in cui il tasto finale si sposta dopo il caricamento di un banner cookie o di un modulo esterno. Un utente umano corregge il gesto quasi senza pensarci. Un agente che aveva deciso di cliccare alle coordinate precedenti puo invece colpire il link sbagliato o ricominciare la procedura. In questo scenario CLS, accessibilita e chiarezza del form non sono tre problemi separati: sono lo stesso problema osservato da tre angoli diversi.
WebMCP e la parte piu nuova, ma non serve ovunque
La pagina ufficiale WebMCP lo definisce come uno standard proposto per esporre strumenti strutturati agli agenti AI nel browser. In pratica aggiunge JavaScript e annotazioni ai form HTML, in modo che l agente non debba inferire tutto da testo, layout e tentativi, ma possa sapere con precisione quali azioni esistono, quali input si aspettano e quale stato ha la pagina.
Qui il vantaggio non e teorico. Chrome spiega che WebMCP puo aumentare affidabilita e performance dell’actuation, cioè l’esecuzione di azioni nel browser per conto dell utente. I casi d’uso citati sono supporto clienti, prenotazioni complesse, form strutturati e persino funzioni di diagnostica in aree nascoste dell’interfaccia.
Detto questo, non tutti i siti devono correre subito ad adottarlo. Se hai un blog semplice, pagine editoriali e poche interazioni, il guadagno immediato puo essere modesto. Se invece hai procedure a piu step, moduli ambigui, date picker, checkout articolati o pannelli con logica difficile da inferire, allora WebMCP puo diventare una forma di progressive enhancement molto sensata.
- Non è una scorciatoia SEO.
- è una tecnologia per esporre in modo strutturato azioni e stato del sito.
- Ha più valore su interfacce complesse che su pagine puramente informative.
Che impatto ha su SEO, GEO e workflow editoriali
Google non presenta questi audit come un nuovo fattore di ranking. La mia lettura, basata sulla documentazione ufficiale, e che oggi si tratti soprattutto di un set di segnali operativi per misurare la readiness del sito verso gli agenti, non di un punteggio SEO da inseguire come si fa con i Core Web Vitals.
L’impatto SEO, quindi, è per ora indiretto. Un sito con albero di accessibilità pulito, layout stabile, form piu espliciti e un eventuale llms.txt ben servito tende anche a essere piu ordinato da mantenere, più semplice da capire e meno fragile nelle interazioni. Questo migliora la qualità tecnica generale del progetto, ma non equivale a dire che domani Google Search premi automaticamente il tuo llms.txt.
Sul fronte GEO e citabilita AI il discorso e ancora piu delicato. Nella documentazione ufficiale non c’è alcuna indicazione di vantaggi diretti nelle AI Overviews o in altre superfici generative. Però emerge una direzione chiara: siti piu strutturati, con segnali piu espliciti e interfacce meno ambigue, sono siti più facili da usare per software che devono leggere, riassumere o agire. Per un editore o un team SEO questo non e una scorciatoia, ma una forma di preparazione tecnica al web che verra.
Cosa fare oggi se gestisci un sito
La mossa giusta non e inseguire tutti i check alla cieca. Prima va capito se il tuo sito ha gia problemi classici che ricadono anche nella lettura agentica: componenti senza nome accessibile, form poco chiari, pulsanti generici, modali che spostano il layout, immagini senza dimensioni o widget che arrivano tardi. In molti casi il primo guadagno non arriva da WebMCP, ma da una base HTML e UX piu solida.
Subito dopo ha senso decidere se llms.txt sia utile per il tuo progetto. Per un piccolo sito locale magari no. Per una documentazione tecnica, un catalogo, un blog specialistico o un software con molte sezioni puo invece diventare una scorciatoia utile per spiegare il perimetro del sito e ridurre il rumore di navigazione.
WebMCP va considerato come terzo step, non come primo. Prima semantica, poi stabilita, poi discoverability, e solo dopo esposizione strutturata degli strumenti. E questo, in fondo, e il messaggio più pragmatico dei nuovi audit di PageSpeed Insights: un sito pronto per gli agenti nasce dagli stessi principi che rendono il sito migliore anche per le persone, solo applicati con un livello di esplicitezza piu alto.
- Controlla accessibilita e nomi accessibili degli elementi interattivi.
- Riduci i layout shift che possono spostare target e pulsanti.
- Valuta se un llms.txt essenziale abbia senso per il tuo dominio.
- Pensa a WebMCP solo se hai task o form davvero complessi.