Ci sono due modi di affrontare la visibilità del proprio sito dentro le risposte generate dalle AI. Il primo è collezionare tattiche: metti lo schema, scrivi le FAQ, pubblica llms.txt, spera. Il secondo è costruire un processo che parte da una domanda misurabile — per quali domande dei miei utenti l’AI deve nominarmi, e oggi mi nomina? — e che si ripete nel tempo perché le risposte cambiano.

Questa guida descrive il secondo. È lunga, e lo è di proposito: contiene la sequenza completa, i template di rilevazione, gli snippet pronti e i punti in cui la maggior parte dei progetti si incaglia.

L’impianto è diviso in due tracce che convivono:

Traccia A — Fondamenta. Far rendere di più quello che hai già. Orizzonte 0-90 giorni, obiettivo risultati misurabili nel trimestre.
Traccia B — Loop continuo. Trasformare tutto questo in una capability che gira dentro il tuo ciclo di pianificazione. Orizzonte annuale.

Chi salta la A e parte dalla B costruisce un processo elegante sopra fondamenta che non reggono. Chi si ferma alla A ottiene un picco e poi guarda i numeri erodersi nel giro di due trimestri, perché i prompt, i competitor e i modelli si muovono.

Come usare questa guida. È il punto di ingresso di un percorso, non l’unico documento. Su quattro temi ho già pubblicato l’approfondimento verticale, e qui li riassumo in forma operativa rinviando al dettaglio tecnico:

Tema	Qui trovi	L’approfondimento
Meccanismo del fan-out	Il modello mentale e cosa implica	Query fan-out: la guida tecnica
Misurazione	Le metriche e le cadenze	Misurare la visibilità nelle AI
Accesso dei crawler	La decisione e la trappola di `robots.txt`	Come gestire i crawler AI nel 2026
`llms.txt`	Perché non lo consiglio	llms.txt: a cosa serve?

Il valore aggiunto di questa pagina è la sequenza: l’ordine in cui vanno fatte le cose, il loop che le tiene in vita, e — al capitolo 5 — uno studio di prima mano sui log del mio server che corregge il metodo di verifica che circola comunemente, incluso quello che avevo scritto io stesso nelle prime versioni di questa guida.

1. Glossario operativo

Non è un glossario divulgativo: sono i termini che useremo per il resto della guida, e che ti servono per tenere allineati brief, fornitori e reportistica. Quando tre persone chiamano “visibilità” tre cose diverse, il report mensile diventa inutile.

Visibilità AI — la presenza del tuo contenuto e del tuo brand dentro le risposte generate dagli assistenti. Si scompone in tre cose misurabili e distinte: essere nominati, essere citati con un link, essere descritti correttamente. È l’obiettivo di tutta la guida.

Ottimizzazione per la ricerca AI — l’insieme delle attività che aumentano quella visibilità. Non è un sottoinsieme della SEO né il suo sostituto: condivide gran parte delle fondamenta tecniche e diverge su obiettivi e metriche.

Tracciamento delle menzioni AI — la rilevazione sistematica e ripetibile di come gli assistenti parlano di te. È la metà del lavoro che quasi nessuno fa, ed è quella che rende dimostrabile l’altra metà.

Answer engine — sistema che restituisce una risposta invece di una lista di link.

AI Overviews — il riassunto generato da Google sopra i risultati classici.

AI Mode — l’esperienza conversazionale di Google, separata dalla SERP tradizionale, con follow-up e ragionamento multi-step.

Prompt — la domanda che l’utente scrive. Nel nostro lavoro sostituisce la keyword come unità di analisi, con una differenza sostanziale: è più lunga, più contestuale e molto più varia. Non esiste un “volume di ricerca” affidabile per i prompt.

Query fan-out — la tecnica con cui un motore AI espande una singola domanda in più sotto-ricerche correlate, esegue ognuna, e poi fonde i risultati. È il motivo per cui ottimizzare sulla sola query letterale non basta più.

Chunk-level retrieval — il recupero avviene su frammenti di pagina, non su pagine intere. Il modello non “legge il tuo sito”: pesca passaggi. Se il tuo passaggio non è autoconsistente, non viene pescato.

Grounding — l’ancoraggio della risposta a fonti recuperate al momento, invece che alla sola memoria parametrica del modello. È la modalità in cui nascono le citazioni.

Citazione — il link a una fonte dentro la risposta. È l’unica metrica che può produrre traffico.

Brand mention — il modello ti nomina, con o senza link. Vale anche senza traffico, perché sposta la consideration.

Share of voice (SOV) — quanto compari tu rispetto al tuo set competitivo, sullo stesso insieme di prompt.

Sentiment / accuratezza — come ti descrive. Sono due cose distinte e vanno misurate separatamente: una risposta può essere favorevole e sbagliata.

Message matching — quanto la risposta veicola i messaggi che tu hai deciso di comunicare. È la metrica più trascurata e spesso la più utile.

E-E-A-T — Experience, Expertise, Authoritativeness, Trustworthiness. Nato in ambito Google Search Quality Rater, resta il vocabolario più pratico per ragionare sui segnali di affidabilità che alimentano anche il retrieval AI.

Crawlabilità — se il bot ci arriva. Prerequisito di tutto il resto, e prima causa di fallimento silenzioso.

Spoofing di user-agent — traffico che dichiara di essere un crawler noto senza esserlo. Non è un dettaglio da paragrafo finale: al capitolo 5 mostro che sul mio server è la maggioranza del traffico che si dichiara OpenAI.

2. Come si forma davvero una risposta AI

Serve un modello mentale, perché ogni tattica di questa guida discende da qui. Lo tengo corto e vado dritto alle implicazioni operative; il meccanismo nel dettaglio — brevetti, pipeline di AI Mode, metodi di estrazione del fan-out reale via API Gemini — sta nella guida tecnica al query fan-out.

Quando un utente fa una domanda a un assistente con accesso alla rete, succedono cinque cose:

Da cui, in ordine:

Dallo stadio 1 → conta il contesto, non la corrispondenza letterale. Una pagina che risponde a una domanda formulata in dieci modi diversi batte dieci pagine che rispondono ognuna a una formulazione.
Dallo stadio 2 → la partita non si gioca sulla domanda che ti aspetti, ma sul grappolo di domande che il motore genera intorno a quella. Gli ordini di grandezza, misurati: su ~70.000 fan-out estratti da 9.000 prompt commerciali, la media è di 9,06 sotto-query per prompt, con forte varianza settoriale (11,7 nel software, 3,79 nel local). E la modalità di ragionamento cambia tutto: su 100 prompt, GPT-5.2 in modalità Instant genera ~245 sotto-query, in modalità Thinking ~1.130. Questo cambia la struttura editoriale: servono cluster, non pagine isolate.
Dallo stadio 3 → il recupero è per frammento. Un paragrafo che inizia con “Inoltre, come dicevamo sopra…” è inutilizzabile perché non regge da solo. Ogni sezione della tua pagina deve poter essere estratta e avere senso fuori contesto.
Dallo stadio 4 → la risposta è un mosaico. Non vinci “il primo posto”: entri o non entri nel mosaico. E puoi entrarci con una frase mentre il resto della risposta viene da un competitor. Il dato che lo dimostra meglio: il 90% delle pagine citate da ChatGPT si posiziona oltre la ventunesima posizione per la query principale. Il ranking classico non predice la citazione.
Dallo stadio 5 → l’attribuzione non è garantita e non segue la logica del ranking. Il sistema cita quello che è stato più facile estrarre e attribuire, non necessariamente la fonte migliore.

C’è un sesto elemento che non è uno stadio ma una condizione di partenza: il modello ha già una conoscenza pregressa su di te, ereditata dall’addestramento. Se quella conoscenza è sbagliata o vecchia, il retrieval la corregge solo se trova qualcosa di più forte e più recente. Non lo dai per scontato: lo verifichi.

Implicazione operativa complessiva. L’obiettivo non è “posizionarsi”. È rendere il tuo contenuto la cosa più facile da estrarre, verificare e attribuire per il grappolo di domande che ti interessa. Tutto quello che segue è questo, declinato.

3. Le quattro metriche che contano

Prima di toccare qualsiasi cosa, definisci come misurerai. Farlo dopo significa raccontarsi il risultato che fa comodo.

Metrica	Definizione	Formula	Cosa ti dice
Mention rate	Il brand viene nominato	menzioni ÷ risposte totali	Esisti nella conversazione
Citation rate	Un tuo dominio viene linkato	risposte con link owned ÷ risposte totali	Puoi ricevere traffico
Accuracy rate	Ciò che dice di te è corretto	risposte corrette ÷ risposte in cui sei nominato	Rischio reputazionale
Message match rate	Veicola i tuoi messaggi chiave	risposte con ≥1 messaggio chiave ÷ risposte in cui sei nominato	Controllo narrativo

A queste aggiungi due metriche di contesto, che non misurano te ma il campo:

Share of voice — menzioni tue ÷ (menzioni tue + menzioni del set competitivo). Definisci il set competitivo una volta e non cambiarlo, altrimenti le serie storiche non sono confrontabili.
Source concentration — quale quota delle citazioni totali, su tutti i tuoi prompt prioritari, arriva dai primi 10 domini. Se è alta, sai esattamente dove concentrare gli sforzi off-site.

La nota metodologica che separa un report da un’illusione

Le risposte degli LLM non sono deterministiche, e l’entità del fenomeno è quasi sempre sottostimata. Rand Fishkin ha quantificato che servono in media 1.500 esecuzioni dello stesso identico prompt per ottenere due risposte uguali dallo stesso modello. Sul fan-out, solo il 27% delle sotto-query resta stabile fra esecuzioni ripetute.

Questo ha una conseguenza che va detta senza ammorbidirla: la visibilità AI non è un valore, è una proporzione stimata da un campione, e va riportata con il suo intervallo di confidenza. Con n=10 esecuzioni il margine di errore al 95% è di ±26 punti; servono n=100 per scendere a ±10 e n=384 per arrivare a ±5. Un tracking “una esecuzione al giorno per prompt” produce grafici che oscillano senza alcun significato statistico.

La regola operativa che ne deriva:

campiona in profondità, non in ampiezza: meglio 20 money prompt con 30 esecuzioni ciascuno che 200 prompt con una;
dichiara sempre l’intervallo, non solo la media — l’intervallo di Wilson è lo standard corretto per campioni piccoli;
geolocalizzazione dichiarata e costante fra le rilevazioni;
versione del modello registrata insieme al risultato, perché un aggiornamento può spostare i numeri più di sei mesi del tuo lavoro.

La metodologia completa, con l’implementazione Python dell’intervallo di Wilson e la tabella dei margini di errore per numero di esecuzioni, è in Misurare la visibilità nelle AI. Se stai valutando una piattaforma di AI visibility, quella è la prima cosa da chiederle: quante esecuzioni fa per prompt, e se espone l’intervallo di confidenza.

Un secondo dato che vincola le priorità: il 91% delle URL citate compare in un solo motore AI (rilevazione di Kevin Indig). La visibilità su ChatGPT non predice quella su Gemini, Perplexity o AI Mode. È il motivo per cui al passo 4.1 si scelgono due o tre motori e si misura lì, invece di inseguire una media fra sistemi che non si somigliano.

4. Traccia A — Fondamenta (0-90 giorni)

L’obiettivo di questa traccia è chiaro: far rendere di più ciò che hai già, prima di produrre qualsiasi cosa di nuovo. Quattro passi in sequenza. Non sono opzionali e non sono riordinabili.

4.1 Assessment del panorama: dove chiedono davvero i tuoi utenti

Il primo errore è ottimizzare per il motore sbagliato. La distribuzione degli assistenti AI cambia in modo drastico da mercato a mercato, e le medie globali non descrivono nessuno. Prima di decidere qualsiasi cosa, tre operazioni.

