Briciole di pane SEO: la guida al breadcrumb

Le briciole di pane, in inglese breadcrumb, sono quella riga di link in cima alla pagina che mostra da dove arrivi: Home > Categoria > Sottocategoria > Pagina attuale. È uno degli elementi di interfaccia più vecchi del web, eppure resta uno dei pochi che serve davvero due pubblici diversi con lo stesso identico pezzo di codice.

Il primo pubblico è la persona che guarda lo schermo: le dice dove si trova dentro la struttura del sito e le offre un modo immediato per risalire di un livello, senza affidarsi al tasto indietro del browser. Il secondo pubblico è il motore di ricerca, che legge la stessa sequenza come una dichiarazione esplicita di gerarchia — quale pagina è genitore di quale — invece di doverla dedurre dai link sparsi nel resto del sito. Fare bene questa cosa piccola ha un effetto sproporzionato rispetto allo sforzo richiesto per implementarla.

I due lavori che fa una breadcrumb

Il lavoro di orientamento diventa evidente quando si pensa a come le persone atterrano davvero su un sito. Chi arriva da un motore di ricerca raramente parte dalla home: il click porta direttamente su una pagina prodotto, su un articolo o su una scheda categoria, saltando tutti i passaggi intermedi. Senza un indicatore di posizione, quella pagina è isolata: non è chiaro se si tratta di un contenuto generico o di uno specifico, né dove guardare per trovare argomenti correlati. La breadcrumb ricostruisce quel contesto in una riga, in meno di un secondo.

Il secondo lavoro, quello rivolto al crawler, è meno visibile ma altrettanto concreto. Un motore di ricerca costruisce la propria mappa del sito seguendo i link, e la breadcrumb è un link interno che dichiara esplicitamente una relazione genitore-figlio. Questo è particolarmente utile quando la struttura degli URL non basta da sola a comunicare la categoria di appartenenza — per esempio un URL del tipo /prodotto/12345 che non contiene alcun segmento di categoria. La breadcrumb colma quel vuoto senza bisogno di toccare lo schema degli indirizzi.

C'è poi un terzo effetto, meno discusso ma reale: la coerenza delle etichette. Se la voce di categoria nella breadcrumb usa esattamente lo stesso nome che compare nel menu di navigazione e nel titolo della pagina categoria, chi legge riconosce immediatamente di essere ancora nello stesso ramo del sito, anche se ha aperto quella pagina da una scheda o da una ricerca diversa. Etichette diverse per lo stesso concetto — "Scarpe" nel menu, "Calzature" nella breadcrumb — introducono un piccolo attrito cognitivo che si somma a ogni pagina visitata, ed è un errore facile da evitare semplicemente riusando lo stesso testo ovunque quel nodo compare.

Il markup BreadcrumbList e la sostituzione dell'URL in SERP

Oltre al widget visibile, esiste una versione strutturata pensata esclusivamente per i motori di ricerca: il tipo BreadcrumbList di schema.org, espresso in JSON-LD. È un elenco ordinato di voci, ciascuna con un nome e un URL, che ripercorre lo stesso percorso mostrato a video — o anche uno leggermente diverso, se la logica editoriale lo richiede. Il markup non aggiunge nulla all'interfaccia: è puro segnale, letto dal crawler e ignorato dal browser.

Il motivo per cui vale la pena impostarlo con cura è che Google, in una porzione consistente dei risultati, sostituisce la riga dell'URL sotto il titolo con il percorso ricavato dalla breadcrumb, al posto del classico dominio-slash-percorso. Quando questo accade, il trail smette di essere un dettaglio di interfaccia e diventa un elemento della pagina dei risultati: è la prima cosa che l'utente legge dopo il titolo, prima ancora di decidere se cliccare. Un trail con nomi di categoria chiari e coerenti comunica subito di che tipo di pagina si tratta; un trail rotto, duplicato o con nomi generici come "Pagina" o "Sezione1" comunica il contrario, anche se il contenuto sottostante è ottimo.

Da qui discende una conseguenza pratica spesso trascurata: il testo delle voci nel markup BreadcrumbList merita la stessa attenzione editoriale riservata al title tag, perché in molti casi è quello che l'utente vede davvero in SERP al posto dell'indirizzo.

