// guida
Come si fa GEO sul proprio sito nella pratica?
Autore: Dmitry Filippov, Founder, GET-GEO.AI
Pubblicato: 2026-08-03 · Aggiornato: 2026-09-22
// risposta breve
In mezza giornata, su get-geo.ai abbiamo allineato i segnali su un solo host, reso i contenuti accessibili alla prima richiesta, configurato una proprietà di dominio in Search Console e generato file llms-full per ogni lingua. I contenuti determinano l'utilità della fonte; la configurazione tecnica permette agli assistenti di leggerla.
- Fare GEO sul nostro sito ha richiesto mezza giornata e nessuna pagina nuova: un solo host principale, una proprietà dominio in Search Console e gli export llms-full ricostruiti.
- Ogni segnale puntava all'apex mentre l'apex rispondeva con un redirect 308 verso www: un loop che i fetcher IA con budget di una sola richiesta non superano mai.
- La checklist di un agente IA diceva che il record A dell'apex doveva puntare a 76.76.21.21; il DNS reale mostrava 216.198.79.1, l'infrastruttura più recente di Vercel: verificate i consigli del modello sul sistema reale.
- Una sitemap appena inviata può mostrare «Impossibile recuperare» per un paio di giorni; controllate tre cose: il file si apre, ogni loc usa l'host giusto, robots.txt la elenca.
- llms-full ora esce con un file per locale in 9 lingue; il devanagari occupa 3 byte per carattere, quindi il file hindi è arrivato a 85 KB e il limite è salito a 300 KB.
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, 9 lingue con hreflang, JSON-LD Schema.org, struttura con la risposta all'inizio, 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. Gli agenti che recuperano pagine per l'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 all'agente è 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 scelta tra apex e www conta meno della coerenza. Il sito deve rispondere su un solo host, con un reindirizzamento diretto dall'altro. Se l'indirizzo effettivo e i segnali canonici non coincidono, il crawler deve compiere passaggi inutili.
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 aggiornamento dei dati di addestramento del modello.
Il consiglio non era dannoso, ma superato: il modello riportava con sicurezza una configurazione non più attuale.
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 tutti e tre i controlli sono superati, aspettate l'elaborazione.
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 leggibile dalle macchine del sito — senza contare sul fatto che l'agente 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 — le nostre pagine più citabili — erano disponibili solo pagina per pagina.
Cosa abbiamo cambiato:
- File per lingua. I testi completi delle guide sono passati in llms-full/{locale}, ogni file interamente nella propria lingua. Ammassare 9 lingue in un solo file significa diluire di nove 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 vengono creati dalla stessa fonte delle pagine delle guide. Pubblicando una guida si aggiornano insieme il sito, la sitemap e llms-full, senza doverli sincronizzare a mano.
- Un limite di dimensione esplicito. Se il contenuto supera la soglia, il file non viene troncato senza avviso: in fondo compare l'elenco delle guide escluse, con i relativi link.
- Una lezione da un posto inaspettato: il primo limite di 100 KB si è rivelato quasi insufficiente per 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 300 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 agente 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 9 lingue è accessibile alle macchine in un file per lingua;
- pubblicare una nuova guida aggiorna automaticamente sito, sitemap e llms-full.
La base tecnica del GEO
Questi interventi rendono i contenuti accessibili agli assistenti. La qualità delle pagine determina se vale la pena citarle; la configurazione tecnica permette ai sistemi di arrivare al testo.
Domande frequenti
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 gli agenti 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 lingua dà loro una rotta diretta verso i contenuti leggibili dalle macchine, senza contare sul fatto che ogni agente conosca la convenzione /llms.txt.
Perché file llms-full per lingua invece di un dump multilingue?
Un solo file con nove lingue diluisce di nove volte la densità utile per qualunque query specifica. Un file per lingua tiene il corpus denso, mette un URL canonico sotto ogni titolo di guida e può essere generato dallo stesso registro delle pagine HTML.
Guide correlate
Fonti
// condividi
Come citare questa pagina
Puoi citare e riutilizzare questi contenuti indicando la fonte e aggiungendo un link a questa pagina.
“Come si fa GEO sul proprio sito nella pratica?” — GET-GEO.AI, 2026-09-22. https://get-geo.ai/it/guides/how-we-do-geo-ourselves