Query fan-out: guida tecnica al meccanismo che decide la visibilità nelle AI

Quando un utente digita una domanda in AI Mode, Google non esegue quella ricerca: ne esegue in media nove diverse, generate da un LLM, in parallelo e all’insaputa dell’utente. Il query fan-out è il meccanismo di espansione delle query che alimenta AI Mode, AI Overviews, Gemini con grounding e — con varianti — ChatGPT Search e Perplexity. È anche la ragione tecnica per cui il ranking tradizionale non predice più la citazione: il 90% delle pagine citate da ChatGPT si posiziona oltre la posizione 21 per la query principale.

Questa guida ricostruisce il fan-out dalle fonti primarie — i brevetti Google, la documentazione ufficiale e tre dataset indipendenti pubblicati tra fine 2025 e luglio 2026 — e arriva al livello operativo: come estrarre le sotto-query reali via API con Python, come costruire un fan-out coverage audit replicabile e come adattare l’architettura dei contenuti.

La definizione ufficiale di Google

Il termine non è gergo SEO: è la terminologia interna di Google, usata pubblicamente all’annuncio di AI Mode (I/O, 20 maggio 2025). La definizione ufficiale recita:

“AI Mode uses our query fan-out technique, breaking down your question into subtopics and issuing a multitude of queries simultaneously on your behalf.”

La documentazione per publisher aggiunge il dettaglio che interessa a chi fa SEO: il sistema emette “multiple related searches across subtopics and data sources”, e questo permette di mostrare “a wider and more diverse set of helpful links” rispetto alla ricerca classica. Deep Search, la variante estesa, arriva a “centinaia di ricerche” per un singolo report.

Due precisazioni per inquadrare correttamente il fenomeno:

• Il fan-out non è nato con AI Mode. L’espansione delle query (sinonimi, riscritture, stemming) esiste da decenni nell’information retrieval. La novità è che ora la genera un LLM con obiettivi di diversità intenzionale, che le sotto-query sono decine e che i risultati alimentano una sintesi generativa invece di una SERP.
• Google dichiara ufficialmente che non servono ottimizzazioni speciali: “There are no additional requirements to appear in AI Overviews or AI Mode”. Vedremo più avanti perché questa affermazione è vera alla lettera e incompleta nella sostanza.

I brevetti dietro il fan-out

Il funzionamento interno non è documentato pubblicamente, ma i brevetti depositati da Google descrivono un’architettura coerente. I sei documenti rilevanti, incrociati dalle analisi di Mike King (iPullRank) e Search Engine Land:

A questi si aggiungono il brevetto US11663201B2 analizzato da Dan Petrovic — che descrive un “control model” che valuta la qualità delle varianti generate e decide se produrne altre, con un tetto di 20 iterazioni — e il più recente brevetto di Thematic Search (US12158907, depositato a dicembre 2024), che usa il fan-out per organizzare i risultati in temi gerarchici espandibili, ciascuno con il proprio riassunto generativo.

Avvertenza metodologica: un brevetto documenta ciò che Google può fare, non ciò che è in produzione oggi. Ma la convergenza tra brevetti, comportamento osservabile e dichiarazioni pubbliche rende questa ricostruzione la migliore approssimazione disponibile.

La pipeline di AI Mode, fase per fase

Combinando “Search with stateful chat” con le analisi citate, la pipeline che processa una query in AI Mode si articola così:

1. Ricezione e contestualizzazione. La query arriva con il suo contesto: sessione conversazionale, localizzazione, dispositivo, cronologia, stato dell’account.
2. Interpretazione iniziale. Un LLM (una versione custom di Gemini) forma ipotesi sull’intento e sul tipo di task richiesto.
3. Query fan-out. L’LLM genera le sotto-query sintetiche. Il prompt interno — secondo WO2024064249A1 — enfatizza diversità intenzionale, variazione lessicale e riformulazioni basate su entità: non varianti casuali, ma una copertura sistematica dello spazio dell’intento.
4. Retrieval parallelo. Ogni sotto-query interroga l’indice (e altre fonti: Knowledge Graph, Shopping Graph, dati locali) simultaneamente.
5. Custom corpus. I documenti recuperati formano un corpus temporaneo, uno “slice” dell’indice rilevante per quella combinazione di query, utente e momento.
6. Ranking passage-level a coppie. Qui il cambio di paradigma: invece di punteggi assoluti (BM25, segnali classici), US20250124067A1 descrive un LLM che confronta i passaggi a due a due — “dato questo intento, quale dei due passaggi risponde meglio?” — producendo un ordinamento relativo.
7. Selezione dei modelli e sintesi. Query classificate per task attivano LLM specializzati (riassunto, confronto, validazione), che compongono la risposta a partire dai passaggi selezionati.
8. Citazioni per reasoning step. Le fonti citate sono quelle che supportano i singoli passaggi del ragionamento — non necessariamente i documenti meglio posizionati per la query originale. Nelle AI Overviews il flusso è addirittura invertito (“generate-first”): la sintesi viene prodotta e poi verificata cercando passaggi che ne confermino le affermazioni.

