Audit SEO tecnico AI: i 5 layer oltre Googlebot nel 2026

Cloudflare ha misurato nel primo trimestre 2026 che il 30,6% del traffico web globale arriva da bot, e che il 89,4% di quel traffico bot AI è costituito da training crawler che hanno un solo obiettivo: leggere il tuo sito per addestrare un modello. Per anni ho fatto audit SEO tecnici pensando a un solo lettore non umano, Googlebot. Oggi i lettori non umani sono almeno una dozzina, e si comportano in modi profondamente diversi.

Il problema operativo non è teorico. Un audit SEO tecnico classico ti dice se Googlebot riesce a renderizzare la pagina, se i link sono crawlabili, se la SERP organica intercetta la query. Tutte cose ancora valide. Ma se il tuo sito è una single-page application costruita in client-side rendering, GPTBot vede una pagina vuota. Se hai messo il contenuto critico dentro un <div> con onClick, ChatGPT Atlas non sa che è un pulsante. Se non hai mai sentito parlare di crawl-to-referral ratio, stai dando in pasto il tuo sito a ClaudeBot che ti restituisce in media un visitatore ogni 20.600 pagine lette.

Questo articolo è il check che ho aggiunto al mio audit SEO tecnico per il 2026. Cinque layer concreti, ognuno con cosa verificare, come testarlo e cosa correggere. Tutto si appoggia sulla traccia uscita su Search Engine Journal il 24 aprile 2026, che ho integrato con dati italiani, esperienze sul campo e un’onesta lista di cose che ancora non sappiamo.

Audit SEO tecnico nel 2026: il sito non lo legge più solo Googlebot

Un audit SEO tecnico nel 2026 deve mappare almeno tre categorie di bot, non più solo Googlebot: i training crawler delle AI, i search crawler che servono risposte in tempo reale e gli agenti che navigano per conto di un utente. Nel 2018 mi bastava un solo lettore macchina, Googlebot, e un singolo obiettivo, posizionarsi in SERP. Quel modello regge ancora per la maggior parte del traffico, ma non descrive più la totalità del problema. I bot che bussano oggi a un sito si dividono, secondo le metriche pubbliche di Cloudflare, in tre categorie funzionali distinte.

La differenza pratica è enorme. Un training crawler che legge la tua pagina oggi ti restituirà valore solo se il modello, addestrato fra qualche mese, citerà il tuo dominio in una risposta. Un search crawler agisce come un retrieval engine in tempo reale, simile a come faceva Bing per Edge anni fa. Un agent invece sta navigando per conto di un utente che ha chiesto qualcosa al suo browser, e si aspetta che la pagina sia attivamente usabile, non solo leggibile.

Cloudflare ha pubblicato a marzo 2026 i rapporti crawl-to-referral, cioè quante pagine un bot AI legge prima di rimandare un singolo utente sul tuo sito. ClaudeBot di Anthropic ha un rapporto medio di rete di circa 20.600 a 1. OpenAI sta a circa 1.300 a 1. Sono medie aggregate: il rapporto effettivo per il tuo sito può essere migliore o decisamente peggiore a seconda del tipo di contenuto e della frequenza di scrittura. Significa che a parità di costi serviti (banda, risposte CDN), Anthropic in media ti ridà il 6% di traffico in confronto a OpenAI. Sapere questi numeri ti serve per decidere chi bloccare e chi lasciare passare, perché il modello di "do tutto a tutti" si paga in banda e in nulla.

Se vuoi un ripasso del funzionamento del crawler "classico" prima di andare avanti, ho scritto la guida a come funziona Googlebot nel 2026 che spiega il limite dei 2 MB e il Web Rendering Service.

Layer 1: chi accede al tuo sito e con quale user-agent

Il primo passo dell’audit tecnico aggiornato è una mappatura sincera dei bot AI che bussano alla porta. Per farla in modo serio servono due fonti: i log del server (o il dashboard Cloudflare AI Audit, se il sito è dietro Cloudflare) e una tabella aggiornata di user-agent stringhe ufficiali, documentata dal vendor stesso.

Ecco quelli che oggi rappresentano la quota più rilevante del traffico AI sui siti italiani che monitoro. Se non hai Cloudflare davanti al sito, per estrarre questo segnale dai log Apache/nginx servono tool dedicati: Screaming Frog Log File Analyser è quello che uso più spesso, GoAccess è l’alternativa open source, su volumi enterprise gli standard sono Splunk o Datadog.

