Audit tecnico AI di un sito: workflow operativo in 12 punti

Un sito che ranka su Google può essere completamente invisibile a ChatGPT, Perplexity e Claude. Misurare la presenza nei chatbot e ottimizzare la lettura da parte dei crawler AI richiede un audit tecnico diverso dalla SEO tradizionale.

Non è una SEO 2.0. È un esercizio parallelo, con priorità diverse, tool diversi, KPI diversi.

Faccio audit tecnici AI da circa diciotto mesi su clienti di vari settori. I problemi che trovo sono molto ricorrenti. La checklist che segue copre il 90 per cento dei casi reali in cui un sito perde citazioni AI per ragioni tecniche risolvibili.

Perché serve un audit specifico per le AI

Una SEO audit tradizionale guarda crawlability, indicizzazione, segnali on-page, struttura, performance, backlink. Un audit AI guarda alcune di queste cose con priorità diverse, e aggiunge dimensioni nuove.

Le dimensioni nuove: comportamento dei crawler AI specifici (GPTBot, ClaudeBot, PerplexityBot, Applebot-Extended), citazioni del sito nelle risposte chatbot, presenza nei dataset di training pubblici (Common Crawl, C4, RefinedWeb), leggibilità del contenuto senza JavaScript renderizzato, qualità degli structured data destinati agli LLM.

Le priorità riviste: structured data prima della velocità, authorship prima del backlink, contenuto in chiaro prima del design. Le tre cose che pesano di più in audit AI sono quelle che pesano di meno in audit SEO classico.

Niente di questo annulla la SEO classica. La integra. Un sito mal indicizzato su Google difficilmente verrà letto bene da ChatGPT, perché molti modelli usano Common Crawl che è correlato alla scopribilità Google. Quindi prima si sistema la base SEO classica, poi si aggiunge il layer AI.

La checklist in dodici punti

I dodici passaggi, da eseguire in sequenza la prima volta e poi in ciclo trimestrale:

• Robots.txt e politiche crawler AI. Verificare che GPTBot, ClaudeBot (Claude-Web e ClaudeBot), PerplexityBot, Applebot-Extended, Google-Extended, CCBot non siano bloccati per errore. Molti siti hanno robots.txt copiati da template del 2022 che escludono questi user agent senza intenzione. Verificare anche se ci sono direttive contraddittorie. Bloccare il crawler equivale a sparire dai chatbot in 6-12 mesi.
• Sitemap XML aggiornata e referenziata. Sitemap che include tutti gli URL canonici, freschi, accessibili (codice 200). Referenziata nel robots.txt e dichiarata in Search Console. I crawler AI usano la sitemap come scorciatoia di discovery quando l’inferenza link-by-link costa troppo.
• Server-side rendering verificato. Aprire una pagina pillar con JavaScript disabilitato. Il contenuto principale deve essere visibile. Se il sito è una single-page app (React, Vue, Angular) senza SSR o pre-rendering, gli LLM vedono pagine vuote. Soluzioni: SSR nativo, static generation, o un servizio tipo Prerender.io per le pagine pubbliche.
• Schema.org Article/BlogPosting su tutti i pillar. JSON-LD nel head, validato con Rich Results Test. Author come Person con sameAs ricco. Organization come publisher con dati verificabili. datePublished e dateModified distinte e accurate.
• Page autore popolata. Ogni autore citato negli Article markup deve avere una pagina dedicata, indicizzata, con biografia reale, foto, link a profili esterni, elenco articoli scritti. Senza pagina autore, il Person markup nell’Article è un’asserzione non verificabile per gli LLM.
• About e contatti trasparenti. Pagina /chi-siamo/ con sede legale, codice fiscale, contatti email reali (non solo form), profilo del team se applicabile. Per gli LLM è un segnale di Trustworthiness. Per Google idem. Per gli utenti che fanno due ricerche prima di comprare, ancora più importante.
• Hreflang e lingue. Se il sito esiste in più lingue, hreflang configurato correttamente, ogni versione linguistica con sua URL pulita, structured data nella lingua corretta. Gli LLM trattano le versioni linguistiche come asset distinti e premiano la coerenza di marcatura.
• Velocità e Core Web Vitals. PageSpeed Insights pulito (LCP sotto 2,5 secondi, CLS sotto 0,1, INP sotto 200 ms). Conta meno per le AI rispetto a Google ranking, ma siti lenti vengono crawlati meno spesso anche dai bot AI, e quindi aggiornano meno il loro contenuto nei dataset.
• HTTPS, HTTP/2 o HTTP/3. Certificato valido, redirect 301 da HTTP a HTTPS, da www a non-www (o viceversa) consistente. HTTP/2 minimo, HTTP/3 dove possibile. I bot AI moderni privilegiano connessioni più rapide.
• Monitoring citazioni nei chatbot. Configurazione di Otterly.ai o Profound (vedi anche il pezzo sul monitoraggio AI per aziende) con un set di 20-30 prompt rilevanti per il settore. Misurazione settimanale. Senza questo monitoring, sei cieco su metà dei segnali che contano.
• Test manuale prompt su tre chatbot. Mensilmente, testare manualmente 5-10 prompt ad alto valore commerciale su ChatGPT, Perplexity e Gemini. Osservare quali fonti vengono citate. È informazione qualitativa che Otterly non cattura nello stesso modo: il contesto della risposta, il tono delle citazioni, la posizione del tuo brand nella narrazione AI.
• Log server analisi crawler AI. Estrarre dai log server le richieste di GPTBot, ClaudeBot, PerplexityBot degli ultimi 30 giorni. Quante volte hanno crawlato, quali URL, con quale codice di risposta. Se vedi solo errori 404 o 500 sulle pagine pillar, hai un problema tecnico. Se non vedi traffico crawler AI per niente, c’è un problema più grave da indagare a monte.