Ogni fase della pipeline è un punto in cui un contenuto può entrare o uscire dalla partita: si può essere recuperati da una sotto-query e scartati nel pairwise ranking, o vincere il ranking e non essere citati perché nessun reasoning step ha bisogno di quel passaggio.

Le tipologie di sotto-query e come coprirle

Le fonti convergono su otto pattern ricorrenti di sotto-query, che vale la pena conoscere perché ciascuno chiede al contenuto una cosa diversa:

L’analisi di iPullRank aggiunge le dimensioni trasversali: query related (adiacenze via Knowledge Graph), implicit (intenti inferiti), comparative (rilevate quando il sistema riconosce una decisione d’acquisto), recent e personalized (dalla cronologia e dal profilo utente). Le ultime due non sono coprebili dal contenuto: sono il motivo per cui due utenti con la stessa query ottengono fan-out diversi.

Quante sotto-query genera davvero: i numeri

Tre dataset indipendenti quantificano il fenomeno, con metodologie diverse e risultati coerenti.

Nectiv (~70.000 fan-out estratti via API Gemini da 9.000 prompt commerciali):

• Media di 9,06 sotto-query per prompt (contro le 2-3 dell’espansione tradizionale); il 59% dei prompt genera 5-11 sotto-query, il 24% ne genera 12-19, con un massimo osservato di 28.
• Lunghezza media di 6,7 parole; il 77% delle sotto-query è tra 5 e 8 parole: il fan-out produce long-tail sintetica, non keyword secche.
• Fortissima varianza settoriale: software 11,7 sotto-query medie, travel 10,8, careers 9,8, local 3,79 — dove l’intento è geografico il sistema ha meno da esplorare.
• Gli n-gram più frequenti nelle sotto-query: anni (“2024/2025”, 6,26% — il sistema cerca esplicitamente freschezza multi-anno), “reviews” (2,14%), “vs” (1,41%), “free” e “top” (1,05%).

Semrush (200 risposte GPT-5.2, luglio 2026): il fan-out dipende dal reasoning. Su 100 prompt, la modalità Instant genera ~245 sotto-query, la modalità Thinking ~1.130 (4,6 volte tante); sulle domande comparative si passa da 5,5 a 24 sotto-query medie. Il fan-out non è una costante del sistema: è una funzione dello sforzo di ragionamento.

Backlinko (aggregazione di studi sulle citazioni ChatGPT): il 90% delle pagine citate si posiziona oltre la posizione 21 per la query principale; le pagine che si posizionano su più sotto-query di fan-out hanno il 161% di probabilità in più di essere citate; solo il 27% delle sotto-query resta stabile tra esecuzioni ripetute; il 44,2% delle citazioni proviene dal primo 30% del documento.

Perché il ranking classico non predice la citazione

I numeri qui sopra hanno una spiegazione architetturale precisa, ed è la parte della pipeline che più cambia il lavoro SEO:

• La competizione è per sotto-query, non per query. Il tuo posizionamento sulla query principale determina al massimo l’ingresso nel custom corpus per una delle nove-e-più ricerche eseguite. Una pagina invisibile sulla head query ma fortissima su tre sotto-query specifiche entra nel corpus tre volte.
• La selezione è passage-level. Il pairwise ranking confronta paragrafi, non pagine. Un singolo paragrafo autosufficiente compete contro i paragrafi di tutti gli altri documenti del corpus — un concetto che chi ha letto la mia analisi del reverse engineering del RAG riconoscerà: il chunk è l’unità competitiva.
• La citazione segue il reasoning, non il rank. US20240256965A1 descrive risposte costruite su passaggi intermedi di ragionamento; viene citato il documento che supporta lo step, non il più autorevole in assoluto. È il meccanismo che spiega perché fonti “minori” ma molto specifiche vengono citate al posto dei leader di categoria.
• Il fan-out è personalizzato. Lo user embedding (WO2025102041A1) — il vettore denso costruito su query passate, click e comportamento cross-Google — influenza quali sotto-query vengono generate e come viene riordinato il corpus. Il rank tracking logged-out misura una realtà che nessun utente vede.

