Google ha aggiunto la navigazione agentica a Lighthouse: cosa significa per l'accessibilità digitale

Gli agenti IA non sono più uno scenario futuro. Già oggi navigano, confrontano prodotti e completano acquisti per conto di persone reali. E Google ha appena reso ufficiale un passaggio importante: da Lighthouse 13.3, rilasciato a maggio 2026, il suo strumento di audit open source include una nuova categoria sperimentale chiamata Agentic Browsing.

Non è uno di quegli aggiornamenti tecnici che i team di sviluppo annotano e dimenticano. È un segnale sulla direzione che sta prendendo il web. E per chi lavora seriamente sull'accessibilità digitale negli e-commerce e nei servizi online, è anche una buona notizia: sei più avanti di quanto pensi.

Cos'è la categoria Agentic Browsing di Lighthouse?

Lighthouse misura già quattro aree: performance, conformità alle Web Content Accessibility Guidelines (WCAG), SEO e best practice. Agentic Browsing ne aggiunge una quinta, con una domanda tanto semplice quanto decisiva: un agente IA riesce davvero a usare il tuo sito?

A differenza del punteggio da 0 a 100 delle categorie Performance o Accessibilità, Agentic Browsing non assegna un voto ponderato. Mostra invece quanti controlli il sito supera sul totale, lo stato di ogni singolo requisito tecnico e alcuni conteggi informativi che danno una panoramica rapida della preparazione complessiva.

Su un punto Google è chiara: gli standard del web agentico sono ancora in fase di definizione. La categoria è contrassegnata come sperimentale e non incide ancora sul ranking. Oggi vale soprattutto come indicazione di direzione, un quadro utile da capire prima che diventi lo standard.

I quattro controlli: cosa testano e cosa significano

Agentic Browsing raccoglie quattro controlli, ognuno con un grado di maturità diverso. Vale la pena vederli uno per uno, perché il primo è anche quello più vicino al lavoro di accessibilità che molti team hanno già avviato.

1. L'albero di accessibilità: il controllo più vicino al lavoro già fatto

È il più maturo dei quattro, e quello più direttamente legato alle pratiche di accessibilità che molti team hanno già avviato.

Gli agenti IA non vedono una pagina come la vede una persona. La leggono attraverso l'albero di accessibilità, cioè la rappresentazione strutturata e semantica di tutti i contenuti e gli elementi interattivi, che il browser genera a partire dal codice HTML. La documentazione di Google lo descrive come il modello di dati primario degli agenti.

È un meccanismo familiare, perché è lo stesso albero su cui si basano gli screen reader. Un pulsante privo di nome accessibile è invisibile per chi usa uno screen reader, e lo è allo stesso modo per un agente IA che prova a completare un'azione. Vale lo stesso per i campi modulo senza etichetta, per i ruoli ARIA (Accessible Rich Internet Applications) annidati male e per una gestione difettosa del focus da tastiera.

Lighthouse seleziona un sottoinsieme dei criteri WCAG più critici per l'interazione automatica: ogni elemento interattivo deve avere un nome programmatico, ruoli e relazioni tra elementi devono essere validi, e nessun contenuto interattivo deve restare nascosto all'albero di accessibilità.

La conseguenza è semplice: se il tuo team ha investito in HTML semantico e in un markup ARIA corretto per servire le persone con disabilità, quel lavoro si traduce subito in siti pronti per gli agenti. È lo stesso percorso visto da una nuova angolazione.

2. Stabilità del layout (CLS): perché le pagine instabili fanno fallire gli agenti

Il Cumulative Layout Shift (CLS) è un Core Web Vital dal 2020 e misura quanto gli elementi di una pagina si spostano durante il caricamento. Entra ora in Agentic Browsing per un motivo preciso: un layout instabile non è solo fastidioso per le persone, è un problema funzionale per gli agenti.

Se un agente IA individua un pulsante e la pagina si sposta prima che riesca a interagire, l'agente fa clic sull'elemento sbagliato o si blocca del tutto. Per un agente che porta a termine azioni al posto di una persona, come una prenotazione, l'invio di un modulo o un acquisto, non è un piccolo intoppo: è il fallimento dell'intera operazione.

Le cause più comuni sono immagini senza dimensioni definite, font che si caricano dopo il primo rendering e contenuti inseriti sopra la piega da script di terze parti. Il report Core Web Vitals in Google Search Console e la scheda Performance di Lighthouse aiutano a individuare questi problemi.

3. llms.txt: una nuova convenzione da conoscere

