Come raggruppare in topic le query di Search Console per trovare opportunità

Perché raggruppare in topic le query di Search Console

Search Console riporta le query una riga alla volta, e su qualsiasi sito con traffico reale la maggior parte di quelle righe è minuscola. Una query con 40 impressioni a trimestre non dice nulla da sola, ma duecento formulazioni della stessa domanda sommate diventano un topic per cui puoi posizionarti, scrivere e che puoi monitorare. Raggruppare trasforma anche un elenco che nessuno legge in una tabella breve su cui agire: quali argomenti ti portano traffico, quali sei vicino a conquistare e quali stanno perdendo terreno. È lo stesso motivo per cui il playbook sulla striking distance funziona meglio per topic che per query, perché di solito una pagina serve un intero cluster.

Prima di iniziare, togli due tipi di query. Le query di brand si comportano diversamente da tutte le altre (si posizionano in alto e ricevono molti clic), quindi raggruppale a parte o non raggrupparle affatto; il filtro per query di brand di Search Console ora divide il report Rendimento in una vista Brand e una Non-brand sui siti idonei. E se nella tua lista di query sono finite stringhe lunghe, a forma di prompt, che gli strumenti di AI visibility inviano a Google a intervalli regolari, filtra anche quelle, altrimenti formeranno un cluster tutto loro che nessun utente ha mai digitato. Il report Query Analysis di GSC Wizard le etichetta come sonde dei tracker LLM così puoi escluderle.

Tre modi per raggruppare le query di GSC, a confronto

Ci sono tre metodi pratici (il secondo ha due varianti, n-gram e sovrapposizione delle SERP), più il raggruppamento che Google stesso ora mostra in Search Console Insights. Bilanciano controllo e copertura: le regole sono prevedibili ma trovano solo ciò a cui avevi pensato, mentre gli embedding trovano ciò che ti era sfuggito ma ti danno gruppi da controllare a mano.

L'opzione di Google merita prima una frase. A ottobre 2025 Google ha aggiunto i Query groups a Search Console Insights, una scheda che “raggruppa query di ricerca simili” e mostra i clic totali per gruppo, ordinati come Top, Trending up e Trending down. Google scrive che “i gruppi sono calcolati usando l'AI; possono evolversi e cambiare nel tempo” e che “sono disponibili solo per le proprietà con un grande volume di query”. È quindi una buona panoramica gratuita se ce l'hai, ma non puoi definire i gruppi, non sono abbastanza stabili da seguirli mese su mese, e i siti più piccoli non ricevono affatto la scheda.

Metodo 1: gruppi regex nel filtro di Search Console

Nel report Rendimento aggiungi un filtro Query, scegli Personalizzato (regex) e scrivi un pattern per topic, per esempio cold.?brew|iced coffee concentrate. Secondo la pagina di aiuto di Google sul filtraggio avanzato, “viene usata la sintassi RE2”, la corrispondenza è parziale (il pattern può corrispondere in qualsiasi punto della query a meno che tu non lo ancori con ^ o $), e non distingue maiuscole e minuscole a meno che tu non inizi il pattern con (?-i). RE2 non ha lookahead né backreference, quindi i pattern copiati da un cheat sheet JavaScript o PCRE a volte falliscono; le FAQ sul filtro regex di Search Console hanno esempi funzionanti.

Il punto di forza di questo metodo è che decidi tu esattamente cosa appartiene a un topic, e lo stesso pattern dà lo stesso gruppo il mese dopo. Il punto debole è che Search Console mostra una sola vista filtrata alla volta, quindi confrontare dodici topic significa dodici viste filtrate e copiare a mano ogni totale in un foglio, e la tabella delle query sotto ogni vista si ferma a 1.000 righe (vedi il limite di 1.000 righe). C'è anche un'insidia più sottile: l'approfondimento di Google sui dati di rendimento spiega che le query anonimizzate, quelle “che non vengono digitate da più di qualche decina di utenti in un periodo di due o tre mesi”, sono escluse dalle tabelle e sono solo “incluse nei totali del grafico, a meno che tu non filtri per query”. Un gruppo regex porta quindi sempre meno clic delle pagine che lo servono, e il divario è maggiore sui topic long tail.

Metodo 2: n-gram in un foglio di calcolo, o sovrapposizione delle SERP

Per una mappa a n-gram, esporta le tue query con clic, impressioni e posizione per un periodo da tre a dodici mesi (l'esportazione dell'interfaccia si ferma a 1.000 righe, quindi su un sito grande usa l'API di Search Console o l'esportazione collettiva dei dati). Metti tutte le query in minuscolo, dividile in parole, elimina le stop word come “how”, “the” e “for”, e riconduci i plurali semplici alla stessa forma, così “grinders” e “grinder” contano come una parola. Poi conta in quante query compare ogni singola parola (unigramma) e ogni coppia di parole vicine (bigramma). Le coppie che ricorrono in molte query, come “cold brew” o “burr grinder”, sono i tuoi topic candidati; assegna a ogni query il candidato più specifico che contiene e fai il pivot delle metriche per topic. Scarta le parole che compaiono in una quota ampia di tutte le query, come “coffee” su un sito di caffè, perché un topic che contiene metà del sito non è un topic.