Il vecchio modello mentale “keyword → posizione → traffico” va sostituito con “spazio di intenti → copertura → probabilità di citazione”. La parte semantica di questo lavoro — entità, disambiguazione, consolidamento — è la stessa descritta nella guida al Knowledge Graph di Google; il fan-out ne è il consumatore finale.

Come osservare le sotto-query reali

Il fan-out di produzione non è pubblico, ma esistono quattro vie di osservazione con gradi diversi di affidabilità.

1. Gemini API con Google Search grounding (il metodo primario)

Quando abiliti il tool google_search, la risposta include groundingMetadata.webSearchQueries: l’elenco delle ricerche Google realmente eseguite dal modello per rispondere. È lo stesso meccanismo di grounding che alimenta le esperienze generative di Google, ed è l’unico metodo documentato ufficialmente. In Python:

from collections import Counter

from google import genai
from google.genai import types

client = genai.Client(api_key="LA_TUA_API_KEY")

config = types.GenerateContentConfig(
    tools=[types.Tool(google_search=types.GoogleSearch())],
    temperature=1.0,
)

def fan_out(prompt: str) -> list[str]:
    """Ritorna le ricerche Google eseguite dal modello per il grounding."""
    resp = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=prompt,
        config=config,
    )
    gm = resp.candidates[0].grounding_metadata
    return list(gm.web_search_queries) if gm and gm.web_search_queries else []

# Il fan-out non e' deterministico: campiona con N ripetizioni
# e osserva quali sotto-query ricorrono.
prompt = "migliore crm per una pmi italiana"
counter = Counter()
N = 10
for _ in range(N):
    counter.update(fan_out(prompt))

for query, freq in counter.most_common():
    print(f"{freq:>2}/{N}  {query}")

Il campionamento ripetuto è essenziale: con il 27% di stabilità tra esecuzioni, una singola run mostra un’istantanea, non la mappa. Le sotto-query che ricorrono in 7-10 run su 10 sono il nucleo stabile dell’intento; quelle che appaiono una volta sono la coda esplorativa.

2. Screaming Frog + Gemini: il fan-out di tutto il sito

Go Fish Digital ha documentato l’industrializzazione del metodo: un custom JavaScript in Screaming Frog (Config → Custom → Custom JavaScript) che per ogni pagina crawlata estrae l’H1, lo invia all’endpoint Gemini con grounding attivo e scrive le sotto-query in una colonna del crawl. Il risultato è la mappa fan-out dell’intero sito in un unico passaggio — con l’avvertenza dei costi: una chiamata API per pagina, quindi si parte dal template set, non dalle 50.000 URL. Dalla versione 24, Screaming Frog espone anche un server MCP che rende questa pipeline pilotabile da agenti.

3. ChatGPT via DevTools

Le sotto-query di ChatGPT Search sono osservabili nei network request di DevTools durante una conversazione con ricerca attiva: è il metodo con cui sono stati costruiti i dataset citati sopra. Utile per il confronto cross-piattaforma, perché — come mostra lo studio Semrush — il fan-out di ChatGPT in modalità reasoning è un animale diverso da quello di Google.

4. Metodi prompt-based: da usare con cautela

Circolano tecniche che chiedono direttamente ad AI Mode di stampare le proprie sotto-query (prompt del tipo “you are a terminal logger… print(query_fan_outs)”). Vanno trattate per quello che sono: output generati, non log di sistema — il modello può produrre un elenco plausibile ma non verificabile, senza segnali di localizzazione e personalizzazione. Per lo stesso motivo diffido dei tool che “simulano” il fan-out senza grounding reale: utili per il brainstorming, non come dato.

Fan-out coverage audit: la metodologia replicabile

Mettendo insieme estrazione e dati GSC, il processo che uso per valutare la copertura di un sito rispetto allo spazio di intenti è questo:

1. Definisci il prompt set. 10-30 money prompt: le domande ad alto intento del tuo dominio, formulate come le porrebbe un utente (non come keyword). Per generarle in modo sistematico, il metodo del Query Decoder resta il riferimento.
2. Campiona il fan-out. Script qui sopra, N=10 ripetizioni per prompt, aggregazione con Counter. Output: per ogni prompt, il nucleo stabile (frequenza ≥ 70%) e la coda esplorativa.
3. Classifica le sotto-query secondo la tabella delle otto tipologie: ti dice subito se il sistema esplora confronti (servono tabelle comparative), specificazioni (servono sotto-pagine o sezioni dedicate), implicazioni (serve contenuto sui prerequisiti).
4. Incrocia con GSC. Per ogni sotto-query stabile, verifica se il sito ha una pagina che si posiziona (query exact e varianti nel report Performance, o via API). Le sotto-query stabili senza pagina posizionata sono i gap di copertura, in ordine di priorità per frequenza.
5. Decidi l’unità di risposta. Per ogni gap: sezione nuova in una pagina esistente (se l’intento è una sfaccettatura) o pagina nuova nel cluster (se l’intento regge da solo). L’errore da evitare è la pagina-fotocopia per ogni sotto-query: il pairwise ranking premia il passaggio migliore, non la pagina più mirata.
6. Rimisura nel tempo. Il fan-out cambia con i modelli e con la stagionalità; l’audit va ripetuto a ogni release rilevante, e la visibilità risultante va trattata come proprietà statistica — metriche e intervalli di confidenza sono nella guida su come misurare la visibilità nelle AI.

