Agenti AI e SEO: preparare il sito per chi naviga per te

Quando si parla di SEO per l'intelligenza artificiale, la maggior parte delle discussioni riguarda un solo scenario: un utente fa una domanda a un assistente AI e il modello cita, o non cita, il tuo sito nella risposta. C'è però un secondo scenario, più recente e meno discusso, che richiede un approccio tecnico diverso: un agente AI che naviga il web per conto dell'utente, visita le pagine, confronta opzioni, compila moduli e in certi casi completa un acquisto o una prenotazione senza che una persona clicchi manualmente su nulla.

Questo articolo si occupa esclusivamente di questo secondo caso: cosa serve perché un sito sia raggiungibile e utilizzabile da un agente che agisce, non solo da un modello che legge e riassume. La differenza non è terminologica: un agente che deve compilare un modulo o leggere un prezzo per completare un task ha esigenze tecniche molto più simili a quelle di uno screen reader o di un test automatizzato che a quelle di un crawler tradizionale, ed è proprio lì che molti siti, altrimenti ben indicizzati, iniziano a fallire senza che nessuno se ne accorga.

Cosa sono gli agenti AI che navigano al posto dell'utente

Un agente AI di navigazione è un software che, ricevuto un obiettivo in linguaggio naturale ("trova il volo più economico per Roma il 12 dicembre e prenotalo", "confronta tre fornitori di hosting e scegli il piano più adatto a un blog"), esegue autonomamente i passaggi necessari: apre pagine, legge il contenuto, segue i link, inserisce dati in campi di un modulo, seleziona opzioni da un menu a tendina e in alcuni casi invia un pagamento.

Il motore alla base è quasi sempre un browser reale, spesso basato su Chromium e controllato via automazione, non un semplice client HTTP che scarica solo l'HTML: molti flussi di prenotazione o acquisto richiedono JavaScript, cookie di sessione e una sequenza precisa di interazioni, esattamente come per un utente umano.

• Agenti di comparazione: raccolgono prezzo, disponibilità e caratteristiche da più siti per produrre una tabella comparativa.
• Agenti di prenotazione o acquisto: portano a termine un flusso multi-step (ricerca, selezione, dati di pagamento, conferma).
• Agenti di compilazione moduli: inseriscono dati anagrafici o di contatto in form di candidatura, richiesta preventivo o iscrizione.
• Assistenti integrati nel browser dell'utente: agiscono con la sessione autenticata della persona, quindi vedono ciò che vede l'utente loggato.

In cosa questo è diverso dall'essere citati in una risposta AI

Quando un modello genera una risposta e cita una fonte, il tuo contenuto viene letto una volta, sintetizzato e presentato con un link, a volte nemmeno cliccato. L'obiettivo di quell'interazione è l'informazione contenuta nella pagina: un paragrafo chiaro, una definizione precisa, una struttura ben segmentata bastano a farsi capire.

Un agente che deve completare un'azione, invece, non si limita a leggere: deve identificare in modo univoco un elemento cliccabile, capire quale campo di un modulo corrisponde a "email" e quale a "codice postale", leggere un prezzo che non cambi tra il caricamento della pagina e il clic su "acquista", e ricevere una conferma comprensibile se qualcosa va storto. Ottimizzare per essere citati riguarda soprattutto il contenuto testuale. Ottimizzare per essere utilizzati da un agente riguarda soprattutto la struttura tecnica della pagina: markup, attributi, stabilità del DOM, assenza di ostacoli interattivi.

• Essere citati: la pagina viene letta e riassunta; conta la chiarezza del testo e la sua struttura informativa.
• Essere utilizzati da un agente: la pagina viene manipolata; contano markup, attributi dei campi e stabilità degli elementi interattivi.
• Una pagina può fare bene la prima cosa e male la seconda: un articolo ben scritto ma con un modulo di contatto senza etichette accessibili blocca comunque un agente che deve compilarlo.

Come un agente raggiunge e legge una pagina