Costruire la gerarchia giusta: struttura del sito, non percorso di clic

L'errore concettuale più comune è pensare alla breadcrumb come a una cronologia di navigazione — la sequenza di pagine che quella persona ha effettivamente visitato per arrivare lì. Non deve esserlo. La breadcrumb deve riflettere dove quella pagina vive in modo permanente dentro l'architettura del sito, indipendentemente da come ci si è arrivati.

Un esempio chiarisce la differenza. Un utente trova un prodotto passando dai risultati di ricerca interna del sito, oppure da una landing page promozionale legata a una campagna stagionale. Se la breadcrumb registrasse il percorso di clic, mostrerebbe qualcosa come "Ricerca > Prodotto" oppure "Offerte Estate > Prodotto": un percorso vero per quella sessione, ma privo di significato per chiunque altro e diverso a ogni visita dello stesso utente. La breadcrumb corretta, invece, resta identica per tutti: "Categoria > Sottocategoria > Prodotto", perché quella è la posizione stabile del prodotto nella tassonomia del catalogo, non una sua fotografia momentanea.

Questa distinzione conta doppiamente per il crawler, che non ha una sessione utente da seguire: legge sempre e solo il markup e il link presenti nell'HTML della pagina. Una breadcrumb legata alla navigazione individuale, oltre a confondere chi la guarda, comunica una gerarchia diversa a ogni scansione, il che equivale a non comunicarne nessuna.

Un caso limite frequente riguarda le pagine generate da filtri, tipiche dei siti e-commerce: colore, taglia, prezzo, ordinamento. Se ogni combinazione di filtri genera una propria variante di URL, la breadcrumb non deve seguire i filtri applicati — mostrare "Categoria > Rosso > Taglia M > Sotto 50 euro" non descrive una posizione stabile nella tassonomia, descrive uno stato temporaneo dell'interfaccia. La breadcrumb corretta, in questi casi, punta sempre alla pagina di categoria canonica, quella priva di filtri, lasciando che sia l'interfaccia di filtro — non il trail — a comunicare la selezione attiva in quel momento.

Gli errori più comuni

Alcuni difetti ricorrono con una frequenza sorprendente, spesso perché la breadcrumb viene implementata come un elemento decorativo piuttosto che come un segnale strutturale:

• Duplicare la navigazione principale: se il trail riporta esattamente le stesse voci del menu in alto (Home, Prodotti, Blog, Contatti) senza scendere di livello, non sta comunicando nessuna gerarchia in più — è solo un secondo menu con un altro nome.
• Partire dalla pagina corrente: una breadcrumb che mostra soltanto il titolo della pagina attuale, senza risalire almeno a un genitore, non orienta nessuno e non dichiara nessuna relazione al crawler. Deve sempre includere almeno un livello sopra quello in cui ci si trova.
• Iniettarla solo via JavaScript: se sia il trail visibile sia — soprattutto — il markup BreadcrumbList vengono generati esclusivamente lato client dopo il caricamento iniziale, il segnale rischia di non essere letto in tutte le scansioni, specialmente su siti con molte pagine dove il rendering non è garantito per ognuna. È più solido avere almeno il markup presente nell'HTML restituito dal server.
• Disaccordo con la struttura degli URL: quando il trail mostra "Categoria > Sottocategoria > Prodotto" ma l'indirizzo effettivo è /prodotto/nome-prodotto, senza alcun segmento di categoria, oppure quando l'ordine delle voci non rispecchia i segmenti di cartella dell'URL, si mandano due segnali di gerarchia in conflitto sulla stessa pagina. Non è un problema fatale, ma è un'incoerenza che vale la pena evitare quando la struttura dell'URL è comunque sotto controllo.

Il valore come link interno sui siti profondi

Su un catalogo con molti livelli — categoria, sottocategoria, sotto-sottocategoria, prodotto — le pagine più in profondità ricevono spesso pochissimi link interni dedicati. I link dalla home puntano alle categorie principali, i link dalle categorie puntano alle sottocategorie, e a un certo punto la catena di link intenzionali si esaurisce mentre la profondità del catalogo continua.