a) Raccogli dati sul tuo mercato, non medie globali.

Ti servono utenti attivi e quota d’uso per motore, sul paese in cui vendi. Fonti utilizzabili: dati di traffico e app usage (Similarweb, Sensor Tower e simili), le dichiarazioni pubbliche degli operatori, e soprattutto — se ce l’hai — il tuo dato di prima parte. Il referral che arriva sul tuo sito dai domini degli assistenti è il segnale più onesto che esista sul tuo mercato specifico:

chatgpt.com
perplexity.ai
claude.ai
gemini.google.com
copilot.microsoft.com

Segmenta in GA4 questi referral e guardali per volume, pagine di atterraggio e comportamento. Non è la misura della tua visibilità AI — è la misura di quanta di quella visibilità produce traffico. Sono due cose diverse e servono entrambe.

b) Separa l’esposizione dalla scelta.

Questa distinzione è la parte più utile di tutto l’assessment e quasi nessuno la fa.

AI embedded nella ricerca (AI Overviews, AI Mode, Copilot dentro Bing): raggiunge tutti per default. L’utente non l’ha scelta. Volumi altissimi, intento spesso superficiale, forte sovrapposizione con la SEO classica.
App standalone (ChatGPT, Claude, Perplexity, Gemini app): l’utente ha deliberatamente aperto l’app per chiedere. Volumi minori, intento molto più alto, sessioni più lunghe e conversazionali.

Pesarle allo stesso modo produce priorità sbagliate. Un B2B con ciclo di vendita lungo trova più valore in 10.000 conversazioni deliberate che in 1.000.000 di esposizioni passive. Un e-commerce di largo consumo probabilmente il contrario.

c) Scegli due o tre motori e basta.

Non puoi auditare e ottimizzare su tutto. Prendi i due o tre che i tuoi utenti effettivamente scelgono, e costruisci lì la baseline. Gli altri li monitori con una rilevazione leggera trimestrale. Il dato di Indig citato sopra — il 91% delle URL citate compare in un solo motore — dice che questa scelta non è una scorciatoia per risparmiare: è metodologicamente corretta, perché i motori non sono intercambiabili e una media fra loro non descrive nessuno.

Output di questo step: una tabella con motore, utenti stimati sul tuo mercato, tipo (esposizione/scelta), referral misurato sul tuo sito, priorità. Una pagina, non venti.

4.2 Audience, journey e must-win prompt

Qui si decide tutto il resto, ed è il punto in cui la maggior parte dei progetti prende la piega sbagliata: si parte dall’elenco di prompt che il tool suggerisce, invece che dalle decisioni che l’utente deve prendere.

L’obiettivo non è vincere tutti i prompt. È vincere quelli che spostano il business.

Un tracciamento standard ti dice visibilità, citazioni, sentiment e mix delle fonti. Non ti dice quali audience contano di più, quali percorsi generano fatturato, quali domande sono momenti di influenza reale, e dove intervenire crea valore. Quella parte la devi mettere tu.

Il metodo in cinque domande

Per ogni prompt candidato, rispondi:

A quale audience mi rivolgo? (non “i clienti”: un segmento con caratteristiche e vincoli propri)
Quale decisione o preoccupazione sta affrontando in questo momento?
In che punto del percorso si trova?
Quale risposta lo farebbe avanzare?
Su cosa il mio brand deve essere accurato o visibile perché quell’avanzamento sia possibile?

Se non sai rispondere alla 2, il prompt non è prioritario: è solo un prompt.

Mappare il percorso decisionale

Uno schema a cinque fasi che funziona nella maggior parte dei settori:

Fase	Cosa succede	Ruolo dell’AI	Esempio di prompt
1. Innesco	L’utente riconosce un problema, non conosce ancora le soluzioni	Esplorazione, definizione del problema	“perché la mia bolletta è raddoppiata”
2. Esplorazione	Confronta approcci e categorie di soluzione	Sintesi comparativa	“conviene di più il fisso o il variabile”
3. Decisione	Sceglie fra opzioni concrete e fornitori	Shortlist, raccomandazione	“qual è il miglior fornitore per una famiglia di 4 persone”
4. Attivazione	Ha scelto, deve procedere	Istruzioni operative	“quanto tempo ci vuole per il passaggio”
5. Uso e advocacy	Utilizza, valuta, consiglia o cambia	Verifiche rapide, risoluzione problemi	“come disdico senza penali”

La fase 3 è quella dove si vince o si perde il fatturato. La fase 1 è quella dove si costruisce la categoria e dove i costi di acquisizione sono più bassi. Le fasi 4 e 5 sono trascurate da quasi tutti ed è lì che l’AI dice più spesso cose sbagliate sul tuo prodotto, perché nessuno ha pubblicato la versione corretta in modo estraibile.

Costruire concretamente la lista

Sei fonti da incrociare, in ordine di valore decrescente. Le prime tre sono dati che possiedi già e che quasi nessuno estrae; per queste do il codice, perché è dove si perde più tempo a farlo a mano.

1. Log della ricerca interna del sito. Domande reali, formulate spontaneamente, da persone già interessate a te. Su WordPress non finiscono in nessuna tabella: stanno nei log del server, nel parametro ?s=. L’estrazione è banale, la parte che conta è il filtro:

import re, sys, collections
from urllib.parse import unquote_plus

# le ricerche interne arrivano come /?s=<query> — su WP e su molti CMS
SEARCH = re.compile(r'GET /\?s=([^ &"]+)')

# la ricerca interna è un campo di input pubblico: è bersaglio di injection
SPAM = re.compile(r'<|>|http[s]?://|script|href=', re.I)

queries = collections.Counter()
noise = 0
for line in open(sys.argv[1], encoding='utf-8', errors='replace'):
    m = SEARCH.search(line)
    if not m:
        continue
    q = unquote_plus(m.group(1)).strip().lower()
    if not q or SPAM.search(q):
        noise += 1
        continue
    queries[q] += 1

print(f"{sum(queries.values())} ricerche reali, {noise} scartate come spam")
for q, n in queries.most_common(50):
    print(f"{n:5d}  {q}")

Il filtro non è un dettaglio difensivo. Sui log di evemilano.com, nella stessa finestra di 6,5 giorni del capitolo 5, su 538 richieste di ricerca interna 524 erano tentativi di injection HTML — un singolo payload ripetuto — e le query reali erano quattordici. Chi conta le righe senza filtrare conclude che la ricerca interna è la fonte più ricca che ha, e sta guardando un bot.

Due conseguenze operative: il volume di questa fonte scala col traffico, quindi su un sito piccolo può rendere nulla e non è un fallimento del metodo; e le query da cercare con più attenzione sono quelle senza risultati, che su WordPress si isolano confrontando l’elenco estratto con le pagine dei risultati che hanno restituito zero match.

2. Team a contatto col cliente. Assistenza, vendite, front office. Chiedi le dieci domande che ricevono ogni giorno e le tre che li mettono in difficoltà. Queste ultime sono oro: sono i punti dove l’informazione pubblica manca, quindi dove l’AI improvvisa. È l’unica fonte non automatizzabile della lista, ed è il motivo per cui non va delegata a un tool.

3. Search Console: impression alte, CTR basso. Il motore ti considera pertinente, l’utente no. Spesso è un problema di formulazione della risposta, che è esattamente il nostro terreno. Via API, in una chiamata:

from googleapiclient.discovery import build

def low_ctr_queries(creds, site_url, start, end,
                    min_impressions=500, max_ctr=0.02, limit=25000):
    """Query ad alta impression e CTR basso: candidate a riformulazione answer-first."""
    service = build('searchconsole', 'v1', credentials=creds)
    body = {
        'startDate': start,
        'endDate': end,
        'dimensions': ['query'],
        'rowLimit': limit,
    }
    rows = service.searchanalytics().query(siteUrl=site_url, body=body).execute().get('rows', [])

    out = [
        {
            'query': r['keys'][0],
            'impressions': r['impressions'],
            'ctr': r['ctr'],
            'position': r['position'],
        }
        for r in rows
        if r['impressions'] >= min_impressions and r['ctr'] <= max_ctr
    ]
    # ordina per impression perse: quante ne prenderesti a CTR di riferimento
    for o in out:
        o['gap'] = o['impressions'] * (0.05 - o['ctr'])
    return sorted(out, key=lambda o: o['gap'], reverse=True)

Il campo gap è la parte utile: ordina per impression sprecate invece che per volume assoluto, così una query da 800 impression con CTR 0,3% viene prima di una da 5.000 con CTR 4%. È la stessa logica con cui si prioritizza qualsiasi altra cosa in questo lavoro — per delta ottenibile, non per dimensione.

4. Contenuti dei competitor. Le loro FAQ ti dicono a quali domande hanno deciso di rispondere. Non serve un crawl completo: servono solo gli heading e i blocchi FAQ.

import requests, json
from bs4 import BeautifulSoup

def extract_questions(url, timeout=20):
    """Heading interrogativi + domande dal markup FAQPage di una pagina."""
    html = requests.get(url, timeout=timeout,
                        headers={'User-Agent': 'Mozilla/5.0 (research)'}).text
    soup = BeautifulSoup(html, 'html5lib')

    found = {'url': url, 'headings': [], 'schema_faq': []}

    for h in soup.find_all(['h2', 'h3', 'h4']):
        t = h.get_text(' ', strip=True)
        # tieni solo ciò che è formulato come domanda
        if t.endswith('?') or t.lower().startswith(
                ('come', 'quanto', 'perche', 'perché', 'quale', 'quali', 'cosa', 'quando', 'dove')):
            found['headings'].append(t)

    # le FAQ dichiarate nel markup: sono le domande che il competitor ha scelto
    for tag in soup.find_all('script', type='application/ld+json'):
        try:
            data = json.loads(tag.string or '')
        except (json.JSONDecodeError, TypeError):
            continue
        for node in (data if isinstance(data, list) else [data]):
            if isinstance(node, dict) and node.get('@type') == 'FAQPage':
                for q in node.get('mainEntity', []):
                    if isinstance(q, dict) and q.get('name'):
                        found['schema_faq'].append(q['name'])
    return found

Dieci concorrenti, le loro venti pagine più importanti: duecento fetch, un pomeriggio, e ottieni l’elenco delle domande a cui il tuo mercato ha già deciso di rispondere. Le domande che ricorrono su più concorrenti sono tavola apparecchiata; quelle che non risponde nessuno sono lo spazio dove si guadagna la citazione.

5. Tool di query e domande. AlsoAsked, AnswerThePublic, i “People Also Ask”, i “Related searches”. Utili per allargare verso il fan-out, non per stabilire le priorità: restituiscono ciò che è frequente, non ciò che ti fa fatturare.

6. Forum e community. Reddit, gruppi di settore, recensioni. Cerca gli attacchi di frase — “qualcuno mi spiega…”, “vale la pena…”, “differenza tra…”. È il linguaggio naturale che poi finisce nei prompt.

Il problema che nessuno affronta: deduplicare

Incrociando sei fonti arrivi facilmente a 400-600 candidati, con moltissime formulazioni diverse della stessa domanda. “quanto costa X”, “prezzo di X”, “X quanto viene” sono lo stesso prompt ai fini della decisione, ma tre righe diverse in un foglio.

Deduplicare per stringa non funziona, perché la sovrapposizione è semantica. Il modo pratico è raggruppare per similarità di embedding e poi scegliere un rappresentante per gruppo:

import numpy as np
from sklearn.cluster import AgglomerativeClustering