Un agente di navigazione arriva sul sito più o meno come un utente reale: richiede l'URL, attende il rendering se usa un motore browser completo, e poi analizza il DOM risultante, non il codice HTML grezzo restituito dal server se questo viene modificato via JavaScript dopo il caricamento.

Questo ha due conseguenze pratiche. La prima: contenuti o prezzi generati solo lato client dopo chiamate asincrone vanno verificati anche qui, perché un timeout più stretto di quello di un browser umano paziente può far leggere all'agente una pagina incompleta. La seconda: l'agente rispetta, o dovrebbe rispettare, le stesse regole di accesso di un crawler; robots.txt non lo blocca in senso tecnico, ma segnala un'intenzione, e un blocco su user-agent noti va deciso consapevolmente, non per errore di un firewall applicativo.

• Verifica che le informazioni necessarie a completare un'azione, come prezzo, disponibilità e orari, siano presenti nel DOM finale, non solo in una risposta di un'API che il rendering non aspetta.
• Non affidarti a contenuti visibili solo dopo un'interazione dell'utente, come hover o scroll infinito, per dati essenziali come il prezzo.
• Controlla che il tuo robots.txt non blocchi involontariamente percorsi come /carrello, /checkout o /prenota, che sono proprio le pagine che un agente deve poter raggiungere per completare il task.

Markup semantico e accessibile: la base perché un agente possa agire

Un agente identifica gli elementi di una pagina più o meno con gli stessi strumenti di uno screen reader: ruoli ARIA, tag HTML semantici come button, nav, main e form, attributi label/for, aria-label, alt. Una pagina costruita con div cliccabili ovunque invece di elementi button, senza etichette sui campi, senza un ordine di tabulazione sensato, è difficile da interpretare per un agente tanto quanto lo è per una persona che naviga con tastiera o lettore di schermo.

Questo è probabilmente il punto in cui SEO tecnica e accessibilità, due discipline storicamente separate, iniziano a sovrapporsi in modo concreto: quello che rende un sito accessibile a chi usa tecnologie assistive tende a renderlo anche interpretabile da un agente automatico.

• Usa elementi HTML nativi come button, select, input e form invece di ricostruirne il comportamento con div e JavaScript personalizzato.
• Ogni campo di un modulo ha un'etichetta associata, via for/id o annidamento, non solo un placeholder che scompare alla digitazione.
• I pulsanti hanno un testo descrittivo, o un aria-label se l'icona non basta, invece di essere identificabili solo da un'icona senza testo alternativo.
• Il markup non cambia struttura in modo imprevedibile tra un caricamento e l'altro: test A/B che alterano radicalmente il DOM confondono sia gli agenti sia gli screen reader.

Dati di prodotto, prezzo e disponibilità leggibili da una macchina

Quando l'obiettivo dell'agente è confrontare o acquistare, il dato più critico è il prezzo, seguito da disponibilità e spese di spedizione. Il modo più robusto per rendere queste informazioni leggibili senza ambiguità è il markup strutturato di tipo Product e Offer, con campi come price, priceCurrency e availability: un dato tipizzato non richiede all'agente di interpretare un testo come "a partire da 49 euro, IVA esclusa" e indovinare se sia il prezzo finale.

In assenza di dati strutturati, l'agente deve estrarre il prezzo dal testo visibile, ed è lì che nascono gli errori: valute ambigue, prezzi scontati mostrati insieme al prezzo pieno senza indicazione di quale sia effettivamente applicato, prezzi che cambiano dopo l'aggiunta di un prodotto al carrello per motivi non dichiarati in pagina, come tasse o spedizione.

• Marca prezzo, valuta e disponibilità con dati strutturati, non solo con testo formattato graficamente.
• Se il prezzo finale differisce da quello mostrato inizialmente per tasse o spedizione, dichiara la differenza nella stessa pagina, non solo a un passaggio successivo del checkout.
• Evita di mostrare più prezzi per lo stesso prodotto, come un "a partire da", un prezzo per variante e un prezzo scontato, senza indicare chiaramente quale si applica di default.
• Aggiorna la disponibilità in tempo reale anche nel markup, non solo nel testo visibile: un agente che si fida del campo strutturato e trova il prodotto esaurito al checkout registra un fallimento del task.

