SEO per agenti AI: come ottimizzare il tuo sito per la terza entità del web

Fino a poco tempo fa, quando ragionavamo su chi visita i nostri siti, avevamo due interlocutori. Da una parte le persone, dall'altra i crawler dei motori di ricerca. Tutta la SEO, se ci pensate, si è sviluppata lungo questo asse: rendere i contenuti utili per gli umani e leggibili per le macchine di Google. Adesso c'è un terzo soggetto, e il fatto che non abbiamo ancora capito bene come gestirlo non significa che possiamo ignorarlo.

Il buco nei dati

Cloudflare pubblica periodicamente dati sulla composizione del traffico web. L'ultimo dato disponibile assegna circa il 32% del traffico totale alla categoria "bot". Il punto è che dentro quel 32% finisce di tutto, compresi gli agenti AI. Nessuno strumento attuale distingue tra queste tipologie.

Per chi fa il nostro mestiere è un problema concreto. Se un agente AI visita la nostra scheda prodotto e poi la scarta perché non riesce a leggere il prezzo, noi non lo sappiamo. Non compare in Analytics, non lascia traccia in nessun log accessibile. Lavoriamo con un pezzo di realtà che ci manca, e quel pezzo diventa più grande ogni mese.

Il paradosso di Google

Possiamo fare tutte le ottimizzazioni che vogliamo, ma senza dati restiamo al buio e oggi i dati non ci sono. Google Analytics non ha una dimensione "agente AI" e non permette di isolare questo tipo di traffico in alcun modo.

Il paradosso è che Google è nella posizione ideale per risolvere la cosa. Scrive le guide su come ottimizzare per gli agenti e allo stesso tempo gestisce Analytics. Il giorno in cui queste realtà si parleranno, avremo finalmente un quadro misurabile. Per ora, chi lavora su queste ottimizzazioni lo fa fidandosi dei segnali di tendenza, senza poterli verificare nei propri dati.

Gli agenti AI sono software che eseguono compiti reali per conto delle persone. Un utente chiede al suo agente di trovare un dentista nella sua zona, e l'agente va a cercare, apre siti e alla fine propone una scelta. Quel processo avviene sul nostro sito senza che noi lo sappiamo e senza che possiamo influenzarlo con le stesse leve della SEO tradizionale.

Cosa vedono gli agenti quando aprono una pagina

Google ha messo online su web.dev una guida su come gli agenti AI interagiscono con i siti. Vale la pena leggerla per intero (non è tanto lunga), ma il punto centrale è che un agente può leggere una pagina in tre modi diversi e spesso li combina.

1. Il primo è quello che viene definito cattura visiva: l'agente fa un rendering completo della pagina e ne cattura un'immagine. Poi passa quell'immagine a un modello di visione che identifica bottoni e campi interattivi, e ne interpreta la funzione in base a come appaiono. Se avete un bottone grande con scritto "Compra ora" in alto, l'agente lo interpreta senza problemi. Se l'azione principale è un piccolo link grigio nascosto tra altri dieci elementi, l'agente potrebbe non trovarlo.
2. Il secondo modo è la lettura diretta del codice HTML. L'agente analizza il DOM e cerca di capire come è strutturata la pagina. Qui conta tutto: se usate i tag corretti l'agente capisce subito cosa è un link e cosa è un pulsante. Se il vostro HTML è un castello di div con comportamenti aggiunti via JavaScript, l'agente deve indovinare, e indovinare significa sbagliare.
3. Il terzo è l'albero dell'accessibilità. Se avete familiarità con gli screen reader, sapete già di cosa si tratta: è la rappresentazione della pagina che il browser espone alle tecnologie assistive. Per un agente AI è la fonte di dati più affidabile, perché ogni elemento è catalogato per funzione senza ambiguità. Chi ha già lavorato sull'accessibilità del proprio sito parte avvantaggiato su questo fronte.

Un agente ben costruito userà probabilmente più di una di queste modalità in parallelo. Il sito, di conseguenza, deve reggere su tutti i livelli.

Le cose da fare