Una riga su cui voglio fermarmi un attimo è Google-Agent. Il 20 marzo 2026 Google ha annunciato l’user-agent dei task agentici eseguiti per conto di un utente Gemini. Secondo le ricostruzioni pubbliche (Search Engine Land, ufficialmente non documentato in dettaglio), Google-Agent agisce come "proxy utente" e tende a ignorare robots.txt come farebbe un browser. Per bloccarlo davvero ti serve autenticazione lato server o una regola firewall che riconosce gli IP ufficiali (Google pubblica un file JSON con i range, lo trovi nella documentazione developer). In aggiunta, una risposta 429 Too Many Requests verso gli user-agent training (GPTBot, ClaudeBot) è il modo più efficace per gestire la pressione di banda senza cancellarli del tutto dal robots.txt.

Cosa controllare nel robots.txt

Apri il robots.txt del sito. Verifica che ogni user-agent della tabella sopra abbia una regola esplicita. L’errore più comune che vedo è un Disallow: / generico per User-agent: * che però viene scavalcato da regole specifiche più permissive scritte sotto. L’altro errore frequente è dimenticarsi che bloccare GPTBot non blocca OAI-SearchBot, che è l’user-agent diverso usato per ricerche live in ChatGPT. Se vuoi essere visibile in ChatGPT Search ma non finire nel training di GPT-5, devi bloccare GPTBot e lasciare passare OAI-SearchBot e ChatGPT-User.

Il trade-off è reale e va deciso in base al contenuto. Per un blog come il mio, dove i contenuti sono il prodotto, lasciare passare i training crawler ha senso solo se accetto che la mia voce contribuisca al modello senza ritorno diretto. Per un e-commerce con descrizioni prodotto uniche, scritte da un copywriter pagato, la scelta è meno ovvia: rischi che il modello impari a riformulare le tue schede e a bypassarti.

Layer 2: la pagina è leggibile senza JavaScript?

Questo è il punto su cui mi gioco la metà degli audit tecnici per i clienti che hanno il sito su Next.js, Nuxt o framework simili. Googlebot e AppleBot eseguono JavaScript con un Web Rendering Service. GPTBot, ClaudeBot, PerplexityBot, CCBot, secondo Cloudflare e secondo i 500 milioni di fetch GPTBot analizzati da Passionfruit nel 2025, leggono solo l’HTML iniziale che il server restituisce. Niente esecuzione JS, niente DOM dinamico.

La conseguenza è semplice. Se la tua homepage è una single-page application, il primo HTML che esce dal server è probabilmente uno shell vuoto con un <div id="root"> e un bundle JavaScript. GPTBot vede quello. ClaudeBot vede quello. Il modello non può citare ciò che non legge.

Il test in 30 secondi col curl

Apri un terminale e simula GPTBot con un comando. Lo riporto qui in formato eseguibile, sostituisci l’URL con la tua homepage o la pagina che ti interessa più.

curl -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible) GPTBot/1.2; +https://openai.com/gptbot" -s https://tuosito.it

Se la risposta contiene il testo dei tuoi articoli, i tuoi titoli, i tuoi link, sei al sicuro. Se ricevi uno shell HTML con qualche meta tag e un <div id="root"></div> vuoto, i bot AI senza rendering non vedono nulla. Il fix è server-side rendering (SSR) o static site generation (SSG): in Next.js sono entrambe attivabili con poche righe, in Nuxt è il default, in SvelteKit pure.

Una nota onesta: c’è una fonte del 2025 (Seresa, dominio specializzato in WooCommerce) che riporta GPTBot e ClaudeBot mentre eseguono JavaScript al punto da sparare pixel di tracciamento. Il consenso pubblico resta che non eseguono JS, ma se gestisci un e-commerce e vedi richieste anomale ai tuoi pixel, vale la pena indagare. Il quadro non è perfettamente stabile.

View Source vs Inspect Element

Chrome ha due funzioni che molti developer confondono. View Source (Ctrl+U) ti mostra l’HTML iniziale, quello che il server ha mandato al browser, prima che JavaScript abbia toccato qualcosa. Inspect Element ti mostra il DOM corrente, dopo che JS ha lavorato. L’audit tecnico AI-aware si fa su View Source, perché è quello che leggono GPTBot e gli altri. Se View Source è povero ma Inspect è ricco, hai un problema di accessibilità ai crawler senza rendering.

Layer 3: structured data, il ponte semantico verso le AI