Accanto a robots.txt, usato dai crawler di ricerca, e a sitemap.xml, usato per l'indicizzazione, c'è ora una terza convenzione da conoscere: llms.txt. Posizionato nella root del dominio (ad esempio https://tuodominio.it/llms.txt), questo file Markdown offre ai grandi modelli di linguaggio (LLM) e agli agenti IA un riepilogo sintetico e strutturato dello scopo del sito e dei suoi contenuti principali.

Lighthouse verifica la presenza del file. Se manca e il server risponde con un 404, il controllo risulta non applicabile, perché per ora il file è facoltativo. Viene invece segnalato quando il server restituisce un errore nel tentativo di leggerlo.

La convenzione sta guadagnando terreno, ma la maggior parte dei siti non ha ancora un llms.txt, ed è del tutto normale. Creare una versione di base richiede meno di un'ora: un file Markdown nella root che descrive l'attività e rimanda alle pagine chiave. È l'intervento col minor sforzo e, allo stesso tempo, il segnale più chiaro disponibile oggi.

4. WebMCP: lo standard emergente da tenere d'occhio

Il Web Model Context Protocol (WebMCP) è una API del browser, ancora sperimentale, che permette a un sito di dichiarare in modo esplicito le proprie funzionalità agli agenti IA. Invece di lasciare che l'agente deduca dal contesto cosa fa un pulsante, WebMCP glielo comunica direttamente, con definizioni leggibili dalle macchine collegate a moduli ed elementi interattivi.

Ci sono due modi per registrarle:

1. uno dichiarativo, con gli attributi toolname e tooldescription sugli elementi HTML <form>,

2. uno imperativo via JavaScript con navigator.modelContext.registerTool, pensato per registrazioni più dinamiche.

Lo standard è ancora in pieno sviluppo, quindi la maggior parte dei siti non supererà questo controllo, ed è esattamente ciò che Google si aspetta. Più che correre, conviene prepararsi: fai ora un inventario dei moduli e delle interazioni principali (richieste demo, iscrizioni, checkout, contatti), così il team sarà pronto quando la specifica sarà matura.

Perché tutto questo va oltre il tema tecnico

Agentic Browsing è un aggiornamento tecnico, ma con implicazioni di business molto concrete.

Nell'e-commerce e nei servizi finanziari, gli agenti IA per lo shopping e gli assistenti finanziari sono già operativi. Quando una persona delega un'azione a un agente, per esempio cercare un prodotto o confrontare offerte, è l'agente a navigare al suo posto. Un sito con moduli senza etichetta, layout instabili e una struttura poco leggibile dalle macchine diventa più difficile da usare, e questa frizione si traduce in conversioni perse, non solo in cattiva esperienza utente.

Nel SaaS e nel B2B, gli acquirenti enterprise usano sempre più strumenti di valutazione basati sull'IA per analizzare i fornitori prima ancora che entri in gioco una persona. Un sito ordinato, ben etichettato e stabile comunica maturità tecnica e affidabilità.

Anche il legame con gli obblighi normativi è diretto. Le Linee guida AgID pubblicate il 4 marzo 2026 hanno reso operativi in Italia gli obblighi dell'European Accessibility Act, recepito con il D.Lgs. 82/2022 e in vigore dal 28 giugno 2025. Il riferimento tecnico resta WCAG 2.1 livello AA. Agentic Browsing punta nella stessa direzione: un sito accessibile è già un sito pronto per gli agenti. È, di fatto, lo stesso lavoro.

Come eseguire l'audit in Chrome

La categoria è semplice da provare in autonomia, quando è disponibile nella tua versione di Chrome. Ecco i passaggi principali, dall'apertura di Lighthouse alla lettura dei risultati.

Aprire Lighthouse in DevTools

Quando la categoria Agentic Browsing è disponibile nella tua versione di Chrome o di Lighthouse:

1. Apri la pagina che vuoi testare.

2. Apri Chrome DevTools (F12 oppure clic destro, poi Ispeziona).

3. Vai al pannello Lighthouse.

In alcune build sperimentali può servire Chrome Canary o un feature flag per vedere le nuove categorie. Se non trovi Agentic Browsing, è probabile che la funzione non sia ancora disponibile nella tua build.

Attivare la categoria Agentic Browsing

Nel pannello Lighthouse puoi scegliere quali categorie eseguire. Quando Agentic Browsing è disponibile, attiva la casella accanto a Performance, Accessibility, SEO e alle altre. Poi:

1. Scegli il tipo di dispositivo (Mobile o Desktop), perché layout e comportamento possono cambiare.

2. Se vuoi, attiva il throttling per simulare condizioni più realistiche.

3. Fai clic su Analizza caricamento pagina.

L'audit eseguirà una nuova navigazione della pagina includendo i controlli di Agentic Browsing.

Leggere il pass ratio e i singoli controlli

Quando il report è pronto, vedrai:

• un indicatore riassuntivo per Agentic Browsing;

• l'elenco dei controlli superati, che confermano la compatibilità con gli agenti in aree specifiche;

• l'elenco dei controlli falliti o non applicabili, ciascuno con dettagli e talvolta snippet di codice.

Per ottenere risultati coerenti, mantieni stabili le condizioni di test: usa sempre lo stesso URL e gli stessi parametri, disattiva dove possibile test A/B e contenuti casuali, ed esegui gli audit sulla stessa versione di Chrome con le stesse impostazioni. Tieni presente che piccole variazioni di CLS o di timing possono far oscillare leggermente i punteggi tra un'esecuzione e l'altra.

Come interpretare i risultati

Non tutti i problemi pesano allo stesso modo sul business di oggi. Conviene dare priorità a:

• la salute dell'albero di accessibilità, che incide sulle tecnologie assistive e sui punteggi Lighthouse Accessibility attuali;

• la stabilità del layout (CLS e simili), già al centro dell'ottimizzazione delle performance;

• i problemi critici di interazione, cioè pulsanti, moduli o navigazione non individuabili o non cliccabili in modo affidabile.

I controlli a bassa priorità e ancora sperimentali, come un llms.txt mancante o il manifest WebMCP, contano più per la preparazione futura che per il traffico o il ranking di oggi.

Dall'obbligo normativo all'infrastruttura del web

Per molto tempo l'accessibilità digitale è stata letta soprattutto come un obbligo normativo, qualcosa da affrontare perché lo chiede la legge. Agentic Browsing sposta il punto di vista. Se gli agenti IA usano la stessa mappa semantica delle tecnologie assistive, il lavoro sull'accessibilità smette di essere un adempimento da spuntare e diventa parte dell'infrastruttura del web moderno.

I team che hanno già costruito esperienze digitali accessibili non sono solo in regola con la normativa: sono in anticipo sulla prossima fase del web. E chi gestisce l'accessibilità come pratica continua, con una piattaforma di accessibilità digitale, è nella posizione migliore per restarci.

In fondo, un web accessibile è un web che funziona per tutte le persone, e oggi anche per gli agenti che agiscono in loro nome.