Ottimizzare l’architettura per il fan-out

Le implicazioni architetturali, in ordine di impatto:

• Hub-and-spoke per entità e intenti. La pagina hub copre il tema e le generalizzazioni; le pagine spoke coprono specificazioni e implicazioni. L’analisi di Oncrawl inquadra bene il principio: la visibilità è diventata un problema di architettura almeno quanto di contenuto.
• Passage-level structure. Heading formulati come domande reali (le sotto-query sono domande di 5-8 parole), risposta diretta nelle prime frasi della sezione, sezioni autosufficienti che sopravvivono all’estrazione dal contesto. Il dato Backlinko sul primo 30% della pagina suggerisce di non seppellire le risposte migliori in fondo al documento.
• Entità esplicite. Nomi propri, prodotti, concetti nominati senza pronomi ambigui, dati strutturati coerenti: le sotto-query entity-expanded navigano il Knowledge Graph, e un’entità non consolidata non viene espansa.
• Copertura comparativa e freschezza. I pattern Nectiv (“vs”, “reviews”, anni correnti) dicono che il sistema cerca attivamente confronti e contenuti datati di recente: le pagine di confronto oneste e aggiornate intercettano una frazione sproporzionata del fan-out commerciale.
• Accesso e renderizzabilità. Tutto questo presuppone che i fetcher AI possano leggere il contenuto: la gestione degli accessi è il prerequisito, e l’ho trattata nella guida ai crawler AI.

Su questo sfondo va letta la posizione ufficiale di Google (“nessuna ottimizzazione speciale necessaria”): è vera nel senso che non esiste un markup magico per le AI — e infatti la documentazione esclude esplicitamente schema dedicati — ma è incompleta, perché l’idoneità tecnica non è la stessa cosa della probabilità di citazione. Tra “eleggibile” e “citato” ci sono il fan-out, il pairwise ranking e le reasoning chain descritti sopra, e su quelli il modo in cui strutturi contenuti e architettura incide eccome.

Limiti e onestà epistemica

Quattro cose che questa guida non può dirti, e che nessuno può dirti onestamente:

• I brevetti non sono la produzione. La ricostruzione della pipeline è la migliore inferenza disponibile, non una specifica confermata. Google non ha mai dettagliato pubblicamente quali brevetti siano implementati e come.
• Il fan-out che estrai non è il fan-out dell’utente. I metodi via API mancano di personalizzazione e stato conversazionale: osservi la versione “spersonalizzata” del meccanismo. È comunque il dato più vicino alla realtà che si possa ottenere.
• L’instabilità è strutturale. Con un quarto delle sotto-query stabili tra run, ottimizzare per il singolo fan-out osservato è overfitting; si ottimizza per il nucleo ricorrente e per la copertura dello spazio, non per la lista di ieri.
• Il campo si muove. Questa guida fotografa luglio 2026: modelli, quote di reasoning e comportamento del fan-out cambiano a ogni release. La metodologia di estrazione e audit resta valida; i numeri specifici vanno rimisurati.

Conclusioni operative

Il query fan-out sposta la domanda strategica da “per quale keyword voglio rankare?” a “quale porzione dello spazio di intenti del mio dominio copro meglio dei concorrenti?”. In pratica:

1. Estrai, non indovinare: il fan-out reale è osservabile via webSearchQueries — usalo al posto delle ipotesi sui “topic correlati”.
2. Campiona sempre: N=1 è rumore; il nucleo stabile emerge solo dalla ripetizione.
3. Ragiona per passaggi: l’unità competitiva è il paragrafo autosufficiente, non la pagina.
4. Copri lo spazio, non la lista: sotto-query stabili senza pagina posizionata = backlog editoriale prioritizzato.
5. Misura come proprietà statistica: presence e citazioni con intervalli di confidenza, mai come ranking giornaliero.

Il fan-out è la ragione per cui la SEO tecnica e semantica contano più di prima, non meno: retrieval, chunking, entità e architettura sono esattamente i punti della pipeline dove si vince o si perde la citazione.