Lo schema markup è la forma di metadati più leggibile per gli LLM, molto più del testo libero o del solo HTML semantico. Il motivo è strutturale: JSON-LD è un blocco contiguo dentro <script type="application/ld+json">, separato dal corpo della pagina, parsificabile in due righe di Python. Microdata e RDFa sono spalmati nei tag e fanno fatica a sopravvivere alle ricomposizioni del modello.

Tre dati che cito spesso ai clienti che mi chiedono se vale la pena investire nello schema. Una ricerca accademica congiunta di Princeton, Georgia Tech e Allen Institute pubblicata nel 2024, conosciuta come paper GEO, ha misurato che aggiungere statistiche citate e schema strutturato migliora la visibilità nelle risposte AI fino al 41% rispetto al baseline (è il massimo del range, la media è attorno al +30%). Una analisi di Yext aggiornata a gennaio 2026 su 17,2 milioni di citazioni AI ha trovato che i siti data-rich ricevono 4,3 volte più citazioni rispetto a siti con dati sparsi o assenti. Microsoft (Fabrice Canel a SMX Munich, marzo 2025) e Google Search team (Search Central Live NY, aprile 2025) hanno entrambi confermato pubblicamente che lo schema markup aiuta i loro LLM a comprendere il contenuto.

Per il dettaglio tecnico su quali schema implementare e come, ho una guida dedicata ai dati strutturati e schema.org per la SEO che resta il punto di partenza per chiunque non li abbia mai messi in piedi.

Gli schema che servono davvero per le AI

Sui siti che audito guardo che almeno questi siano presenti, validati e coerenti col contenuto della pagina:

• Organization, completo di nome, URL, logo, sameAs verso LinkedIn, Wikidata, Crunchbase
• Article (o BlogPosting) per ogni post, con headline, datePublished, dateModified, author Person, image
• Person per l’autore, con sameAs verso profili professionali attivi (questo conta più di quanto credi)
• Product per le pagine prodotto, con price, aggregateRating, brand, sku
• FAQPage per blocchi di domande frequenti, scritti come testo nella pagina e replicati nello schema
• BreadcrumbList per la navigazione, perché aiuta gli agenti a capire dove sono

La proprietà sameAs nello schema Person e Organization merita un’attenzione particolare. Will Scott in un’analisi di luglio 2025 ha mostrato che la presenza di link sameAs verso fonti autorevoli e profili attivi è uno dei segnali con maggior peso nel processo di entity recognition dei motori AI. Secondo Scott i profili dormienti sono peggio che assenti, perché tendono a indebolire il segnale invece di rafforzarlo. Pulire i sameAs vecchi è uno di quei micro-task ad alto rendimento che nessuno fa.

Layer 4: l’accessibility tree è il nuovo DOM per gli agenti

Questo è il layer dove faccio più fatica a far passare il messaggio quando spiego il concetto a sviluppatori di vecchia scuola. Browser agentici come ChatGPT Atlas (lanciato a ottobre 2025 da OpenAI, con feature update a gennaio 2026), Comet di Perplexity, Chrome auto-browse di Google con Gemini 3 (annunciato il 28 gennaio 2026, $19.99/mese in piano AI Pro), non guardano la tua pagina rendering pixel. Guardano l’accessibility tree, o un rappresentazione semantica equivalente.

L’accessibility tree è una rappresentazione parallela del DOM costruita dal browser per le tecnologie assistive. Elimina layout, CSS, animazioni. Mantiene struttura semantica: heading con il loro livello, link con il testo, button con il loro nome accessibile, form field con la loro label, regioni come <main>, <nav>, <aside>. È quello che leggono uno screen reader e, oggi, anche un agent navigatore. Microsoft Playwright MCP, uno degli standard più diffusi per far navigare un LLM dentro un browser, restituisce snapshot dell’accessibility tree, non screenshot. Che i browser agentici commerciali lo usino direttamente non è documentato in dettaglio dai vendor, ma il principio è lo stesso: lavorano sulla struttura semantica, non sul pixel.

La conseguenza è che un <div class="btn" onclick="...">Acquista</div> per un browser agentico è invisibile come pulsante. È un blocco di testo. Il click non è discoverable. Sul tuo sito quel pulsante funziona perché il visitatore vede uno sfondo blu, gli sviluppatori lo riconoscono. ChatGPT Atlas non lo riconosce perché non è marcato come <button> e non ha role="button". Lo stesso vale per immagini senza alt, link senza testo, form senza label.

