Vai al contenuto
Sitequiry

Pronti per la ricerca AI? I problemi di SEO tecnico più comuni che impediscono ai siti di essere trovati

Le risposte AI di Google, della ricerca di ChatGPT, di Claude e di Perplexity possono usare solo una pagina che un crawler è riuscito a scaricare e a leggere. Per questo i problemi più vecchi della SEO tecnica sono anche i primi problemi della ricerca AI: un link che finisce su un 404, una sitemap che elenca URL reindirizzati, una pagina il cui testo compare solo dopo l'esecuzione di JavaScript. Qui trovi i dati della nostra scansione di 90 siti, cosa documentano i motori di ricerca e le aziende AI su ciascun problema e cosa nessuno può ancora dirti.

Aggiornato Lettura: 10 min Scritto dal team GE-KO

Da dove vengono i numeri

Il 29 settembre 2026 SitequiryBot ha scansionato 106 siti noti (soprattutto sloveni e tedeschi, più siti in inglese e in altre lingue: negozi online, testate giornalistiche, servizi pubblici, aziende, turismo, organizzazioni non profit). La scansione si è conclusa per 90 siti; 13 hanno risposto al nostro crawler con 403, 429 o una verifica anti-bot e 3 hanno reindirizzato verso un altro dominio. Per ogni sito completato abbiamo analizzato fino a 20 pagine e controllato i 12.381 link interni trovati, con gli stessi controlli del Report del sito a pagamento.

Ogni dato conta siti, non pagine: un sito conta una volta per un problema, che l'URL coinvolto sia uno o siano cinquanta. Il campione è di comodo, fatto di siti noti, e non rappresenta il web nel suo insieme; 20 pagine non sono una scansione completa, quindi un sito che «supera» un controllo può avere lo stesso problema altrove. I dati su robots.txt, sitemap, llms.txt e markup sono pubblicati con il relativo metodo nel nostro studio sulla preparazione dei siti alla ricerca AI (in inglese). I dati tecnici di questa pagina vengono dalla stessa scansione e sono scaricabili, in inglese, in formato CSV e JSON con licenza CC BY 4.0. Non pubblichiamo risultati per singolo sito.

