Per molti anni la SEO ha ottimizzato un percorso dominato dall’interazione umana: contenuti indicizzati, ranking, click, navigazione e conversione. Quel percorso resta fondamentale, ma oggi viene affiancato da un secondo canale, sempre più rilevante: l’esecuzione mediata da agenti IA.
Gli agenti non si limitano a recuperare informazioni. Interpretano intenti operativi e transazionali come “prenota”, “compra”, “configura”, “richiedi un preventivo”, e provano a completarli al posto dell’utente. In questo scenario, essere trovabili non basta: diventa strategico essere anche invocabili, in modo controllato e verificabile.
Qui entra in gioco l’AEO (Agent Engine Optimization): l’insieme di scelte architetturali, di prodotto e di sicurezza che rendono un sito utilizzabile dagli agenti senza affidarsi a tentativi sulla UI, ma tramite capability esplicite, contratti macchina-a-macchina e governance robusta.
In YourDigitalWeb accompagniamo le aziende proprio in questa transizione: dalla logica “pagina e click” alla logica “azioni e contratti”. Lo facciamo con un approccio ingegneristico, perché l’AEO non è un’etichetta: è un modo diverso di progettare sistemi digitali che devono funzionare con utenti umani e con agenti.
Definizione MCP
MCP (Model Context Protocol) è un protocollo pensato per standardizzare il modo in cui un’applicazione o un agente IA scopre e utilizza strumenti (tools) e contesto esposti da sistemi esterni. In pratica, MCP descrive come pubblicare capability (azioni invocabili) e come trasferire in modo strutturato informazioni utili all’esecuzione (schemi di input/output, metadati operativi, policy).
Il vantaggio architetturale di MCP è ridurre l’integrazione “ad hoc” tra agenti e servizi, sostituendola con un modello più uniforme basato su contratti e discovery.
Definizione WebMCP
WebMCP (Web Model Context Protocol) è un’evoluzione concettuale applicata al contesto web: l’obiettivo è permettere a un sito o a una web app di esporre azioni invocabili e descrizioni strutturate in modo più nativo rispetto al semplice UI-driving.
In termini pratici, WebMCP mira a rendere più diretto e controllabile il passaggio dal “capire la pagina” al “chiamare un’azione”, privilegiando schemi e contratti rispetto all’interpretazione visiva del DOM.
È utile trattarlo come un tassello di una direzione più ampia: un web in cui la UI resta centrale per gli umani, ma le capability diventano accessibili anche agli agenti tramite interfacce operative.
Perché l’UI-driving è fragile in produzione
Molti agenti oggi operano come “utenti simulati”: cercano elementi nella pagina, interpretano etichette, cliccano pulsanti, compilano form. È un approccio che può funzionare in contesti semplici, ma che diventa fragile su siti reali perché la UI non è un contratto: è una rappresentazione che cambia e che spesso include elementi che interrompono o deviano il flusso.
Le cause di rottura sono ricorrenti:
-
refactor e cambi di framework/componenti che modificano DOM e attributi
-
A/B test che alterano gerarchie e copy dei pulsanti
-
stato gestito lato client che non si riflette in URL o markup stabile
-
modali, interstitial, cookie banner e overlay che bloccano la sequenza di azioni
-
UI asincrona (lazy load, skeleton, caricamenti progressivi) che crea condizioni di race
-
localizzazione e formati che cambiano valute, date e separatori decimali
Il problema non è solo tecnico. Un agente che si blocca o interpreta male un passaggio non produce “solo” un drop-off: può generare errori operativi, configurazioni invalide, richieste duplicate, tentativi ripetuti, costi di supporto e rischio reputazionale. Quando l’esecuzione è mediata da automazione, l’affidabilità del funnel diventa una proprietà di sistema, non un dettaglio di interfaccia.
Dal web semantico al web operativo: entità e azioni
Negli anni, i dati strutturati hanno reso il web più interpretabile per le macchine: non solo testo, ma entità e relazioni. Nel mondo agentico serve un salto ulteriore: oltre a descrivere “cosa” è una cosa (prodotto, servizio, evento), bisogna rendere esplicito “cosa può fare” il sito e “come farlo” in modo verificabile.
Un’architettura agent-ready si basa su tre elementi:
-
capability: azioni invocabili (ricerca, preventivo, prenotazione, checkout, post-vendita)
-
contratti: input/output tipizzati e vincolati (JSON Schema/OpenAPI)
-
governance: sicurezza, limiti, osservabilità e tracciabilità
Protocolli e pattern come MCP e tool calling vanno letti in questa direzione: non come “moda”, ma come convergenza verso un web in cui le azioni sono descrivibili e chiamabili in modo standardizzato. La scelta strategica corretta è costruire capability e contratti in modo agent-agnostic, così da poter parlare con ecosistemi differenti senza riscrivere l’architettura.
Tabella: SEO vs AEO
| Dimensione | SEO (Search Engine Optimization) | AEO (Agent Engine Optimization) |
|---|---|---|
| Obiettivo | Essere trovabili e cliccati | Essere selezionabili e “eseguibili” da agenti |
| Unità ottimizzata | Pagina / contenuto | Capability / azione |
| Output desiderato | Ranking, traffico umano | Invocazioni riuscite, task completati |
| Superficie tecnica | HTML, contenuti, dati strutturati | API, schemi, policy, tool calling |
| Failure mode tipico | Bounce / drop-off | Errore operativo (parametri errati, duplicazioni, blocchi) |
| KPI principali | Impression, CTR, sessioni | Success rate, completion rate, drop-off agentico |
API-first con UI: la regola che rende un sito eseguibile
La differenza tra un sito “compatibile con gli agenti” e un sito “agent-ready” è dove vive l’esecuzione.
In un sistema agent-ready:
-
il backend è la fonte di verità e il punto di enforcement
-
l’API è la superficie operativa per agenti e per lo stesso front-end
-
la UI è una vista, un orchestratore e un fallback, non l’unico strato eseguibile
Questo non significa rinunciare all’esperienza utente: significa separare presentazione e operatività. Quando l’azione critica passa per capability ben progettate, l’agente non deve interpretare la UI: deve invocare un’azione esplicita con parametri validi.
Capability modeling: trasformare processi in funzioni invocabili
AEO efficace parte da una domanda pratica: quali azioni generano valore e devono diventare “invocabili”?
In contesti e-commerce, servizi e SaaS, le capability ricorrenti includono:
-
discovery: ricerca e suggerimenti per disambiguazione
-
pricing e disponibilità: stock, preventivi, spedizioni, slot
-
transazione: carrello, preparazione checkout, commit ordine
-
post-vendita: tracking, resi, ticket, rinnovi
La granularità conta: capability troppo grandi aumentano il rischio di errore e rollback; capability troppo piccole moltiplicano round-trip e complessità. La progettazione migliore è spesso quella “a state machine”: azioni atomiche che spostano il sistema da uno stato al successivo in modo esplicito e auditable.
Un principio operativo che alza enormemente l’affidabilità è distinguere chiaramente tra azioni di lettura e azioni di commit. Le azioni di commit devono essere idempotenti e progettate per i retry: con agenti e automazioni, timeout e ripetizioni non sono un caso raro, ma un comportamento normale.
Tassonomia delle capability agent-ready
| Area | Capability (esempi) | Tipo | Note di progettazione |
|---|---|---|---|
| Discovery | searchProducts, suggestProducts |
Safe | Favorire filtri tipizzati e disambiguazione |
| Pricing | getQuote, calculateShipping |
Safe/Proposal | Restituire breakdown e vincoli (validity window) |
| Availability | checkAvailability, listSlots |
Safe | Separare disponibilità da prenotazione |
| Cart | createCart, updateCart |
Proposal | Prevedere versioning e stato esplicito |
| Checkout | prepareCheckout |
Proposal | Genera un oggetto vincolante (checkoutId) |
| Commit | commitOrder, bookAppointment |
Unsafe | Idempotency key obbligatoria + conferme high-stakes |
| Post-sales | trackOrder, initiateReturn |
Safe/Unsafe | Motivazioni in enum e audit log |
Contratti macchina: tipizzazione forte, vincoli e error model stabile
L’agente non deve “indovinare” parametri. Deve poter leggere un contratto rigoroso.
Un contratto “machine-grade” include:
-
required/optional espliciti
-
enum al posto di stringhe libere dove possibile
-
vincoli (range, pattern, formati) e canonicalizzazione
-
esempi realistici e edge case
-
error taxonomy stabile (codici, dettagli, hint)
Un pattern particolarmente robusto è separare proposta ed esecuzione in due step.
Nel primo step si produce una proposta strutturata: un oggetto con identità (id), importi calcolati, vincoli e finestra di validità. Nel secondo step si accetta quella proposta tramite riferimento immutabile, vincolando l’esecuzione ai termini calcolati. Questo riduce ambiguità e limita drasticamente il rischio che l’agente “inventa” parametri o interpreti male condizioni economiche.
Pattern “Two-step execution”
| Fase | Nome (esempio) | Caratteristica | Output consigliato | Perché riduce errori |
|---|---|---|---|---|
| Proposta | prepareCheckout / getQuote |
Non irreversibile | quoteId/checkoutId, totali, vincoli, scadenza |
L’agente lavora su un oggetto stabile, non su testo |
| Commit | commitOrder / acceptQuote |
Irreversibile o ad alto impatto | ricevuta/ordine, stato, riferimenti audit | L’esecuzione è vincolata ai termini della proposta |
Discovery e binding: rendere le capability trovabili dagli agenti
Avere capability non basta: devono essere scopribili, versionate e collegate al contesto.
Le strategie efficaci sono complementari:
-
un manifest capability che elenca azioni disponibili, versioni, schemi e policy
-
integrazioni tool calling/MCP dove il canale lo supporta, mantenendo schemi rigorosi
-
collegamenti semantici tra entità e azioni, così che una pagina “prodotto” o “servizio” punti chiaramente alle capability rilevanti
Qui è importante evitare un errore comune: scrivere descrizioni “persuasive” in stile marketing. Un agente sceglie meglio quando trova descrizioni operative che riducono ambiguità: prerequisiti, output garantiti, limiti, e cosa la capability non fa.
Checklist del “contratto macchina”
| Sezione | Requisito | Buona pratica |
|---|---|---|
| Tipi | Tipizzazione esplicita | Evitare stringhe libere quando esistono enum |
| Vincoli | Range/pattern/formati | Canonicalizzare valute, date, decimali |
| Enum | Scelte discrete | Es. shippingMethod: ["STANDARD","EXPRESS"] |
| Error model | Codici stabili | error.code enum + error.details strutturato |
| Versioning | Versioni dichiarate | Compatibilità backward quando possibile |
| Retry semantics | Retryable vs non-retryable | retryAfter, idempotenza per commit |
| Idempotency | Obbligatoria sui commit | Prevenire duplicazioni e doppi addebiti |
Security layer: zero trust per automazioni e agenti
Rendere un sito invocabile aumenta la superficie d’attacco. Un’implementazione AEO producibile richiede un trust layer esplicito:
-
autenticazione delegata (OAuth2/OIDC) con scope minimali
-
separazione tra azioni safe e azioni ad alto rischio
-
rate limiting per identità/token/IP e mitigazione anti-abuso
-
validazione strict server-side (type checking, range validation, sanitizzazione, rifiuto parametri extra)
-
human-in-the-loop per azioni irreversibili o economicamente rilevanti (approvazione esplicita, 2FA, conferme out-of-band)
Questa parte non è accessoria: è ciò che trasforma una demo in un sistema sostenibile.
In questo contesto, MCP e WebMCP rappresentano due modi complementari di pensare l’integrazione agentica: MCP come modello generale di discovery e invocazione di strumenti con contratti; WebMCP come declinazione orientata al web, dove l’obiettivo è ridurre la dipendenza dall’interpretazione della UI e favorire azioni invocabili e verificabili. Al di là dei nomi, la direzione architetturale resta la stessa: capability chiare, schemi rigorosi, governance e sicurezza.
Osservabilità AEO: misurare la conversione “machine-mediated”
Quando gli agenti entrano nel funnel, le metriche cambiano. Oltre a traffico e conversion rate, diventa importante misurare:
-
discovery rate delle capability
-
invocation rate per capability
-
success rate tecnico e successo “business”
-
distribuzione errori per codice e per versione contratto
-
disambiguation rate e drop-off agentico
-
time-to-task-completion
-
retry rate e utilizzo dell’idempotenza
Un segnale pratico: un alto volume di errori di validazione spesso indica contratti troppo permissivi o descrizioni tool insufficientemente precise. In ottica AEO, l’analisi degli errori è una leva di ottimizzazione tanto quanto lo è la keyword research in SEO.
Come YourDigitalWeb supporta le aziende: dal concetto all’implementazione
Qui si gioca la differenza tra “parlare di agenti” e costruire sistemi agent-ready.
YourDigitalWeb lavora con le aziende su un percorso completo, che integra architettura, sviluppo e governance, senza sacrificare SEO, UX e performance.
Audit AEO e mapping delle capability
Analizziamo i funnel ad alto valore (preventivo, booking, acquisto, onboarding, assistenza) e li traduciamo in capability con confini chiari. Identifichiamo i punti di fragilità tipici del UI-driving e definiamo la strategia di separazione tra UI e superficie operativa.
Design dei contratti e standardizzazione
Progettiamo JSON Schema/OpenAPI con tipizzazione forte, enum, vincoli e error taxonomy stabile. Introduciamo pattern di proposta/commit, versioning, compatibilità backward e semantica di retry.
Implementazione API-first e refactoring controllato del front-end
Portiamo i flussi critici su endpoint robusti e facciamo evolvere la UI affinché diventi un client delle capability, preservando esperienza utente e velocità di sviluppo. Questo rende il sistema più resiliente anche a refactor, redesign e A/B test.
Integrazione agentica (MCP/tool calling) e discovery
Dove ha senso, esponiamo le capability come strumenti invocabili tramite integrazioni compatibili con i principali ecosistemi. Costruiamo manifest e meccanismi di discovery che rendono le azioni trovabili e selezionabili dagli agenti senza ambiguità.
Security e trust layer
Implementiamo autenticazione delegata, scopes, rate limiting, anti-abuse, validazione strict e human-in-the-loop per high-stakes. Progettiamo logging e audit per tracciare le invocazioni e garantire accountability.
Osservabilità, metriche e regressione
Costruiamo dashboard AEO e introduciamo suite di test/eval per prevenire regressioni. L’obiettivo non è “fare un progetto una tantum”, ma mantenere l’eseguibilità agentica come proprietà stabile del sistema.
Questo approccio consente di preparare i siti a un ecosistema multi-agente senza dipendere da un singolo vendor o da una singola modalità di esecuzione. Il risultato è un’architettura più pulita, più sicura e più interoperabile, che migliora l’affidabilità dei funnel e apre canali di conversione che non passano necessariamente dal click tradizionale.