WebAIM ha pubblicato a febbraio 2026 il Million Report annuale, l’analisi automatica del top milione di home page web. Risultato: media di 56,1 errori di accessibilità per pagina, in aumento del 10,1% rispetto al 2025. Dato controintuitivo: le pagine che usano ARIA hanno in media 59,1 errori, contro 42 di quelle senza ARIA. Tradotto: ARIA mal implementato peggiora la situazione invece di migliorarla. Aggiungere aria-label a caso non aiuta nessuno.

A febbraio 2026 John Mueller ha definito su Bluesky "a stupid idea" la proposta di servire markdown ai bot al posto di HTML, sostenendo che il significato sta nella struttura, nella gerarchia e nel contesto, non nel testo nudo. Un H1 dentro un <article> dentro un <main> dice qualcosa di diverso da "## Titolo" su una riga di testo. Mueller ha ragione: gli agenti hanno bisogno della stessa struttura che hanno sempre aiutato i lettori non vedenti.

Il check pratico in cinque minuti

Apri DevTools, sezione Accessibility (in Chrome è dentro la tab Elements). Clicca sui tuoi pulsanti più importanti, le call-to-action, i link di navigazione. Per ognuno, leggi cosa appare nel pannello: ruolo (button, link, generic?), nome accessibile (descrittivo o vuoto?), stato. Se trovi role="generic" su un elemento che è un pulsante, hai trovato un problema. Per un audit più sistematico, axe DevTools o Lighthouse fanno il lavoro a tappeto. Personalmente uso anche Playwright MCP via Claude Code per ottenere lo snapshot esatto che vedrebbe un agent.

Layer 5: llms.txt, una verità scomoda da dire

llms.txt è una specifica markdown proposta da Jeremy Howard di Answer.AI a settembre 2024. L’idea è di pubblicare un file plain text alla root del sito (/llms.txt) che dichiari struttura, contenuti chiave e link autorevoli, in modo che un LLM possa "capire" il sito senza dover crawlare migliaia di pagine. Su carta è elegante. In Italia "llms.txt" è una keyword da 720 ricerche al mese secondo Google Ads, segno che il tema interessa.

Cosa devo dirti onestamente? BuiltWith stima 844.000 siti che hanno implementato llms.txt a ottobre 2025. SE Ranking ha analizzato 300.000 domini e ne ha trovati con llms.txt il 10,13%. Nessuno dei top 1.000 siti globali lo usa. Ma il punto vero è un altro: nessun vendor LLM, né OpenAI, né Anthropic, né Google, né Perplexity, ha mai dichiarato pubblicamente di consumare llms.txt dai siti che crawlano. Lo pubblicano sulle proprie docs (platform.openai.com/llms.txt esiste), ma non lo leggono da te. John Mueller e Gary Illyes nel 2025 hanno detto pubblicamente che Google non usa llms.txt come segnale operativo.

SE Ranking nello stesso studio non ha trovato correlazione fra presenza di llms.txt e citazioni AI. L’analisi indipendente "AM I Cited" ha confermato il dato. Quindi cosa fai? Lo metti perché costa zero, perché alcuni LLM lo suggeriscono come best practice quando glielo chiedi, e perché in due-tre anni potrebbe diventare lo standard ufficiale dei motori AI. Ma non aspettarti un effetto sulla visibilità misurabile oggi. Mettere llms.txt al posto di un audit serio degli altri quattro layer è un’illusione di lavoro fatto.

I limiti dell’audit SEO tecnico AI-aware

Voglio essere chiaro su cosa questo lavoro non risolve, perché ho visto troppi consulenti vendere audit AI come pillola magica.

Primo limite: questi cinque layer non spostano direttamente il ranking organico Google. Servono a farti vedere dai crawler AI e dagli agenti, ma non sostituiscono un audit SEO tradizionale su Core Web Vitals, sitemap, indicizzazione, crawl budget, internal linking. Se il sito non si posiziona in SERP, llms.txt non lo salva. Devi avere entrambi i piani in testa.

Per chi sta partendo e vuole prima sistemare le basi, il punto di partenza resta la guida pratica al SEO audit in 7 passi che copre il versante "umano" e Google-first.

Secondo limite: i dati su citazioni AI cambiano ogni mese. Quando uno studio dice "i siti data-rich ricevono 4,3 volte più citazioni", il dato è valido per un campione, in un periodo, su un set di modelli specifico. Tre mesi dopo, OpenAI cambia il sistema di retrieval, Perplexity rilascia un nuovo modello, e il numero si sposta. Quello che resta stabile sono i principi: schema valido, HTML semantico, JS rendering risolto, sameAs puliti. I numeri specifici no.

