In sintesi: Gli agenti AI leggono il tuo sito attraverso tre lenti diverse (screenshot, DOM grezzo e albero di accessibilità) e la maggior parte dei siti, senza volerlo, è ostile a tutte e tre. Le correzioni si sovrappongono al lavoro su accessibilità e Core Web Vitals che dovresti già fare. Qui trovi l’ordine di priorità, un audit da 5 minuti e un ciclo di misurazione che puoi avviare oggi stesso.
Qualche settimana fa stavo costruendo il nostro strumento “agent-ready”. L’idea era alimentare un agente basato su Playwright con siti reali dei clienti e osservare come li utilizzava. Così l’ho puntato sulla nostra homepage—che avevo pubblicato un migliaio di volte—e gli ho chiesto di trovare la pagina prezzi.
Ha cliccato la CTA sbagliata. Poi ha provato a cliccare un pulsante che pulsante non era (un <div> stilizzato assemblato in fretta). Alla fine si è arreso e mi ha chiesto dove fossero i prezzi.
Il fatto è che sapevo che il nostro sito aveva stati hover che rivelavano la navigazione secondaria. Un umano muove il cursore, appare il menu, problema risolto. L’agente lavorava da un singolo screenshot dello stato di riposo. Nessun cursore da muovere. Per lui la nav solo-hover non esisteva proprio.
Quel giorno ho smesso di considerare gli agenti AI crawler più intelligenti e ho iniziato a vederli come nuovi visitatori con limiti particolari. (Nota a margine: per mesi avevo dato per scontato che funzionassero come Googlebot con qualche passaggio in più. Per i primi sei mesi dell’anno scorso mi sbagliavo.) Quello che segue è ciò che ho imparato da allora, soprattutto rompendo cose e guardando come reagivano gli agenti.
Un agente AI che atterra sulla tua homepage non sta facendo crawling per un indice di ricerca. Sta cercando di svolgere un compito che un umano gli ha assegnato: prenotare il volo, confrontare i piani, aggiungere l’articolo al carrello. Ha minuti, non ore. E ogni clic sbagliato costa token di inferenza all’utente.
Questo cambia il problema di design. Un bot di ricerca può fallire in silenzio e non lo saprai mai. Un agente fallisce in modo evidente, davanti a un utente pagante, e alla successiva richiesta l’utente potrebbe dirgli di saltare il tuo sito. I motori di ricerca AI stanno iniziando a comportarsi allo stesso modo: se il loro crawler non riesce a estrarre una risposta sicura dalla tua pagina, la risposta verrà da chi è più facilmente analizzabile. I clic che prima ottenevi dalla SERP vengono sostituiti da citazioni in un riepilogo AI, e le citazioni si conquistano con la leggibilità, non con il budget pubblicitario.
Per un’analisi più ampia del lato “AI come canale di discovery”, il pilastro silo in ask engine optimization tratta direttamente l’aspetto search. Questo articolo riguarda l’altra metà: cosa succede quando un agente cerca davvero di usare il tuo sito.
Questa è la parte che avrei voluto mi spiegassero un anno fa. Non esiste un unico modo con cui gli agenti vedono le pagine web. Sono tre, e i principali vendor li combinano in modo diverso.
"Gli agenti possono visualizzare il tuo sito in tre modi principali: screenshot, HTML grezzo e albero di accessibilità. L’albero di accessibilità è un’API nativa del browser che distilla il DOM in ciò che conta di più: ruoli, nomi e stati degli elementi interattivi. Per un agente AI funziona come una mappa ad alta fedeltà che ignora il 'rumore' visivo del CSS per concentrarsi sulla pura utilità."
— Kasper Kulikowski & Omkar More, web.dev: Build agent-friendly websites
Ecco lo stato attuale a inizio 2026. Il computer-use di Anthropic funziona solo a screenshot. Claude vede un’immagine 1024×768, ragiona in coordinate pixel e dice all’harness dove muovere il mouse. Nessun input DOM lato Anthropic. L’Operator di OpenAI (CUA) stratifica screenshot con dati DOM e dell’albero di accessibilità, anche se la documentazione di lancio di OpenAI enfatizza il loop screenshot e il layer DOM emerge per lo più da reverse engineering di terze parti. Project Mariner di Google legge sia i pixel sia il DOM sottostante. I framework basati su Playwright come browser-use preferiscono prima l’albero di accessibilità e ricorrono agli screenshot quando fallisce.
L’economia qui conta più dell’architettura. Uno snapshot dell’albero di accessibilità di una pagina tipica pesa 2–5 KB. Uno screenshot della stessa pagina è da 100 KB in su. Circa 20–50 × di costo per step in token di inferenza. Gli agenti che possono leggere l’albero di accessibilità hanno un forte incentivo a farlo. I siti che producono un albero pulito vengono utilizzati. Gli altri costringono all’uso degli screenshot, generano più errori e alla fine vengono saltati.
Puoi vedere subito l’albero di accessibilità del tuo sito. Apri Chrome DevTools, vai nel pannello Accessibility, spunta “Enable full accessibility tree”. È più o meno ciò che un agente come browser-use preleverà. Chrome nasconde i nodi ignorati e quelli generici senza nome per impostazione predefinita—utile, perché sono esattamente gli elementi con cui gli agenti faticano.
Le citazioni sono i nuovi clic, almeno per alcune query. Secondo la ripartizione cross-platform di Profound, Wikipedia copre il 47,9 % delle fonti top-10 di ChatGPT; Reddit il 21 % di Google AI Overviews e il 46,7 % di Perplexity. I pattern cambiano di continuo (stando al monitoraggio Leapd, la quota Reddit di ChatGPT è crollata dal 60 % al 10 % in sei settimane dopo un singolo parametro di Google), ma la direzione è chiara: i motori AI premiano i contenuti che possono analizzare con sicurezza e scartano il resto.
"Alcuni LLM, come ChatGPT e Claude, non eseguono JavaScript (a differenza di Gemini), rendendo il server-side rendering (SSR) fondamentale affinché i contenuti importanti compaiano nelle loro risposte."
— Aleyda Solis, AI Search: Where Are We & What Can We Do About It?
Quella singola frase è più concreta della maggior parte dei consigli AI-SEO che ho letto. Se il tuo contenuto importante è renderizzato client-side, ChatGPT e Claude non lo vedono. Gemini sì. Che ti piaccia o no, è un requisito ingegneristico falsificabile. Il nostro articolo su AI crawler playbook va più a fondo su quali crawler eseguono JavaScript e quali no.
Devo essere onesto su ciò che non sappiamo. Non esiste uno studio pubblico che correli direttamente i punteggi di accessibilità con i tassi di citazione AI. Il meccanismo è difendibile (l’albero di accessibilità è la stessa struttura letta dagli agenti e dai screen reader), ma il legame empirico non è stato dimostrato. Il dato più vicino è il riassunto di accessibility.works di uno studio su 10 000 siti che mostra che i siti conformi alle WCAG ottengono il 23 % di traffico organico in più e si posizionano per il 27 % di keyword in più rispetto ai pari non conformi. La metodologia è poco documentata (nessun livello di conformità WCAG specificato, nessuna peer review), quindi lo considero indiziario, non determinante.
In questo settore vedrai molte liste “8 cose”. La lista è davvero utile come struttura organizzativa; smette di esserlo se tratti tutti gli otto punti come ugualmente importanti. Non lo sono. Ecco il confronto.
| Segnale | Cosa vede l’agente se è corretto | Cosa si rompe se è errato | Sforzo |
|---|---|---|---|
| Elementi semantici nativi | <button>, <a>, <h1> compaiono nell’a11y tree con ruoli impliciti |
I pulsanti in <div> stilizzati spariscono dall’a11y tree |
Basso |
| Nomi accessibili sugli input | "input, type=email, label='Indirizzo email'" | "input, type=text" (il placeholder da solo non crea un nome) | Basso |
| Target interattivi visibili | Pulsanti > ~8 px² (minimo empirico web.dev), idealmente 24×24 px CSS (WCAG 2.5.8 AA) | I modelli di visione filtrano i target piccoli; gli agenti a coordinate mancano il clic | Basso |
| Layout stabile (CLS basso) | Le coordinate di clic atterrano sull’elemento giusto | Le immagini lazy-load spostano la pagina; l’agente clicca il pulsante sbagliato | Medio |
| Contenuto renderizzato server-side | ChatGPT e Claude vedono l’HTML completo al primo fetch | I contenuti solo-hydrated sono invisibili ai crawler che non eseguono JS | Medio-Alto |
| Gerarchia di heading | Un <h1>, <h2>/<h3> annidati con ruoli impliciti |
Heading visivi come <p> = niente outline documento |
Basso |
| Niente overlay fantasma / focus trap | Gli eventi click raggiungono l’elemento visibile | Layer trasparenti intercettano i clic; l’agente resta bloccato | Medio |
| URL e form prevedibili | L’agente può riprendere dopo una navigazione; i campi descrivono sé stessi | Route SPA che azzerano la history confondono i task multi-step | Medio |
Due di questi segnali dominano. Elementi semantici nativi e nomi accessibili sono la base. Se sbagli quelli, il resto non conta. Su qualche centinaio di siti passati dal nostro agent-ready check, l’errore singolo più comune è proprio questo: una CTA costruita come <div> stilizzato che sparisce dall’albero di accessibilità. Circa metà delle home che auditiamo ne ha almeno una. La soglia degli 8 px² (da web.dev) è empirica, non un limite architetturale rigido; gli encoder di visione per modelli CLIP usano in realtà patch 14×14 o 16×16 px, quindi considera quel valore un minimo sensato, non un numero magico.
Questa è la parte che non vedo mai negli articoli sulla agent-readiness. La maggior parte ti dà una checklist da 8 a 30 punti e basta. Ecco cosa faccio davvero quando ho 5 minuti tra due call.
Minuto 1. Esegui il nostro agent-ready check gratuito. Invita la tua homepage a un agente Playwright e restituisce segnalazioni come <div role="button"> senza tabindex, input nascosti che intrappolano il focus o CTA che l’agente vede nello screenshot ma non trova nell’a11y tree. È lo strumento che Lida ed io abbiamo lanciato dopo il momento “GPT non vede gli hover” (lei voleva aspettare dati più puliti; io ho pubblicato la versione grezza). È gratis e non chiede email.
Minuto 2. Apri il sito in Chrome, DevTools → Accessibility, abilita l’albero completo. Cerca nodi con ruolo "generic" e senza nome. Ognuno è un punto in cui l’agente deve indovinare.
Minuto 3. Esegui lo scanner vibe-coded sullo stesso URL. È un’analisi di qualità del codice che intercetta pattern che Cursor, Copilot e Lovable creano di default: <div onClick> come pulsanti, label mancanti, heading stilizzati da paragrafi. (L’ho costruito perché metà dei siti che auditiamo è ormai AI-generated e i generatori non hanno ancora imparato l’HTML semantico.)
Minuto 4. Avvia un audit Lighthouse. Segna il punteggio CLS. Sopra 0,1 è borderline; oltre 0,25 rovina i clic degli agenti. Segna anche il punteggio accessibilità: lo stesso audit rileva label mancanti e problemi di contrasto che impattano sia gli screen reader sia gli agenti.
Minuto 5. Scegli il singolo problema peggiore tra i quattro report e annotalo. Domani risolvi solo quello. Non tentare di sistemare tutta la lista.
Cinque minuti è il budget reale che la maggior parte dei marketing lead ha. Se ne hai di più, meglio, approfondisci. Se no, questo loop basta a far emergere il problema più grande del tuo sito—di solito tutto ciò che ti serve sapere.
Tre pattern causano la maggior parte dei fallimenti che vedo. Il primo è il pulsante in <div> stilizzato. Sembra un pulsante, ha uno stato hover, reagisce al clic, ma per l’albero di accessibilità non è un pulsante.
"Non usare un
<div>,<span>o un altro elemento non interattivo. Se non puoi raggiungerlo con Tab da tastiera, probabilmente è una pessima idea usarlo."— Adrian Roselli, Links, Buttons, Submits, and Divs, Oh Hell
Roselli lo scrisse nel 2016, un decennio prima che qualcuno pronunciasse “AI agent” in questo contesto. L’euristica del tab-tastiera che descrive si sovrappone perfettamente all’agente-readability di oggi: se la tastiera non lo raggiunge, l’a11y tree non lo esporrà e un agente Playwright non lo vedrà. Il conto di dieci anni di pulsanti in <div> è arrivato.
Il secondo pattern è l’instabilità di layout. L’abbiamo vista di brutto durante la migrazione da .io a .com. Alcune nuove hero image lazy-load sul lato .com spostavano il pulsante “Get started” di 40 px circa 800 ms dopo il rendering. Gli utenti umani quasi non se ne accorgevano. Gli agenti Playwright identificavano il pulsante nella posizione originale, attendevano, e cliccavano lo spazio vuoto. Non è un’ipotesi: Playwright issue #6238 documenta il problema e resta aperto. Il CLS di Lighthouse è il proxy che mi fido di usare. Oltre 0,1 è sospetto.
Il terzo pattern sono gli overlay fantasma. Banner cookie che non si chiudono, popup GDPR con backdrop trasparente lasciato dopo la chiusura, widget intercom a z-index 9999 sopra la CTA. Ognuno intercetta i clic destinati a qualcosa di visibile sotto. Web.dev li cita esplicitamente e il nostro vibe-coded scanner li segnala.
"Questi dispositivi si basano sull’Accessibility Tree—il meccanismo che i computer usano per permettere alla tecnologia assistiva di leggere e interpretare i contenuti dell’interfaccia utente—in modo programmatico. Affidandoci a markup collaudato, rendiamo il nostro lavoro versatile e robusto."
— Eric Bailey, Truths about digital accessibility
Bailey lo ha scritto nel 2019 parlando di screen reader. La frase che continuo a citare è “il meccanismo che i computer usano”. Definiva l’albero di accessibilità come interfaccia programmatica per le macchine, non solo per persone con disabilità. L’arrivo degli agenti AI fa convergere tre compiti (accessibilità, crawlability SEO, agent-readability) in un’unica esigenza: produrre una descrizione machine-readable pulita di ciò che fa la tua UI.
Trovi una trattazione più lunga del lato SEO in accessibility-for-SEO. Il riassunto: le stesse correzioni (HTML semantico, nomi accessibili, layout stabile) muovono tre KPI insieme.
Se non fai nient’altro, fai questo nell’ordine seguente.
<div>/<span> con <button>. Leva massima, costo minimo. Ti rende “visibile” per agenti a11y-first come browser-use, Mariner e crawler Playwright.<label for> a ogni input di form. Il placeholder non è un nome accessibile.<h1> per pagina, ecc.
Ho visto team passare due settimane a pubblicare un llms.txt prima di correggere il pulsante checkout in <div>. Ordine inverso.
Hai deployato le fix. E adesso?
Per la stabilità di layout, l’audit Lighthouse è la metrica più economica e affidabile. Eseguilo sullo stesso URL prima e dopo, osserva CLS, punteggio accessibilità e INP muoversi insieme. (Pulendo i pulsanti <div> sulle nostre pagine marketing, il punteggio accessibilità Lighthouse è salito di 14 punti e il CLS è sceso da 0,18 a 0,04.)
Per la leggibilità agli agenti, riesegui l’agent-ready check. Il tool restituisce un punteggio di parseabilità più l’elenco delle CTA raggiunte o mancate. La metrica che guardo è “CTAs riconosciute con successo”: se non è 100 %, l’agente sta ancora indovinando da qualche parte.
Per le citazioni AI (l’output SEO che ti interessa), usa il nostro backlink checker per tracciare le menzioni nei riepiloghi AI. Le citazioni da ChatGPT, Perplexity e AI Overviews assomigliano ai backlink, solo da nuove fonti. Se le fix funzionano, vedrai aumentare le citazioni in settimane, non giorni. La nostra metodologia di audit AI visibility spiega il loop di misurazione lento.
Segnalo la statistica di Wil Reynolds che circola via Orbit Media, “0,8 % di traffico, 10 % di lead”, perché prima o poi la sentono tutti. È un dato reale e utile, ma viene da un’unica azienda in un periodo specifico, e Reynolds stesso ha chiarito che non è universale. Io lo prendo come prova che il traffico AI performa sopra la media, non come moltiplicatore da forecast. Se il tuo traffico AI converte 5× la media organica, hai qualcosa; se non lo fa, quel moltiplicatore non vale per te.
WebMCP è la spec da tenere d’occhio. Permette a un sito di registrare strumenti JavaScript che gli agenti AI possono chiamare direttamente, trasformando la pagina in un server Model Context Protocol. Chrome 146 Canary ha introdotto una preview con flag; Edge 147 ha aggiunto supporto a marzo 2026. Il draft del W3C Community Group è del 23-04-2026.
Mi piace. Sono anche realista sui tempi. La spec stessa precisa: “Non è uno standard W3C né è nello Standards Track”. Nessun grande vendor LLM ha documentato l’uso di tool WebMCP. Il crawl Cloudflare conta meno di 15 siti che implementano MCP Server Cards. È una storia da 2-5 anni, nella migliore ipotesi.
"Il browser web è progettato per utenti umani e developer, non per sistemi AI agentici. La maggior parte dei contenuti è strutturata per la fruizione visiva, non programmatica, con elementi dinamici, layout complessi e componenti interattivi che resistono a un parsing semplice."
— Cobus Greyling, The Future of Web Browsing AI Agents
Greyling sostiene che la checklist agent-friendly (questo articolo, in pratica) sia un workaround per un mismatch architetturale più profondo che standard come WebMCP tentano di risolvere. Potrebbe avere ragione. Non so se vincerà WebMCP, llms.txt, NLWeb di Microsoft o altro. So che la piramide di priorità sopra è il lavoro da fare ora, mentre lo strato di standard si assesta. Il nostro punto di vista è in agentic SEO workflows.
Un sito che può essere letto e usato in modo affidabile dagli agenti AI (Claude computer-use, OpenAI Operator, Project Mariner, crawler Playwright) oltre che dagli umani. Requisito chiave: elementi interattivi chiari nell’albero di accessibilità, layout stabile mentre l’agente opera, contenuti importanti renderizzati server-side così i crawler senza JS possono leggerli.
Usano una o più fra tre modalità: screenshot, HTML grezzo, albero di accessibilità. Gli agenti solo-screenshot (computer-use di Anthropic) ragionano in pixel e ignorano target sotto ~8 px². Quelli DOM-aware (Mariner, Operator) sovrappongono dati sugli elementi. Gli agenti a11y-first (browser-use, molti crawler Playwright) ottengono una mappa strutturale pulita ma perdono ciò che non è esposto semanticamente.
Bing ha confermato che lo schema aiuta Copilot a capire i contenuti. Google ha ammesso che i dati strutturati danno un vantaggio nei risultati. Le prove dirette sull’aumento di citazioni AI sono miste: uno studio non ha trovato correlazioni, un altro ha visto un 61,7 % di citazioni con schema ricco di attributi. Consideralo utile per il lato AI-search, non come moltiplicatore garantito.
È un formato proposto (simile a robots.txt) che indica ai crawler AI dove trovare i contenuti importanti in formato pulito. A ottobre 2025 lo avevano pubblicato oltre 844 000 siti. L’adozione è alta, il consumo basso: John Mueller e Gary Illyes di Google hanno dichiarato che nessun grande sistema AI lo usa come segnale operativo. Pubblicalo se hai 10 minuti; non priorizzarlo rispetto ai pulsanti in <div>.
Il percorso più rapido è un audit da 5 minuti: agent-ready check, pannello Accessibility in DevTools, report Lighthouse e scanner vibe-coded. Insieme fanno emergere il problema più grosso. Risolvi prima quello, poi passa al successivo.
Gli agenti AI leggono il tuo sito tramite screenshot, DOM e albero di accessibilità, in mix diversi a seconda del vendor. La maggior parte delle correzioni coincide con le best practice di accessibilità: elementi semantici nativi, nomi accessibili, layout stabile, contenuto server-side. Lo strato di standard (WebMCP, llms.txt, NLWeb) è reale ma lento; le correzioni meno sexy sono urgenti.
Esegui il nostro agent-readiness check gratuito per scoprire quanto è leggibile il tuo sito da ChatGPT, Claude e Perplexity. Ti dirà quali CTA l’agente ha mancato, quali pulsanti sono spariti dall’a11y tree e quali layout shift stanno mangiando clic. È lo strumento che avrei voluto il giorno in cui GPT non vedeva i nostri hover.
no credit card required