Dodici punti. Tre ore di lavoro per un audit completo su un sito medio. Sei ore se il sito è grande. Un giorno se ci sono problemi strutturali profondi da analizzare.

Robots.txt, il punto numero uno per ragione

Tra i dodici passaggi, il primo è anche quello dove ho trovato più sorprese nei miei audit. Dei venti siti italiani che ho controllato nel 2025, otto avevano almeno un crawler AI bloccato per errore nel robots.txt.

Gli scenari tipici: un consulente SEO ha aggiunto Disallow per GPTBot per “proteggere i contenuti dall’addestramento” senza chiedere al cliente. Un developer ha copiato un robots.txt da un blog di Stack Overflow del 2023. Un’agenzia ha messo in produzione una configurazione di test che bloccava tutti i bot AI. In nessuno di questi casi la scelta era stata consapevole e strategica.

La domanda da fare al cliente prima di procedere: “Vuoi essere citato nei chatbot AI?”. Se la risposta è sì, niente Disallow su GPTBot, ClaudeBot, PerplexityBot e Google-Extended. Se la risposta è no (caso legittimo per alcuni publisher con paywall e accordi commerciali separati), allora Disallow esplicito e consapevole, documentato.

Una distinzione operativa che vale la pena conoscere. Esistono due tipi di crawler AI: quelli che alimentano direttamente le risposte in tempo reale (ChatGPT-User, Claude-Web, PerplexityBot) e quelli che raccolgono dati per training futuro (GPTBot, ClaudeBot, Google-Extended, CCBot). Hanno trattamenti diversi nelle policy AI di alcune testate. Se un publisher non vuole che il suo contenuto entri nei dataset di training ma vuole essere citato in tempo reale, può bloccare i secondi e permettere i primi. È una scelta che richiede consapevolezza, non un copia-incolla.

Server-side rendering, l’ostacolo invisibile

Il punto tre della checklist è quello dove i siti moderni perdono di più. React, Next.js senza SSR configurato, Vue senza Nuxt, applicazioni single-page con routing client-side: tutto questo produce pagine che gli LLM leggono parzialmente o per niente.

Verifica concreta in due minuti: aprire una pagina pillar in Chrome, F12, scheda Network, filtrare per “Doc”, ricaricare. Cliccare sulla prima richiesta, andare nella scheda Response. Quello che si vede lì è (più o meno) quello che vede un crawler senza JavaScript. Se il contenuto principale dell’articolo non c’è, hai un problema.

Soluzioni in ordine di costo crescente. Pre-rendering statico per le pagine pubbliche tramite Next.js export, Nuxt static, Gatsby. Servizio terzo tipo Prerender.io che intercetta i bot e serve loro l’HTML renderizzato. Migrazione a SSR completo, che richiede settimane di lavoro per riarchitettare il routing e la gestione stato.

