Il modo in cui le persone interagiscono con il web cambia sotto i nostri occhi e la trasformazione in corso non riguarda soltanto l'interfaccia grafica o le abitudini di navigazione. Gli assistenti basati su grandi modelli linguistici iniziano a operare sul web in rappresentanza degli utenti: leggono pagine, confrontano prodotti, compilano form, in alcuni casi autorizzano pagamenti. Il fenomeno prende il nome di web agentico e ridefinisce il perimetro di ciò che un sito deve saper fare. Se fino a ieri il successo di un progetto digitale si misurava sulla capacità di catturare lo sguardo umano con un layout curato, adesso entra in gioco una dimensione diversa, quella della capacità di esporre informazioni e azioni in un formato che un agente automatico comprende senza ambiguità.
La figura che emerge da questo scenario è il machine customer, un consumatore software che agisce per conto di una persona o di un'azienda, riceve obiettivi, budget e vincoli e li traduce in operazioni concrete. Non prova fiducia emotiva, non si lascia persuadere da un banner lampeggiante, non valuta la sfumatura di colore di un pulsante. Cerca dati, li verifica, li confronta. Quando il sito non espone ciò che serve nel modo giusto, l'agente può passare al concorrente senza che l'utente umano se ne accorga. Per chi gestisce un ecommerce, una piattaforma B2B o un sito di lead generation, questa dinamica tocca direttamente la pipeline commerciale.
Proiezione illustrativa della ripartizione tra transazioni umane e transazioni guidate da agenti AI. I dati esemplificativi non rappresentano rilevazioni di mercato documentate. Passa il mouse sui punti per leggere le percentuali.
In questo articolo trovi una bussola tecnica e strategica per orientarti. Parliamo di Agent Experience, Search Experience Optimization, dei protocolli emergenti per il commercio agentico e delle best practice di sviluppo supportate dalla documentazione tecnica attuale. L'obiettivo non è convincerti che il web agentico rappresenti il futuro. L'obiettivo è mostrarti cosa puoi fare fin da subito, con strumenti verificabili e cosa invece appartiene ancora al terreno delle ipotesi da validare. Se gestisci un progetto digitale e vuoi capire da dove iniziare, prosegui nella lettura.
In questo approfondimento
Dall'UX all'AX: cosa cambia davvero
L'UX classica progetta per occhi umani e lo fa da oltre vent'anni seguendo metriche consolidate come il tasso di conversione, il tempo sulla pagina e la profondità di scroll. L'AX progetta per agenti che interpretano il codice e agiscono sulla base di ciò che il codice dichiara. In questo articolo utilizziamo il termine AX per indicare l'insieme delle pratiche di progettazione che rendono un sito utilizzabile da un agente autonomo. Non si tratta di uno standard formalizzato, quanto di un'etichetta editoriale che raccoglie sotto un'unica voce interventi tecnici diversi.
La differenza rispetto all'UX non è una sfumatura lessicale: cambia il criterio con cui si valuta se una pagina funziona. Un agente browser moderno può utilizzare una combinazione di DOM, accessibility tree, screenshot, testo e stato della pagina per orientarsi. Non puoi assumere che la gerarchia visiva progettata per una persona costituisca da sola un'interfaccia machine-readable affidabile. Il problema non è che l'agente non vede il colore del bottone: il problema è che i segnali visivi non bastano a garantire che l'agente riconosca l'azione, la comprenda e la esegua nel modo previsto.
Da questa premessa nasce un cambio di paradigma anche sul piano strategico.
La persuasione visiva non perde valore, ma deve convivere con segnali machine-readable che la rendono verificabile. L'utente che delega la scelta a un agente fornisce budget, tempi, preferenze e condizioni e si aspetta che il sistema trovi la soluzione migliore. In questo contesto la pagina smette di essere soltanto un imbuto emotivo e diventa anche un'interfaccia di negoziazione basata su informazioni verificabili.
Qui entra in gioco la SXO, un approccio che unisce SEO, UX e CRO per soddisfare contemporaneamente l'intento umano e quello agentico. Come per AX, anche in questo caso utilizziamo SXO come termine di settore, non come standard tecnico codificato. La SXO organizza contenuti, dati strutturati, percorsi di conversione e prove di fiducia in un unico sistema coerente.
La fine del funnel persuasivo visivo
Il funnel tradizionale lavora sulla leva emotiva: scarsità, urgenza, prova sociale, autorità percepita. Un banner che annuncia "solo due camere rimaste" produce un effetto reale su una persona che sta decidendo dove passare il weekend. Un agente può verificare la disponibilità effettiva, il prezzo, le condizioni di cancellazione, i tempi di check-in e confrontare questi dati con quelli di altre strutture.
Se il sito non espone queste informazioni in formato leggibile, l'agente può rimuovere l'offerta dalla rosa delle opzioni, oppure può tentare un percorso alternativo, oppure può chiedere chiarimenti all'utente. Il comportamento varia da agente ad agente e da contesto a contesto. Ciò che conta è che la pressione psicologica non produce alcun effetto se non è supportata da informazione strutturata.
Questo cambio di scenario non significa che il copywriting perda valore. Significa che il copy deve convivere con dati che lo confermano o lo smentiscono. La trasparenza diventa un criterio di credibilità: il sito dichiara cosa vende, a quale prezzo, con quali tempi entro quali vincoli.
Il team marketing continua a raccontare valore, ma il team tecnico espone i dati che rendono quel valore verificabile. La coerenza tra messaggio, dati e codice determina il successo. Un'agenzia che lavora su conversione e dati trova in una consulenza CRO il punto di partenza per misurare l'attrito reale e intervenire sui colli di bottiglia che possono bloccare anche gli agenti.
Chi sono i machine customer e come operano
Un machine customer è un agente software che agisce per conto di una persona o di un'azienda e riceve un mandato operativo con obiettivi, budget e vincoli. Il termine è utilizzato nel dibattito enterprise per descrivere soggetti non umani che effettuano acquisti. Valuta le informazioni disponibili su API, DOM, dati strutturati e policy e le confronta con i vincoli del task eventualmente attraverso tool e servizi esterni. Non prova fiducia emotiva, cerca prove concrete: recensioni verificate, certificazioni, tempi di consegna garantiti, condizioni di reso chiare, disponibilità aggiornata.
Il livello di autonomia varia e definisce requisiti tecnici diversi. Nel primo stadio l'agente si comporta come suggeritore, propone opzioni all'utente e aspetta una decisione umana. Nel secondo stadio esegue l'operazione ma richiede approvazione esplicita prima di concludere. Nel terzo stadio compra in autonomia entro un budget prefissato. Ogni stadio richiede garanzie tecniche diverse e il sito che supporta solo il primo limita la propria esposizione commerciale rispetto a chi abilita il terzo.
La tabella seguente riassume i tre stadi e i requisiti associati.
| Stadio di autonomia | Comportamento dell'agente | Requisiti tecnici del sito |
|---|---|---|
| Suggeritore | Propone opzioni all'utente e attende la scelta | Dati leggibili, confronto, prezzo, disponibilità aggiornata |
| Esecutore | Prepara carrello e checkout, chiede conferma prima di pagare | Checkout assistito, mandati di spesa, log delle operazioni, conferma esplicita |
| Autonomo | Compra entro un budget prefissato senza intervento umano | Protocolli di pagamento, autorizzazione, policy, audit trail, revoca del mandato |
La differenza tra UX e AX si vede soprattutto in questo passaggio. L'utente umano tollera un clic in più, un campo aggiuntivo, un breve caricamento. Un agente può avere un timeout più breve, oppure può tentare strategie alternative. L'esito dipende dal tipo di agente, dal runtime, dal task e dalla stabilità dell'interfaccia. Il team di sviluppo lavora su semantica, API e dati strutturati mentre il team marketing lavora su offerta, contenuto e fiducia. Il risultato è un sito che serve persone e agenti con lo stesso livello di cura, senza che l'uno escluda l'altro.
Lo stato degli standard del web agentico
Il web agentico è un cantiere aperto e una guida tecnica seria non può presentare come consolidato ciò che è ancora in evoluzione. Alcune specifiche sono concrete e documentate, altre sono proposte in early preview, altre ancora sono etichette di settore prive di formalizzazione. Questa distinzione è essenziale per capire dove investire oggi e cosa monitorare nei prossimi mesi.
Universal Commerce Protocol (UCP) è un protocollo aperto promosso da Google per il commercio agentico, con documentazione pubblica che descrive profili, capability, checkout, fulfillment e order lifecycle.
AP2 è una specifica che definisce mandati, autorizzazione e meccanismi crittografici per i pagamenti autonomi e si integra con UCP.
WebMCP è una proposta di standard web, attualmente in early preview e origin trial su Chrome, che permette a una pagina di registrare tool strutturati che un agente può scoprire e invocare.
Schema.org è uno standard consolidato per i dati strutturati, ma le sue azioni come BuyAction non costituiscono un protocollo di esecuzione.
| Standard o termine | Stato attuale | Funzione | Maturità |
|---|---|---|---|
| UCP | Protocollo aperto con documentazione pubblica | Commercio agentico: catalogo, checkout, fulfillment, ordini | In evoluzione, implementazioni in corso |
| AP2 | Specifica v0.2 con mandati e ruoli definiti | Sicurezza e autorizzazione dei pagamenti agentici | In evoluzione, integrata con UCP |
| WebMCP | Proposta di standard early preview, origin trial | Esposizione di tool strutturati agli agenti | Sperimentale |
| Schema.org Actions | Standard consolidato | Descrizione semantica di azioni potenziali | Maturo, ma non è un protocollo di esecuzione |
| AX, SXO, Agent-Trapping | Terminologia di settore | Concetti e pratiche editoriali | Non standardizzati |
L'architettura invisibile: protocolli e specifiche
Gli agenti hanno bisogno di contratti chiari, perché ogni loro azione poggia su un'interfaccia che qualcuno ha progettato. I protocolli del web agentico definiscono come un sito espone catalogo, disponibilità, carrello e pagamento e stabiliscono quali informazioni l'agente può usare per decidere e quali operazioni può eseguire.
Universal Commerce Protocol (UCP) di Google struttura il commercio per agenti, mentre AP2 gestisce autorizzazioni e pagamenti. I mandati autorizzano un agente a operare entro limiti concordati e il protocollo prevede meccanismi di delega che, a seconda dell'implementazione, possono esonerare l'utente dall'inserire i dati della carta a ogni acquisto. L'agente presenta una richiesta firmata, il sito verifica il mandato, l'importo e il merchant e il pagamento procede. Il merchant mantiene il controllo su regole e antifrode e il protocollo supporta meccanismi di revoca del mandato, la cui esperienza concreta dipende dall'implementazione del merchant e del credential provider.
UCP e AP2: commercio e pagamenti per agenti
UCP è un protocollo aperto che definisce un linguaggio comune per il commercio agentico. Il business pubblica un profilo UCP in un file JSON accessibile pubblicamente, che dichiara capability, versioni, endpoint e configurazione dei pagamenti. Google negozia le capability con il server del merchant e instrada le richieste verso gli endpoint dichiarati. Il protocollo copre checkout, fulfillment, gestione degli ordini e applicazione di sconti e prevede un ciclo di vita dell'ordine con webhook per gli aggiornamenti di stato.
AP2 opera come livello di sicurezza all'interno di un protocollo di commercio come UCP. La specifica v0.2 definisce cinque ruoli: Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor e Trusted Surface. Definisce inoltre due tipi di mandato: il Checkout Mandate, che fornisce al merchant la prova crittografica che l'agente è autorizzato a completare il checkout che ha assemblato e il Payment Mandate, che autorizza il pagamento su uno strumento specifico ed è condiviso con il Credential Provider, le reti e il processore di pagamento del merchant. La terminologia precedente utilizzava il termine "Cart Mandate", che la documentazione corrente sostituisce con Checkout Mandate. I mandati possono essere utilizzati come evidenza in caso di disputa.
Il valore di questo meccanismo sta nella governance dei mandati, che diventa parte integrante del prodotto e non un'aggiunta di sicurezza. Un ecommerce che adotta standard aperti entra nei flussi degli assistenti digitali con un'integrazione documentata e interoperabile, mentre un ecommerce che ignora questi standard rimane dipendente da integrazioni personalizzate, difficili da mantenere e poco compatibili con l'ecosistema in evoluzione.
WebMCP: esporre tool strutturati agli agenti
WebMCP è una proposta di standard web, attualmente in early preview e origin trial su Chrome, che permette a una pagina web di esporre tool strutturati che un agente può scoprire e invocare. Il sito dichiara lo scopo degli elementi interattivi invece di lasciare che l'agente interpreti un bottone o un campo attraverso tentativi di attuazione sul DOM.
WebMCP propone due API: una dichiarativa, basata su annotazioni di elementi HTML form e una imperativa, basata su JavaScript. L'obiettivo è ridurre l'ambiguità e migliorare l'affidabilità del completamento dei task.
La differenza rispetto all'attuazione tradizionale sta nell'esposizione esplicita di capacità: l'agente non deve dedurre l'azione dal contesto visivo o dalla posizione di un elemento, ma riceve una descrizione strutturata con nome, tipo e parametri. WebMCP supporta discovery, JSON Schema per input e output e stato condiviso del contesto della pagina. La proposta è pensata per essere aggiunta come progressive enhancement e non sostituisce le API esistenti. Le API restano il livello di integrazione profonda, mentre WebMCP opera al livello di ciò che l'agente vede e utilizza durante la navigazione nel browser.
Un ecommerce che adotta WebMCP offre un percorso potenzialmente più stabile e meno dipendente dalle variazioni grafiche del frontend, a condizione che la superficie dei tool venga mantenuta, versionata e protetta. Il developer definisce endpoint, schema e permessi, mentre il marketing definisce priorità e contenuti. Chi progetta ricerca e contenuti per questi flussi trae vantaggio da una consulenza AEO orientata a far leggere e citare i contenuti del sito dagli assistenti AI.
Best practice di sviluppo per un sito agent-ready
Tre elementi costituiscono una buona base tecnica per un sito agent-ready: consegna HTML già popolato espone azioni semantiche comprensibili e dichiara dati strutturati orientati all'azione. A questi si aggiungono altri tasselli altrettanto rilevanti, come autenticazione, autorizzazione, gestione dello stato error handling, idempotenza, osservabilità e affidabilità degli endpoint.
Googlebot esegue JavaScript e il rendering lato server o il pre-rendering restano una buona pratica perché migliorano velocità e compatibilità, soprattutto con quei bot che non eseguono JavaScript. Da questo non deriva che le SPA falliscano sempre né che l'SSR garantisca automaticamente il successo di un agente. Il comportamento varia in base all'agente, al runtime, al tipo di task e alla stabilità dell'interfaccia.
Rendering e disponibilità dei dati: quando il tempo conta
La velocità con cui il DOM diventa utilizzabile influisce sulla probabilità che un agente completi il task. Se il contenuto arriva solo dopo l'idratazione client-side, l'agente deve attendere che JavaScript popoli la pagina. Questo introduce una variabile che non dipende dal sito ma dal runtime dell'agente, dal browser e dal task. Google raccomanda il rendering server-side o il pre-rendering perché rende il sito più veloce per utenti e crawler e perché non tutti i bot eseguono JavaScript. Framework come Next.js, Nuxt e Remix offrono SSR maturo e documentato.
Il beneficio non è soltanto tecnico. Un sito che serve HTML già popolato migliora le metriche di velocità percepite dagli utenti umani e semplifica il lavoro dei crawler. Il team di sviluppo deve misurare con attenzione Core Web Vitals e tempo di rendering, tenendo presente che queste metriche riguardano l'esperienza utente e non coincidono con le metriche di successo degli agenti. Una consulenza Core Web Vitals aiuta a individuare i colli di bottiglia che penalizzano sia gli utenti sia gli agenti.
Accessibilità: segnali strutturati per agenti e persone
L'accessibilità diventa anche un'importante fonte di segnali strutturati attraverso cui gli agenti possono interpretare e utilizzare una pagina. Non è l'unico modo in cui un agente comprende il web e non sostituisce gli altri canali, ma offre una base semantica che riduce l'ambiguità. Un agente browser può esaminare l'accessibility tree e Chrome documenta esplicitamente che etichette e semantica aiutano il completamento dei task. La best practice resta quella di usare HTML semantico nativo prima di ricorrere ad ARIA, che va trattata come strumento e non come scorciatoia universale.
Un pulsante costruito con <div onclick> può essere problematico per un agente, ma non è detto che non venga riconosciuto: l'agente può avere altri segnali a disposizione. Un tag <button> con un accessible name chiaro è semanticamente più appropriato e riduce il rischio di fraintendimenti. Gli heading logici H1-H6, le label dei form, i landmark e le regioni navigabili aiutano l'agente a orientarsi e le linee guida WCAG forniscono un riferimento consolidato che vale anche per l'utente umano.
I team che lavorano su feed e schede prodotto devono coordinare dati e landing page per garantire coerenza tra ciò che l'agente legge nel feed e ciò che trova nella pagina. Una consulenza Merchant Center aiuta a mantenere allineati prodotto, prezzo, disponibilità e condizioni di spedizione.
Dati strutturati: descrivere azioni potenziali
I dati strutturati descrivono entità e azioni potenziali, ma non costituiscono un'interfaccia transazionale. Schema.org dispone di BuyAction, PotentialAction ed EntryPoint, che indicano all'agente l'URL di checkout e i parametri richiesti. Un Product con BuyAction descrive un'azione potenziale, ma non conferisce all'agente la capacità di comprare: l'esecuzione richiede un sistema che sappia interpretare quel dato e un endpoint realmente utilizzabile. Il JSON-LD è un ottimo canale machine-readable, ma non è l'unico: un agente può ottenere il prezzo dal DOM, dall'accessibility tree, da microdata, da API o da feed.
Il team di sviluppo deve allineare dati strutturati e API, verificare che il JSON-LD corrisponda al contenuto visibile e mantenere endpoint stabili nel tempo.
Il monitoring con analytics e tag management diventa essenziale per distinguere il traffico agentico da quello umano e per verificare l'efficacia degli interventi. Una consulenza Analytics aiuta a costruire segmenti dedicati e a misurare metriche specifiche per gli agenti, come task success rate, tool-call latency, retry rate e checkout completion rate. Il risultato è una misurazione granulare che guida le decisioni tecniche e impedisce di investire risorse su interventi che non producono effetti misurabili.
Agent-Trapping: una categoria per gli ostacoli agli agenti
Con il termine Agent-Trapping, che in questo articolo utilizziamo come categoria descrittiva e non come standard tecnico, indichiamo una condizione in cui un agente resta bloccato in un ciclo, non trova l'azione che cerca o interpreta male un elemento dell'interfaccia e l'operazione si interrompe. Il sito perde la transazione e l'utente può non ricevere alcuna notifica. Le cause più frequenti includono pop-up newsletter, cookie banner modali, caroselli automatici, captcha visuali legacy e scroll infinito senza paginazione. L'agente può non comprendere il consenso quando il testo del banner è ambiguo, può non superare il captcha quando richiede percezione visiva, può non trovare la fine di una lista infinita quando la paginazione non è dichiarata.
Distribuzione illustrativa delle cause di blocco. I dati esemplificativi servono a mostrare quali categorie di problemi meritano attenzione. Passa il mouse sulle fette per leggere i suggerimenti di intervento.
Caroselli infiniti, captcha e altri ostacoli
Un carosello automatico cambia contenuto mentre l'agente legge e l'agente può perdere il riferimento all'elemento che stava analizzando. Un cookie banner modale copre il pulsante di checkout e l'agente può cercare la chiusura senza trovare un'etichetta chiara. Un captcha visuale legacy richiede percezione umana e l'agente può non superare la sfida. Questi elementi servono a obiettivi legittimi, ma possono bloccare transazioni agentiche quando non offrono alternative accessibili. Il team deve prevedere banner non bloccanti, captcha con token invisibile, paginazione dichiarata e transizioni prevedibili.
La progettazione difensiva riduce il rischio di Agent-Trapping più di qualsiasi correzione successiva. Un test con agenti simulati prima del lancio rivela i punti di rottura e un audit periodico mantiene il sito allineato agli standard emergenti. La verifica deve coprire sia i percorsi principali sia i casi limite.
Sicurezza e governance: oltre il robots.txt
La sicurezza richiede regole chiare, perché il traffico agentico può crescere e consumare risorse. robots.txt è un meccanismo di istruzioni ai crawler e non un sistema di autenticazione o autorizzazione. Per la governance agentica servono strumenti diversi: autenticazione, autorizzazione, OAuth/OIDC quando appropriato, scope, token, rate limiting, request signing, audit log, consent, mandati, revoca e idempotenza. AP2 tratta esplicitamente la delega e verifica dell'autorizzazione dell'agente e UCP prevede meccanismi di autenticazione e firma delle richieste.
WebMCP introduce una superficie di rischio che merita attenzione specifica. La documentazione Chrome evidenzia rischi come tool poisoning, ovvero definizioni di tool con istruzioni nascoste in nomi, parametri o descrizioni e output contaminati da contenuti di terze parti che possono contenere istruzioni malevole. Un agente che opera in una sessione autenticata può diventare un vettore di attacco se non applica difese come limiti sui token, conferma umana per azioni che modificano lo stato e restrizioni sulle interazioni cross-origin. Un ecommerce che espone WebMCP senza controlli crea vulnerabilità concrete, mentre un ecommerce che definisce permessi granulari protegge dati e margini. La trasparenza verso gli agenti autorizzati diventa parte del prodotto e non un'aggiunta di sicurezza.
Il business case: i vantaggi economici dell'ottimizzazione
In molti scenari il business case parte dal checkout, dove si concentra una quota rilevante dell'attrito. Quando un agente compila e paga per conto dell'utente, l'attrito di registrazione, inserimento indirizzo e scelta del metodo di pagamento può ridursi. L'utente delega, il merchant riceve ordini con dati completi e verificati e il costo di assistenza può diminuire perché le richieste di supporto legate a errori di compilazione calano. AP2 fornisce meccanismi per autorizzazione, verifica e auditability, ma non abbiamo qui evidenza sufficiente per affermare che riduca necessariamente chargeback e contestazioni. Per ottimizzare ecommerce per Agenti AI, la trasformazione del checkout in API diventa un primo passo concreto.
Checkout a basso attrito: impatto potenziale sul tasso di abbandono
Il checkout tradizionale richiede account, indirizzo, metodo di pagamento e conferma e ogni campo aggiuntivo crea una probabilità in più di abbandono.
L'agente elimina i campi manuali perché usa mandati e dati già autorizzati e il sito convalida le informazioni senza chiedere all'utente di reinserirle. Il beneficio per l'utente umano è indiretto ma reale, perché l'infrastruttura che serve gli agenti serve anche a chi compila il checkout in autonomia. Recuperare un punto percentuale di abbandono non equivale automaticamente a recuperare ordini con costo di acquisizione nullo, ma la riduzione dell'attrito produce un effetto potenzialmente positivo sul ricavo.
Il costo dell'inadeguatezza agentica
Il costo dell'inadeguatezza agentica può diventare difficile da osservare nelle analytics tradizionali. Gli assistenti digitali possono scegliere i siti che completano il task e un sito non ottimizzato può scomparire dalle risposte senza che l'utente se ne accorga. L'utente non vede il rifiuto, vede solo un'alternativa. Le aziende che adottano pratiche di web agentico e SXO possono conquistare traffico qualificato prima che il mercato si accorga di questo cambio di paradigma.
La consulenza Performance Marketing collega questi interventi a KPI di ricavo e permette di dimostrare il ritorno dell'investimento in modo verificabile. Il budget segue i risultati e non le mode. La portata del vantaggio dipende dall'evoluzione degli standard, dall'adozione degli agenti e dalla capacità di misurare i risultati. Il costo dell'inazione non è una previsione, è un'ipotesi da monitorare con attenzione.
Caso di studio simulato: un ecommerce che supera il test degli agenti
I valori seguenti non rappresentano una previsione né un benchmark di settore: sono numeri ipotetici utilizzati per illustrare come costruire un test di misurazione e come leggere i risultati. Non sono attribuibili a un cliente reale né a una rilevazione empirica.
Un ecommerce di arredamento con dodicimila SKU affronta un calo di conversione da assistenti AI. Il sito usa una SPA pesante, pop-up newsletter all'ingresso e captcha visuale al checkout. Il team ipotizza che gli agenti abbandonino l'operazione e decide di misurare il success rate con un set di test controllati. Nello scenario ipotetico il success rate misurato è del 18% e il traffico agentico rappresenta una quota crescente delle sessioni totali. Il team avvia un piano in quattro fasi che non stravolge l'architettura esistente ma interviene sui punti di rottura più evidenti.
Nella prima fase migra le pagine prodotto a SSR e riduce il tempo di rendering. Nella seconda sostituisce i div cliccabili con button e accessible name, aggiunge label ai form e sistema la gerarchia degli heading. Nella terza espone tool WebMCP per ricerca, filtri e carrello e definisce endpoint stabili con schema chiaro. Nella quarta aggiunge JSON-LD con BuyAction e integra AP2 per la gestione dei mandati di spesa. Dopo otto settimane, nello scenario ipotetico il success rate sale al 76%, il tempo medio di completamento scende da quattordici a quattro secondi e le transazioni agentiche passano dal 3% al 19% del totale. Il team nota un effetto collaterale positivo: anche gli utenti umani completano il checkout più rapidamente. La tabella riassume i risultati dello scenario.
| Metrica | Scenario iniziale | Scenario dopo gli interventi |
|---|---|---|
| Success rate agenti | 18% | 76% |
| Tempo medio di completamento | 14 s | 4 s |
| Transazioni agentiche sul totale | 3% | 19% |
| Abbandono checkout umano | 68% | 54% |
FAQ sul web agentico
Che differenza c'è tra SEO e SXO nel contesto del web agentico?
La SEO ottimizza contenuti e autorità per i motori di ricerca e lavora su keyword, link e segnali di rilevanza. La SXO integra SEO, UX e CRO per soddisfare intenti umani e agentici e aggiunge dati strutturati, semantica, accessibilità e percorsi di azione. Nel web agentico l'obiettivo non è solo il ranking, ma il completamento del task e questo sposta il baricentro dalla visibilità alla verificabilità delle informazioni.
Un piccolo ecommerce può diventare agent-ready senza rifare tutto il sito?
Spesso sì e nella maggior parte dei casi non serve riscrivere l'intera architettura. Le priorità sono rendering server-side o ibrido, HTML semantico, accessible name chiari, JSON-LD action-oriented e checkout con mandati. Un audit tecnico individua gli interventi a maggiore impatto e permette di pianificare un percorso per gradi, con misurazione costante dei risultati.
WebMCP sostituisce le API tradizionali?
No. WebMCP espone azioni della pagina come tool per agenti e opera al livello del browser, durante la navigazione. Le API restano il livello di integrazione profonda, utile quando l'agente opera su larga scala o quando il sito deve esporre funzionalità che non trovano corrispondenza diretta nell'interfaccia visibile. WebMCP e MCP risolvono problemi differenti e non sono sostituti l'uno dell'altro.
Come si misura il traffico generato dagli agenti AI?
Identificare il traffico agentico non è banale: lo user-agent può essere assente, generico o modificato. Occorre distinguere crawler, scraper, search bot, browser agent e agenti LLM e combinare segnali diversi. Si costruiscono segmenti dedicati in analytics e log server e si confrontano metriche come success rate, tool-call latency, retry rate, abandonment rate e checkout completion rate per segmento. Senza misurazione, ogni ottimizzazione resta cieca.
Quali dati strutturati servono per il checkout agentico?
Servono Product, Offer, PriceSpecification, disponibilità, spedizione e reso, insieme a PotentialAction, BuyAction ed EntryPoint con URL di checkout. Il JSON-LD deve corrispondere al contenuto visibile e alle API. I dati strutturati descrivono azioni potenziali ma non eseguono l'acquisto: per l'esecuzione servono API o tool WebMCP realmente invocabili.
Qual è la differenza tra Core Web Vitals e metriche di successo degli agenti?
Core Web Vitals misurano aspetti dell'esperienza web come LCP, INP e CLS e riguardano prevalentemente l'utente umano. Le metriche di successo degli agenti sono diverse: task success rate, tool-call success rate, tool-call latency, retry rate, hallucinated action rate, abandonment rate e human escalation rate. Le due famiglie sono correlate indirettamente, ma non coincidono e richiedono strumenti di misurazione distinti.
Fonti
Google for Developers — Universal Commerce Protocol (UCP): profilo e specifica
AP2 — Agent Payments Protocol, specifica v0.2
Chrome for Developers — WebMCP: proposta di standard per tool strutturati
Chrome for Developers — WebMCP: considerazioni di sicurezza per agenti
Schema.org — Actions: PotentialAction, BuyAction entryPoint
Google Search Central — Understand JavaScript SEO Basics
W3C — Web Content Accessibility Guidelines (WCAG)
