WebMCP e la Navigazione agentica: cosa misura la nuova sezione di PageSpeed Insights

Da qualche mese in fondo ai report di PageSpeed Insights compare una sezione nuova, “Navigazione agentica”, che misura quanto un sito è pronto per gli agenti AI e convalida le integrazioni di un protocollo chiamato WebMCP.

Per quasi tutti i siti, oggi, i controlli WebMCP risultano “Non applicabile”: è la condizione normale, e in questo articolo spiego perché. Ma “normale” non significa “da ignorare”: dietro quei tre controlli grigi c’è il primo tentativo di Google di misurare una cosa che finora nessuno misurava, cioè quanto un sito è utilizzabile da un software che agisce per conto di un utente.

Nelle prossime sezioni spiego cos’è WebMCP e come funziona, cosa verificano davvero i tre controlli, che effetti ha su SEO e visibilità nei motori AI, e se conviene muoversi già adesso.

Da quando esiste la categoria “Navigazione agentica”

La categoria è arrivata con Lighthouse 13.3.0, rilasciata il 7 maggio 2026: le note di rilascio su GitHub la annunciano come “New agentic browsing category added to default config” e dichiarano l’arrivo nei DevTools di Chrome 150 e “su PageSpeed Insights entro 2 settimane”¹. Non esiste un annuncio puntuale del giorno esatto in cui la sezione è comparsa in PSI: la finestra ufficiale è metà/fine maggio 2026.

A differenza delle altre categorie di Lighthouse, questa non produce un punteggio da 0 a 100. Mostra una frazione, il numero di controlli superati sul totale, e la scelta è motivata nero su bianco nella documentazione: gli standard del web agentico sono ancora in formazione, e “l’obiettivo attuale è raccogliere dati e fornire segnali su cui agire, non una classifica definitiva”². La stessa descrizione che si legge in PSI dichiara che la categoria “è ancora in fase di sviluppo e soggetta a modifiche”. È una misura sperimentale, e va trattata come tale.

I controlli della categoria sono sei: tre riguardano WebMCP e sono il tema di questo articolo; gli altri tre (albero di accessibilità ben formato, stabilità del layout, presenza di llms.txt) verificano lavoro che la SEO tecnica conosce già. Del check su llms.txt, e del curioso rapporto tra Lighthouse e quel file, ho scritto nell’articolo dedicato.

Cos’è WebMCP

WebMCP (Web Model Context Protocol) è una proposta di standard web che dovrebbe permettere a un sito di esporre le proprie funzionalità come “tool” strutturati per gli agenti AI: form HTML oppure funzioni JavaScript, ciascuno con una descrizione in linguaggio naturale e uno schema che dichiara quali dati servono in ingresso³.

Il ribaltamento concettuale è questo: oggi un agente AI che deve compiere un’azione su un sito “guarda” la pagina come farebbe una persona, tra screenshot, HTML e albero di accessibilità, e interpreta. Deve indovinare quale campo vuole il nome e quale il cognome, quale bottone conferma e quale annulla, e a ogni redesign l’interpretazione si rompe. Con WebMCP è il sito a dichiarare cosa si può fare: “qui c’è un tool che si chiama cerca_voli, vuole una partenza, una destinazione e una data, e restituisce risultati strutturati”. Semrush l’ha riassunto con l’immagine più efficace che ho letto: il sito diventa un’API per gli agenti, senza che tu debba costruire e mantenere un’API separata[^4].

Dietro la proposta non c’è un esperimento solitario di Google: WebMCP è incubato nel Web Machine Learning Community Group del W3C e ci lavorano i team di Chrome e di Edge³. Va detto con precisione: un Community Group è un luogo di incubazione, non un percorso di standardizzazione formale; “standard proposto” significa che tutto può ancora cambiare.

Quanto allo stato di avanzamento, la sostanza è questa: oggi WebMCP non è attivo per il pubblico. Esiste solo dentro la origin trial, l’esperimento a tempo con cui Chrome prova le funzioni nuove: il proprietario di un sito si iscrive, attiva WebMCP sulle sue pagine e lo prova con i visitatori reali. Su tutti gli altri siti la funzione non esiste. Le date dicono quanto tutto sia giovane: annuncio dell’anteprima a febbraio 2026, documentazione pubblica a maggio, esperimento aperto il 9 giugno con chiusura già fissata a Chrome 156, sette versioni più avanti⁴. Al ritmo di Chrome, una versione nuova circa ogni mese, significa indicativamente fino a inizio 2027.

Le due API: dichiarativa e imperativa

WebMCP offre due strade per definire i tool³.

La via dichiarativa: si annotano form HTML esistenti con due attributi, toolname e tooldescription, e il browser traduce da solo i campi del form in uno schema strutturato per l’agente. Un form di prenotazione, semplificando l’esempio della documentazione:

