Topic cluster nella struttura del sito: come ho tradotto il metodo in URL, schema.org e dati

Come funziona un topic cluster

La costruzione classica di un topic cluster segue pochi passi. Si scelgono gli argomenti principali e si verifica che abbiano una domanda di ricerca. Si scrive una pillar page che li tratta per intero, poi i contenuti di cluster, ognuno su un sottotema, tutti collegati alla pillar e la pillar a tutti loro. Il formato di ogni contenuto (una guida, un tutorial, un confronto, una case history) si decide solo alla fine, pezzo per pezzo, guardando l’intento di chi cerca.

È un metodo che funziona, e lo uso anch’io. Ma ha una caratteristica che si nota poco: vive soprattutto nella testa di chi lo progetta. Nel piano editoriale, in una matrice, in un foglio condiviso. Il sito ne vede solo una parte: i link tra la pillar e i contenuti.

Dove si perde la mappa

Su un blog la mappa si perde poco, perché tutto è un post e la categoria fa il lavoro del cluster. Le cose cambiano quando i formati diventano tipi di contenuto veri, ognuno con i suoi campi, il suo template e il suo archivio.

A quel punto l’albero del sito si organizza a silos per tipologia: un ramo per il blog, uno per i tutorial, uno per le case history. Un tutorial e un articolo sullo stesso argomento finiscono in due rami diversi.

E non è solo l’albero. Lo schema.org descrive ogni pagina da sola, senza dire a quale argomento appartiene. I report elencano URL, non argomenti. Ogni disciplina vede un pezzo della mappa, e chi vuole la mappa intera deve ricostruirla a mano. Ogni volta.

Prima traduzione: l’alberatura e gli URL

La prima cosa che ho fatto è stata portare la logica del cluster nell’albero del sito. Al primo livello c’è la pillar page del Topic. Sotto, i contenuti, divisi e organizzati come nel cluster, anche negli URL. Il formato diventa una vista dentro l’argomento. Un esempio semplificato:

/seo-tecnica/                                   pillar del Topic
/seo-tecnica/blog/topical-authority-struttura/
/seo-tecnica/tutorial/schema-about-audience/
/seo-tecnica/tutorial/                          i tutorial di quel Topic

Al posto di:

/blog/topical-authority-struttura/
/tutorial/schema-about-audience/

Il breadcrumb segue la stessa strada: dopo la home passa dal Topic e linka la pillar. Un albero a silos dice «pubblico in questi formati». Un albero per Topic dice «so queste cose». E il collegamento tra ogni contenuto e la sua pillar non dipende più da qualcuno che si ricordi di metterlo: è nella struttura, e i link interni seguono la mappa.

Seconda traduzione: lo schema.org

Il motivo per cui non ho ridotto tutto a post con una categoria è proprio lo schema.org. Un tutorial non è un articolo: è una procedura con dei passi, e il nodo che lo descrive meglio è HowTo. Un evento è un Event, un annuncio di lavoro un JobPosting. Ogni tipo ha il nodo più coerente con ciò che è.

Ma formati diversi non devono voler dire cluster diversi. Nel mio grafo il Topic diventa un’entità a sé, un DefinedTerm che ha come indirizzo la sua pillar. Ogni contenuto del cluster lo dichiara in about, dove schema.org lo ammette. Se parla anche di un secondo argomento, dichiara anche quello. Lo stesso vale per il pubblico, in audience.

Quello che nel piano editoriale è «questo tutorial appartiene al cluster SEO tecnica», nel codice della pagina diventa un collegamento esplicito. Ho raccontato come in di cosa parla, per chi.

Terza traduzione: i dati

Misurare un argomento, di solito, vuol dire ricostruirlo dopo. Si parte da un elenco di URL, si raggruppano le pagine con un’espressione regolare o con una lista tenuta a mano, e si spera che nel frattempo nessuno abbia pubblicato qualcosa di nuovo. Il report arriva, ma con una forma diversa da quella con cui il sito è stato progettato.

Se la mappa è già nella struttura, la misura la può leggere da lì. In due modi, che si sommano:

