KEYWORD CLUSTERING · FIELD NOTES
Keyword Clustering: Perché la sovrapposizione SERP batte la somiglianza delle stringhe
La maggior parte delle guide di clustering raggruppano le keyword per quello che le parole sembrano. L'unità onesta è la sovrapposizione SERP — se due query restituiscono risultati sostanzialmente identici, Google ha già stabilito che condividono un intento e appartengono a una pagina.
Cercate “keyword clustering” e la prima pagina è una fila di vendor di strumenti che insegnano la stessa procedura: esportate la vostra lista di keyword, raggruppate quelle che si assomigliano, assegnate a ogni gruppo una pagina. La procedura non è sbagliata tanto quanto elide l’unica domanda su cui una vera content plan si regge: quale di queste query può una singola pagina vincere allo stesso tempo? Raggruppare per quello che le parole sembrano — radici condivise, modificatori condivisi, somiglianza degli embedding — risponde a una domanda diversa, e la risponde male. Due query appartengono alla stessa pagina quando Google restituisce risultati sostanzialmente identici per entrambe. Non quando rimano.
Questa è la tesi di questa guida: l’unità del clustering è la sovrapposizione SERP, non la somiglianza delle stringhe — e una volta che il clustering è fatto così, il cluster (mai la keyword) diventa l’unità dell’intera content plan. Questo rientra nel nostro pilastro agentic SEO come livello di pianificazione: decide quali pagine esistono prima che il loop find → fix → verify le tocchi mai.
Che cosa il keyword clustering veramente è — e a che cosa serve
Il keyword clustering è il passo tra una lista di keyword e una content plan. Una lista grezza di mille query candidate è inutilizzabile: non potete costruire mille pagine, e non dovreste — la maggior parte di quelle query è la stessa domanda formulata diversamente. Il clustering comprime la lista in gruppi che condividono l’intento, così ogni gruppo corrisponde a esattamente una pagina. Fatto bene, risponde a tre domande allo stesso tempo: quante pagine la plan ha bisogno, che cosa ogni pagina deve coprire, e quale query in ogni gruppo è il termine testa per cui la pagina è valutata.
La modalità di fallimento è decidere “condivide l’intento” per procura. Le procure offerte sono lessicali (le stringhe condividono parole?) e semantiche (i loro embedding si sedono vicino insieme?). Entrambi misurano il linguaggio. Nessuno misura la cosa su cui state effettivamente scommettendo una pagina — come Google risolve la query. L’unico record pubblico e per-query di quella risoluzione è la SERP stessa, per cui il metodo di sovrapposizione funziona: legge la risposta di Google invece di indovinarla.
I due metodi di clustering — solo uno misura l’intento
Ogni approccio di clustering in circolazione si riduce a una delle due famiglie. Suonano intercambiabili nella lista delle funzioni di uno strumento. Producono piani materialmente diversi.
Clustering lessicale e semantico: raggruppare per quello che le parole sembrano
Il clustering lessicale raggruppa le query che condividono token — “crm software,” “crm software pricing,” “best crm software” si ritrovano insieme perché le stringhe si sovrappongono. Il clustering semantico aggiorna il confronto agli embedding: le query i cui vettori si sedono vicino nel meaning-space si raggruppano anche senza parole condivise. Entrambi sono economici, veloci, e funzionano completamente offline — per cui esattamente il pricing-per-volume della maggior parte degli strumenti li favorisce. Ed entrambi ereditano lo stesso punto cieco: modellano la domanda e ignorano la risposta. La somiglianza del linguaggio è un’ipotesi sull’intento. A volte l’ipotesi è giusta. Il problema è che non potete dire quali volte, perché il metodo non contiene nessun controllo contro la realtà.
SERP-overlap clustering: raggruppare per quello che Google ha già deciso
Il SERP-overlap clustering pone una domanda più smussata: quando gli utenti reali digitano queste due query, Google restituisce risultati sostanzialmente uguali nel top? Se i top dieci per la query A e la query B condividono diversi URL, Google — con tutta la sua macchineria di query-understanding e anni di dati sui clic — ha già concluso che i due esprimono un intento, soddisfacibile da una pagina. Non state inferendo l’intento dal linguaggio; state leggendo il verdetto del sistema che giudicherà la vostra pagina comunque. Quel verdetto è la ground truth che ogni altro metodo sta cercando di approssimare.
| Clustering lessicale / semantico | SERP-overlap clustering | |
|---|---|---|
| Cosa confronta | Le stringhe di query o i loro embedding | I risultati top che Google restituisce per ogni query |
| Cosa misura | Somiglianza del linguaggio — una procura per l'intento | Comportamento di ranking — il verdetto dell'intento stesso |
| Costo | Quasi zero, funziona offline | Un live SERP pull per query |
| Fallisce quando | Parole simili nascondono intenti diversi (o viceversa) | Le SERP sono volatili o thin per la query |
| Verdetto | Va bene per un primo rough cut | L'unità su cui una content plan dovrebbe essere costruita |
Perché la somiglianza delle stringhe sbaglia l’intento
Il fallimento funziona in entrambe le direzioni, e ogni direzione costa diversamente. Direzione uno: stringhe simili, intenti diversi. “Coffee grinder” e “grind coffee” condividono quasi ogni token; una SERP è elenchi di prodotti, l’altra è contenuto how-to. Un clustering lessicale li fonde, costruite una pagina cercando di servire entrambi, e la pagina non si classifica per nessuno — Google legge l’intento misto come non rispondendo bene a nessuno. Direzione due: stringhe diverse, un intento. “Best CRM for small business” e “small business CRM reviews” appena correlano come stringhe, ma le loro SERP sono vicino a identiche. Un metodo basato su stringhe le divide in due pagine, e ora avete scritto due thin page competendo l’una l’altra per uno slot — keyword cannibalization, fabbricata dalla vostra propria metodologia.
Il secondo fallimento è quello costoso, perché composto. Su un sito che abbiamo controllato, la proprietà si è classificata profondamente — pagine quattro a otto — per dozzine di varianti long-tail della stessa domanda commerciale, senza una singola pagina costruita per rispondere. String-clustered, quelle varianti sembravano una dozzina di argomenti separati che meritavano una dozzina di brief separati. Le loro SERP raccontavano la storia opposta: sovrapposizione pesante, un intento, una pagina forte richiesta. Il metodo string avrebbe moltiplicato il problema esistente del sito per dodici. Il metodo di sovrapposizione l’ha collassato in un fix.
Fondere quello che dovrebbe essere diviso e la pagina non si classifica per niente. Dividere quello che dovrebbe essere fuso e le vostre pagine si canibalizzeranno l’un l’altra. La somiglianza delle stringhe commette entrambi gli errori — e non può dirvi quando.
Il metodo SERP-overlap, passo per passo
Il metodo è semplice abbastanza da eseguire manualmente su una piccola lista e meccanico abbastanza da delegare su una grande. Cinque passi.
- Assemblate la lista dei candidati. Seed keyword, loro espansioni, e — il passo che la maggior parte delle guide salta — le query che la vostra Search Console già mostra impressioni per. La vostra GSC è l’unica fonte di keyword che riflette la domanda per cui siete già idonei; raggruppate quella prima.
- Tirate i live top 10 per ogni query. Non i ranking messi in cache da un database — la SERP attuale, perché la sovrapposizione è significativa solo tra i risultati catturati nella stessa finestra.
- Valutate ogni coppia per URL condivisi. Contate quanti dei dieci risultati top due query hanno in comune. La convenzione di lavoro: 3 o più URL condivisi su 10 significano che le query condividono l’intento e appartengono a una pagina. Innalzate la soglia a 4–5 quando le puntate di un merge sbagliato sono alte (pagine money commerciali); tenete 3 per long-tail informativo.
- Raggruppate intorno agli hub. Prendete la query non-clustered dal volume più alto come hub, attaccate ogni query che cancella la soglia di sovrapposizione contro di essa, rimuovete il cluster dalla pool, ripetete. Ogni cluster finito è una pagina: l’hub è la keyword primaria, i membri sono i subtopici, i heading, e le voci FAQ che la pagina deve coprire.
- Riconciliate contro le pagine che già esistono. Mappate ogni cluster a un URL — una pagina esistente da rinforzare, un insieme di pagine canibalizanti da consolidare, o un gap da costruire. Questo è dove la plan smette di essere un spreadsheet e diventa una task list.