Gli n-gram sono veloci, gratuiti e ripetibili, e si spiegano da soli: una query sta in “cold brew” perché contiene quelle parole. Quello che non riescono a fare è cogliere il significato. “French press” e “cafetiere” finiscono in topic diversi, e un errore di battitura come “coldbrew” non trova il suo gruppo. La sovrapposizione delle SERP risolve il problema dall'altra parte: recuperi i primi 10 risultati di Google per ogni query e metti due query nello stesso cluster quando condividono abbastanza URL posizionati, per esempio tre o più. Questo misura ciò che Google considera lo stesso intento, il che ne fa il metodo migliore per decidere se un topic richiede una pagina o due, ma costa una richiesta SERP per query, i risultati cambiano con posizione, dispositivo e data, e scala male oltre qualche migliaio di query. GSC Wizard non fa il clustering per sovrapposizione delle SERP, perché lavora solo sui tuoi dati di Search Console e non fa scraping dei risultati di Google.

Metodo 3: clustering semantico basato su embedding

Un modello di embedding trasforma ogni query in un vettore di numeri, in modo che le query con significato simile finiscano vicine, a prescindere dalle parole usate. Una pipeline tipica calcola l'embedding di ogni query con un modello multilingue (così “cafetière” e “french press” possono finire insieme), riduce i vettori a poche dimensioni con UMAP e li raggruppa con HDBSCAN o k-means. Poi dai a ogni cluster il nome delle sue query più grandi e sommi le metriche come prima. È il metodo che trova topic che non sapevi di avere, e gestisce errori di battitura, ordine delle parole e altre lingue molto meglio delle regole.

I costi, però, sono reali. Ti serve Python o un'API di embedding a pagamento, e il risultato dipende dalle impostazioni: cambia la dimensione minima del cluster, o aggiungi tre mesi di nuove query, e i gruppi si spostano, il che rende inaffidabile il monitoraggio mese su mese. HDBSCAN lascia inoltre una quota di query come rumore che non appartiene a nessun cluster. E la vicinanza semantica non coincide con un unico intento: “cold brew maker” e “cold brew recipe” stanno vicine nello spazio vettoriale, ma una vuole una pagina prodotto e l'altra una ricetta. Il flusso di lavoro che consiglio è scoprire i topic una volta con embedding o n-gram, poi scrivere i topic che ti interessano come regole e monitorare le regole.

Un esempio pratico: le stesse query, tre metodi

Le query qui sotto sono inventate per una caffetteria immaginaria, per mostrare come i metodi non concordano; sono illustrative, non dati di un sito reale. Le regole regex sono cold.?brew per Cold brew, french press|press pot|cafeti[eè]re per French press e grinder per Grinders. La colonna degli embedding mostra il tipo di raggruppamento che un modello di embedding tende a produrre, non l'output di un'esecuzione reale.

Lo schema è tipico. Le regole sono esatte ma cieche a tutto ciò che non hai scritto (“iced coffee concentrate”), gli n-gram dividono i topic in base all'ortografia, e gli embedding raggruppano per significato ma sfumano il confine tra intenti vicini (“coarse grind for press pot”). Nessuno dei tre sbaglia; rispondono a domande diverse.

Cosa fare con i tuoi cluster per trovare opportunità

Quando ogni query ha un topic, somma clic e impressioni per cluster e calcola posizione media e CTR ponderati per impressioni (una media semplice delle posizioni fa pesare una query con 3 impressioni quanto una con 30.000). Confronta lo stesso periodo dell'anno scorso o il periodo precedente, così ogni cluster ha una direzione. Poi cerca quattro schemi.