<form toolname="prenota_tavolo"
      tooldescription="Prenota un tavolo indicando data, ora e coperti">
  <input type="date" name="data" required>
  <input type="time" name="ora" required>
  <input type="number" name="coperti" required>
  <button type="submit">Prenota</button>
</form>

È la via a basso costo: se il sito ha già form HTML puliti, con campi nominati e label sensate, renderli leggibili a un agente è questione di attributi.

La via imperativa: si registrano tool via JavaScript con la nuova interfaccia navigator.modelContext, indicando nome, descrizione, schema degli input e la funzione da eseguire. Serve per le interazioni dinamiche, e ha una proprietà interessante: i tool possono comparire e sparire in base allo stato della pagina, per esempio un tool di checkout che esiste solo quando il carrello non è vuoto[^4]. L’agente vede sempre e solo ciò che ha senso nel contesto corrente.

WebMCP e MCP: che differenza c’è

Sono complementari, non concorrenti: MCP è un’integrazione di backend tra un agente e un server, WebMCP vive dentro la scheda del browser. Il sito che usa WebMCP si può pensare come un piccolo server MCP incorporato nelle sue pagine³.

La riga dell’autenticazione è quella che cambia i giochi pratici: un tool WebMCP opera dentro la sessione dell’utente già autenticato, con il suo carrello e le sue preferenze, senza replicare credenziali su un server terzo[^4].

Cosa verificano i tre controlli WebMCP

I nomi che si leggono in PSI sono traduzioni dall’inglese, e almeno una è ambigua. Il codice sorgente dei tre controlli, però, è pubblico⁵ e chiarisce subito la cosa più importante: due controlli su tre sono puramente informativi e non possono bocciare nulla; uno solo ha un esito positivo o negativo.

Copertura del modulo WebMCP

Prima cosa da sapere: “modulo” qui traduce l’inglese form. Il nome originale è “WebMCP form coverage” e il controllo riguarda i form HTML della pagina, non un “modulo software”.

Cosa fa: elenca i form della pagina che non hanno le annotazioni dichiarative (toolname e tooldescription), suggerendo di aggiungerle. Nel codice l’audit è marcato come informativo: non fallisce mai, qualunque cosa trovi; al massimo mostra la lista dei form scoperti⁵. Risulta “Non applicabile” in tre casi: la pagina non ha form, il browser di test non supporta WebMCP, oppure tutti i form sono già annotati.

Strumenti WebMCP registrati

È un inventario. Elenca i tool WebMCP registrati sulla pagina al momento dell’analisi, divisi tra imperativi (con la posizione nel sorgente JavaScript che li ha registrati) e dichiarativi (con l’elemento DOM corrispondente), ciascuno con nome, descrizione e schema di input. Anche questo è informativo: fotografa, non giudica⁵.

Una sfumatura da conoscere se un giorno implementerai dei tool: la fotografia dipende dal momento dello scatto. Lighthouse guarda la pagina in un istante preciso, e un tool che il JavaScript registra più tardi, per esempio solo quando il carrello si riempie, in quell’istante non c’è ancora: il report ne mostra meno di quanti il sito ne abbia, e due test sulla stessa pagina possono dare elenchi diversi. La documentazione cita proprio questo caso tra le cause dei risultati che cambiano da una rilevazione all’altra².

Gli schemi WebMCP sono validi

L’unico dei tre che può bocciare, ed è il controllo di qualità dell’implementazione. L’audit fallisce (punteggio 0) in presenza di errori, cioè toolname mancante sul form, tooldescription mancante, o attributo name mancante su un campo obbligatorio. Si ferma a metà (0,5) con soli warning, come le descrizioni mancanti sui campi. Passa (1) se tutto è pulito⁵.

La ragione d’essere è semplice: uno schema incompleto o ambiguo costringe l’agente a tornare a indovinare, che è esattamente il problema che WebMCP vuole eliminare. Il controllo non premia chi ha WebMCP, misura se chi ce l’ha lo ha fatto bene.

Perché vedi “Non applicabile” (e perché va bene così)

“Non applicabile” significa che l’API WebMCP non è attiva nel browser che esegue il test. Nel codice, tutti e tre gli audit restituiscono quell’esito quando il supporto WebMCP non c’è, e il supporto oggi c’è solo per i siti iscritti alla origin trial o con il flag sperimentale attivo⁵. Dato che la quasi totalità dei siti non è iscritta, la quasi totalità dei report mostra “Non applicabile”. La nota nella documentazione della categoria conferma i requisiti: per testare la categoria serve Chrome 150 o successivi, e per gli audit WebMCP serve la registrazione alla origin trial².