Una nota su quello che la soglia vi compra. Converte un giudizio editoriale fuzzy — “questi sembrano lo stesso argomento?” — in un test riproducibile con un numero attaccato. Due persone eseguendo il metodo sulla stessa lista ottengono gli stessi cluster. Quella riproducibilità è quello che permette al clustering di essere delegato a un agente comunque: lo strumento che legge le SERP è lo stesso coperto nella nostra guida a SERP analytics, puntato a coppie di query invece di una.
Il cluster — non la keyword — è l’unità della content plan
Ecco il reframe che rende il metodo vale i SERP call. Una volta che i cluster esistono, ogni decisione di pianificazione che era solita essere fatta per keyword viene fatta per cluster, e ognuna di loro migliora. Domanda: un hub a 480 ricerche al mese sembra marginale da solo, ma un cluster aggrega il volume di ogni membro — la long tail non è competizione per il termine head, è il rialzo della stessa pagina. Difficoltà: valutate la vincibilità una volta, contro una SERP, invece di ondeggiare attraverso quaranta. Canibalization: non può verificarsi per costruzione, perché un intento mappa a uno URL. Misurazione: la pagina è giudicata sui clic dell’intero cluster, che è l’unità onesta — una pagina che si classifica per il suo hub e trenta varianti sta avendo successo anche se una singola variante sembra piccola.
Il piano basato su keyword
Quaranta keyword, quaranta brief, quaranta thin page. Diverse servono lo stesso intento e si canibalizzeranno l'una l'altra; diverse infilano intenti opposti in uno URL. Il volume è letto per keyword, così le opportunità reali sembrano troppo piccole da costruire e vengono tagliate dalla plan.
Il piano basato su cluster
Quaranta keyword collassano forse in nove cluster — nove pagine, ognuno possedendo un intento con una keyword hub e un set di subtopic definito. Il volume è letto per cluster, così la plan vede la vera dimensione di ogni opportunità. La canibalization è strutturalmente impossibile.
L’era zero-click afila il caso piuttosto che indebolirlo. Quando un AI Overview o un motore di risposta compone una risposta, seleziona un piccolo numero di fonti per intento — e un sito che ha sparso un intento attraverso cinque thin page ha cinque candidati deboli dove aveva bisogno di uno forte. Consolidare un cluster in una singola pagina autoritativa è tanto un gioco di citabilità quanto un gioco di ranking; la meccanica di quello spostamento è coperta nella nostra guida a zero-click SEO.
Dove il clustering si sedette in un loop chiuso
Una mappa cluster non è un deliverable; è un input. Il pattern di fallimento con il clustering — come con ogni artefatto di pianificazione in SEO — è che viene prodotto una volta, ammirato, e abbandonato: uno spreadsheet bellissimo che nessuno riconcilia contro la realtà di nuovo. In un loop chiuso, ogni cluster diventa un task con una affermazione testabile attaccata al momento della creazione: la pagina a cui questo cluster mappa, il fix o la costruzione di cui ha bisogno, l’impatto atteso, e la metrica che lo giudicherà — clic o posizione sulla query hub, impegnato prima che il lavoro spedisca. Più o meno tre settimane dopo che la pagina atterra, la metrica viene ri-letta e il task è confermato o riapertoQuesto contratto — find, fix, verify — è il meccanismo descritto nella nostra guida a closed-loop SEO; il clustering è semplicemente il suo stadio di pianificazione fatto alla risoluzione giusta.
L’argomento della verifica inoltre risolve quale metodo di clustering usare. Un cluster basato su stringhe produce un piano inestabile — se la pagina underperforms, non potete dire se l’esecuzione ha fallito o il raggruppamento era sbagliato dall’inizio. Un cluster basato su SERP porta la sua propria evidenza: la sovrapposizione che ha giustificato il merge è on record, così una pagina che fallisce di muoversi viene diagnosticata contro un’ipotesi documentata invece di un presentimento. I piani costruiti su sovrapposizione misurata possono essere controllati. I piani costruiti su stringhe che assomigliano possono solo essere difesi.
Limiti onesti: dove il SERP clustering si rompe
Il metodo ha costi reali e bordi reali, e fare finta di altro è come gli strumenti lo vendono in eccesso. Costa un live SERP pull per query — banale per duecento keyword, una decisione di budget per ventimila; il pattern sano è un rough cut economico basato su stringhe prima, con la sovrapposizione SERP che confirma o divide i merge che contano. Le SERP sono anche volatili: una sovrapposizione misurata oggi è uno snapshot, non un deed, così i cluster su query a cui tenete meritano il re-checking trimestrale — e ogni volta che una pagina che stava vincendo inizia a scivolare, perché un cluster che si divide nella natura selvaggia è una causa comune, silenziosa. E le thin SERP mentono: su query a basso volume Google a volte restituisce risultati quasi identici per intenti genuinamente diversi semplicemente perché poco contenuto esiste, così trattate la sovrapposizione su sparse SERP come un segnale più debole e lasciate innalzare la soglia. Nessuno di questi limiti argomenta per il ritiro alla somiglianza delle stringhe. Argomentano per trattare il clustering il modo in cui questa intera disciplina dovrebbe essere trattata — come una misurazione che decade, su un calendario di re-misurazione, non un artefatto una tantum.
Il modo più veloce per vedere i vostri propri cluster è partire dalle query che già avete. Un report SEO gratuito connette la vostra Search Console e superficie il pattern di cui questa guida continua a puntare: le varianti long-tail per cui vi classificate già che nessuna singola pagina possiede — i cluster nascosti nei vostri propri dati, aspettando di essere consolidati. Se preferiste avere l’intero loop eseguito per voi — clustering, consolidazione, e la verifica di tre settimane che prova che ha funzionato — prenotate una call.
Frequently asked questions

Scritto da
Luke McCormackFondatore, My Agentic SEO
Specialista SEO e Google, responsabile del go-to-market e della crescita di My Agentic SEO.
Più su LukeParte del cluster
SEO agentico: che cos'è e come un agente gestisce il vostro SEOLasci che l’agente esegua il primo passo sui Suoi dati reali
Colleghi la Sua Google Search Console e riceva un report SEO professionale gratuito — diagnosticato e prioritizzato sul Suo sito reale. Richiede pochi minuti.