Log server, il punto che pochi guardano

Il punto dodici, analisi log server, è quello che dà più informazione a chi sa leggerla. È anche quello che pochi fanno perché richiede accesso ai log raw del server, che non sempre l’agenzia o il consulente esterno ha.

Cosa cercare nei log. User-agent dei bot AI noti (lista aggiornata su Anthropic, OpenAI, Google docs). Numero di hit settimanali per ogni bot. URL più crawlati. Codici di risposta (qualsiasi cosa diversa da 200 è da indagare). Distribuzione temporale (alcuni bot crawlano in burst, altri in modo continuo).

Un caso reale. Cliente nel B2B SaaS, fatturato 4 milioni, blog con 80 articoli. Audit log ha rivelato che GPTBot crawlava regolarmente, ma ClaudeBot non era mai passato in tre mesi. Causa: regola firewall sul reverse proxy che bloccava IP range Anthropic come “traffico anomalo”. Risolto in due ore. Nei tre mesi successivi le citazioni del cliente in Claude sono cresciute da zero a sette su un set di 30 prompt monitorati.

Questo tipo di problema è invisibile dall’esterno e non lo trovi senza guardare i log. È il valore vero di un audit fatto bene rispetto a un check superficiale.

Secondo caso reale, di gennaio 2026. Cliente nel settore healthcare, presenza nazionale. Audit log mostra GPTBot che crawla regolarmente ma sempre con codice 403 sulle pagine pillar mediche. Causa: il WAF aveva una regola che bloccava user agent non standard sulle URL contenenti “diagnosi”, “sintomi” o “patologia”, come protezione anti-bot generica del 2021. Lista di parole costruita prima che esistessero crawler AI legittimi. Risolto whitelisting esplicito degli user agent AI noti. Sei settimane dopo, le citazioni del sito in ChatGPT su domande mediche sono passate da casuali a sistematiche.

Pattern ricorrente: configurazioni di sicurezza datate che fanno collateral damage sui crawler AI senza che nessuno se ne accorga. WAF, anti-bot, CDN con regole troppo aggressive, geolocation block. Ognuna di queste può bloccare crawler legittimi e nessuna lo segnala nelle dashboard di marketing. Solo i log lo mostrano.

Cadenza e ownership dell’audit

L’audit completo va eseguito una volta a setup, poi una volta a trimestre. I primi tre-quattro punti (robots.txt, sitemap, SSR, structured data) vanno controllati anche dopo ogni release importante del sito o dopo migrazioni infrastrutturali.

Ownership tecnica: deve essere chiaro chi è responsabile. In aziende strutturate, il SEO Manager con supporto del Dev Lead. In PMI, il consulente SEO esterno con accesso ai log. In freelance, il professionista stesso che gestisce sito e contenuti.

Senza ownership chiara, l’audit viene fatto una volta e poi dimenticato. Sei mesi dopo, una migrazione cambia il robots.txt e nessuno se ne accorge. L’audit non è un evento, è una pratica trimestrale documentata.

Una distinzione utile tra audit e monitoring. L’audit è il check trimestrale strutturato sui dodici punti. Il monitoring è il segnale di allarme continuo: tracciare giornalmente robots.txt change (con strumenti tipo ChangeTower o un semplice cron job che diffa il file), errori 5xx in Search Console, calo brusco delle citazioni in Otterly. Audit più monitoring insieme coprono lo spettro: il monitoring intercetta i problemi acuti, l’audit intercetta i problemi cronici. Solo uno dei due non basta.

Per chi vuole strutturare questo lavoro come servizio o per chi cerca un confronto operativo, AIPIA raccoglie professionisti che fanno audit AI come parte della loro offerta consulenziale, e che condividono benchmark, template e casi reali nelle attività della community. È il modo più rapido per evitare di rifare errori che altri hanno già fatto.

Un sito che fa audit AI ogni tre mesi nel 2026 mantiene una visibilità nei chatbot stabile e crescente. Un sito che lo fa una volta e poi dimentica regredisce in sei-dodici mesi senza accorgersene. La SEO tecnica AI-ready non è uno stato, è un processo. Trattatela come tale.