def cluster_prompts(prompts, embed_fn, threshold=0.15):
    """Raggruppa formulazioni equivalenti. embed_fn: lista di stringhe -> matrice (n, d).
    threshold e' distanza coseno: 0,15 tiene insieme le riformulazioni,
    separa le domande diverse. Va tarato guardando i cluster, non a occhio."""
    vecs = np.asarray(embed_fn(prompts), dtype=float)
    vecs /= np.linalg.norm(vecs, axis=1, keepdims=True)

    labels = AgglomerativeClustering(
        n_clusters=None,
        distance_threshold=threshold,
        metric='cosine',
        linkage='average',
    ).fit_predict(vecs)

    groups = {}
    for prompt, label in zip(prompts, labels):
        groups.setdefault(int(label), []).append(prompt)

    # rappresentante = la formulazione piu' breve: e' di norma la piu' vicina
    # a come la scriverebbe un utente, non a come la scrive il marketing
    return {k: {'representative': min(v, key=len), 'variants': v}
            for k, v in groups.items()}

Due avvertenze che valgono più del codice. La soglia va tarata ispezionando i cluster, non presa da qui: 0,15 è un punto di partenza ragionevole con embedding general-purpose, ma dipende dal modello e dal dominio. E le varianti non si buttano: restano nella riga come variants, perché servono in fase di copertura del fan-out — sono letteralmente le riformulazioni che il motore genererà.

Dimensionamento e struttura

Per un progetto medio: 40-80 prompt prioritari per mercato, con la precisazione del capitolo 3 — è il numero dei prompt definiti, non quello dei prompt che puoi campionare in profondità ogni mese. La rilevazione statisticamente utile si concentra su un sottoinsieme di 15-25 money prompt con molte esecuzioni ciascuno; gli altri si monitorano con cadenza più larga e si accetta che il loro dato sia indicativo.

Struttura ogni riga così:

ID	Prompt	Audience	Fase	Motore	Priorità business (1-5)	Messaggio chiave atteso
P-012	quanto costa X per una PMI	Decisore PMI	3	ChatGPT, Google AI Mode	5	Prezzo trasparente, nessun costo di setup

Output di questo step: la lista dei must-win prompt, versionata e datata. È l’asset più importante di tutto il progetto e va trattata come tale: non la si riscrive ogni mese, la si aggiorna con un changelog.

4.3 Audit dei contenuti a quattro lenti

Adesso hai la domanda. Ti serve l’inventario dell’offerta, e un modo per decidere dove intervenire.

Fai l’inventario di tutto ciò che è pubblicato: pagine prodotto e servizio, guide, FAQ, hub, contenuti di campagna, comunicati, materiali su siti partner e contenuti earned che parlano di te. Sì, anche quelli che non controlli: entrano nel retrieval esattamente come i tuoi.

Poi assegna a ogni asset un punteggio su quattro lenti.

Le quattro lenti

Lente 1 — Freschezza. Quando è stato pubblicato o aggiornato in modo sostanziale? I sistemi di retrieval privilegiano il recente, soprattutto su temi dove i fatti cambiano (prezzi, normative, disponibilità, versioni). Che il segnale sia esplicitamente cercato lo si vede nella composizione delle sotto-query di fan-out, dove gli n-gram più frequenti sono gli anni (“2024”, “2025”, nel 6,26% dei casi). Attenzione: aggiornare la data senza toccare il contenuto non è un aggiornamento, ed è una pratica che si ritorce contro.
Lente 2 — Domanda. Quanta domanda intercetta il tema, nel tuo mercato? Qui il volume di ricerca classico resta il proxy migliore che abbiamo, integrato con la frequenza con cui il tema compare nelle tue fonti di prompt.
Lente 3 — Priorità business. Quanto conta per gli obiettivi dell’anno? Un tema con poca domanda ma legato al lancio su cui è appeso il budget vale più di un tema ad alto volume e margine zero. È la lente che pesa di più ed è l’unica che non puoi ricavare da un tool.
Lente 4 — Accessibilità. Il bot ci arriva? La pagina è già citata? Questa non è una lente da punteggio: è un cancello.

Come si combinano

Le prime tre le pesi:

Punteggio = (Business × 0,5) + (Domanda × 0,3) + (Freschezza × 0,2)

con ogni voce da 1 a 5. I pesi non hanno nulla di scientifico e non pretendo che l’abbiano: servono a rendere esplicito e discutibile un ordine di priorità che altrimenti resta implicito nella testa di chi decide. Il rapporto che conta è che il business pesi più della somma delle altre due, perché è l’unica lente che incorpora informazione non ricavabile da un tool. Se nel tuo contesto la freschezza è critica — normative, prezzi, disponibilità — alza il suo peso e abbassa quello della domanda, ma decidi i pesi una volta e non cambiarli fra un audit e il successivo, altrimenti stai confrontando classifiche costruite con righelli diversi.

La quarta lente funziona diversamente e questa distinzione è il cuore del metodo:

Se una pagina non è accessibile, non entra nella coda di riscrittura. Entra in una coda separata, con priorità superiore, e l’azione non è “riscrivere” ma “sbloccare”.

Riscrivere una pagina che i crawler non raggiungono è la forma più pura di lavoro sprecato, ed è molto più comune di quanto sembri. Prima si apre la porta, poi si arreda la stanza.

La griglia di audit

URL	Freschezza	Domanda	Business	Punteggio	Accessibile	Già citata	Azione
/prodotto/piano-base	2	4	5	4,0	Sì	No	Riscrittura answer-first
/guide/come-scegliere	5	5	3	4,1	No — JS	No	Sbloccare (SSR)
/faq	1	3	4	3,1	Sì	Sì	Aggiornare e ampliare

I gap che cerchi

L’audit serve a isolare quattro categorie:

Alta priorità, non accessibile → intervento tecnico immediato.
Alta priorità, accessibile, mai citata → problema di struttura o di autorevolezza. È il cuore del lavoro.
Alta priorità, obsoleta → aggiornamento sostanziale.
Informazione frammentata su più URL → consolidamento (ci torno sotto, è più insidioso di quanto sembri).

Due avvertenze che valgono il costo di un progetto

Contenuti dietro autenticazione. Se sta dietro login, per i motori generativi in pratica non esiste. Non è un problema risolvibile con lo schema. La domanda giusta non è “come lo faccio indicizzare” ma “quale parte di questa informazione può stare fuori dal login”. Spesso la risposta è: la parte che conta per chi deve ancora diventare cliente.

PDF e documenti. Sono estraibili peggio dell’HTML, spesso privi di struttura semantica, raramente aggiornati. Se un’informazione critica vive solo dentro un PDF, la vera azione è portarla in HTML, non ottimizzare il PDF.

4.4 Fondamenta tecniche

Qui si separa chi fa questo lavoro da chi ne parla. Cinque aree.

4.4.1 Accesso dei bot AI — e la posizione che consiglio

I crawler che ti interessano si dividono in tre categorie funzionali che quasi tutti confondono, con conseguenze concrete:

Categoria	Cosa fa	Cosa ti restituisce	Esempi
Training	Raccoglie contenuti per addestrare modelli futuri	Nulla di misurabile. Nessuna attribuzione, nessun traffico, nessuna possibilità di correzione	`GPTBot`, `ClaudeBot`, `CCBot`, `Google-Extended`, `Applebot-Extended`, `Bytespider`
Retrieval / indexing	Costruisce l’indice che l’assistente interroga per rispondere	Citazioni. È il canale da cui nasce la visibilità	`OAI-SearchBot`, `Claude-SearchBot`, `PerplexityBot`, `DuckAssistBot`, `Googlebot`, `bingbot`
Fetch on-demand	Scarica una pagina in tempo reale perché un utente l’ha chiesta	Citazioni e traffico di referral	`ChatGPT-User`, `Claude-User`, `Perplexity-User`, `MistralAI-User`

La mia posizione, dichiarata come tale: per la maggior parte dei siti a contenuto il default sensato è bloccare il training e lasciare aperti retrieval e fetch on-demand.

Il ragionamento. Il crawler di training prende il tuo contenuto e lo dissolve nei pesi di un modello: nessuna attribuzione, nessun clic, e — punto decisivo — nessuna possibilità di correggere un errore. Se il modello impara una cosa sbagliata su di te, quella cosa resta lì fino al retraining successivo e tu non hai leve. Il crawler di retrieval fa l’opposto: legge la tua pagina ora, cita la fonte, e se domani correggi la pagina la correzione si propaga alla prossima risposta.

Il default non è però universale, e la scelta cambia col modello di business: per un sito con contenuti premium, dati proprietari o paywall ha senso un approccio più restrittivo anche sul retrieval; per un e-commerce il training è ininfluente sulle conversioni, quindi bloccarlo non costa nulla. Il framework decisionale completo per tipologia di sito, l’enforcement lato server con Nginx, Apache e fail2ban per i bot che ignorano robots.txt, e la tabella di riferimento aggiornata degli user-agent stanno in Come gestire i crawler AI nel 2026.

Le obiezioni oneste, perché ci sono:

Bloccare il training oggi non ti toglie dai modelli già addestrati. Se lì c’è un errore su di te, questa mossa non lo risolve. Serve altro (vedi 4.6).
Alcuni operatori usano lo stesso user-agent per scopi diversi, o cambiano le regole. La tabella va riverificata periodicamente sulla documentazione ufficiale di ciascun operatore — per OpenAI la fonte è la pagina bots di OpenAI. Non è un file che scrivi una volta.
robots.txt è una richiesta, non un controllo di accesso. Chi vuole ignorarlo lo ignora. Per l’applicazione vera servono regole a livello di edge/WAF o le funzioni di bot management del tuo CDN — rate limiting e blocco selettivo lato server sono un capitolo a sé. Il capitolo 5 quantifica quanto questo conti nella pratica.

Ecco il file, commentato:

# =========================================================
# 1. REGOLE GENERALI
# =========================================================
User-agent: *
Disallow: /wp-admin/
Disallow: /carrello/
Disallow: /*?orderby=
Allow: /wp-admin/admin-ajax.php

# =========================================================
# 2. CRAWLER DI TRAINING — bloccati
#    Nessuna attribuzione, nessun traffico, nessuna
#    possibilità di correggere errori a valle.
# =========================================================
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Bytespider
Disallow: /

# =========================================================
# 3. RETRIEVAL E FETCH ON-DEMAND
#    NON dichiarare gruppi dedicati: vedi nota sotto.
#    Lasciandoli fuori ereditano le regole di "User-agent: *"
# =========================================================

Sitemap: https://www.esempio.it/sitemap_index.xml

La nota che salva il progetto. Un crawler obbedisce a un solo gruppo: quello il cui user-agent corrisponde più specificamente al proprio nome. La documentazione di Google è esplicita — “Only one group is valid for a particular crawler […] Google’s crawlers determine the correct group of rules by finding in the robots.txt file the group with the most specific user agent that matches the crawler’s user agent. Other groups are ignored.“ (Google robots.txt spec). La RFC 9309 §2.2.1 formalizza lo stesso comportamento: il gruppo * è un fallback che si applica solo quando nessun gruppo specifico corrisponde, mentre la fusione di più gruppi avviene soltanto fra gruppi che dichiarano lo stesso product token.

Tradotto: se scrivi

User-agent: *
Disallow: /carrello/
Disallow: /wp-admin/

User-agent: PerplexityBot
Allow: /

hai appena autorizzato PerplexityBot a scansionare /carrello/ e /wp-admin/, perché quel bot smette di leggere il gruppo *. È un errore frequentissimo, generato dalla buona intenzione di “dare il permesso esplicito”.

Regola pratica: per i bot che vuoi ammettere, non creare un gruppo dedicato. Li lasci ereditare da *. Crei un gruppo dedicato solo quando devi davvero differenziare, e in quel caso ripeti dentro il gruppo tutte le Disallow generiche.

Il caso Google, che merita un paragrafo suo. Google-Extended non controlla la comparsa in AI Overviews e AI Mode: quelle esperienze attingono all’indice di Search, governato da Googlebot. La documentazione ufficiale lo dice senza ambiguità — “robots.txt directives for Googlebot is the control for site owners to manage access to how their sites are crawled for Search” — e colloca Google-Extended fra i controlli per “AI training and grounding in some of Google’s other systems”, cioè i prodotti Gemini (AI Features and Your Website).

Tradotto: non puoi uscire dalle AI Overviews restando in Search tramite robots.txt. Le uniche leve sono i controlli di snippet:

<meta name="robots" content="nosnippet">
<meta name="robots" content="max-snippet:50">

<p>Testo utilizzabile.</p>
<p data-nosnippet>Questo blocco non verrà usato negli snippet.</p>

Con un compromesso che va detto chiaramente: nosnippet toglie anche lo snippet classico nella SERP. Per il 95% dei siti è un pessimo affare. data-nosnippet a livello di blocco è più chirurgico e ha senso su disclaimer, dati sensibili o testo legale che non vuoi vedere estratto fuori contesto. Il quadro completo delle direttive è nella guida ai meta tag HTML.

4.4.2 JavaScript e rendering

Il retrieval AI è, in generale, meno tollerante verso il JavaScript rispetto a Googlebot. Alcuni fetcher on-demand scaricano l’HTML grezzo e non eseguono nulla. Se il tuo contenuto compare solo dopo l’idratazione, per quei client la pagina è vuota.

Il test, in due comandi:

# Cosa vede un client che non esegue JavaScript
curl -sL -A "Mozilla/5.0 (compatible; TestBot/1.0)" https://www.esempio.it/pagina/ \
  | grep -c "frase-chiave-della-pagina"

# Confronto: peso dell'HTML grezzo
curl -sL https://www.esempio.it/pagina/ | wc -c

Se il conteggio è 0, hai un problema di rendering, non di contenuto. La soluzione strutturale è il server-side rendering o il prerendering statico per le pagine che contano. Il dynamic rendering è una toppa e va trattato come tale.

Da controllare in particolare, perché sono i punti dove si nasconde il contenuto che serve di più:

tab e accordion che caricano il contenuto solo al clic;
FAQ iniettate da script di terze parti;
tabelle di confronto e prezzi generati lato client;
recensioni caricate da widget esterni;
contenuto in lazy loading legato allo scroll.

Regola pratica: se un’informazione è nella lista dei must-win prompt, deve stare nell’HTML della risposta iniziale. Punto.

4.4.3 Structured data

Chiariamo prima un equivoco, così non ci perdiamo tempo — e la versione che circola è ormai datata.

I rich result FAQ non sono stati “ridimensionati nel 2023”: sono spariti. Ad agosto 2023 Google li ha ristretti ai soli siti governativi e sanitari (Changes to HowTo and FAQ rich results); poi la documentazione ha ricevuto un avviso di deprecazione — “This feature will no longer appear in Google Search starting May 7, 2026” — e a giugno 2026 la pagina di documentazione del rich result FAQ è stata rimossa del tutto.

Questo ha fatto concludere a molti che lo schema FAQ non serva più. È una conclusione affrettata, ma la ragione per usarlo è cambiata. Il rich result era l’effetto visibile; il markup resta un modo esplicito e non ambiguo di dichiarare “questa stringa è una domanda, quest’altra è la sua risposta”. Per un sistema che deve estrarre coppie domanda-risposta, è un regalo. Lo metti per la macchina, non per l’accordion.

Detto con la stessa onestà: dal momento che Google non documenta più quel rich result, non esiste più una garanzia lato Google su come quel markup venga interpretato, e il Rich Results Test non lo valida più come feature. FAQPage resta un tipo valido di schema.org e resta leggibile da qualunque parser: è su questo che poggia la scelta, non su una promessa di Google che non c’è più. Se il costo di manutenzione è alto, è legittimo depriorizzarlo rispetto a Organization e Article.

Organization — il tipo più sottovalutato. Serve a consolidare l’entità: dire ai sistemi che il tuo brand, la tua pagina Wikipedia, il tuo profilo LinkedIn e la tua voce Wikidata sono la stessa cosa. È la base del riconoscimento di entità, che è il vero terreno del lavoro off-site.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.esempio.it/#organization",
  "name": "Esempio",
  "legalName": "Esempio S.r.l.",
  "url": "https://www.esempio.it/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://www.esempio.it/logo.png",
    "width": 512,
    "height": 512
  },
  "foundingDate": "2011-03-15",
  "vatID": "IT01234567890",
  "sameAs": [
    "https://it.wikipedia.org/wiki/Esempio",
    "https://www.wikidata.org/wiki/Q00000000",
    "https://www.linkedin.com/company/esempio/",
    "https://www.youtube.com/@esempio"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer support",
    "telephone": "+39-02-0000000",
    "areaServed": "IT",
    "availableLanguage": ["it", "en"]
  }
}

L’@id è il pezzo che quasi nessuno usa: ti permette di referenziare la stessa entità da tutte le altre entità del sito senza ripeterne la definizione, costruendo un grafo coerente invece di isole scollegate.

FAQPage.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Quanto costa il piano Base?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Il piano Base costa 29 € al mese con fatturazione annuale, 34 € al mese con fatturazione mensile. Include 3 utenti, 10 GB di spazio e assistenza via email. Non include accesso API né SSO."
      }
    },
    {
      "@type": "Question",
      "name": "Posso cambiare piano in qualsiasi momento?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Sì. Il passaggio a un piano superiore è immediato e l'importo viene riproporzionato sui giorni residui. Il passaggio a un piano inferiore ha effetto dal rinnovo successivo."
      }
    }
  ]
}

Due regole: la risposta nel markup deve coincidere con quella visibile in pagina, e deve essere autoconsistente — leggibile senza il resto della pagina. Il markup FAQ è, non a caso, un ottimo esercizio di chunking forzato.

Article — per contenuti editoriali. author come Person con @id e sameAs è il pezzo che porta il segnale di expertise; dateModified alimenta la lente freschezza.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Come scegliere un fornitore: guida al confronto",
  "datePublished": "2026-04-12T09:00:00+02:00",
  "dateModified": "2026-08-28T11:30:00+02:00",
  "author": {
    "@type": "Person",
    "@id": "https://www.esempio.it/autori/mario-rossi/#person",
    "name": "Mario Rossi",
    "jobTitle": "Responsabile analisi di mercato",
    "sameAs": ["https://www.linkedin.com/in/mariorossi/"]
  },
  "publisher": { "@id": "https://www.esempio.it/#organization" },
  "mainEntityOfPage": "https://www.esempio.it/guide/come-scegliere/"
}

Product — con offers e, se li hai davvero, aggregateRating. Prezzo, disponibilità e valuta espliciti nel markup sono esattamente i dati che un assistente deve poter estrarre per rispondere a “quanto costa” senza inventare.

DefinedTerm / DefinedTermSet — per glossari e tassonomie. È il tipo che nessuno usa e che ha più senso per la ricerca AI: dichiara esplicitamente cosa significa un termine nel tuo dominio, il che è utile a un sistema che deve disambiguare.

{
  "@context": "https://schema.org",
  "@type": "DefinedTermSet",
  "@id": "https://www.esempio.it/glossario/#set",
  "name": "Glossario del settore",
  "hasDefinedTerm": [
    {
      "@type": "DefinedTerm",
      "@id": "https://www.esempio.it/glossario/#portabilita",
      "name": "Portabilità",
      "description": "Procedura che consente di trasferire un servizio attivo da un fornitore a un altro mantenendo le condizioni contrattuali sottoscritte.",
      "inDefinedTermSet": "https://www.esempio.it/glossario/#set"
    }
  ]
}

BreadcrumbList — banale e sempre utile: esplicita la gerarchia e aiuta a collocare la pagina nel contesto del sito.

Valida sempre con il Rich Results Test e con lo Schema Markup Validator: il primo dice cosa Google riconosce come feature, il secondo cosa è formalmente corretto. Servono entrambi, e — vedi sopra — sono due domande diverse.

4.4.4 `llms.txt`: perché non lo consiglio

La proposta è un file Markdown alla radice del dominio che offre ai modelli una mappa curata dei contenuti principali. La struttura è questa:

# Esempio

> Piattaforma di gestione documentale per PMI italiane. Attiva dal 2011.

## Prodotto
- [Panoramica](https://www.esempio.it/prodotto/): funzionalità principali
- [Prezzi](https://www.esempio.it/prezzi/): tre piani, confronto e limiti

## Documentazione
- [Guida introduttiva](https://www.esempio.it/docs/start/)

Lo metto qui per completezza, perché è la prima cosa che ti verrà proposta da chiunque venda “ottimizzazione per l’AI”. La mia posizione è netta e non è cambiata da quando ho scritto l’articolo dedicato: non lo consiglio, e non è uno standard.

Non è uno standard. È una proposta individuale, non adottata da alcun ente di standardizzazione e non implementata da alcun operatore di modelli. Nessuno l’ha annunciata, nessuno si è impegnato a consumarla.

Google l’ha esclusa esplicitamente. John Mueller l’ha paragonata al meta tag keywords, aggiungendo l’osservazione che conta di più: “you can tell when you look at your server logs that they don’t even check for it”. Gary Illyes, a Search Central Live APAC nel luglio 2025, ha confermato che Google non lo supporta e non ha piani per farlo.

E l’ho verificato sui miei log. L’osservazione di Mueller è esattamente il tipo di affermazione che si può controllare invece di ripetere, quindi l’ho controllata su evemilano.com. Il risultato, su una finestra di una settimana e 119.700 richieste: zero richieste di /llms.txt da parte di un qualsiasi crawler AI, contro 1.764 richieste di /robots.txt. Gli unici a chiederlo sono i tool che ti fanno l’audit per dirti che non ce l’hai.

L’argomento di merito, che resta il più importante: se nasceranno direttive utili per gli LLM, la sede corretta è estendere robots.txt — un formato compreso e rispettato da decenni, con una RFC alle spalle — non proliferare file di configurazione paralleli che i webmaster devono mantenere allineati a mano. Un secondo file che duplica informazioni già presenti nel sito è, per costruzione, un file che prima o poi diverge dal sito.

Cosa faccio, in pratica. Non lo pubblico e non lo inserisco negli audit. Se un cliente ce l’ha già non chiedo di rimuoverlo — non fa danno — ma non compare nei report e non conta come attività. Se qualcuno ti propone un intervento sulla visibilità AI il cui deliverable principale è un llms.txt, hai la risposta che ti serve sul resto della proposta.

Per l'”AI readiness” la domanda utile è un’altra — è quella che misura la reale accessibilità del sito agli agenti — ed è tutta in questo capitolo: i crawler di retrieval raggiungono le tue pagine prioritarie, ottengono un 200, e trovano il contenuto nell’HTML senza dover eseguire JavaScript?

4.4.5 Performance, indicizzazione, consolidamento

Velocità. I fetcher on-demand hanno timeout aggressivi. Una pagina che impiega otto secondi a rispondere può semplicemente non essere recuperata. Il TTFB conta più del punteggio Lighthouse.
Stato HTTP puliti. Catene di redirect e soft 404 mandano fuori strada i client meno sofisticati di Googlebot. Quanto sia diffuso il problema si misura sui log, e il capitolo 5 mostra come farlo senza prendere abbagli.
Link interni. Il retrieval usa il contesto circostante: un link con anchor clicca qui non dice nulla, un link con anchor confronto tra i piani di abbonamento colloca la destinazione.
Consolidamento. È il punto più insidioso di tutti.

Sul consolidamento vale la pena fermarsi. Lo scenario tipico: la stessa informazione — condizioni, costi, limiti, avvertenze — esiste in quattro versioni su quattro URL, ognuna con un livello di completezza diverso. Il PDF ha l’elenco puntuale, la pagina prodotto ha una versione discorsiva, la FAQ ne cita metà, la landing di campagna ne ha una versione vecchia.

Per un sistema di retrieval questo non è ridondanza utile: è rumore che riduce la fiducia. Le fonti si contraddicono, nessuna è manifestamente autorevole, e il sistema può scegliere la peggiore — o rivolgersi a un terzo che l’ha detto in modo più pulito.

Il rimedio: per ogni informazione critica designi una pagina canonica, la rendi la più completa e la più recente, e da tutte le altre ci punti. Non serve cancellare: serve una gerarchia esplicita.

4.5 Struttura del contenuto

Tecnica a posto, il bot arriva e legge. Adesso il punto è se quello che legge è estraibile.

La regola: la risposta in cima

Il pattern che funziona è risposta diretta, poi contesto, poi dettaglio. È l’opposto di come si scrive normalmente in azienda, dove si costruisce la premessa e si arriva al punto in fondo.

Non è una preferenza stilistica: nelle aggregazioni sulle citazioni ChatGPT, il 44,2% delle citazioni proviene dal primo 30% del documento. La posizione dell’informazione dentro la pagina pesa sulla probabilità che venga estratta.

Prima:

La nostra azienda, attiva dal 2011, ha sempre posto grande attenzione alla trasparenza nei confronti dei propri clienti. Nel corso degli anni abbiamo sviluppato una gamma articolata di soluzioni pensate per rispondere alle esigenze più diverse. Il nostro approccio si fonda sull’ascolto e sulla capacità di adattare l’offerta al contesto specifico di ogni realtà. Proprio per questo abbiamo strutturato tre piani, il primo dei quali parte da 29 euro mensili.

Il dato che serve è nell’ultima riga, annegato. Nessun sistema di retrieval lo estrae in modo pulito, perché il frammento in cui compare non regge da solo.

Dopo:

Quanto costa il piano Base? Il piano Base costa 29 €/mese con fatturazione annuale (34 €/mese con fatturazione mensile). Include 3 utenti, 10 GB di spazio e assistenza via email. Non include accesso API né SSO. Il piano è pensato per team fino a 5 persone con esigenze di archiviazione contenute. Sopra i 10 GB o i 3 utenti conviene valutare il piano Pro…

[Aggiungere tabella pricing]

Il secondo blocco funziona perché l’heading è la domanda reale, il primo paragrafo è autoconsistente ed estraibile senza il resto, i numeri sono espliciti, c’è anche l’informazione negativa (cosa non è incluso — spesso è ciò che l’utente sta effettivamente chiedendo), e la tabella permette il confronto diretto senza doverlo dedurre dal testo.

Heading come domande reali

Usa la formulazione che usa l’utente, non quella del reparto marketing.

Non così	Così
Soluzioni flessibili	Posso cambiare piano in corso d’anno?
Il nostro impegno per la sicurezza	Dove sono conservati i miei dati?
Tariffe e condizioni	Quanto costa e cosa è incluso?
Assistenza dedicata	In quanto tempo rispondete a una richiesta?

Non è una questione di tono: un heading formulato come la domanda dell’utente aumenta la probabilità che quel blocco venga associato a quella domanda in fase di retrieval.

Chunking: quattro regole

Ogni sezione regge da sola. Test pratico: copia una sezione, incollala in un documento vuoto. Ha senso? Se inizia con “come abbiamo visto” o “inoltre”, no.
Un concetto per sezione. Se un H3 copre tre argomenti, saranno tre H3.
Paragrafi brevi, 40-80 parole. Non per leggibilità: per granularità di estrazione.
Ripeti il soggetto. Nel parlato “questo” e “esso” funzionano. In un frammento estratto fuori contesto, no. Ripetere il nome del prodotto o del concetto non è cattivo stile, è progettazione per l’estrazione.

Per approfondire puoi leggere la guida dedicata: Content Chunking per AI Search: analisi dei rischi e strategie di ottimizzazione semantica.

Coprire il fan-out

Per ogni prompt principale, la pagina deve rispondere anche al grappolo di sotto-domande che il motore genererà. Che questa copertura paghi è misurato: le pagine che si posizionano su più sotto-query di fan-out hanno il 161% di probabilità in più di essere citate.

Griglia di lavoro:

Tipo di sotto-domanda	Esempio a partire da “software gestione documentale PMI”
Costo	quanto costa, ci sono costi nascosti, esiste un piano gratuito
Confronto	differenze rispetto a X, quale conviene, alternative
Idoneità	va bene per un’azienda di 10 persone, funziona nel mio settore
Attivazione	quanto ci vuole, serve un tecnico, si può migrare da un altro sistema
Rischio	i miei dati dove stanno, cosa succede se disdico, è conforme al GDPR
Tempistiche	quando conviene farlo, quanto dura il contratto

Non tutte devono stare nella stessa pagina. Il modello che funziona è hub e spoke: una pagina pilastro che tocca tutti i temi con una risposta breve e autoconsistente per ciascuno, e pagine di approfondimento collegate per i temi che meritano spazio proprio. È esattamente l’impianto di questa guida, e il motivo per cui i capitoli 2, 3 e 4.4.1 rimandano ad approfondimenti verticali invece di ripeterli.

Attenzione a un’insidia: il fan-out osservato oggi non è quello di domani. Con solo il 27% delle sotto-query stabile fra esecuzioni, ottimizzare per la lista esatta estratta ieri è overfitting. Si ottimizza per il nucleo ricorrente e per la copertura dello spazio di intenti, non per la lista.

Multimodale

I sistemi generativi usano volentieri tabelle, elenchi e dati strutturati, e restituiscono immagini e video quando aiutano. Due indicazioni:

Non lasciare informazione critica solo dentro immagini o video. Se l’unico posto dove spieghi una procedura è un video, per il retrieval quella spiegazione non esiste. Accompagna sempre con testo — trascrizione, sintesi, o entrambi.
Tabelle vere in HTML. <table> con <th>, non un layout a <div> che sembra una tabella. La struttura semantica è ciò che rende la tabella estraibile.

Evidenza, autore, data

Ogni claim numerico ha una fonte esplicita e linkata.
I contenuti hanno un autore identificabile, con una pagina autore che dice perché quella persona è competente su quel tema.
La data di ultimo aggiornamento è visibile e vera.
Dati proprietari — le tue analisi, i tuoi benchmark, i tuoi casi — sono la cosa più difficile da replicare e quella che più spesso genera citazioni. Un contenuto che ripete quello che c’è già ovunque non ha nessuna ragione di essere citato al posto di quello che c’era già. Il capitolo che segue è, per questa guida, l’applicazione di questa regola a sé stessa.

4.6 Autorevolezza off-site

Il tuo sito è la base, non il perimetro. I sistemi generativi costruiscono le risposte pescando ovunque, e su molti prompt le fonti dominanti non sono i siti dei brand.

Il cambio di prospettiva. In SEO classica il link è un voto che trasferisce autorevolezza. Per la ricerca AI conta di più la menzione come fonte: essere descritti, citati e associati ai temi giusti su domini che il sistema recupera. È lavoro di riconoscimento di entità e di reputazione — lo stesso terreno del segnale di qualità del sito e della branded search — più che di link building.

Le famiglie di fonti che ricorrono

Con la premessa che la distribuzione cambia molto per settore e per motore, e che va misurata sui tuoi prompt invece che assunta:

Enciclopedie e knowledge base collaborative — peso strutturale nel grounding di quasi tutti i sistemi.
Stampa e testate verticali — la copertura editoriale resta un segnale forte, soprattutto per l’attualità.
Recensioni e comparatori indipendenti — dominanti sui prompt di scelta e confronto, che sono i prompt che convertono.
Community e forum — molto presenti, con linguaggio vicino a quello dei prompt reali. Terreno delicato: l’astroturfing si vede e si ritorce contro.
Video — le trascrizioni sono materiale di prima classe per il retrieval. Se produci video, la trascrizione pubblicata e indicizzabile è metà del valore.
Documentazione istituzionale e di settore — associazioni, enti, standard, pubblicazioni tecniche.
Documenti aziendali pubblici — bilanci, report, white paper: sottovalutati, e spesso l’unica fonte primaria su di te.

Quattro attività concrete

a) Mappa le fonti effettivamente citate sui tuoi prompt. Per ciascuno dei prompt prioritari, registra ogni dominio citato. Aggrega. Ottieni la classifica dei domini che formano le risposte nel tuo mercato — che di solito è sorprendentemente concentrata: spesso 10-15 domini coprono la maggioranza delle citazioni. Quella lista è il tuo piano di digital PR, costruito su dati invece che su intuizioni.

b) Recupera le menzioni senza link. Cerca le occorrenze del tuo brand su domini che non ti linkano. Sono conversioni facili e rafforzano l’associazione entità-dominio.

c) Correggi le inesattezze, con metodo. Interroga i modelli sul tuo brand e sui tuoi prodotti e annota ogni errore fattuale. Poi risali alla fonte: quasi sempre l’errore ha un’origine identificabile — una pagina vecchia, un articolo mai rettificato, una voce di terze parti sbagliata. Correggere alla fonte è più efficace che pubblicare una smentita sul proprio sito, perché è la fonte che verrà recuperata di nuovo.

Processo minimo, da eseguire ogni trimestre:

10-15 prompt fissi su brand, prodotti, prezzi, condizioni, confronti diretti.
Esecuzione su tutti i motori prioritari, con un numero di run coerente col capitolo 3.
Registrazione di ogni affermazione errata con la fonte citata.
Contatto con il gestore della fonte, con la documentazione della correzione.
Riverifica dopo 30 giorni.

d) Struttura i contenuti PR per l’estrazione. Un comunicato scritto per l’ufficio legale non viene citato. Un comunicato scritto per essere estratto sì. Cosa cambia in pratica: titolo specifico e fattuale invece che evocativo; primo paragrafo che è già la risposta completa; dati in tabella e non nel discorso; citazioni attribuite a persone con ruolo e competenza dichiarati; una sezione di FAQ in coda; nessun gergo aziendale.

5. Cosa dicono i log: uno studio di prima mano

Tutto il capitolo precedente poggia su un presupposto: che tu sappia chi passa davvero dal tuo server. Il metodo che circola per verificarlo — e che avevo scritto anch’io nella prima stesura di questa guida — è un grep sugli user-agent. Ho deciso di controllare se regge, misurandolo sui log di evemilano.com.

Non regge. E la differenza fra il numero che produce e la realtà è abbastanza grande da ribaltare le conclusioni.

Metodo

Fonte: log Nginx di evemilano.com, formato combined.
Finestra: dal 26 agosto 2026 alle 00:00 al 1 settembre 2026 alle 12:51 — 6,5 giorni.
Volume: 119.700 richieste totali.
Verifica: per ogni richiesta il cui user-agent dichiara un bot OpenAI, l’IP di origine è stato confrontato con i prefissi pubblicati ufficialmente da OpenAI (openai.com/gptbot.json, /searchbot.json, /chatgpt-user.json).

Il grafico anticipa i due risultati che seguono. A sinistra quanto del traffico dichiarato è autentico; a destra come cambia la diagnosi sui codici di stato quando si contano solo i bot verificati.

Risultato 1 — la maggioranza dei “bot OpenAI” non è OpenAI

User-agent dichiarato	Richieste totali	Verificate	Spoofate	% falso	IP unici
`GPTBot`	615	228	387	62,9%	18
`OAI-SearchBot`	567	184	383	67,5%	88
`ChatGPT-User`	782	371	411	52,6%	273

Fra il 53% e il 68% del traffico che si dichiara crawler OpenAI non proviene da OpenAI. Un’analisi basata sul solo user-agent sovrastima il passaggio dei bot AI di due o tre volte.

Il traffico falso è concentrato: quattro indirizzi generano oltre 1.100 delle richieste spoofate, e tutti e quattro hanno reverse DNS *.bc.googleusercontent.com — cioè macchine affittate su Google Cloud. Chi guarda solo il PTR e vede “google” nel nome può concludere che sia traffico Google. Non lo è: googleusercontent.com è l’hosting, non l’infrastruttura di crawling di Google.

Cosa chiede questo traffico:

    8  /.mcp.json
    8  /old/.env
    8  /config/gcp-credentials.json
    8  /.aws/config
    8  /api/v1/env
    7  /download?file=../../../../etc/passwd
    7  /firebase-config.json
    7  /gcp-service-account.json

Non è crawling: è ricerca di credenziali. Lo user-agent di un bot AI viene usato come travestimento, nella ragionevole aspettativa che i siti lo lascino passare. Che /.mcp.json sia il path più richiesto è il dettaglio del 2026: i file di configurazione dei server MCP contengono spesso chiavi API in chiaro.

Risultato 2 — i bot veri si comportano in modo molto diverso

Isolando il solo traffico con IP verificato, il quadro cambia completamente:

Bot (solo IP verificati)	Richieste	URL distinti	200	301	404
`GPTBot` (training)	228	211	152	72	1,8%
`OAI-SearchBot` (retrieval)	184	62	132	35	8,2%
`ChatGPT-User` (fetch on-demand)	371	75	314	57	0,0%

Confronto con quello che avrebbe detto il grep ingenuo sugli stessi user-agent: 34%, 36% e 26% di 404. La diagnosi sarebbe stata “i bot AI sbattono contro centinaia di 404, ho un grave problema di URL rotti”. La diagnosi corretta è l’opposto: i bot veri trovano quasi sempre quello che cercano, e i 404 erano tutti degli attaccanti che sondavano path inesistenti.

I tre profili di comportamento, che mappano con precisione le tre categorie funzionali del capitolo 4.4.1:

GPTBot (training) — 211 URL distinti su 228 richieste: quasi una richiesta per URL. Crawl ampio e superficiale, di scoperta. Vuole coprire il sito.
OAI-SearchBot (retrieval) — 62 URL distinti su 184 richieste: circa tre passaggi per URL. Crawl stretto e ripetuto su un insieme selezionato. Mantiene aggiornato un indice, non lo costruisce da zero.
ChatGPT-User (fetch on-demand) — 75 URL, 371 richieste, zero 404. Sono pagine richieste perché un utente reale, in una conversazione reale, ha chiesto qualcosa che ha portato lì. Zero 404 perché arrivano da link e citazioni che esistono davvero.

Quest’ultima riga è la più interessante da leggere in chiave di business: 371 fetch on-demand in 6,5 giorni sono 371 momenti in cui un assistente ha aperto una mia pagina per rispondere a qualcuno. È il canale che il capitolo 4.4.1 dice di tenere aperto, misurato.

Risultato 3 — nessuno chiede `llms.txt`

Sulla stessa finestra:

File	Richieste	Da chi
`/robots.txt`	1.764	Tutti i crawler, ripetutamente
`/llms.txt`	17 (tutte 404)	SEOJuice-SearchBot, NetRanksPolicyAudit, TheWebReport, PoweredByBot, più qualche browser generico

Richieste di /llms.txt da parte di un crawler AI — GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Applebot, Bytespider, CCBot, DuckAssistBot, Amazonbot, Googlebot, bingbot: zero.

Il rapporto è di circa 100 a 1 in favore di robots.txt, e i pochi che chiedono llms.txt sono strumenti di audit SEO che verificano se ce l’hai — cioè esattamente il meccanismo che alimenta la domanda del file. È la verifica empirica dell’osservazione di Mueller, su un dataset indipendente.

Lo script, per rifarlo sui tuoi log

import re, json, ipaddress, collections

LOG = "/var/log/nginx/access.log"

def load(path):
    """Carica i prefissi IPv4 pubblicati da un operatore (formato OpenAI)."""
    d = json.load(open(path))
    return [ipaddress.ip_network(p["ipv4Prefix"])
            for p in d.get("prefixes", []) if "ipv4Prefix" in p]

# scarica prima: curl -O https://openai.com/gptbot.json (e searchbot/chatgpt-user)
BOTS = {
    "GPTBot":        load("gptbot.json"),
    "OAI-SearchBot": load("searchbot.json"),
    "ChatGPT-User":  load("chatgpt-user.json"),
}

LINE = re.compile(
    r'^(\S+) \S+ \S+ \[([^\]]+)\] "(\S+) (\S+)[^"]*" (\d{3}) \S+ "[^"]*" "([^"]*)"'
)

stats = collections.defaultdict(
    lambda: {"tot": 0, "ok": 0, "fake": 0, "urls": set(), "status": collections.Counter()}
)

def verified(ip, nets):
    try:
        addr = ipaddress.ip_address(ip)
    except ValueError:
        return False
    return any(addr in net for net in nets)

with open(LOG, encoding="utf-8", errors="replace") as f:
    for line in f:
        m = LINE.match(line)
        if not m:
            continue
        ip, _, _, path, status, ua = m.groups()
        for bot, nets in BOTS.items():
            if bot not in ua:
                continue
            s = stats[bot]
            s["tot"] += 1
            if verified(ip, nets):
                s["ok"] += 1
                s["urls"].add(path)
                s["status"][status] += 1   # statistiche SOLO sul traffico verificato
            else:
                s["fake"] += 1

for bot, s in stats.items():
    pct = 100 * s["fake"] / s["tot"] if s["tot"] else 0
    print(f"{bot}: {s['tot']} dichiarate, {s['ok']} verificate, "
          f"{s['fake']} spoofate ({pct:.1f}%), {len(s['urls'])} URL reali")

Il punto metodologico da portare a casa è nella riga commentata: le statistiche di comportamento vanno calcolate solo sul traffico verificato. Tutto il resto è rumore, e nel mio caso è la maggioranza.

Limiti di questo studio, dichiarati

Perché sia utile va detto anche cosa non dimostra:

Un solo sito, una sola finestra. Un blog tecnico italiano di nicchia, in 6,5 giorni. Le proporzioni su un e-commerce internazionale o su un editore ad alto volume saranno diverse. La metodologia è generale, i numeri sono miei.
Verifica completa solo per OpenAI. Ho applicato le liste di prefissi ufficiali ai tre bot OpenAI perché sono pubblicate in formato consumabile. Per Anthropic, Perplexity e gli altri non ho eseguito la stessa validazione, quindi non riporto i loro numeri: sarebbero contaminati dallo stesso spoofing e presentarli sarebbe l’errore che questo capitolo denuncia.
Le liste di prefissi cambiano. Vanno riscaricate a ogni analisi. Un IP legittimo aggiunto dopo il download risulta falsamente spoofato.
Lo spoofing è una stima per difetto. Chi si traveste da browser normale, invece che da bot, non compare in questa analisi.

6. Traccia B — Il loop continuo

Le fondamenta producono un salto. Poi i modelli si aggiornano, i competitor si muovono, i prompt cambiano, e senza manutenzione il vantaggio si consuma. La traccia B è il ciclo che va innestato nel processo di pianificazione, non un progetto con una data di fine.

    ┌──────────────────────────────────────────────┐
    │                                              │
    ▼                                              │
 DEFINE ──▶ BENCHMARK ──▶ ANALYSE ──▶ ACTIVATE ────┘
                                          │
                                          ▼
                                       MONITOR

6.1 Define — trimestrale

Rivedi la lista dei must-win prompt. Non la riscrivi: la aggiorni. Cosa cambia in un trimestre: nuovi prodotti, nuove obiezioni dall’assistenza, nuovi concorrenti, stagionalità, cambi normativi.

Aggiungi le nuove voci, archivia quelle non più rilevanti — archivia, non cancella, altrimenti perdi la serie storica — e tieni un changelog. Se il 40% della lista cambia ogni trimestre, il problema non è il mercato: è che la lista iniziale era costruita male.

6.2 Benchmark — prima volta, poi a ogni cambio rilevante

La baseline è la fotografia di partenza. Va fatta bene una volta e poi mantenuta identica nel metodo, altrimenti i confronti non valgono nulla.

Elementi da fissare e non toccare più: il set di prompt, il set competitivo, i motori, il numero di esecuzioni per prompt, la geolocalizzazione, il formato del dato.

Se devi cambiare qualcosa, cambialo e segnalo nel report come rottura di serie. Un grafico che sale perché hai cambiato metodo è peggio di nessun grafico.

6.3 Analyse — mensile

Esegui i prompt e registra. Il punto critico non è quali campi raccogli: è dove li metti. Un foglio di calcolo regge il primo trimestre e poi collassa, perché la struttura del dato è a due livelli — l’osservazione singola e l’aggregato per prompt — e un foglio ne rappresenta bene solo uno.

La granularità corretta è una riga per esecuzione, mai per prompt. Gli aggregati si calcolano, non si registrano:

CREATE TABLE observation (
    id              INTEGER PRIMARY KEY,
    observed_at     TEXT    NOT NULL,   -- ISO 8601, con timezone
    prompt_id       TEXT    NOT NULL,   -- P-012: stabile nel tempo, mai riusato
    engine          TEXT    NOT NULL,   -- chatgpt | google-ai-mode | perplexity | ...
    model_version   TEXT,               -- se esposta dal motore
    run_index       INTEGER NOT NULL,   -- 1..n dentro la stessa rilevazione
    geo             TEXT    NOT NULL,   -- costante fra rilevazioni, dichiarata
    brand_mentioned INTEGER NOT NULL,   -- 0/1
    prominence      TEXT,               -- opening | body | closing | absent
    owned_link      INTEGER NOT NULL,   -- 0/1: c'e' un link a un dominio nostro
    accuracy        TEXT,               -- correct | imprecise | wrong
    sentiment       TEXT,               -- positive | neutral | negative
    method_version  INTEGER NOT NULL,   -- vedi sotto: le rotture di serie
    raw_response    TEXT                -- la risposta integrale, sempre
);

CREATE TABLE observation_citation (
    observation_id  INTEGER NOT NULL REFERENCES observation(id),
    domain          TEXT    NOT NULL,
    is_owned        INTEGER NOT NULL
);

CREATE TABLE observation_competitor (
    observation_id  INTEGER NOT NULL REFERENCES observation(id),
    competitor      TEXT    NOT NULL
);

Tre scelte di schema che sembrano pedanteria e non lo sono:

raw_response si conserva sempre. Fra sei mesi vorrai rispondere a una domanda che oggi non ti sei posto — “da quando hanno smesso di citare quel comparatore?” — e senza il testo integrale devi rifare tutto. Costa niente e non è recuperabile a posteriori.
Citazioni e competitor in tabelle separate. Sono relazioni uno-a-molti. Comprimerle in una colonna con valori separati da virgola è la scelta che rende impossibile la query che ti servirà davvero, cioè la concentrazione delle fonti.
method_version su ogni riga. È il modo di rendere le rotture di serie un dato invece che una nota in fondo al report. Quando cambi numero di esecuzioni, motori o geolocalizzazione, incrementi la versione: i confronti si filtrano per versione e nessuno costruisce per sbaglio un grafico che sale perché è cambiato il righello.

L’aggregato che conta si calcola con l’intervallo di Wilson, coerentemente col capitolo 3:

import math, sqlite3

def wilson_ci(k, n, z=1.96):
    """IC 95% di Wilson per una proporzione. k = successi, n = prove."""
    if n == 0:
        return 0.0, 0.0, 1.0
    p = k / n
    denom = 1 + z * z / n
    centre = (p + z * z / (2 * n)) / denom
    margin = z * math.sqrt(p * (1 - p) / n + z * z / (4 * n * n)) / denom
    return p, max(0.0, centre - margin), min(1.0, centre + margin)

def mention_rate(db, prompt_id, engine, method_version):
    cur = db.execute("""
        SELECT SUM(brand_mentioned), COUNT(*)
        FROM observation
        WHERE prompt_id = ? AND engine = ? AND method_version = ?
    """, (prompt_id, engine, method_version))
    k, n = cur.fetchone()
    p, lo, hi = wilson_ci(k or 0, n or 0)
    return {
        'prompt_id': prompt_id, 'engine': engine, 'n': n,
        'mention_rate': p, 'ci_low': lo, 'ci_high': hi,
        'width': hi - lo,          # se supera ~0,20 il dato non decide nulla
    }

Il campo width è quello da guardare per primo nel report mensile: un prompt il cui intervallo è più largo di 20 punti non sta dicendo niente, e l’azione corretta è aumentare le esecuzioni su quel prompt o toglierlo dal set attivo — non commentarne la variazione.

E la query che alimenta direttamente il lavoro off-site del capitolo 4.6:

-- concentrazione delle fonti: i domini che formano le risposte nel tuo mercato
SELECT c.domain,
       COUNT(*)                                       AS citations,
       ROUND(100.0 * COUNT(*) / (SELECT COUNT(*)
                                 FROM observation_citation), 1) AS share_pct
FROM observation_citation c
JOIN observation o ON o.id = c.observation_id
WHERE o.method_version = :current_version
GROUP BY c.domain
ORDER BY citations DESC
LIMIT 20;

Se i primi dieci domini coprono la maggioranza delle citazioni — è lo scenario tipico — quella lista è il piano di digital PR, ordinato per impatto e costruito su dati invece che su intuizioni.

Le domande a cui questo impianto deve rispondere:

Compaio? E con quale intervallo di confidenza, non con quale percentuale secca.
Chi c’è al posto mio? Competitor diretti, o fonti terze che dominano il tema?
La risposta è accurata? Ogni errore va tracciato con la fonte da cui deriva.
Quali domini formano la risposta? È l’input diretto della traccia off-site.
Dove sono i gap più grandi? Assenza totale, informazione sbagliata, sentiment negativo, o fonti scadenti che dicono cose su di me.

6.4 Activate — continuo

Le azioni si distribuiscono su quattro leve, e la scelta dipende dalla diagnosi:

Diagnosi	Leva
Non compaio e non ho contenuto sul tema	Produrre contenuto
Ho il contenuto ma non viene estratto	Ristrutturare (answer-first, chunking, schema)
Il contenuto non è raggiungibile	Intervento tecnico
Compaio male, o dominano fonti terze	Off-site, PR, correzione alla fonte

Il principio che tiene insieme tutto: coerenza del messaggio su ogni canale. Se il sito dice una cosa, il comunicato un’altra e la scheda su un comparatore una terza, il sistema di retrieval trova versioni discordanti e la fiducia cala. Allineare i messaggi non è un esercizio di brand: è ottimizzazione tecnica.

6.5 Monitor — mensile, con revisione trimestrale

Riesegui i prompt con lo stesso metodo.
Traccia i quattro KPI e il SOV nel tempo.
Automatizza tutto ciò che è automatizzabile: la rilevazione manuale non sopravvive al terzo mese.
Riverifica dopo ogni evento rilevante: lancio di prodotto, migrazione, restyling, cambio di prezzi, aggiornamento maggiore di un modello.
Riporta gli apprendimenti nella fase Define del trimestre successivo.

7. Misurazione: KPI, cadenze, tool

Questa è la parte che nella maggior parte dei progetti resta implicita, e per questo salta per prima.

Cadenze

Frequenza	Cosa	Perché
Settimanale	Nulla di sistematico	Il rumore supera il segnale. Con i numeri di esecuzioni sostenibili settimanalmente, il margine di errore è più ampio della variazione che stai cercando di leggere
Mensile	Rilevazione dei money prompt con campionamento profondo, quattro KPI, mix delle fonti	La cadenza minima per vedere un trend
Trimestrale	Revisione della lista prompt, analisi competitiva, riprioritizzazione, audit di accuratezza sul brand	Allineata al ciclo di pianificazione
Ad evento	Rilevazione mirata dopo lanci, migrazioni, aggiornamenti di modello	Isola l’effetto dell’evento

Cosa non misurare

Il traffico da LLM come unica metrica. Gran parte del valore è zero-click: la menzione sposta la consideration anche senza clic. Se misuri solo il traffico, concluderai che non funziona niente.
I prompt sul brand name. Se qualcuno chiede “cosa fa [tuo brand]”, comparire è il minimo sindacale. Misurarlo gonfia i numeri e non informa nessuna decisione.
La posizione. Non esiste un ranking. Esiste presenza, prominenza dentro la risposta, e accuratezza.
Una singola esecuzione. Vedi capitolo 3: non è un dato, è un’osservazione con un margine di errore che copre quasi tutta la scala.
I passaggi dei bot AI contati per user-agent. Vedi capitolo 5: sul mio server sarebbe stato un errore del 53-68%.

Search Console: cosa puoi vedere oggi, e cosa no

Questo punto va aggiornato, perché la risposta che circola — “non è misurabile” — è ferma a prima di giugno 2026.

Cosa è cambiato. Google ha introdotto i Search Generative AI performance reports in Search Console, con rollout completato il 31 agosto 2026. Esiste quindi una vista dedicata alle funzionalità generative di Search.

Cosa ti danno, esattamente. Meno di quanto il nome suggerisca, e i limiti contano più della feature:

Aspetto	Stato
Impression nelle funzionalità generative	Sì, esposte nel report dedicato
Clic	No. Il report riporta impression, non clic
AI Overviews e AI Mode separati	No, sono aggregati
Dati per query	No. Le dimensioni disponibili sono Pagine, Paesi, Date, Dispositivi
Sovrapposizione col report principale	Sì: gli stessi dati sono conteggiati anche nel tipo di ricerca “Web”

Fonte: Generative AI performance report, documentazione Search Console.

Cosa resta vero della vecchia obiezione. I clic provenienti dalle AI Overviews continuano a non essere isolabili: sono conteggiati nei totali del report Prestazioni e non esiste un filtro che li separi. Chi ti promette il numero esatto di clic da AI Overviews sta stimando, e dovrebbe dirtelo.

Cosa farci in pratica. Il report generativo ti dà l’andamento delle impression in ambito AI — utile per capire se la tua esposizione cresce o cala, e su quali pagine. Per l’effetto sul traffico resta l’indizio indiretto: impression in crescita con CTR in calo su query informative è il pattern tipico di una query dove la risposta generata soddisfa l’utente. Non è una prova, è un indizio, ma ora hai un secondo segnale da incrociarci.

Panorama dei tool

Non è una classifica ed è deliberatamente neutra: la scelta dipende da budget, mercati e volumi.

Fase	Categoria	Strumenti
Prompt research	Domande e fan-out	AlsoAsked, AnswerThePublic, Semrush, Ahrefs
Prompt research	Dati di prima parte	Search Console, log di ricerca interna, ticket dell’assistenza
Audit tecnico	Crawler	Screaming Frog, Sitebulb, JetOctopus
Audit tecnico	Log dei bot AI	Stack ELK, log del CDN, script custom (capitolo 5)
Audit tecnico	Validazione dati strutturati	Rich Results Test, Schema Markup Validator
Visibilità AI	Tracking di menzioni e citazioni	Semrush AI Toolkit, Ahrefs Brand Radar, Profound, Peec AI, Otterly.AI, Scrunch, Rankscale, BrightEdge, Conductor
Reputazione	Menzioni e sentiment	Brandwatch, Talkwalker, Mention
Traffico	Referral dai domini AI	GA4 con segmento dedicato

Un avvertimento sulle piattaforme di AI visibility. Sono utili e fanno risparmiare tempo, ma il numero che ti danno dipende interamente dai prompt che ci hai messo dentro e dal numero di esecuzioni che eseguono per ciascuno. Un tool con la lista sbagliata produce report bellissimi e inservibili; un tool che esegue un prompt al giorno produce grafici che misurano rumore. Sono le due domande da fare in fase di valutazione, prima del prezzo. Il lavoro del capitolo 4.2 non è delegabile al tool: è il tool che dipende da quel lavoro.

Log dei bot: la verifica che quasi nessuno fa bene

I log del server sono l’unica prova diretta che i crawler AI passino davvero e cosa raggiungano; per il corredo di comandi con cui interrogarli c’è la guida al fare SEO da terminale. Ma vanno letti nel modo giusto: un grep sugli user-agent, sul mio server, avrebbe sovrastimato il traffico OpenAI di due o tre volte e prodotto una diagnosi sbagliata sui 404. Il metodo corretto, i risultati e lo script completo sono al capitolo 5.

In sintesi, i tre passaggi:

Filtra per user-agent per isolare i candidati.
Verifica l’IP contro i prefissi pubblicati dall’operatore. Senza questo passaggio i numeri non valgono.
Calcola le statistiche solo sul traffico verificato: URL distinti, codici di stato, frequenza, copertura delle pagine prioritarie.

Cosa cerchi alla fine: quali bot passano davvero, con quale frequenza, su quali pagine e con quali codici di stato. Se i tuoi contenuti prioritari non compaiono in quella lista, hai un problema di accesso che nessun lavoro sui contenuti risolverà.

8. Guardrail ed errori comuni

I quattro guardrail

1. Non controlli l’output. Non esiste una leva che garantisca la comparsa in una risposta generata. Puoi aumentare la probabilità di essere recuperato, citato e descritto correttamente. Qualsiasi obiettivo formulato come “essere primi su ChatGPT” è mal posto e produrrà una discussione sgradevole a fine trimestre. Formula in termini di mention rate, citation rate e accuratezza, con una baseline, un delta e un intervallo di confidenza.

2. Definisci i KPI prima di scalare. Un pilota su pochi prompt e due motori, con metrica dichiarata e baseline, vale più di un programma su cinque mercati senza un modo condiviso di dire se sta funzionando.

3. La revisione precede la pubblicazione. In settori regolamentati questo è ovvio. Vale però ovunque: contenuti scritti per essere estratti e citati fuori contesto vanno rivisti pensando al fuori contesto. Una frase perfettamente corretta dentro la sua pagina può diventare fuorviante da sola. È un rischio nuovo e va gestito in redazione, non dopo.

4. Non superare il confine con la manipolazione. Nel maggio 2026 Google ha aggiornato le proprie spam policy nominando esplicitamente la manipolazione delle risposte generative: alterare artificiosamente ciò che le funzioni AI di Search restituiscono è spam, soggetto ad azioni manuali e demotion algoritmica esattamente come la manipolazione del ranking organico. In pratica: niente acquisto di citazioni, niente testo nascosto o prompt injection nei contenuti, niente pagine costruite per pilotare gli assistenti. La leva legittima resta l’information gain — dire qualcosa che non c’era. Il dettaglio della policy è in Come gestire i crawler AI nel 2026.

Dieci errori che vedo ripetersi

Partire dai contenuti invece che dai prompt. Produci, poi scopri che nessuno chiedeva quella cosa.
Ottimizzare per il nome del brand. Vanity metric. Chi cerca il tuo nome ti ha già trovato.
Confondere visibilità AI e traffico da AI. Sono due obiettivi con due misure. Servono entrambe.
Riscrivere pagine che i bot non raggiungono. Prima l’accesso, sempre.
Trattarlo come progetto. Fine progetto, fine risultati, in due trimestri.
Fidarsi di una singola esecuzione. Metà dei casi di successo che circolano sono varianza campionaria.
Bloccare tutto per prudenza. Un Disallow: / generalizzato a tutti i bot AI ti toglie anche dai canali che producono citazioni e traffico. Distingui le tre categorie.
Il feticcio di llms.txt. Nessun operatore lo consuma, e sui miei log nessun crawler AI lo ha mai richiesto. Non è una strategia: è una casella da spuntare che qualcuno ti vende.
Ignorare le fonti terze. Se un comparatore pubblica dati sbagliati su di te, quella è la fonte che verrà recuperata, non la tua smentita.
Contare i bot per user-agent. È l’errore che ho scoperto commettendo: senza verifica dell’IP i numeri sono gonfiati di due o tre volte e la diagnosi sui codici di stato si ribalta.

9. Checklist operativa

Fase 0 — Preparazione

[ ] Definiti i quattro KPI e come si calcolano
[ ] Deciso il numero di esecuzioni per prompt e il modo di riportare l’intervallo di confidenza
[ ] Definito e congelato il set competitivo
[ ] Individuati i due o tre motori prioritari sul mercato di riferimento
[ ] Stabiliti proprietà del processo e cadenza di reporting
[ ] Concordato il processo di revisione dei contenuti prima della pubblicazione

Fase 1 — Assessment

[ ] Raccolti dati di utilizzo per motore sul mercato specifico
[ ] Distinta esposizione passiva da uso deliberato
[ ] Segmentati in GA4 i referral dai domini degli assistenti
[ ] Tabella di priorità dei motori completata

Fase 2 — Prompt

[ ] Estratti e analizzati i log della ricerca interna
[ ] Intervistati i team a contatto col cliente
[ ] Analizzate le query GSC ad alta impression e basso CTR
[ ] Fatto crawl di heading e FAQ dei competitor
[ ] Raccolte le formulazioni reali da forum e recensioni
[ ] Lista di prompt prioritari, versionata e datata
[ ] Individuato il sottoinsieme di money prompt da campionare in profondità
[ ] Ogni prompt associato ad audience, fase, priorità business e messaggio atteso

Fase 3 — Audit contenuti

[ ] Inventario completo degli asset (owned, partner, earned)
[ ] Pesi delle lenti decisi e congelati per il ciclo
[ ] Punteggio su freschezza, domanda, priorità business
[ ] Verifica di accessibilità come cancello, non come punteggio
[ ] Verificata la citazione attuale per ogni asset prioritario
[ ] Coda “sbloccare” separata dalla coda “riscrivere”
[ ] Individuati i casi di informazione frammentata su più URL

Fase 4a — Tecnico

[ ] robots.txt rivisto con le tre categorie di bot distinte
[ ] Verificato che i bot ammessi non abbiano un gruppo dedicato che scavalca le regole generali
[ ] Testato il rendering senza JavaScript sulle pagine prioritarie
[ ] SSR o prerendering attivi dove necessario
[ ] Organization con @id e sameAs implementato
[ ] Article, Product, BreadcrumbList dove pertinenti; FAQPage valutato sapendo che Google non lo documenta più
[ ] Markup validato su entrambi i validatori
[ ] TTFB verificato sulle pagine prioritarie
[ ] Catene di redirect e soft 404 risolte
[ ] Anchor dei link interni descrittive
[ ] Contenuti frammentati consolidati con pagina canonica designata
[ ] Liste di prefissi IP degli operatori scaricate e aggiornate
[ ] Log dei bot AI analizzati con verifica dell’IP, non per solo user-agent
[ ] Copertura delle pagine prioritarie verificata sul traffico verificato

Fase 4b — Contenuto

[ ] Pagine prioritarie riscritte con la risposta in cima
[ ] Heading riformulati come domande reali
[ ] Sezioni verificate come autoconsistenti (test copia-incolla)
[ ] Paragrafi entro 40-80 parole
[ ] Sotto-domande del fan-out coperte, per pagina o per cluster
[ ] Informazione critica non lasciata solo in immagini o video
[ ] Tabelle in HTML semantico
[ ] Claim numerici con fonte linkata
[ ] Autore identificato con pagina autore
[ ] Data di aggiornamento visibile e veritiera
[ ] Almeno un dato proprietario per pagina pilastro

Fase 4c — Off-site

[ ] Mappati i domini citati sui prompt prioritari
[ ] Individuata la concentrazione delle fonti (top 10 domini)
[ ] Piano PR costruito su quella lista
[ ] Menzioni senza link individuate e recuperate
[ ] Audit di accuratezza sul brand eseguito
[ ] Errori ricondotti alla fonte e correzioni richieste
[ ] Comunicati ristrutturati per l’estrazione
[ ] Trascrizioni dei video pubblicate e indicizzabili

Fase 5 — Loop

[ ] Baseline stabilita e metodo congelato
[ ] Template di rilevazione operativo
[ ] Rilevazione mensile calendarizzata con un responsabile
[ ] Revisione trimestrale della lista prompt calendarizzata
[ ] Riverifica ad evento prevista nel processo di rilascio
[ ] Reporting automatizzato dove possibile
[ ] Changelog delle modifiche a prompt e metodo

10. FAQ

L’ottimizzazione per la ricerca AI sostituisce la SEO?

No. Condividono la maggior parte delle fondamenta tecniche — accessibilità, rendering, struttura, velocità, autorevolezza — e divergono su obiettivi e metriche. Un sito con fondamenta SEO solide parte molto avanti. Un sito con problemi SEO strutturali non può lavorare sulla visibilità AI: sta cercando di ottimizzare un canale a cui il canale non accede.

Quanto tempo serve per vedere risultati?

Gli interventi tecnici che sbloccano l’accesso possono riflettersi in poche settimane, perché il retrieval è live. Ristrutturazione dei contenuti: uno o due mesi per vedere il movimento sui prompt interessati. Autorevolezza off-site: due o tre trimestri, ed è la parte con l’inerzia più alta. Se qualcuno promette risultati in due settimane, sta parlando di prompt sul brand name.

Devo bloccare i crawler AI?

Distingui. Bloccare i crawler di training ha una logica difendibile: non ti restituiscono nulla di misurabile e non ti lasciano correggere gli errori. Bloccare quelli di retrieval e i fetcher on-demand significa uscire volontariamente dal canale che produce citazioni e traffico — sul mio blog sono 371 fetch on-demand verificati in una settimana, cioè 371 volte in cui un assistente ha aperto una pagina per rispondere a qualcuno. Il blocco indiscriminato è quasi sempre un errore. E ricorda che robots.txt è una richiesta: per un controllo effettivo servono regole a livello di edge.

`llms.txt` serve davvero?

No, e non lo consiglio. Non è uno standard: è una proposta individuale che nessun operatore di modelli ha adottato. Google l’ha esclusa esplicitamente — Mueller l’ha paragonata al meta tag keywords, Illyes ha confermato che non è supportata e non è nei piani. Sui log di questo sito, in 6,5 giorni e 119.700 richieste, /llms.txt è stato richiesto 17 volte, mai da un crawler AI: solo da tool di audit SEO che verificano se ce l’hai. Nello stesso periodo robots.txt è stato richiesto 1.764 volte. Il ragionamento completo è in llms.txt: a cosa serve?.

Lo schema FAQ ha ancora senso, se i rich result non esistono più?

Ha senso per una ragione diversa da quella originale, e con una precisazione. Il rich result FAQ è stato ristretto nel 2023 e rimosso del tutto il 7 maggio 2026, con la documentazione Google eliminata a giugno. Quindi non c’è più alcuna garanzia lato Google su come quel markup venga trattato. Resta però un tipo valido di schema.org e un modo esplicito di dichiarare la relazione domanda-risposta, che è ciò che serve a un sistema che deve estrarre coppie. Lo metti per la macchina, non per l’accordion — e se il costo di manutenzione è alto, Organization e Article vengono prima.

Come misuro il traffico dalle AI Overviews?

I clic non sono isolabili: sono conteggiati nei totali di Search Console senza un filtro che li separi. Le impression sì, da giugno 2026: il report Generative AI di Search Console (rollout completato il 31 agosto 2026) espone le impression nelle funzionalità generative, aggregando AI Overviews e AI Mode, con dimensioni Pagine, Paesi, Date e Dispositivi — ma senza dati per query. Il traffico dagli assistenti standalone è invece pienamente misurabile: si segmenta in GA4 sui referral dai loro domini.

Quanti prompt devo monitorare?

Meno di quanti te ne propongono, campionati meglio. Definisci pure 40-80 prompt prioritari per mercato, ma la rilevazione statisticamente utile si concentra su 15-25 money prompt con molte esecuzioni ciascuno. Con n=10 il margine di errore è ±26 punti: un tool che monitora 200 prompt con una esecuzione al giorno ti sta vendendo 200 numeri che non significano nulla.

I risultati cambiano ogni volta che rieseguo lo stesso prompt. È normale?

Sì, ed è più estremo di quanto sembri: servono in media 1.500 esecuzioni dello stesso prompt per ottenere due risposte identiche. Per questo una singola esecuzione non è un dato. Esegui più volte, riporta la proporzione con l’intervallo di confidenza e osserva la varianza. Un prompt con alta varianza non è un prompt vinto a metà: è un prompt instabile, e va trattato come tale.

Come faccio a sapere se i bot AI passano davvero dal mio sito?

Guardando i log, ma verificando l’IP e non solo lo user-agent. Sul mio server fra il 53% e il 68% del traffico che si dichiarava crawler OpenAI proveniva da indirizzi fuori dai prefissi ufficiali — in gran parte scanner in cerca di file di credenziali. Il metodo, i numeri e lo script sono al capitolo 5.

Ha senso investire in visibilità AI se il mio settore è di nicchia?

Spesso ha più senso che in un settore affollato. Nelle nicchie le fonti autorevoli sono poche, la concorrenza sul contenuto strutturato è bassa e diventare la fonte di riferimento su un tema specifico è realistico. Il rovescio della medaglia è che i volumi assoluti sono bassi: vanno misurate le conversioni, non le impression.

Da dove comincio se ho poco tempo?

Nell’ordine, e senza saltare: verifica sui log — con controllo dell’IP — che i bot di retrieval raggiungano le tue pagine prioritarie e ottengano un 200; costruisci una lista di 30-40 prompt reali partendo dalla ricerca interna e dall’assistenza; esegui una baseline manuale su 10-15 money prompt con abbastanza esecuzioni da avere un intervallo leggibile; riscrivi answer-first le cinque pagine più importanti. Sono due settimane di lavoro e ti danno una misura di partenza e un primo movimento.

Fonti

Documentazione ufficiale

Google Search Central — AI Features and Your Website
Google — How Google Interprets the robots.txt Specification
IETF — RFC 9309: Robots Exclusion Protocol
Google Search Central — Changes to HowTo and FAQ rich results
Google Search Central — Search Generative AI performance reports
Search Console Help — Generative AI performance report
OpenAI — Overview of OpenAI Crawlers

Approfondimenti su evemilano.com

Dati di terze parti citati

Nectiv — analisi di ~70.000 fan-out estratti da 9.000 prompt commerciali via API Gemini
Semrush — analisi di 200 risposte GPT-5.2, luglio 2026
Backlinko — aggregazione di studi sulle citazioni ChatGPT
Rand Fishkin (SparkToro) — stabilità delle risposte LLM
Kevin Indig — sovrapposizione delle citazioni fra motori AI

Dati di prima parte

Log Nginx di evemilano.com, 26 agosto – 1 settembre 2026, 119.700 richieste. Metodo, risultati e script al capitolo 5.

La parte difficile non è nessuno dei singoli passaggi: è mantenere il loop acceso quando l’entusiasmo iniziale finisce. Metti in calendario la rilevazione mensile prima di iniziare qualsiasi altra cosa.