1. Cluster con molte impressioni e CTR o posizione deboli. Ordina per impressioni e cerca i cluster con posizione media da 8 a 25 o con un CTR ben sotto il resto del sito. Google ti collega già a quel topic, semplicemente non lo stai vincendo. Apri il cluster, trova le due o tre query che portano la maggior parte delle sue impressioni e migliora la pagina che si posiziona per loro, partendo dal title e dalla prima schermata di contenuto; i playbook sulla striking distance e sul recupero del CTR spiegano le modifiche.
2. Cannibalizzazione dentro un cluster. Per ogni cluster, conta quanti dei tuoi URL ottengono impressioni per le sue query. Se tre pagine si posizionano ciascuna intorno alla posizione 15 per lo stesso cluster, Google non riesce a decidere quale mostrare e nessuna arriva in prima pagina. Scegli la pagina più forte, unisci o reindirizza le altre e punta i link interni sulla vincente, come nel playbook sulla cannibalizzazione.
3. Lacune nei contenuti. Un cluster che ottiene impressioni attraverso una pagina che non parla di quel tema (la home page che si posiziona al 30° posto per una domanda del tipo come fare, o una pagina di categoria che si posiziona per un confronto) chiede una pagina dedicata. Lo stesso vale per le query che nessun cluster ha catturato: leggi quell'elenco residuo una volta a trimestre, perché un nuovo topic di solito compare prima lì.
4. Cluster che si muovono nel tempo. Monitora ogni cluster ogni mese. Un cluster le cui impressioni salgono mentre i clic restano piatti sta guadagnando una visibilità che non converte ancora, e un cluster che scende per tre mesi di fila è in decay, di cui si occupa il playbook sul content decay. I cluster rendono leggibile anche una migrazione del sito: è più facile sistemare un topic perso che quattrocento query perse (vedi le migrazioni di sito in Search Console).

Ecco come appare quel triage sulla caffetteria immaginaria, di nuovo con numeri inventati:

Come GSC Wizard raggruppa le query di Search Console

Ho costruito il clustering di GSC Wizard attorno alle regole, perché le regole sono ciò che si può monitorare e spiegare, e voglio essere preciso su cosa fa e cosa non fa ogni parte.

Topic Clusters (basati su regole, definiti da te). In Property Setup crei un cluster come un nome più un elenco di massimo 100 keyword, digitate o importate da un file CSV. Una keyword semplice corrisponde a qualsiasi query che la contiene, senza distinguere maiuscole e minuscole, e una keyword racchiusa tra slash, come /cold.?brew/, è un'espressione regolare. Una query entra in un cluster quando una qualsiasi delle sue keyword corrisponde, e una query può appartenere a più di un cluster, nel qual caso conta per intero in ciascuno, quindi i totali dei cluster non sono pensati per sommarsi al totale del sito. Quando clicchi su Run Analysis, il report Topic Clusters confronta le regole con ogni query della proprietà per il periodo scelto, dai dati conservati nel warehouse quando la proprietà è in archiviazione completa e dall'API di Search Console altrimenti, quindi non è limitato alle 1.000 righe che mostra l'interfaccia di Search Console. Ogni cluster ottiene clic, impressioni, CTR, una posizione media ponderata per impressioni e un conteggio delle query, con la variazione rispetto al periodo precedente, e si espande nelle query corrispondenti con la keyword che ha catturato ciascuna.

Il report ha un interruttore brand e non-brand (basato sui termini di brand che salvi sulla proprietà) e tre filtri rapidi che corrispondono agli schemi di cui sopra: Opportunity mostra i cluster con almeno la mediana delle impressioni dei tuoi cluster, una posizione media tra 11 e 25 e un CTR dell'1% o meno; Rising mostra i cluster le cui impressioni sono cresciute di almeno il 20% mentre i clic sono cresciuti del 5% o meno; Declining mostra i cluster le cui impressioni sono calate del 10% o più. Una sezione separata, Cluster Performance Over Time, mostra l'andamento di ogni cluster su 3, 6 o 12 mesi con una tabella mensile. Gli stessi cluster funzionano anche come filtro nei report Queries, New & Lost Rankings, Rank Changes, Cannibalization, Query Decay e Page Poaching, ed è così che controlli cannibalizzazione o decay dentro un singolo topic. La documentazione di Topic Clusters ha i dettagli, e i Gruppi di contenuti fanno la stessa cosa per le pagine, in base a una regola sugli URL.

Cosa Topic Clusters non fa. Non inventa cluster per te: in questo report non c'è raggruppamento automatico né semantico e, a differenza dei Gruppi di contenuti, non ha un assistente che suggerisce. Se vuoi aiuto a scrivere le regole, il server MCP di GSC Wizard permette a un assistente AI come Claude o ChatGPT di leggere le tue query principali, proporre cluster, salvarli con create_topic_cluster o update_topic_cluster e misurarli con get_topic_cluster_performance, che riporta anche le query che nessun cluster ha trovato. Il raggruppamento è allora un giudizio dell'assistente, quindi leggi le regole prima di salvarle.

Topic lessicali automatici in Confronto migrazioni. L'unico punto in cui GSC Wizard raggruppa le query in automatico è la scheda Queries di Confronto migrazioni, che raggruppa in topic le query di un confronto prima e dopo, così una migrazione andata male per una linea di prodotti si legge come una sola riga. È il metodo n-gram descritto sopra, reso deterministico: prende fino a 5.000 query (prima quelle con più clic), elimina le stop word in sette lingue e riconduce i plurali semplici alla stessa forma, usa come candidati le singole parole e le coppie di parole che ricorrono in almeno tre query ma non in più del 40% di esse, assegna a ogni query il suo miglior candidato e tiene i 25 topic più grandi, con il resto sotto “Other queries”. Le stesse righe danno sempre gli stessi topic, e non usa embedding.

