Link interni e topical authority: perché i correlati vanno derivati dalla struttura, non dalla categoria
Stessa categoria, stesso post type: per anni è stato il mio modo di generare i correlati, e credo sia ancora il default di molti siti WordPress. Funziona, ma chiude i link interni dentro il silos del formato. Qui racconto cosa succede quando i link li deriva la classificazione dei contenuti, con un crawl del mio sito a fare da verifica.
Perché i link interni contano per la topical authority?
Perché sono il modo più diretto in cui un sito dice a Google quali pagine stanno insieme. Google lo scrive in due posti. Nella guida ai suoi sistemi di ranking spiega che usa i collegamenti tra le pagine per capire di cosa parlano e quali possono essere più utili, e che PageRank, il sistema con cui è nato, fa ancora parte dei sistemi principali. Nella guida ai link aggiunge che i link sono un segnale di rilevanza e che ogni pagina importante dovrebbe riceverne almeno uno da un’altra pagina del sito.
Il testo del link conta quanto il link: dice a chi legge, e a Google, cosa troverà dall’altra parte. Per questo, quando si parla di topical authority, i link interni non sono un dettaglio di navigazione. Sono la mappa del sito che Google legge davvero, link per link.
La domanda allora non è se linkare, ma chi decide dove vanno i link. Nella maggior parte dei siti lo decide un’abitudine.
Il correlato di default chiude i link nel silos
Per anni il mio sistema per i correlati è stato questo: stessa categoria, stesso post type. Nei casi particolari, quando c’era una tassonomia più importante della categoria, adattavo il template per prendere i correlati di quel termine. Ma il meccanismo restava lo stesso.
È un sistema ragionevole, e non lo considero un errore. Ha però un effetto collaterale che si vede solo guardando il grafo dei link: i link non attraversano mai i formati. Un articolo linka altri articoli, un tutorial altri tutorial. Se un articolo e un tutorial parlano dello stesso argomento, non si incontrano. E la navigazione principale di solito rafforza la stessa logica: in menu ci sono /blog/ e /tutorial/, gli archivi del formato.
Il risultato è un sito in cui la link equity scorre lungo i formati, non lungo gli argomenti. Esattamente il contrario di quello che serve a un topic cluster, dove la pillar e i contenuti di un tema dovrebbero rimandarsi a vicenda, qualunque sia la loro forma.
Quattro direzioni, quattro coordinate
Sul mio sito i correlati non li sceglie la categoria: li deriva la classificazione. Ogni contenuto dichiara di cosa parla, il Topic, e per chi è scritto, il Target. Da lì nascono quattro direzioni di link, ognuna con la sua regola:
| Direzione | Da dove nasce | Dove porta l’equity |
|---|---|---|
| Verticale: breadcrumb e blocco “In questo articolo parlo di” | Primary Topic e cluster | Alla pillar del Topic, con il nome del Topic o del cluster come testo del link |
| Orizzontale: fascia “altri contenuti sul tema” | Topic, Relations comprese | Agli altri contenuti dello stesso tema, di ogni formato, e agli archivi del Topic |
| Trasversale: fascia “altri temi per…” | Target | Ai contenuti per lo stesso pubblico, anche su altri Topic |
| Temporale: sidebar | Data di pubblicazione (un mese prima e dopo) | Ai contenuti usciti nello stesso periodo, cioè, nelle intenzioni, alla stessa serie |
Due dettagli fanno la differenza. Il primo: nella fascia del tema compaiono anche gli archivi del Topic (/{pillar}/blog/, /{pillar}/tutorial/), ma solo quelli che hanno almeno un contenuto. La struttura non linka mai una pagina vuota. Il secondo: il testo dei link verticali non lo scrive nessuno. È il nome del Topic o del cluster, quindi è descrittivo per costruzione, come chiede Google.
Ho raccontato come il Topic diventa radice degli URL e delle pagine in la mappa che hai in testa, dentro il sito. Qui guardo solo i link.
Cosa dice il crawl
Una tesi così si verifica, non si racconta. Il 20 ottobre ho fatto un crawl di bebopcreative.it con la versione gratuita di Screaming Frog, che arriva fino a 500 URL: al mio sito ne bastano 27 di pagine HTML. Poi ho esportato tutti i link in entrata e li ho divisi per zona della pagina, usando il percorso di ogni link: menu, footer, breadcrumb, le due fasce dei correlati, sidebar, testo.
Tolta la navigazione, restano i Topic
La prima cosa che si vede è che la navigazione appiattisce tutto. Il footer linka le quattro pillar da 26 pagine su 27. Contare gli inlink unici, da soli, non distingue niente: le pillar sono tutte al massimo.
Togliendo menu e footer, il quadro cambia. Questi sono i breadcrumb che arrivano a ogni pillar:
| Pillar | Pagine il cui breadcrumb passa dalla pillar | Contenuti e archivi del Topic |
|---|---|---|
| Bebop Content Model | 8 | 2 articoli, 4 pagine del modello, 2 archivi |
| SEO Tecnica | 4 | 1 articolo, 1 tutorial, 2 archivi |
| Data Analisi | 3 | 1 tutorial, 2 archivi |
| Sviluppo Web | 0 | nessuno |
I link strutturali verso una pillar crescono con i contenuti che il suo Topic ha davvero. Nessuno li ha messi a mano: li ha messi la classificazione.
Una pillar senza cluster
La pillar di Sviluppo Web è il caso più istruttivo. Oggi nessun contenuto ha Sviluppo Web come argomento principale: compare solo come argomento secondario del primo articolo del blog. Risultato: la pillar riceve i link del footer e nient’altro.
È il comportamento giusto. Un Topic senza contenuti non ha un cluster, e la struttura non finge che ce l’abbia. Il buco nel piano editoriale diventa un buco nel grafo dei link, e si vede in un crawl.
Solo nel suo pubblico
Sui contenuti la fascia del tema fa la parte più grande. Ma è la fascia del Target a raccontare la cosa più interessante:
| Contenuto | Fascia del tema | Fascia del Target | Sidebar | Testo |
|---|---|---|---|---|
| Content model in WordPress (E01) | 11 | 2 | 4 | 2 |
| La mappa che hai in testa (N02) | 10 | 2 | 4 | 0 |
| about e audience (E08) | 9 | 2 | 4 | 3 |
| dataLayer per Topic e Target (E04) | 8 | 2 | 4 | 2 |
| Il problema non sono i team (E17) | 8 | 0 | 4 | 4 |
E17 è l’unico contenuto scritto per chi decide, non per chi implementa. Nella fascia del Target non ha “fratelli”, quindi non riceve nessun link da lì. Chi è solo nel suo pubblico è solo anche nel grafo.
E con cinquanta contenuti?
Il crawl fotografa un sito giovane, e per forza sbilanciato: quattro Topic, cinque contenuti. Alcune regole della struttura però sono deterministiche, e permettono di immaginare il sito quando avrà, diciamo, cinquanta contenuti distribuiti bene tra Topic e pubblici. È una proiezione costruita sulle regole, non un dato. Le ipotesi: dodici o tredici contenuti per Topic, almeno cinque o sei per ogni pubblico, una settantina di pagine in tutto.
| Oggi (crawl del 20 ottobre) | Con 50 contenuti (proiezione) | |
|---|---|---|
| Breadcrumb verso ogni pillar | 8 · 4 · 3 · 0 | circa 15 per ogni pillar: i suoi contenuti più i suoi archivi |
| Footer verso ogni pillar | 26 pagine | circa 70 pagine |
| Contenuti senza “fratelli” nella fascia del Target | 1 su 5 | nessuno |
| Fasce del tema e del Target | in parte vuote | fascia del tema piena (9 card); fascia del Target con i contenuti dello stesso pubblico su altri Topic |
Due cose cambiano. La prima: le pillar si pareggiano. Oggi la distanza tra 8 e 0 racconta i buchi del piano editoriale. In un sito bilanciato i breadcrumb arrivano a tutte in egual misura, e una pillar che resta indietro torna a segnalare un Topic trascurato.
La seconda: la navigazione continua a pesare. Il footer cresce con il sito quanto i breadcrumb, quindi verso le pillar il rapporto tra link strutturali e di navigazione cambia poco. Cambiano invece i link tra contenuti. Ogni fascia mostra al massimo nove card, e la fascia del Target esclude i contenuti già presenti in quella del tema. Vuol dire che la fascia del tema porta fino a nove link, tutti dentro l’argomento, e la fascia del Target porta solo contenuti per lo stesso pubblico su altri Topic. Con un pubblico che ha cinque o sei contenuti, circa due link su tre tra contenuti restano nel tema. Con entrambe le fasce piene, nove e nove, si scende a metà: è il minimo che le regole permettono.
Due cose sui numeri, per onestà. Il sito è piccolo, e 27 pagine non fanno statistica: è una fotografia del 20 ottobre, non una legge. E il crawl mostra come è fatto il grafo, non come Google lo pesa. Non ho dati di ranking da affiancare, e non li invento.
La fascia del Target disperde la link equity?
Un po’ sì, e lo faccio apposta. È la scelta che un SEO mi contesterebbe per prima: se voglio rafforzare un cluster, perché mandare link verso contenuti di altri Topic?
Perché quei link non vanno a caso. Vanno verso contenuti scritti per lo stesso lettore. Il mio sito ha due assi: di cosa parla e per chi è scritto. Un link trasversale per pubblico dichiara il secondo asse, così come il breadcrumb dichiara il primo. Google dice di usare i link anche per capire di cosa parlano le pagine: un grafo che ha due assi coerenti mi sembra più leggibile di uno che ne ha uno solo e per il resto tace.
E la dispersione ha un tetto scritto nelle regole: con nove card per fascia, e la seconda che esclude la prima, al massimo metà dei link tra contenuti esce dal tema. Mai di più.
Il resto è una mia posizione, non un dato. La differenza con il correlato di default è che anche la dispersione qui è dichiarata: so esattamente dove va e perché.
Cosa la struttura non fa
La struttura genera i link che derivano dalla classificazione. Non scrive quelli che derivano dal ragionamento. I link nel testo restano un lavoro editoriale, e il crawl lo dice senza giri di parole: al 20 ottobre l’articolo più recente della serie non riceveva nessun link dal corpo di un altro contenuto. Lo linkavano fasce e sidebar, nessuna frase.
Ed è stato proprio il crawl a mostrarmelo. Mi ha fatto trovare anche dei bug, e capire in modo semplice dove andare a sistemare.
Il link nel testo è quello che dice perché due contenuti stanno insieme. La classificazione dice che stanno insieme. Servono tutti e due.
Rifallo sul tuo sito
La verifica si rifà in mezz’ora. Fai un crawl con Screaming Frog, anche nella versione gratuita se il sito sta sotto i 500 URL, ed esporta tutti i link in entrata. Poi separa i link per posizione: la colonna che indica se un link sta nel contenuto, nella navigazione o nel footer è il punto di partenza, il percorso del link ti dice in quale blocco si trova. Togli menu e footer, e guarda cosa resta.
Se quello che resta disegna i tuoi argomenti, con le pillar più ricche che ricevono più link e le pagine sullo stesso tema che si linkano anche tra formati diversi, la struttura sta lavorando per te. Se disegna i formati, o non disegna niente, i link interni li sta decidendo un’abitudine.
Cosa costa
Il primo costo è editoriale. Una struttura così rende visibili i buchi: una pillar senza contenuti, un pubblico con un contenuto solo. È scomodo, ma è utile, perché i buchi diventano un piano di lavoro.
Il secondo è di manutenzione. Questa struttura genera molte pagine, un archivio per ogni incontro tra Topic e formato, e tenerle tutte curate richiede attenzione. Lo stesso crawl mi ha mostrato che i title degli archivi per Topic erano rimasti tutti uguali: il plugin prevede come differenziarli, io me n’ero dimenticato. Succede. Un crawl fatto ogni tanto serve anche a questo.
Cosa mi porto via
Per molto tempo i correlati li ho generati per categoria, e funzionavano. Il crawl ha reso visibile quello che quel sistema non poteva fare: tolti menu e footer, i link del mio sito disegnano i Topic. Non perché li abbia messi uno per uno, ma perché li deriva la stessa classificazione che decide URL, schema e misura.
Da sviluppatore mi piace vedere come le cose si connettono. Guardando il crawl, la mappa che fino a ora era nella mia testa si è concretizzata: è diventata qualcosa di tangibile, una tabella che chiunque può aprire e controllare. La struttura tiene il tempo, io intervengo dove serve davvero, nel testo. Questo è swing.
E tu: se togli la navigazione, i link del tuo sito disegnano ancora la tua mappa? Se vuoi il quadro completo, da cui questo pezzo è partito, leggi la mappa che hai in testa, dentro il sito. Per il lato dei dati strutturati, c’è about e audience nel grafo di Yoast.
