Screenshot e visione
Il modello interpreta gerarchie visive, testo, icone e posizione dei controlli. Sovrapposizioni, componenti trasparenti e cambi di layout possono però rendere ambigua l’azione.
Apri la fonteGuide
Il tuo sito è pronto per gli agenti AI? Come rendere pagine, moduli e checkout utilizzabili
Gli assistenti non si limitano più a leggere e riassumere pagine. Possono cercare un servizio, confrontare alternative, compilare moduli e tentare di completare un’attività. Un sito può essere indicizzato benissimo e restare comunque inutilizzabile quando a navigarlo è un agente.
La risposta breve
Un sito è pronto per gli agenti AI quando le informazioni sono trovabili, la struttura è comprensibile, le azioni hanno nomi e stati espliciti e le operazioni sensibili restano controllate. Servono HTML semantico, layout stabile, moduli etichettati, feedback verificabili, prestazioni e sicurezza. Non serve inseguire ogni nuovo protocollo: WebMCP è una possibile estensione, non la fondazione e non una garanzia di utilizzo.
Gian Luca Partengo
Sviluppatore web dal 1995 · siti su misura · Aggiornato il
“Agent‑ready” non è un bollino: è una catena che deve funzionare
La qualità non si misura chiedendo a un chatbot se il sito gli piace. Si verifica attraversando quattro livelli, nell’ordine.
- 01Trovabile: pagine pubbliche, URL stabili, collegamenti e contenuti possono essere raggiunti.
- 02Comprensibile: titoli, regioni, controlli, dati e relazioni hanno un significato esplicito.
- 03Azionabile: pulsanti, link, campi e flussi funzionano con input affidabili e stati osservabili.
- 04Controllato: autorizzazioni, conferme, validazione e registri limitano errori e abusi.
Un agente può vedere screenshot, DOM e accessibility tree
Non esiste una sola modalità di navigazione. I sistemi moderni possono combinare l’aspetto visivo della pagina con la sua struttura tecnica.
HTML e struttura della pagina
Elementi, attributi, testo e relazioni permettono di distinguere navigazione, contenuto e controlli. Un div cliccabile resta molto meno esplicito di un vero pulsante.
Apri la fonteAccessibility tree
Browser e tecnologie assistive espongono nomi, ruoli, valori e stati. La stessa struttura può offrire agli agenti segnali più stabili dell’aspetto grafico.
Apri la fonteLa conseguenza pratica
Progettare soltanto per l’occhio umano o soltanto per il crawler è insufficiente. L’interfaccia, l’HTML e l’albero di accessibilità devono descrivere la stessa azione.
Essere presenti nelle risposte AI non significa essere utilizzabili dagli agenti
SEO, GEO e usabilità agentica si toccano, ma rispondono a domande differenti.
Trovabile
Il contenuto è raggiungibile tramite URL, link e sitemap; non è nascosto dietro interazioni fragili o aree che il sistema non può aprire.
Comprensibile
La pagina risponde in modo chiaro, mostra relazioni e condizioni e usa dati coerenti. Questo aiuta ricerca, citazioni e decisioni.
Azionabile
Il sistema può identificare un controllo, inserire dati, procedere e verificare se l’azione è riuscita o deve essere corretta.
Governato
L’agente non ottiene più potere del necessario; i passaggi irreversibili richiedono conferma e il server resta l’autorità finale.
L’HTML semantico è già un’interfaccia per persone, browser e agenti
Prima di aggiungere manifest o API, conviene descrivere correttamente ciò che esiste nella pagina.
Principio tecnico
Usa l’elemento nativo che rappresenta l’azione
Un collegamento porta a una risorsa; un pulsante avvia un’azione; un campo raccoglie un valore; heading e landmark definiscono la gerarchia. Queste differenze sono informazione, non stile.
ARIA può integrare componenti complessi, ma non rende automaticamente corretto un elemento costruito male. Nome, ruolo, valore e stato devono restare coerenti con ciò che accade davvero.
Link reali e descrittivi
Ogni navigazione usa un href valido e un nome che descrive la destinazione, evitando decine di “clicca qui” indistinguibili.
Pulsanti reali
Invio, apertura, aggiunta e conferma usano button, funzionano da tastiera e comunicano lo stato disabilitato o occupato.
Gerarchia e landmark
Un solo h1, titoli ordinati e regioni come header, nav, main e footer aiutano a delimitare contenuto e funzioni.
Nomi, ruoli e stati
Etichette visibili e nomi accessibili coincidono; menu, tab, dialog e toggle espongono apertura, selezione e valore corrente.
Un layout prevedibile evita che l’agente agisca sul bersaglio sbagliato
La stabilità non è soltanto Core Web Vitals: è continuità fra ciò che il sistema osserva e ciò su cui tenta di intervenire.
Navigazione coerente
Menu, breadcrumb e azioni principali restano riconoscibili tra le pagine, con nomi e posizioni che non cambiano senza motivo.
Controlli visibili
Il bersaglio ha testo o un nome esplicito, dimensioni adeguate e non è coperto da overlay, banner o elementi invisibili.
Interfaccia stabile
Immagini, font e contenuti dinamici riservano spazio. Il pulsante non si sposta mentre l’agente sta decidendo dove agire.
Dialog governabili
Modali e pannelli hanno titolo, focus corretto, chiusura comprensibile e non nascondono il contenuto senza un percorso di uscita.
Un modulo compilabile spiega cosa chiede, in quale formato e perché
Placeholder e posizione visiva non bastano. Ogni campo deve conservare la propria identità prima, durante e dopo la compilazione.
Regola di progetto
Il campo deve poter essere interpretato senza indovinare
Un label associato identifica il controllo; fieldset e legend raggruppano scelte correlate; tipo, autocomplete e istruzioni rendono espliciti formato e finalità.
La validazione nel browser migliora l’esperienza, ma il server deve convalidare ogni dato. Un agente può sbagliare o essere manipolato quanto un utente e non deve aggirare le regole applicative.
Etichette persistenti
Ogni input ha un label visibile e correttamente associato. Il placeholder resta un esempio, non l’unico nome del campo.
Formato e completamento
Tipo di dato, unità, vincoli e autocomplete aiutano a distinguere email, telefono, indirizzo, quantità e dati di pagamento.
Gruppi e dipendenze
Radio, checkbox e campi condizionali spiegano la relazione. Quando una scelta apre altri campi, il cambiamento è annunciato e prevedibile.
Invio non ambiguo
Il pulsante descrive l’effetto reale — invia richiesta, salva bozza, continua al pagamento — e impedisce invii duplicati durante l’elaborazione.
Senza stati, errori e conferme osservabili l’agente non sa se ha finito
Un cambio di colore o un messaggio che scompare troppo presto possono essere invisibili al sistema e poco chiari anche per una persona.
Caricamento
L’interfaccia comunica che l’operazione è in corso, blocca duplicazioni e mantiene il controllo associato alla richiesta.
Errore specifico
Il problema è collegato al campo o al passaggio corretto, spiega come risolverlo e non cancella dati già validi.
Esito verificabile
Una conferma persistente, un numero pratica o un nuovo stato permettono di distinguere il successo da una semplice animazione.
Passo successivo
La pagina indica cosa è avvenuto, cosa succederà e quale azione resta disponibile senza costringere a dedurlo dal contesto.
Evita il falso successo
La risposta HTTP, lo stato applicativo e il messaggio visibile devono raccontare la stessa realtà. Una notifica verde non prova che il server abbia registrato l’operazione.
Carrello e checkout sono un test end‑to‑end, non una collezione di pulsanti
Un agente deve attraversare prezzi, varianti, disponibilità, identità, spedizione, pagamento e conferma senza incontrare dati contraddittori.
-
01
Prodotto e variante
Nome, identificatore, prezzo, valuta, disponibilità e opzione scelta restano coerenti dalla scheda al carrello.
-
02
Carrello autorevole
Quantità, sconti, imposte e subtotali vengono ricalcolati dal server; modifiche e rimozioni producono un nuovo stato osservabile.
-
03
Costi prima dell’impegno
Spedizione, commissioni, rinnovi e condizioni essenziali compaiono prima che l’utente confermi o fornisca il pagamento.
-
04
Identità e indirizzo
Campi, autocomplete, paesi, province e validazione gestiscono dati reali senza intrappolare l’utente in errori generici.
-
05
Conferma esplicita
L’azione irreversibile ha importo e conseguenze visibili. L’agente non dovrebbe acquistare soltanto perché ha trovato un pulsante disponibile.
-
06
Ordine e recupero
L’esito fornisce identificatore, riepilogo e istruzioni; timeout e ritentativi non devono creare ordini o addebiti duplicati.
Accessibilità e compatibilità agentica condividono fondamenta, non equivalenza
La stessa semantica che aiuta una persona con tecnologie assistive può rendere l’interfaccia più leggibile per un agente. Gli obiettivi, però, non coincidono.
Distinzione necessaria
Un sito agent‑ready non è automaticamente conforme alle WCAG
HTML nativo, nomi accessibili, focus visibile, tastiera, istruzioni ed errori chiari migliorano entrambi i perimetri. Sono buone fondamenta, non una certificazione.
La conformità richiede criteri, livello, pagine campione, contenuti, test manuali e tecnologie assistive definiti rispetto al progetto e alla norma applicabile.
Tastiera
Azioni e sequenza di focus funzionano senza puntatore, senza trappole e con un indicatore sempre visibile.
Nome accessibile
Controlli e immagini informative comunicano uno scopo significativo anche quando l’elemento visivo non viene interpretato.
Stato programmabile
Espanso, selezionato, non valido, occupato e disabilitato sono esposti nel codice e aggiornati insieme all’interfaccia.
Contenuti comprensibili
Titoli, istruzioni e messaggi sono diretti, coerenti e non dipendono soltanto da colore, forma o posizione.
Per obblighi, esenzioni, WCAG e servizio di verifica consulta la guida completa su accessibilità dei siti web.
Più un agente può fare, più il sito deve limitare ciò che può sbagliare
Il contenuto della pagina, le risposte di strumenti esterni e perfino istruzioni apparentemente legittime possono tentare di deviare l’obiettivo dell’agente.
Minimo privilegio
Ogni funzione vede e modifica soltanto i dati necessari. Un agente che cerca disponibilità non riceve permessi per cambiare prezzi o utenti.
Conferma delle conseguenze
Acquisti, invii, pubblicazioni, cancellazioni e cambi irreversibili mostrano oggetto, importo ed effetto prima dell’esecuzione.
Validazione server
Ruoli, quantità, prezzi, destinazioni e input vengono verificati sul server. Il DOM e il client non sono una fonte autorevole.
Idempotenza e limiti
Token idempotenti, rate limit e protezioni contro replay evitano che ritentativi e loop producano duplicazioni o abuso.
Output non fidato
Testo, pagine, file e risposte di tool vengono trattati come dati, non come istruzioni da eseguire automaticamente.
Log e interruzione
Operazioni, errori, autorizzazioni e identità sono tracciabili; il sistema può fermare, annullare o recuperare un flusso anomalo.
La regola pratica
Non progettare assumendo che l’agente “si comporterà bene”. Progetta assumendo errori, input ostili, obiettivi deviati e tentativi ripetuti.
Per patch, infrastruttura, applicazione e monitoraggio approfondisci la sicurezza di un sito web.
Velocità e stabilità riducono timeout, tentativi e ambiguità
Un sito lento costa attenzione alle persone e cicli operativi agli agenti. La velocità utile nasce da un sistema più semplice, non da un punteggio isolato.
HTML subito disponibile
Contenuto, navigazione e azioni essenziali arrivano nella risposta iniziale quando possibile, senza dipendere da catene fragili di JavaScript.
Dipendenze contenute
Script, tag, font e componenti esterni sono ridotti e governati. Meno terze parti significano meno blocchi, variazioni e superfici di errore.
Stato conservato
Ricariche, errori e ritorni non cancellano inutilmente carrello o dati validi; sessioni e scadenze sono spiegate e recuperabili.
Risposte affidabili
Timeout, errori HTTP e ritentativi sono gestiti in modo coerente, distinguendo problemi temporanei da esiti definitivi.
WebMCP può esporre strumenti strutturati, ma oggi resta una tecnologia emergente
L’idea è permettere alla pagina di dichiarare funzioni che un agente può scoprire e chiamare senza ricostruirle soltanto dall’interfaccia visiva.
Azioni con schema
Nome, descrizione, parametri ed esito trasformano una funzione del sito in uno strumento più esplicito per l’agente.
Apri la fonteDichiarativo o imperativo
Le proposte descrivono sia moduli arricchiti sia strumenti JavaScript per flussi complessi, mantenendo l’interfaccia umana.
Apri la fonteBozza, non standard stabile
Il documento è un Draft Community Group Report e non una Raccomandazione W3C. API, disponibilità e comportamento possono ancora cambiare.
Apri la fonteProgressive enhancement
Prima deve funzionare il sito accessibile e sicuro. WebMCP si valuta poi per attività ripetibili e ad alto valore, con un’alternativa umana completa e senza promettere compatibilità universale.
Audit agent‑ready: 20 controlli prima di parlare di integrazioni
Il test deve usare pagine e attività reali, non una demo costruita apposta per riuscire.
Scoperta e comprensione
- Le pagine importanti hanno URL pubblici, canonical e collegamenti interni.
- Titolo, h1 e contenuto spiegano scopo, destinatario e condizioni.
- Menu, breadcrumb e main sono riconoscibili nel DOM.
- Dati visibili e strutturati raccontano la stessa realtà.
- Contenuto essenziale non dipende da interazioni o script fragili.
Controlli e moduli
- Link e pulsanti usano elementi nativi e nomi univoci.
- Ogni campo ha label, tipo, formato e istruzioni utili.
- Focus, tastiera, dialog e menu funzionano senza puntatore.
- Errori sono specifici, collegati e correggibili.
- Invio, caricamento e successo producono stati osservabili.
Flusso e affidabilità
- Prezzi, disponibilità e riepiloghi restano coerenti.
- Il server convalida dati, ruolo e conseguenze.
- Refresh, ritorni e timeout non perdono dati validi.
- I ritentativi non duplicano invii, ordini o pagamenti.
- L’esito finale ha identificatore e istruzioni persistenti.
Sicurezza e governo
- Azioni sensibili chiedono una conferma esplicita.
- Permessi e dati seguono il minimo privilegio.
- Output esterni non diventano istruzioni fidate.
- Rate limit, idempotenza e log coprono le operazioni.
- Esiste un modo per fermare, annullare e recuperare.
Metodo GLP: fondamenta robuste prima delle funzioni agentiche
La preparazione parte dal sito reale e dal valore dell’attività. Non aggiungo tecnologia emergente soltanto per poterla nominare in un preventivo.
-
01
Definizione delle attività
Individuo cosa una persona o un agente dovrebbe trovare, confrontare, compilare o completare e quali passaggi hanno conseguenze.
-
02
Audit della base
Verifico HTML, accessibilità strutturale, contenuti, moduli, stati, performance e sicurezza sulle pagine pubblicate.
-
03
Correzione dei flussi
Rendo comprensibili controlli, errori, riepiloghi e conferme senza creare una seconda interfaccia riservata alle AI.
-
04
Prove manuali end‑to‑end
Eseguo attività reali da tastiera, con tecnologie assistive pertinenti e con scenari di errore, recupero e doppio invio.
-
05
Valutazione dell’integrazione
Solo se utile confronto WebMCP, API o altri strumenti con costi, compatibilità, sicurezza, manutenzione e alternativa umana.
-
06
Monitoraggio e manutenzione
Controllo errori e cambiamenti del sito o degli standard, perché un flusso operativo può deteriorarsi anche senza cambiare URL.
| Livello | Perimetro | Stato | Prezzo |
|---|---|---|---|
| Sito su misura | Semantica, tastiera, focus, moduli etichettati, prestazioni, sicurezza e tema light/dark | Fondamenta incluse nei pacchetti sito | Incluso |
| Preferenze accessibilità | Pannello base e supporto alla riduzione delle animazioni, disattivabile insieme al tema | Incluso, non certificazione | Incluso |
| Conformità WCAG | Perimetro, adeguamenti, test automatici e manuali, tecnologie assistive, report e 12 mesi | Pacchetto opzionale documentato | Da 1.800 € |
| WebMCP, API o agenti | Analisi, progettazione, sicurezza, sviluppo, test e manutenzione dell’integrazione concordata | Sviluppo avanzato separato | Quotato ad hoc |
Nessuna soluzione costituisce certificazione automatica, garanzia di conformità legale o promessa che un agente userà o completerà il sito. Il prezzo dipende da pagine, funzioni, rischi e perimetro concordato.
Approfondisci come apparire su ChatGPT e nelle AI, come preparare un e-commerce allo shopping AI oppure consulta i servizi e prezzi dei siti su misura.
Fonti primarie verificate
Le capacità degli agenti e le proposte WebMCP evolvono rapidamente. Le fonti distinguono fondamenta consolidate, indicazioni di prodotto e specifiche ancora in bozza.
-
web.dev — Build agent-friendly websitesApri la fonte
Screenshot, DOM, accessibility tree, controlli semantici, layout stabile e interfacce prevedibili.
-
Google Search Central — Generative AI optimizationApri la fonte
Fondamenti SEO, crawl, testo, page experience, dati strutturati e tecnologie emergenti per agenti.
-
web.dev — The accessibility treeApri la fonte
Come browser e tecnologie assistive derivano ruoli, nomi, stati e proprietà dal DOM.
-
W3C WAI — Labeling controlsApri la fonte
Etichette esplicite, associazione label-for, nomi accessibili e controlli dei moduli.
-
W3C WAI — User notificationsApri la fonte
Feedback, errori, successo e notifiche che restano percepibili e associati al contesto.
-
W3C — Web Content Accessibility Guidelines 2.2Apri la fonte
Criteri verificabili per contenuti percepibili, utilizzabili, comprensibili e robusti.
-
Chrome for Developers — WebMCPApri la fonte
Panoramica della proposta, strumenti dichiarativi e imperativi e sperimentazione nel browser.
-
Web Machine Learning CG — WebMCP draftApri la fonte
Specifica tecnica e stato di Draft Community Group Report, non Raccomandazione W3C.
-
Chrome for Developers — Agent securityApri la fonte
Rischi delle azioni in sessioni autenticate, istruzioni ostili, permessi e protezione degli utenti.
-
OWASP GenAI — Agentic AI securityApri la fonte
Goal hijack, uso improprio degli strumenti, privilegi eccessivi, prompt injection indiretta e controlli difensivi.
Fonti controllate il 28 luglio 2026. WebMCP è una proposta in evoluzione: verificare stato, supporto dei browser, rischi e specifiche prima di implementarla.
Domande frequenti
Risposte dirette per separare fondamenta concrete, tecnologie emergenti e promesse che oggi non si possono fare.
Che cosa significa davvero “sito pronto per gli agenti AI”?
Significa che contenuti e funzioni sono trovabili, comprensibili e azionabili attraverso strutture esplicite, mentre autorizzazioni, conferme e validazione governano le conseguenze. Non è un marchio o una certificazione ufficiale.
Un sito ben posizionato su Google è già agent‑ready?
Non necessariamente. SEO e GEO aiutano la scoperta e la comprensione, ma un agente può ancora bloccarsi su controlli non semantici, moduli senza label, errori invisibili o flussi incoerenti.
Serve WebMCP per rendere un sito utilizzabile dagli agenti?
No. HTML semantico, accessibilità strutturale, moduli chiari, stati osservabili, prestazioni e sicurezza sono la base. WebMCP può diventare un’estensione per attività definite, ma al 28 luglio 2026 resta una proposta in evoluzione.
Agent‑ready significa conforme alle WCAG?
No. Le due qualità condividono molte fondamenta, ma la conformità WCAG richiede un perimetro e verifiche specifiche. Una buona compatibilità agentica non sostituisce un audit di accessibilità.
Basta aggiungere ARIA a div e componenti personalizzati?
No. Va preferito l’HTML nativo. ARIA aggiunge nomi, ruoli, proprietà o stati quando necessario, ma non ricrea automaticamente tastiera, focus e comportamento corretti.
Un agente può compilare qualsiasi modulo?
No. Dipende dal sistema, dai permessi e dalla qualità del modulo. Label, tipi, autocomplete, istruzioni, errori e conferme aumentano l’affidabilità ma non garantiscono il completamento.
Posso lasciare che un agente completi un acquisto senza conferma?
È una scelta ad alto rischio. Importo, oggetto e conseguenza dovrebbero essere mostrati prima dell’azione irreversibile; il server deve verificare autorizzazione, prezzi e idempotenza.
I dati strutturati rendono il sito azionabile?
No. Rendono entità e proprietà più esplicite per i sistemi che li usano, ma non sostituiscono controlli, moduli, stati applicativi, API o sicurezza.
Un sito scritto a mano è automaticamente migliore per gli agenti?
No. Il vantaggio nasce dal controllo sul risultato: HTML pulito, dipendenze contenute, semantica, prestazioni e flussi verificabili. Anche il codice su misura deve essere progettato e testato bene.
Quanto costa rendere un sito agent‑ready?
Dipende da pagine, moduli, checkout, autenticazione, rischi e integrazioni. Le fondamenta strutturali sono incluse nei nuovi siti su misura; audit WCAG parte da 1.800 €, mentre WebMCP, API e funzioni agentiche vengono quotati separatamente.
Puoi garantire che ChatGPT o un altro agente userà il sito?
No. Posso migliorare compatibilità, chiarezza, sicurezza e verificabilità, ma scelta del sito, disponibilità degli strumenti e completamento dipendono dall’agente, dal browser e dai servizi coinvolti.
Da dove conviene iniziare su un sito esistente?
Da tre attività reali ad alto valore: trovare un’informazione, inviare un modulo e completare il flusso commerciale principale. Si verificano DOM, tastiera, stati, errori, performance e sicurezza prima di aggiungere nuovi protocolli.
Prossimo passo
Vuoi capire se il tuo sito è davvero utilizzabile, non soltanto visibile?
Partiamo dalle attività che contano: analizzo struttura, moduli, stati, prestazioni e sicurezza e ti dico cosa correggere prima di investire in integrazioni agentiche.