Da SEO ad AEO: progettare siti agent-ready WebMCP e MCP - YourDigitalWeb

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

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

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”