Errori che bloccano l'agente senza che tu te ne accorga

Molti dei sistemi pensati per fermare bot dannosi, come il rilevamento di user-agent non umani, le sfide CAPTCHA, i blocchi basati sul fingerprinting del browser o un rate limiting aggressivo su percorsi come login o checkout, non distinguono un agente che sta eseguendo un task per conto di un utente reale da uno scraper ostile.

Il risultato è che una protezione configurata per bloccare l'abuso può bloccare esattamente il traffico che vorresti servire: una persona che ha delegato un acquisto a un assistente non sa perché "il sito non funziona", perché l'errore avviene un livello sotto, nell'interazione tra l'agente e il sistema anti-bot o il firewall applicativo.

• Un CAPTCHA prima del login o del checkout ferma l'agente come fermerebbe una persona che non lo sa risolvere: valuta se serve lì o se può restare solo sui punti a rischio reale, come la creazione massiva di account.
• Un blocco per user-agent "non riconosciuto" è rischioso: gli elenchi noti diventano obsoleti in fretta, e un blocco troppo aggressivo respinge anche traffico legittimo.
• Sessioni che scadono in pochi minuti, o pagine interstiziali come il consenso cookie e popup a tutto schermo prima del contenuto utile, interrompono un task o fanno esaurire all'agente il tempo a disposizione.

Moduli e checkout: cosa serve per completare un task in autonomia

Un modulo pensato solo per un occhio umano che "capisce dal contesto" è un ostacolo per un agente. I campi devono essere identificabili per nome, tramite gli attributi name, id e autocomplete, e non solo per posizione visiva sulla pagina.

I messaggi di errore devono essere associati programmaticamente al campo che li ha generati, non apparire come un testo colorato isolato senza legame strutturale con l'input; e i passaggi obbligatori di un flusso, come la selezione di una taglia prima di poter procedere o l'accettazione di un termine, devono essere segnalati come tali nel markup, non solo bloccati silenziosamente al clic su "continua".

• Usa l'attributo autocomplete standard sui campi comuni, come email, nome, indirizzo e numero di carta, per permettere il riconoscimento automatico del tipo di dato richiesto.
• Segnala i campi obbligatori con l'attributo required, non solo con un asterisco visivo senza equivalente nel markup.
• Restituisci messaggi di errore specifici e associati al campo, come "formato email non valido" sul campo email, non un messaggio generico in cima alla pagina.
• Evita un CAPTCHA visivo come unico modo per procedere in un checkout, se esiste un'alternativa lato server che non richiede la soluzione di un puzzle visivo.

Come verificare se il sito è pronto per gli agenti

La verifica più affidabile non è teorica: consiste nel far eseguire a un agente reale un task concreto sul proprio sito, come una ricerca, un'aggiunta al carrello o la compilazione di un modulo di contatto, e osservare dove si blocca.

In parallelo, i log del server raccontano già molto: user-agent riconducibili a motori di automazione browser, richieste che si interrompono sempre allo stesso passaggio, spesso login o pagamento, codici di risposta 403 o 429 concentrati su percorsi specifici. Nessuno di questi segnali richiede strumenti sofisticati: richiede guardare i log con la domanda giusta in mente, che non è "quanto traffico bot arriva" ma "dove si ferma un agente che sta cercando di completare qualcosa".

• Esegui manualmente un task end-to-end con un assistente o agente disponibile e annota ogni punto in cui si è bloccato o ha dovuto indovinare.
• Controlla i log per pattern di interruzione ricorrenti sullo stesso passaggio di un flusso multi-step.
• Verifica con un ispettore del DOM, non con la sola vista del codice sorgente, che i dati critici come prezzo, disponibilità e campi del modulo siano effettivamente presenti e correttamente etichettati dopo il rendering.
• Rivedi le regole del sistema anti-bot sui percorsi di conversione, come checkout, login e moduli, separatamente da quelle sul resto del sito, perché il costo di un falso positivo lì è più alto.