Clustering degli URL, non delle query. La Longtail Visualization raggruppa le pagine anziché le query: ordina i tuoi URL per clic, leviga la curva cumulativa dei clic con un filtro gaussiano e colloca due punti di flesso dove la curva si piega di più, il che divide il sito in Head, Chunky Middle e Long Tail. Servono almeno 30 URL (sotto mostra l'elenco ordinato), gira in un Web Worker nel tuo browser così un sito grande non blocca la pagina, ed è disponibile anche agli assistenti AI come get_longtail_clusters. Risponde a una domanda diversa dal clustering per topic, cioè quanto dipendi da poche pagine, e la documentazione sulla long tail spiega i livelli.

Clustering semantico. GSC Wizard non raggruppa le query con gli embedding, quindi se vuoi cluster semantici applica tu il Metodo 3 a un'esportazione delle query e riporta in GSC Wizard come regole i topic che vuoi monitorare, dove restano stabili di mese in mese. Ogni piano include Topic Clusters, Confronto migrazioni, la Longtail Visualization e il server MCP, a partire da 17 € al mese con una prova gratuita di 7 giorni (vedi i prezzi).

Domande frequenti

Come raggruppo le mie query di GSC in topic per trovare opportunità?

Assegna ogni query di Search Console a un topic, con regole regex o per frase, n-gram di parole condivise o embedding semantici, poi somma clic e impressioni e calcola posizione media e CTR ponderati per impressioni per ogni topic. Le opportunità sono i topic con molte impressioni ma una posizione media in seconda pagina o un CTR basso, i topic in cui più URL si dividono le stesse query, e i topic che ottengono impressioni senza una pagina scritta per loro.

Google Search Console può raggruppare le query in topic da solo?

In parte. Search Console Insights ha una scheda Query groups che raggruppa le query simili con l'AI e mostra i clic per gruppo, ma solo per le proprietà con un grande volume di query, e Google dice che i gruppi possono cambiare nel tempo. Nel report Rendimento puoi filtrare le query con una regex personalizzata, che mostra un gruppo alla volta, quindi confrontare i tuoi topic fianco a fianco richiede comunque di copiare i totali a mano.

Quale sintassi regex usa il filtro delle query di Search Console?

RE2. La pagina di aiuto di Google dice che la corrispondenza è parziale per impostazione predefinita, quindi un pattern corrisponde in qualsiasi punto della query a meno che tu non lo ancori con ^ o $, e non distingue maiuscole e minuscole a meno che tu non inizi il pattern con (?-i). RE2 non supporta lookahead né backreference.

Perché i totali dei miei cluster non corrispondono al totale del sito?

Per due motivi. Google esclude le query anonimizzate (le query rare) da ogni tabella delle query e dai totali filtrati per query, quindi le query raggruppate portano sempre meno del totale del sito. E se una query corrisponde a due cluster, uno strumento che ammette la sovrapposizione, come Topic Clusters di GSC Wizard, la conta in entrambi.

Il clustering basato su embedding è meglio delle regole per keyword?

Trova sinonimi e traduzioni che le regole non vedono, quindi è meglio per scoprire topic in un insieme di query ampio e disordinato. Le regole sono meglio per il monitoraggio: danno lo stesso raggruppamento ogni mese e puoi spiegarle a un cliente. Un buon flusso di lavoro è scoprire i topic con embedding o n-gram e poi scriverli come regole.

GSC Wizard raggruppa automaticamente le query di Search Console?

Non nel report Topic cluster: definisci ogni cluster come un elenco di frasi o pattern regex e GSC Wizard lo misura sull'intera proprietà. Confronto migrazioni raggruppa automaticamente le query di una migrazione in topic lessicali, e la Longtail Visualization raggruppa gli URL, non le query, in head, parte centrale e long tail. GSC Wizard non raggruppa le query con gli embedding; per cluster semantici, esegui un modello di embedding su un'esportazione delle query e riporta i topic come regole.

Un assistente AI può costruire i cluster al posto mio?

Sì, tramite il server MCP di GSC Wizard. Un assistente come Claude o ChatGPT può leggere le tue query principali, proporre dei cluster, salvarli con create_topic_cluster e misurarli con get_topic_cluster_performance. Controlla le regole proposte prima di salvarle, perché il raggruppamento è un giudizio dell'assistente.

Prossimo playbook

Hai trovato un cluster in cui più pagine competono tra loro? Risolvilo prima di riscrivere qualsiasi cosa: risolvi la cannibalizzazione delle keyword →