In questo scenario la breadcrumb, presente identica su ogni pagina di quel ramo, è spesso l'unico link stabile che una pagina genitore offre esplicitamente verso i suoi discendenti diretti — e, viceversa, l'unico link che ogni pagina figlia offre sempre verso l'alto. Non sostituisce una buona architettura di link interni pensata apposta, ma la rinforza in modo capillare e automatico, senza richiedere che qualcuno ricordi di linkare manualmente ogni nuova pagina aggiunta in profondità. È anche un percorso di scoperta aggiuntivo per il crawler, complementare alla sitemap XML ma basato su link reali anziché su un semplice elenco di indirizzi.

Lo stesso vale per i siti di documentazione tecnica e per i blog organizzati in categorie profonde: un articolo pubblicato tempo fa e non più promosso da nessun link editoriale recente resta comunque raggiungibile attraverso la breadcrumb di ogni pagina della stessa sezione, oltre che dalla pagina di categoria che lo elenca. È un meccanismo silenzioso, ma è spesso la ragione per cui una pagina vecchia e poco linkata continua a essere scansionata con regolarità invece di scivolare fuori dall'indice per mancanza di percorsi interni che la raggiungano.

La visualizzazione su mobile: troncare senza perdere senso

Su schermo largo un trail di cinque o sei livelli occupa una riga senza problemi. Sullo stesso trail, su uno schermo stretto, lo spazio disponibile può bastare per due o tre voci prima di dover andare a capo o uscire dal contenitore.

Le soluzioni che funzionano davvero mantengono visibili gli estremi del percorso e comprimono il centro: si mostra sempre la voce più vicina alla pagina corrente, quella immediatamente sopra — il genitore diretto, che è la voce con il maggior valore di orientamento — e si nasconde o si comprime dietro un'ellissi cliccabile tutto ciò che sta nel mezzo. Alcuni pattern usano lo scroll orizzontale del solo trail, altri un singolo chevron "torna a categoria" al posto del percorso completo. Quello che non funziona è il contrario: tagliare via il genitore diretto per mostrare solo la radice del sito toglie proprio l'informazione che serve di più in quel momento, cioè da dove si è appena arrivati.

Vale la pena ricordare che questo compromesso riguarda solo la resa visiva: il markup BreadcrumbList nell'HTML può restare completo, con tutti i livelli, indipendentemente da quanti ne mostra effettivamente l'interfaccia su schermo piccolo. Il crawler legge il markup, non uno screenshot della pagina, quindi comprimere la UI mobile non comporta la perdita di alcun segnale strutturato: i due livelli — quello mostrato all'utente e quello dichiarato al motore di ricerca — possono avere una granularità diversa senza alcun conflitto.

Quando un sito è troppo piatto per averne bisogno

Non ogni sito ha bisogno di una breadcrumb. Su un sito vetrina di poche pagine, su un blog senza categorie annidate, o su qualsiasi struttura dove ogni pagina è raggiungibile a un click dalla home, il trail si ridurrebbe sempre a "Home > Pagina Attuale": due voci che non aggiungono nessuna informazione a quella già presente nel menu principale e nel titolo della pagina stessa.

In quel caso implementarla comunque è solo spazio sottratto all'interfaccia e markup da mantenere per un beneficio pari a zero. La soglia pratica è semplice: appena esistono almeno due livelli reali di gerarchia — una categoria che contiene sottocategorie, o una sezione che contiene sotto-sezioni — la breadcrumb inizia a portare informazione utile sia a chi legge sia a chi scansiona, ed è a quel punto che vale la pena introdurla.

Anche i siti organizzati principalmente per tag piuttosto che per categorie gerarchiche rientrano spesso in questo caso limite: se un articolo può appartenere a più tag contemporaneamente e non esiste un genitore univoco, forzare una breadcrumb a scegliere un solo tag come categoria principale è arbitrario quasi quanto ometterla del tutto. In quella situazione è più onesto lasciare che sia la pagina del singolo tag, linkata dall'articolo in modo esplicito, a fare il lavoro che altrove farebbe il trail — senza inventare una gerarchia che nel modello dei contenuti non esiste davvero.