Scansione del 29 settembre 2026: siti con il problema
Problema Siti Percentuale
Link interno verso un URL che reindirizza 67 su 90 74%
Catena di redirect (due o più passaggi) 23 su 90 26%
Link interno verso una pagina 4xx/5xx 18 su 90 20%
Stesso title su due o più pagine indicizzabili 16 su 90 18%
Pagina renderizzata lato client: nessun contenuto nell'HTML del server 5 su 90 6%
URL della sitemap che reindirizza o restituisce un errore 15 su 75 con sitemap 20%
URL della sitemap con noindex 6 su 75 con sitemap 8%
Errore hreflang (manca l'autoriferimento o il link di ritorno) 4 su 31 con hreflang 13%
Canonical verso una pagina con errore, redirect o noindex 1 su 90 1%
Home page con noindex 1 su 90 1%

SEO classica e visibilità nell'AI: stesse fondamenta, ultimo passo diverso

Google è esplicito: le sue funzionalità AI non richiedono nulla in più. La pagina Funzionalità di AI e il tuo sito web spiega che una pagina deve essere indicizzata e idonea a comparire con uno snippet e che valgono le normali basi della SEO. Nessun markup o file speciale rende una pagina idonea per AI Overview o AI Mode.

Gli altri prodotti di ricerca AI mandano crawler propri. OpenAI usa OAI-SearchBot per mostrare i siti nella ricerca di ChatGPT, separato da GPTBot, che raccoglie dati per l'addestramento. Anthropic documenta Claude-SearchBot, Claude-User e ClaudeBot e dichiara che rispettano il robots.txt; Perplexity usa PerplexityBot per i suoi risultati di ricerca. Qualunque cosa facciano dopo, questi sistemi partono come un motore di ricerca: scaricano l'URL, seguono i link, leggono l'HTML.

È l'ultimo passo a cambiare. Un motore di ricerca ordina un elenco di pagine; una risposta AI sceglie pochi estratti e può citarli. Nessuna di queste aziende pubblica come vengono scelte le fonti da citare, e nessuna scansione, compresa la nostra, può misurarlo. Il livello tecnico decide una cosa più circoscritta e più facile da verificare: se una pagina può entrare o no tra le candidate.

1. I crawler vengono respinti prima di vedere una pagina

Il primo filtro è il robots.txt. Nel nostro studio 14 dei 90 siti (16%) bloccavano almeno uno dei quattro crawler di ricerca AI che controlliamo, e 18 (20%) almeno uno di 15 crawler AI di qualsiasi tipo. Da fuori non si vede se un blocco è voluto, quindi verifica che una regola scritta per fermare l'addestramento dell'AI non colpisca anche un crawler di ricerca. La verifica crawler AI mostra separatamente crawler di ricerca, recuperi avviati dagli utenti e crawler di addestramento, così vedi a cosa serve ciascun user agent.

Il secondo filtro è il firewall o la CDN, e il robots.txt non ne dice nulla. Dei 106 siti del nostro campione, 13 non hanno lasciato entrare affatto il nostro crawler, rispondendo con 403, 429 o una pagina di verifica. Lo stesso schema l'abbiamo trovato sul nostro sito: il 13 ottobre 2026 sitequiry.com consentiva tutti i crawler nel robots.txt, eppure il firewall dell'hosting restituiva 403 allo user agent Bytespider. Una protezione anti-bot che non distingue un crawler di ricerca da uno scraper può chiudere fuori OAI-SearchBot o PerplexityBot come chiunque altro, e il proprietario del sito non lo vedrà mai nel robots.txt.

Un terzo filtro, più silenzioso, è il noindex. Google fa notare che una pagina bloccata dal robots.txt non può mostrare il suo tag noindex, perché il crawler non la scarica mai (Google: bloccare l'indicizzazione con noindex). Nella nostra scansione una home page aveva il noindex: un solo sito, ma era proprio l'ingresso principale a chiedere di restare fuori.

  • Apri il tuo robots.txt e leggi ogni gruppo User-agent che nomina un crawler AI; la verifica crawler AI lo fa per 15 di loro.
  • Chiedi al tuo hosting o alla CDN quali bot il firewall sottopone a verifica. Cloudflare, per esempio, ha un'impostazione che blocca i crawler AI indipendentemente da quello che dice il robots.txt.
  • Controlla che le pagine che vuoi far trovare non abbiano noindex nell'HTML né in un header X-Robots-Tag.

2. Link interni che non portano da nessuna parte, o ci arrivano per la strada più lunga

I crawler scoprono la maggior parte delle pagine seguendo i link. Dei 12.381 link interni controllati, 64 portavano a una pagina di errore (60 erano 404). Sembra poco, ma erano distribuiti su 18 dei 90 siti (20%), e su 10 di questi 18 lo stesso link rotto partiva da tre o più delle pagine analizzate: di solito è il segno di un link nel menu, nel footer o nel template.

I redirect erano molto più frequenti: 67 siti (74%) avevano almeno un link interno verso un URL che reindirizzava, per lo più da http:// a https:// o alla versione con o senza barra finale. Un singolo passaggio non fa danni. Il problema sono le catene: 23 siti (26%) avevano almeno un URL che richiedeva due o più redirect. I crawler di Google seguono fino a 10 passaggi (Google: codici di stato HTTP), e le indicazioni di Google sullo spostamento di un sito chiedono un redirect diretto all'URL finale oppure una catena di meno di cinque passaggi, idealmente non più di tre (Google: spostamento di un sito). Gli altri crawler AI non documentano i loro limiti, quindi conviene presumere che ogni passaggio in più sia una richiesta che potrebbe non essere fatta.

I due problemi si risolvono allo stesso modo: aggiorna il link stesso all'URL finale, nel template che lo genera, invece di aggiungere un altro redirect. Se un URL reindirizzato resta fuori dall'indice, la guida sul sito che non compare su Google spiega come leggere in Search Console gli stati «Pagina con reindirizzamento» ed «Errore di reindirizzamento».

3. Sitemap che contraddicono le pagine che elencano

La sitemap è l'elenco degli URL che chiedi ai motori di ricerca di scansionare e indicizzare. Ce l'avevano 75 dei 90 siti. Tra questi, 15 (20%) elencavano almeno un URL che reindirizzava o restituiva un errore e 6 (8%) una pagina con noindex. Ogni caso è una contraddizione: la sitemap dice «indicizza questa pagina», la pagina risponde «mi sono spostata», «non esisto» o «non indicizzarmi».

Google chiede di inserire gli URL canonici che vuoi vedere nei risultati di ricerca e usa lastmod solo se è sempre accurato (Google: creare una sitemap). Bing dice la stessa cosa pensando alla ricerca AI: in un post di luglio 2025 (in inglese) consiglia una sitemap completa con un lastmod veritiero e IndexNow per le pagine modificate, così che i risultati basati sull'AI restino aggiornati.

  • Genera la sitemap dagli stessi dati che decidono canonical e noindex: così una pagina reindirizzata o esclusa esce dalla sitemap da sola.
  • Imposta lastmod sulla data dell'ultima modifica dei contenuti, non su quella in cui è stato generato il file.
  • Dichiara la sitemap nel robots.txt. Lo facevano 70 degli 84 siti con un robots.txt leggibile; gli altri contano sul fatto che i motori di ricerca la trovino all'indirizzo predefinito.

4. Canonical, duplicati e segnali di lingua in disaccordo

Il tag canonical indica ai motori di ricerca quale tra più URL simili è quello principale. Google lo considera un segnale forte, come i redirect, mentre l'inserimento di un URL nella sitemap è un segnale debole (Google: URL canonici). Un canonical che punta a una pagina che reindirizza, dà errore o ha il noindex manda i crawler in un vicolo cieco. Lo abbiamo trovato su un solo sito: in questo campione gli errori di canonical erano rari, ma un canonical sbagliato in un template si ripete su ogni pagina costruita con quel template.

I title duplicati erano più frequenti: 16 siti (18%) avevano almeno due pagine indicizzabili con lo stesso title. Quando due pagine si presentano in modo identico, il motore di ricerca deve capire da solo quale risponde a una ricerca; le linee guida di Google sui link del titolo chiedono un title distinto e descrittivo per ogni pagina.

I siti multilingue aggiungono hreflang, che funziona solo se ogni versione linguistica elenca sé stessa e tutte le altre e se ogni link viene ricambiato; altrimenti le annotazioni possono essere ignorate (Google: versioni localizzate). Dei 31 siti con hreflang, 4 (13%) interrompevano questo circuito su almeno una pagina. La verifica hreflang e canonical controlla in pochi secondi un URL e le sue versioni alternative.

5. Contenuti che esistono solo dopo l'esecuzione di JavaScript

Su 5 dei 90 siti (6%) almeno una pagina analizzata era un guscio renderizzato lato client: l'HTML inviato dal server non conteneva testo leggibile finché non veniva eseguito JavaScript. Altri tre siti sono rimasti fuori dai dati sulle pagine dello studio per lo stesso motivo, perché quasi nessuna delle loro pagine aveva contenuto nell'HTML.

Google esegue JavaScript, ma in una fase separata dopo la scansione, e continua a consigliare il rendering lato server o il pre-rendering, anche perché non tutti i crawler sono in grado di eseguire script (Google: nozioni di base su JavaScript e SEO). Per i crawler AI la misurazione pubblica più solida è l'analisi di Vercel del dicembre 2024 (in inglese): in quel momento nessuno dei principali crawler AI eseguiva JavaScript; i crawler di OpenAI e di Anthropic scaricavano i file degli script senza eseguirli, mentre Gemini (tramite l'infrastruttura di Google) e Applebot eseguivano il rendering. Può cambiare, ma oggi una pagina il cui testo compare solo nel browser è probabilmente invisibile ad alcuni crawler di ricerca AI.

La prova è semplice: apri il sorgente della pagina (non lo strumento Ispeziona) e cerca una frase del testo principale. Se non c'è, chiedi al tuo sviluppatore il rendering lato server o la generazione statica per le pagine che contano.

6. Pagine difficili da capire una volta lette

Essere scaricati non vuol dire essere capiti. Lo studio ha rilevato che il 59% delle home page aveva qualche markup schema.org ma solo il 35% indicava l'organizzazione che sta dietro al sito, e che sul 43% dei siti controllati due o più pagine indicizzabili non avevano un H1. I dati strutturati da soli non fanno guadagnare un posto nelle risposte AI: la regola di Google è che descrivano ciò che è visibile sulla pagina (Google: linee guida sui dati strutturati), e i suoi consigli di maggio 2025 sulle esperienze AI mettono al primo posto contenuti unici e utili, prima di qualsiasi aspetto tecnico.

In pratica servono un H1 chiaro che nomini l'argomento, title e description diversi da quelli di ogni altra pagina, un blocco Organization che corrisponda al nome e all'indirizzo riportati sulla pagina e un testo che risponda con frasi semplici alla domanda di cui tratta la pagina. La guida ai dati strutturati contiene un esempio essenziale di blocco Organization.

Cosa questa scansione non può dirti

  • Se un sito viene citato in ChatGPT, Perplexity, Claude o nelle risposte AI di Google. Abbiamo misurato solo segnali di preparazione: nessun dato di questa pagina misura visibilità o posizionamento.
  • Se uno di questi problemi ha causato una variazione di posizionamento. Sono ostacoli documentati alla scansione e all'indicizzazione, non fattori di citazione AI dimostrati.
  • Qualsiasi cosa oltre le 20 pagine per sito, o cosa avrebbe ricevuto un crawler da un'altra località o con un altro user agent.
  • Velocità e Core Web Vitals, che per questo campione non sono stati misurati.

Un ordine di controllo per il tuo sito

  • Accesso: i gruppi del robots.txt per i crawler di ricerca e AI, più le impostazioni anti-bot di firewall o CDN. Usa la verifica crawler AI.
  • Indicizzabilità: nessun noindex indesiderato, canonical che puntano a pagine attive e indicizzabili. Usa la verifica meta tag.
  • Link: nessun link interno verso pagine 404, nessuna catena di redirect; aggiorna i link al loro URL finale.
  • Sitemap: solo URL canonici e indicizzabili che rispondono 200, con un lastmod veritiero.
  • Rendering: il testo principale è nel sorgente della pagina.
  • Lingue: hreflang elenca ogni versione, compresa la pagina stessa, e ogni link è ricambiato. Usa la verifica hreflang e canonical.
  • Comprensione: un solo H1, title e description unici, dati strutturati che corrispondono alla pagina.

L'analisi gratuita controlla questi segnali su un URL, più la velocità tramite Google PageSpeed. Il Report del sito a pagamento esegue gli stessi controlli di questa scansione su un massimo di 20 pagine di un sito e verifica i link interni che trova. Quando le correzioni richiedono uno sviluppatore, il team di GE-KO che sta dietro a Sitequiry può occuparsi dell'implementazione.

Domande frequenti

La SEO tecnica per la ricerca AI è diversa da quella per Google?

Per scansione e indicizzazione, no. Google dice che le sue funzionalità AI non hanno requisiti tecnici aggiuntivi, e gli altri crawler di ricerca AI scaricano le pagine allo stesso modo. Le differenze riguardano l'accesso: ogni azienda AI usa i propri user agent, che robots.txt e firewall possono consentire o bloccare separatamente.

Quale problema conviene correggere per primo?

Tutto ciò che ferma del tutto un crawler: un crawler bloccato, un noindex sulle pagine che vuoi far trovare, una home page che reindirizza a un errore. Poi i link interni rotti e gli errori nella sitemap, infine le catene di redirect e i title duplicati.

Aggiungere llms.txt o markup schema fa entrare un sito nelle risposte AI?

Nessuno dei due è documentato come via d'accesso. Nel nostro studio 12 siti su 90 avevano un file llms.txt, e nessuno dei principali motori di ricerca si è impegnato a usarlo per le risposte AI. I dati strutturati aiutano i motori di ricerca a leggere i fatti di una pagina, ma devono corrispondere al contenuto visibile, e nessun fornitore promette una citazione in cambio.

Posso usare questi dati in un mio articolo?

Sì. I dati aggregati sono pubblicati con licenza CC BY 4.0: cita «Sitequiry, AI search readiness 2026 crawl» e inserisci un link a questa pagina o allo studio. Il CSV, in inglese, riporta la definizione e la dimensione del campione di ogni dato.

Controlla il tuo robots.txt

Inserisci il tuo dominio per vedere quali crawler AI il tuo robots.txt consente o blocca, e quale riga lo determina.

Controlla il tuo sito in circa un minuto

L'analisi gratuita misura sul tuo URL i punti di questa guida e mostra cosa correggere per primo.