Terzo limite: il ROI diretto è difficile da misurare. Esistono tool come Otterly AI o Profound che provano a tracciare le menzioni AI, ma il segnale è rumoroso e i campioni piccoli. L’unico tracciamento gratuito che consiglio in tutti gli audit è una segmentazione GA4 sui referral provenienti da chat.openai.com, perplexity.ai, claude.ai, copilot.microsoft.com e gemini.google.com: è il modo più diretto per vedere se gli utenti delle AI atterrano davvero sul sito, e in molti contesti italiani (PMI, consulenza locale) restituisce numeri ancora a singola cifra percentuale del traffico totale. Investire metà del budget in lavoro AI-only senza prima aver risolto Googlebot è quasi sempre un calcolo sbagliato.

Quarto limite, il più ovvio: l’audit AI-aware si concentra sulla forma. Se il contenuto sotto è povero, la struttura tecnica perfetta non lo salva. Una pagina ben marcata semanticamente con schema impeccabile ma con quattro paragrafi generici scritti da un’AI verrà ignorata. Lo abbiamo visto bene nei dati di citazione recenti.

Sul versante contenuto ho scritto un pezzo dedicato a perché il great content da solo non basta più nell’era AI search e su come distribuire la tua voce fuori dal tuo dominio.

Da dove iniziare se hai un’ora di tempo

Se hai un’ora libera e vuoi capire dove sta il tuo sito sui cinque layer, questa è la sequenza che seguo io quando faccio una valutazione preliminare.

• Minuti 0-10: log e robots.txt: apri Cloudflare AI Audit (o i log server) e identifica i tre user-agent AI più frequenti delle ultime 4 settimane. Confronta con il robots.txt del sito. Annota le mancate copperture.
• Minuti 10-25: test curl rendering: fai curl con UA GPTBot sulla homepage e su tre pagine prodotto/articolo. Verifica che il contenuto principale sia in HTML iniziale. Se non lo è, il fix SSR è la priorità numero uno.
• Minuti 25-40: schema audit: apri Schema Markup Validator e Google Rich Results Test su cinque pagine rappresentative. Verifica Organization, Article, Person, sameAs. Lista delle proprietà mancanti, non implementi tutto subito.
• Minuti 40-50: accessibility quick check: lancia Lighthouse in DevTools, sezione Accessibility. Punteggio sotto 90 vuol dire che gli agenti faranno fatica a navigarti. Le tre voci più gravi diventano i tuoi prossimi ticket di sviluppo.
• Minuti 50-60: piano azione: metti in fila i fix per impatto stimato e costo di sviluppo. SSR di solito è alto impatto ma richiede settimane. Schema markup è basso impatto singolo ma facile e cumulativo. Pulizia robots.txt è gratis e immediata.

Questo non è un audit completo. È una mappa. Un audit completo richiede decine di ore, accesso ai log, monitoring continuo nel tempo. Ma in un’ora puoi sapere dove stai, e questo basta per non spendere il prossimo trimestre a inseguire la moda di llms.txt mentre la tua homepage è invisibile a GPTBot.

Cosa lascio per il prossimo audit

Tre cose che mi sono segnato per i prossimi mesi e che oggi non ho ancora abbastanza dati per dirti come comportarti. Primo, il browser AI di OpenAI Atlas e quello di Perplexity Comet stanno introducendo session memory e personalizzazione, e questo cambierà il modo in cui i siti dovranno presentare contenuti dinamici a un visitatore agentico. Secondo, Google sta sperimentando con AI Overviews che pescano da fonti non indicizzate in modo classico, e non è chiaro come questo impatterà la relazione fra ranking organico e citation share. Terzo, gli standard tipo llms.txt o le proposte W3C su AI access manifest potrebbero formalizzarsi nei prossimi diciotto mesi e cambiare il quadro normativo.

Per restare aggiornato sull’evoluzione AI search nel 2026 la mia content strategy GEO 2026 con dati aggiornati è il pezzo che integra il discorso lato contenuto.

Se gestisci un sito e vuoi capire a che punto sei con questi cinque layer, su quali servizi di consulenza SEO lavoro e come strutturo i percorsi lo trovi nella pagina dedicata; mi puoi scrivere dalla pagina contatti per partire. I primi venti minuti sono gratis.