• dall’URL: se l’albero segue i Topic, il percorso è già un raggruppamento. Un filtro sul prefisso della pillar restituisce l’argomento intero, anche negli strumenti che non conoscono le tue dimensioni, come Search Console;
• dal dataLayer: ogni pagina dichiara il suo Topic, il suo cluster, il pubblico per cui è scritta e la fase del percorso, e GA4 li registra come dimensioni personalizzate. Non serve più indovinare a quale argomento appartiene una pagina: lo dice lei.

Il risultato è un report che ha la stessa forma della progettazione. Parte dal Topic, scende nei cluster, arriva al singolo contenuto, come la mappa scende dalla pillar ai pezzi del cluster. E si incrocia con le altre coordinate del piano:

• quale cluster regge un argomento, e quale no;
• quale formato funziona meglio dentro lo stesso Topic, un articolo o un tutorial;
• quale pubblico arriva, e in quale fase del percorso.

Sono le domande che chi fa strategia si pone quando disegna la mappa. Il report risponde con le stesse parole. Il come, passo per passo, è in un dataLayer che parla la lingua del modello.

Cosa cambia per chi fa strategia

Se fai strategia, sei in cima alla catena dei contenuti. La mappa la disegni insieme al team: in un’agenzia si lavora a stretto contatto, e non c’è chi comanda e chi esegue. Eppure, finita la riunione, ogni disciplina la reinterpreta con i suoi strumenti: lo sviluppo nell’albero, la SEO nello schema, l’analisi nei report. Non per cattiva volontà: ognuno la traduce nella sua lingua, e ne tiene una copia un po’ diversa.

Qui la mappa si dichiara una volta, classificando ogni contenuto: di cosa parla per primo, a quale cluster appartiene, per chi è scritto. Da quella classificazione si derivano tutte e tre le traduzioni. Vuol dire che:

• la mappa condivisa arriva intatta fino al codice, invece di essere tradotta da ognuno a modo suo;
• le decisioni prese insieme pesano: scegliere il Primary Topic di un contenuto decide il suo indirizzo, il suo posto nel grafo e la riga del report in cui finisce;
• la mappa si può verificare: se un cluster ha pochi contenuti, o un pubblico non ne ha nessuno, lo vedi nella struttura, non solo nel foglio di calcolo.

Non è una cosa che vedo spesso. Di solito la mappa resta in un documento condiviso e la struttura prende un’altra strada. Il punto di questo approccio è che la struttura del sito è la mappa.

La struttura non crea l’autorità: la rende leggibile

Qui voglio essere preciso, perché è facile dire troppo. Mettere il Topic nell’URL non ti fa salire su Google: le parole nell’URL sono un segnale minimo, e da inizio 2025 sui risultati da mobile Google mostra solo il dominio. E Google non dice da nessuna parte di usare about per capire di cosa sei esperto.

Quello che Google dice, nella sua SEO Starter Guide, è più semplice: un sito organizzato in modo logico aiuta a capire come le pagine si collegano, e il testo dei link dice qualcosa della pagina linkata. Sono punti di struttura, non di contenuto.

C’è però un punto in cui la struttura lavora davvero: i link interni. Google dice che usa i link tra le pagine per capire di cosa parlano e quali possono essere più utili, e che PageRank è ancora uno dei suoi sistemi principali. In un albero per Topic i link non dipendono dalla memoria di chi scrive. Ogni contenuto punta alla sua pillar con il breadcrumb, e gli archivi del Topic e i correlati trovano i contenuti del cluster dalla classificazione. I link si concentrano dove sta l’argomento, invece di disperdersi negli archivi per formato. Nel mestiere lo chiamiamo link juice. Io preferisco dire che la struttura fa scorrere i link nella stessa direzione della mappa.

L’autorità su un tema la fanno altre cose: quanto lo copri, quanto bene, quanto ti citano. La struttura la rende leggibile: a Google, a un motore AI che legge dentro un contesto dichiarato invece di doverlo dedurre, e a chi misura. Il punto non è nessuno di questi segnali preso da solo. È che derivano dalla stessa classificazione, e quindi non si contraddicono mai. Sono tanti puntini che sembrano scollegati. Messi in fila, disegnano la tua mappa.