// guida
Come si fa GEO sul proprio sito nella pratica?
Aggiornato: 2026-08-03
// risposta breve
Il GEO tecnico è igiene, non magia. Su get-geo.ai mezza giornata di lavoro ha fatto puntare ogni segnale a un solo host, ha dato ai fetcher di IA il contenuto alla prima richiesta, ha passato Search Console a una proprietà di dominio e ha messo il corpus completo delle guide in file llms-full per locale che si aggiornano dallo stesso registro delle pagine. Il contenuto decide se vi citeranno; la tecnica decide se qualcuno leggerà abbastanza da citare.
Punto di partenza: un sito che sembra a posto
Vendiamo GEO — quindi il nostro sito deve essere l'implementazione di riferimento. Questa guida non è teoria ma il protocollo di una vera giornata di lavoro: cosa abbiamo trovato, come l'abbiamo sistemato, cosa abbiamo verificato. Ogni esempio viene da questo stesso sito.
get-geo.ai è stato costruito «a regola d'arte» fin dal primo giorno: rendering lato server, 8 lingue con hreflang, JSON-LD Schema.org, struttura answer-first, llms.txt. Cosa mai ci sarebbe da sistemare? L'audit ha trovato un problema invisibile a occhio nudo.
Scoperta n. 1: il conflitto apex / www
Il sito viveva fisicamente su www.get-geo.ai, mentre tutti i segnali — canonical, sitemap, hreflang, JSON-LD, llms.txt — puntavano a get-geo.ai (l'apex, il dominio senza sottodominio). E l'apex rispondeva con un redirect 308 verso www.
Il risultato: un anello. «La versione canonica è l'apex» → l'apex reindirizza a www → www dichiara «la versione canonica è l'apex». Un crawler Google classico sopravvive, pur bruciando crawl budget. I fetcher di IA spesso no: molti hanno un budget di una o due richieste per pagina, e alcuni semplicemente non arrivano mai al contenuto attraverso un redirect. Per il GEO è critico: un file invisibile al fetcher è un file che non esiste.
La correzione: l'apex è diventato dominio primario sull'hosting (Vercel), con www in 308 verso l'apex. Un solo interruttore — e tutti i segnali sono diventati coerenti: indirizzo reale, canonical, link interni, sitemap e llms.txt ora puntano nello stesso punto.
La lezione: la scelta tra apex e www non conta. Conta che il sito viva esattamente su uno dei due e che l'altro reindirizzi in modo netto. Ogni scarto tra «dove vive il sito» e «dove puntano i segnali» è una tassa su ogni visita del crawler.
Scoperta n. 2: il consiglio datato di un agente IA
La diagnostica era condotta da un agente IA, e la sua checklist includeva: «verifica che il record A dell'apex punti a 76.76.21.21». Il controllo del DNS reale ha mostrato altro: il dominio risolve verso 216.198.79.1 — la nuova infrastruttura di Vercel, su cui l'hosting è migrato dopo la data di taglio dei dati di addestramento del modello.
Il consiglio non era dannoso — solo stantio. Il modello citava il passato con sicurezza.
La lezione: un agente IA senza strumenti di verifica è memoria, non conoscenza. Confrontate ogni raccomandazione tecnica di un modello con lo stato reale del sistema: una query DNS costa un secondo e chiude la questione. Questo, peraltro, è il principio stesso del GEO: i modelli rispondono da ciò che sono riusciti a leggere — ed è esattamente per questo che rendiamo i contenuti leggibili.
Passo 3: Google Search Console — la proprietà di dominio
Dopo il cambio di host primario, la vecchia proprietà GSC (prefisso URL su https://www.get-geo.ai/) è diventata inutile: copre solo www, mentre le pagine migravano sull'apex.
La configurazione corretta è una proprietà di dominio (get-geo.ai, senza protocollo né sottodominio): copre in un colpo apex, www, http, https e tutti i sottodomini. Si verifica solo tramite record DNS TXT — con un dettaglio piacevole: il token google-site-verification è legato all'account, non al metodo di verifica, quindi un record aggiunto al DNS in precedenza ha superato la verifica all'istante. Poi — invio della sitemap all'indirizzo apex: https://get-geo.ai/sitemap.xml.
La lezione: una sitemap appena inviata in GSC resta spesso con lo stato rosso «Impossibile recuperare» e zero pagine. Non è un errore ma un segnaposto fino alla prima elaborazione — asincrona, può richiedere fino a un paio di giorni. Prima di andare nel panico, controllate tre cose: il file si apre all'URL diretto, ogni <loc> al suo interno punta all'host giusto, e robots.txt contiene una riga Sitemap:. Se tutte e tre reggono — aspettate e basta.
Passo 4: la sitemap come strumento GEO, non formalità
La nostra sitemap non include solo pagine. Elenca llms.txt, llms-full.txt e tutte le versioni linguistiche llms-full/{locale} — con date lastmod e priorità.
Perché: i crawler di IA (GPTBot, ClaudeBot, PerplexityBot) sono stati osservati leggere le sitemap, ed elencare esplicitamente i file LLM dà loro una rotta diretta verso la versione machine-readable del sito — senza contare sul fatto che il fetcher conosca la convenzione /llms.txt.
La lezione: trattate la sitemap come un menù per le macchine, non come una casella da spuntare. Tutto ciò che volete mostrare ai sistemi di IA deve esservi elencato, con date lastmod oneste.
Passo 5: llms-full — il contenuto completo, non l'indice
La convenzione distingue due file: llms.txt è un indice con link; llms-full.txt è il contenuto completo per i sistemi che non seguono i link. La nostra versione full all'inizio conteneva solo la landing: le guide — il nostro asset più citabile — erano disponibili solo pagina per pagina.
Cosa abbiamo cambiato:
- File per locale. I testi completi delle guide sono passati in llms-full/{locale}, ogni file interamente nella propria lingua. Ammassare 8 lingue in un solo file significa diluire di otto volte la densità utile per qualunque query specifica.
- Un URL sotto ogni titolo. Nel file, ogni guida si apre con il titolo e l'URL canonico subito sotto — così un modello che riprende il testo può citare la pagina, non il file txt.
- Generazione automatica da un registro unico. I file si costruiscono dalla stessa fonte delle pagine delle guide. Una nuova guida arriva sul sito, nella sitemap e in llms-full con un'unica azione. La sincronizzazione manuale muore in un mese — non l'abbiamo nemmeno iniziata.
- Un limite con degradazione onesta. Il file ha un tetto di dimensione; in caso di sforamento, invece del troncamento silenzioso, aggiunge l'elenco delle guide rimaste fuori, con i link.
- Una lezione da un posto inaspettato: il primo limite di 100 KB è stato quasi rotto da un sistema di scrittura. Devanagari (hindi) occupa 3 byte per carattere in UTF-8 contro 1 del latino — il file hindi toccava 85 KB quando l'inglese ne pesava la metà. Abbiamo alzato il limite a 200 KB. Se il vostro sito è multilingue, fate i conti tenendo presente la scrittura: i sistemi CJK e indiani «pesano» diverse volte di più.
Il bilancio della giornata
Mezza giornata di lavoro, nemmeno una pagina di contenuto nuova — eppure:
- ogni segnale del sito punta a un solo host, senza anelli né redirect superflui;
- un fetcher di IA con budget di una richiesta ottiene il contenuto al primo colpo;
- GSC raccoglie i dati dell'intero dominio, non di un solo sottodominio;
- il corpus completo delle guide in 8 lingue è accessibile alle macchine in un file per locale;
- pubblicare una nuova guida aggiorna automaticamente sito, sitemap e llms-full.
Igiene, non magia
Questa è la parte tecnica del GEO: non magia, igiene. Il contenuto decide se vi citeranno. La tecnica decide se qualcuno leggerà fino al contenuto.
Domande correlate
Il confronto apex vs www conta per il GEO?
La scelta in sé no. Conta che il sito viva esattamente su un solo host e che ogni segnale — canonical, sitemap, hreflang, JSON-LD, llms.txt — punti lì, con l'altro hostname che reindirizza in modo netto. Un anello tra apex e www brucia crawl budget e spesso ferma i fetcher di IA che fanno solo una o due richieste.
Si deve usare una proprietà di dominio in Google Search Console?
Sì, se vi importano sia apex sia www (o http e https). Una proprietà di dominio li copre tutti insieme e si verifica via DNS TXT. Una proprietà prefisso URL solo su www diventa cieca nel momento in cui l'host primario passa all'apex.
Perché elencare llms.txt nella sitemap?
I crawler di IA sono stati osservati leggere le sitemap. Elencare llms.txt e i file llms-full per locale dà loro una rotta diretta verso il corpus machine-readable, senza contare sul fatto che ogni fetcher conosca la convenzione /llms.txt.
Perché file llms-full per locale invece di un dump multilingue?
Un solo file con otto lingue diluisce di otto volte la densità utile per qualunque query specifica. Un file per locale tiene il corpus denso, mette un URL canonico sotto ogni titolo di guida e può essere generato dallo stesso registro delle pagine HTML.