Quando leggete la lista delle raccomandazioni tecniche per gli agenti AI, la sensazione è di déjà vu. Sono le stesse cose che avremmo dovuto fare da anni per la SEO tecnica e per l'accessibilità, solo che adesso c'è un motivo in più.

Per approfondire, leggi: LLM SEO (o GEO) non esiste: sempre di SEO si tratta

• Evitare il layout shift
  Un agente che fa lo screenshot della pagina memorizza dove si trova ogni elemento. Se dopo mezzo secondo un banner pubblicitario sposta tutto verso il basso, le coordinate registrate non corrispondono più a niente. Il Cumulative Layout Shift non è più solo una metrica da ottimizzare per i Core Web Vitals: è un problema diretto di usabilità per gli agenti.
• Usare i tag HTML per quello che sono
  Un <button> dice "sono un pulsante" senza bisogno di interpretazione. Un <div> con class="btn" e un onclick attaccato via JavaScript lo dice forse, se l'agente è abbastanza sofisticato da capirlo. La stessa logica si applica ai link: <a href="..."> è autoesplicativo, <span> con un event listener no.
• Aggiungere role e tabindex come piano B
  Se il vostro sito ha cinque anni di codice accumulato e non potete riscrivere il markup da zero, gli attributi ARIA sono il minimo sindacale. Un div role="button" tabindex="0" non è elegante, ma comunica la funzione dell'elemento sia all'agente sia agli screen reader.
• Rispettare gli 8 pixel quadrati
  La guida di Google fissa questa soglia come area minima perché un elemento interattivo venga rilevato dall'analisi visiva. Sotto quella misura, il bottone potrebbe semplicemente non essere visto dall'agente.
• Rendere i contenuti leggibili al primo caricamento.
  Questo è il punto su cui serve più attenzione. Slideshow, modal, tooltip e menu in hover pongono due problemi distinti a seconda di come l'agente legge la pagina. Un agente che lavora via screenshot non vede il contenuto delle slide successive o di un modal ancora chiuso, perché lo screenshot registra solo lo stato corrente. Un agente che legge il DOM, invece, spesso trova quei contenuti nel markup (sono lì, solo nascosti via CSS), ma potrebbe non sapere come attivare l'interazione per raggiungerli. In entrambi i casi, la soluzione è la stessa: se un'informazione serve al percorso dell'utente, deve essere visibile e leggibile già al primo rendering.

Per approfondire, leggi anche: Perché oggi ti serve una community e non solo un’audience?

Il salto dai tentativi al protocollo

Pensate a un form di contatto con otto campi. Senza informazioni pregresse, l'agente deve guardare il form, capire cosa è obbligatorio e provare a dedurre se il campo "telefono" accetta il prefisso internazionale oppure no. Ci arriva, dopotutto non sarebbe un'intelligenza artificiale, ma il processo è lento e soggetto a errori.

Con un protocollo come MCP (Model Context Protocol), il sito dichiara in anticipo la struttura del form con i relativi vincoli di formato. L'agente riceve tutto già pronto e compila direttamente.

Oggi siamo ancora nella fase in cui la maggior parte degli agenti deve arrangiarsi da sola, il che rende le ottimizzazioni di markup e accessibilità la cosa più utile che possiamo fare adesso. I protocolli strutturati sono il passo successivo, rilevante soprattutto per chi gestisce e-commerce o siti con flussi di prenotazione.

Perché ha senso farlo lo stesso

Tutto quello che migliora il sito per gli agenti AI lo migliora anche per le persone. Markup semantico e accessibilità ben fatta portano vantaggi a qualsiasi visitatore del sito, bot o umano che sia.

Il pubblico delle nostre pagine si è allargato. Il terzo tipo di visitatore è già attivo, anche se ancora invisibile nei report. Preparare il sito per questo destinatario è un lavoro che produce risultati concreti a prescindere dall'evoluzione degli strumenti di misurazione. E il giorno in cui quei dati diventeranno disponibili, chi ha già investito in questa direzione non dovrà rincorrere.