Il punto importante è che non essere pronti per WebMCP non penalizza. Un controllo non applicabile non conta come bocciato: viene proprio tolto dal totale. La categoria ha sei controlli, ma nel report del mio sito, più sopra, i tre WebMCP sono grigi e il conteggio si fa solo sugli altri tre: per questo la frazione dice 3/3, non 3/6.

Il caso del link “rotto” della origin trial

C’è un dettaglio che può far pensare a un progetto già abbandonato, e merita di essere chiarito. La versione italiana della documentazione linka la pagina di registrazione alla origin trial con un URL che risponde 404: chi clicca conclude che la pagina non esista più. La pagina esiste. L’URL canonico, con la barra prima del cancelletto (developer.chrome.com/origintrials/#/register_trial/…), risponde regolarmente; è la variante generata dalla doc localizzata, con il parametro ?hl=it inserito nel punto sbagliato, a rispondere 404. Un link malformato nella traduzione, non una origin trial sparita (verificato il 31 luglio 2026).

Come provare WebMCP oggi

Per toccare con mano non serve la origin trial, basta una macchina di test:

1. Attiva il flag: chrome://flags/#enable-webmcp-testing, poi riavvia Chrome³.
2. Installa l’estensione Model Context Tool Inspector dal Chrome Web Store: mostra i tool registrati su qualunque pagina, permette di invocarli a mano e di dialogare in linguaggio naturale per vedere se un agente li userebbe correttamente. Un dettaglio di trasparenza: i prompt dell’inspector vengono inviati di default a un modello Gemini³.
3. Apri le demo ufficiali di GoogleChromeLabs: un configuratore di pizze e una ricerca voli per l’API imperativa, un ristorante per quella dichiarativa³.

Per attivare WebMCP sul proprio sito con utenti reali, invece, la strada è l’iscrizione alla origin trial, finché resta aperta. Può farlo chiunque, senza costi. Ci si registra sulla pagina ufficiale delle origin trial di Chrome, la stessa del link “rotto” di cui sopra, indicando il proprio dominio. In cambio si riceve un token, un codice da inserire nelle proprie pagine, e da quel momento Chrome attiva WebMCP per i visitatori del sito⁶.

WebMCP ha un impatto sulla SEO?

A oggi non c’è alcuna evidenza che la categoria “Navigazione agentica” o WebMCP influiscano sul posizionamento su Google. Nessun documento ufficiale lo suggerisce, e la natura stessa della categoria lo rende improbabile nel breve: è sperimentale, non produce nemmeno un punteggio, e Google la descrive come raccolta di segnali².

Aggiungo il contesto che do sempre quando si parla di Lighthouse: è uno strumento di laboratorio. Nemmeno il punteggio Performance è mai stato un fattore di ranking diretto; ciò che entra nei sistemi di Google sono i Core Web Vitals misurati sugli utenti reali, che sono un’altra cosa. Trattare una frazione sperimentale di controlli superati come un fattore di posizionamento significherebbe scambiare una diagnosi di laboratorio per un segnale di ranking.

E la visibilità sui motori AI (GEO/AEO)?

WebMCP non riguarda l’essere citati nelle risposte di ChatGPT, Perplexity, Gemini, Claude e Google AI Overviews: riguarda l’essere utilizzabili dagli agenti che devono completare un compito sul sito. È un canale di azione, non di contenuto, e conviene tenere le due cose distinte quando si decidono le priorità.

La lettura che se ne può dare è quella di uno stack che si allarga: finora l’ottimizzazione per i motori generativi ha inseguito menzioni e citazioni; WebMCP aggiunge un piano sopra, l’operabilità. E i due piani si alimentano in un ordine preciso: un agente deve prima scoprire il tuo brand, di solito attraverso gli stessi meccanismi di ricerca e citazione di oggi, per poi arrivare a usare il tuo sito. Essere citati oggi è la condizione per essere “eseguiti” domani[^4].

C’è anche un limite strutturale che ridimensiona le aspettative di breve periodo: i tool WebMCP si scoprono solo visitando la pagina, con un browser visibile; la documentazione esclude esplicitamente i browser “headless”, quelli senza finestra usati dai sistemi automatici³. Ne beneficiano quindi gli agenti che navigano davvero, a partire da quelli integrati nei browser, non i sistemi che oggi generano le risposte citando fonti.

La mia posizione, a oggi: non esiste alcuna correlazione misurata tra tool WebMCP esposti e presenza nelle risposte dei motori AI, e chi sostiene il contrario sta anticipando i fatti.

Conviene adottarlo adesso? Casi d’uso, pro e contro

I casi d’uso che Google porta come esempio sono concreti: un e-commerce dove l’agente trova il prodotto, configura le opzioni e attraversa il checkout; una ricerca voli dove filtra e prenota su dati strutturati; un ticket di assistenza compilato con tutti i dettagli tecnici al posto dell’utente; i form complessi dove un tool distingue senza ambiguità il campo “nome e cognome” dai campi separati⁴.

I pro sono la ragione d’essere del protocollo: l’attuazione guidata dai tool è più affidabile e più veloce dell’interpretazione dell’interfaccia, l’esecuzione resta visibile nella pagina (l’utente vede cosa sta succedendo), la sessione è quella dell’utente autenticato, e sulla via dichiarativa il costo di ingresso è basso.

I contro vanno pesati altrettanto seriamente. Lo standard è ancora una bozza e può cambiare, e la origin trial, per sua natura, è un esperimento con una scadenza. Il costo di ingresso basso vale solo per i form semplici: un’interfaccia complessa va riprogettata, non annotata con due attributi. E soprattutto si apre una superficie di sicurezza nuova. Finché l’agente legge soltanto, un suo errore produce al massimo una risposta sbagliata. Quando può agire, lo stesso errore diventa un ordine, una prenotazione, un dato spedito. E l’errore si può indurre: l’agente decide in base ai testi che legge, e un testo scritto ad arte può spingerlo a usare un tool nel modo sbagliato. Google per prima prende il rischio sul serio: ha pubblicato una guida agli attacchi contro gli agenti e ha messo limiti tecnici dentro l’API⁷. Qui la prudenza non è pessimismo.

Su come muoversi, il mio consiglio è netto: sperimentare sì, mettere in produzione flussi critici no. Non è scetticismo, è una questione di ordine: si impara su una pagina di prova, e solo quando lo standard sarà stabile si toccano i percorsi da cui passa il fatturato, come un checkout.

Cosa fare oggi, concretamente

• Curare le fondamenta: HTML semantico, label chiare, form puliti, layout stabile. Sono le stesse cose della checklist di leggibilità AI.
• Censire le azioni chiave: cosa viene a fare un utente sul sito (un preventivo, una prenotazione, una ricerca) e quanto lo capirebbe una macchina, campo per campo.
• Per chi sviluppa, provare: flag, inspector e una pagina di test costano un pomeriggio.
• Tenere d’occhio la origin trial: come evolve, e se compaiono agenti che usano davvero i tool.

Nessuna urgenza: oggi non si “perde” nulla a non avere WebMCP. Il vantaggio andrà a chi si farà trovare preparato quando lo standard si stabilizza, non a chi corre adesso.

Il tema tocca in pieno il lavoro che faccio su SEO e GEO/AEO, e continuerò a seguirlo nelle sue evoluzioni. Se intanto vuoi capire come è messo il tuo sito sul fronte che conta già oggi, dalla leggibilità AI alla citabilità nelle risposte dei motori generativi, ti racconto come lavoro oppure scrivimi.

Fonti

1. Le release notes di Lighthouse v13.3.0 (7 maggio 2026): github.com ↩

2. Google, “Lighthouse agentic browsing scoring”, documentazione ufficiale della categoria (ultimo aggiornamento 5 maggio 2026): developer.chrome.com ↩ ↩² ↩³ ↩⁴

3. L’explainer della proposta WebMCP nel Web Machine Learning Community Group del W3C: github.com; la documentazione ufficiale di Chrome, con limitazioni, sicurezza, flag di test, estensione inspector e demo (pubblicata il 18 maggio 2026): developer.chrome.com[^4]: Leigh McKenzie, “WebMCP: What It Is, Why It Matters, and What to Do Now”, Semrush (11 marzo 2026): semrush.com ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

4. L’annuncio dell’anteprima: André Cipriani Bandarra, “WebMCP is available for early preview”, blog di Chrome (10 febbraio 2026): developer.chrome.com; l’annuncio della origin trial e i casi d’uso: Alexandra Klepper, “Join the WebMCP origin trial”, blog di Chrome (9 giugno 2026): developer.chrome.com; la finestra Chrome 149-156 è dichiarata nell’Intent to Experiment su blink-dev: groups.google.com ↩ ↩²

5. Il codice sorgente dei tre audit nel repository di Lighthouse: webmcp-form-coverage.js, webmcp-registered-tools.js, webmcp-schema-validity.js; la configurazione della categoria (sei audit, pass ratio): agentic-browsing-config.js ↩ ↩² ↩³ ↩⁴ ↩⁵

6. La guida ufficiale di Chrome alle origin trial, che le dichiara “public and open to all developers” e spiega registrazione e uso del token: developer.chrome.com ↩

7. Google, “Agent security considerations for WebMCP”: developer.chrome.com; i requisiti di origin isolation e la permissions policy tools sono documentati nella pagina ufficiale di WebMCP: developer.chrome.com ↩