Lingue

Schema BreadcrumbList

Come implementare i dati strutturati BreadcrumbList per ottenere la visualizzazione del percorso breadcrumb nei risultati Google, il rapporto tra schema.org/BreadcrumbList e la vera navigazione HTML e come testarla.

Prima pubblicazione: 27 giu 2026 · Ultimo aggiornamento: 8 ago 2026 · Advanced
Lingue
AIScritto daAI v2
1 segnale di evidenza in questa pagina

BreadcrumbList è un blocco di codice, di solito JSON-LD, che dice a Google come rappresentare il percorso di navigazione di una pagina. Serve a due cose: può rendere il percorso leggibile nello snippet e aiuta Google a classificare le informazioni della pagina. Non è un fattore di ranking e non sostituisce i link HTML visibili. La struttura minima è BreadcrumbList → itemListElement → ListItem, con position e name per ogni elemento; ogni elemento intermedio deve avere un item URL assoluto, mentre l’ultimo può ometterlo perché è la pagina corrente. Rappresenta un percorso tipico dell’utente, non necessariamente le cartelle dell’URL. Il markup valido rende idonei, ma non garantisce che il breadcrumb appaia.

TL;DR — BreadcrumbList descrive il percorso breadcrumb di una pagina come dato strutturato (JSON-LD raccomandato; sono supportati anche Microdata/RDFa). Svolge due lavori: può essere idoneo a mostrare il percorso nello snippet Google al posto dell’URL e, nelle parole di Google, Google “uses breadcrumb markup in the body of a web page to categorize the information from the page in search results”; per questo una pagina può apparire sotto percorsi diversi per query diverse. La forma richiesta è BreadcrumbList.itemListElement, un array ordinato di ListItem, ciascuno con position, name e item; item è facoltativo solo sull’ultimo elemento, quello corrente. Google raccomanda un percorso utente tipico, non la struttura dell’URL, e dice che si possono omettere sia homepage sia pagina corrente. Non è un segnale di ranking, il markup valido non garantisce mai la visualizzazione e l’idoneità passa dai tre livelli di Mueller (markup valido → conformità alle policy → fiducia/qualità del sito). La visualizzazione affidabile nelle SERP 2026 è davvero contestata: implementa comunque il markup per il valore di categorizzazione, il costo basso e l’assenza di svantaggi, poi controlla i tuoi risultati.

Che cos’è, precisamente

BreadcrumbList è un tipo schema.org. schema.org lo definisce come “an ItemList consisting of a chain of linked Web pages, typically described using at least their URL and their name, and typically ending with the current page.” In pratica costruisci un BreadcrumbList il cui itemListElement è un array ordinato di voci ListItem, una per ogni passaggio. Evidence for this claim Google's breadcrumb examples use ordered ListItem entries with position, name, and item, with documented flexibility for the final item. Scope: Google Search breadcrumb feature requirements; schema.org permits a broader vocabulary. Confidence: high · Verified: Google: Breadcrumb structured data

Puoi esprimerlo in JSON-LD, Microdata o RDFa. JSON-LD è il formato raccomandato da Google e quello che sceglierei come predefinito: vive in un solo blocco script, non si mescola al markup visibile ed è il più semplice da modellare e diagnosticare.

I due lavori del markup breadcrumb

È l’inquadramento che manca nella maggior parte delle pagine concorrenti: saltano subito a “incolla questo JSON-LD”. Il markup breadcrumb fa due cose separate:

1. Può ottenere una visualizzazione avanzata nella SERP. Google può rendere il percorso nello snippet al posto dell’URL grezzo. Nota la parola idoneo: il markup valido ti rende candidato, non garantisce la visualizzazione.

2. È un segnale di categorizzazione letto internamente da Google. La documentazione Google dice: “Google Search uses breadcrumb markup in the body of a web page to categorize the information from the page in search results.” È la metà sottovalutata. Spiega perché lo stesso URL può apparire sotto percorsi diversi per query diverse: Google usa il percorso come contesto, non solo come decorazione. Questo valore esiste anche quando non viene renderizzato alcun breadcrumb visibile.

In concreto, la documentazione Google mostra più oggetti BreadcrumbList separati sulla stessa pagina: un blocco JSON-LD completo per ogni percorso realistico che può portare l’utente alla pagina, invece di un unico percorso che si adatta alla query. Se una pagina è davvero raggiungibile da più categorie (caso comune nell’e-commerce), contrassegna ogni percorso con il proprio BreadcrumbList e mantieni ogni variante valida in modo indipendente; ciascuna deve avere position, name e item per ogni ListItem. Non trattare un unico percorso “primario” come copertura del valore di categorizzazione per percorsi che non descrive.

Proprietà obbligatorie e facoltative

Questa è la spina dorsale dell’accuratezza: se la fai bene, il resto è dettaglio.

Obbligatorie:

  • BreadcrumbList.itemListElement — “An array of breadcrumbs listed in a specific order.” È l’elenco ordinato dei passaggi.
  • ListItem.position — “The position of the breadcrumb in the breadcrumb trail. Position 1 signifies the beginning of the trail.” Parti da 1 e incrementa.
  • ListItem.item (con un name) — URL ed etichetta di ogni passaggio. È obbligatorio per tutti gli elementi tranne l’ultimo, che è la pagina corrente e può omettere l’URL.

Google presenta chiaramente l’eccezione dell’ultimo elemento: “It is not required to include a breadcrumb ListItem for the top level path (your site’s domain or host name), nor for the page itself.” Quindi sia la homepage sia la pagina corrente sono facoltative: è un equivoco comune pensare che debbano comparire entrambe.

Un percorso valido deve avere almeno due ListItem per essere significativo: un breadcrumb a un solo passaggio non è un percorso.

Percorso dell’utente o struttura dell’URL

È la sfumatura da assimilare, perché Google la dichiara esplicitamente e molte guide la saltano: “We recommend providing breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure.”

Evidence for this claim Google recommends breadcrumbs that represent a typical user path rather than simply mirroring the URL structure. Scope: Google Search breadcrumb guidance; sites should choose an accurate navigational path. Confidence: high · Verified: Google: Breadcrumb structured data

In altre parole, il percorso breadcrumb è una dichiarazione navigazionale, non una dichiarazione di cartelle. Quando i due aspetti divergono — URL piatti con categorizzazione profonda, pagine tag o navigazione fortemente sfaccettata in cui un prodotto è raggiungibile da molti percorsi — contrassegna il percorso che un utente seguirebbe davvero, non le cartelle dell’URL. Conta soprattutto nell’e-commerce, dove un prodotto può appartenere legittimamente a più categorie (e dove, non a caso, navigazione sfaccettata e struttura degli URL diventano caotiche). Scegli il percorso utente primario per il markup della pagina.

Non è un fattore di ranking

Dillo chiaramente, perché “aiuta il ranking?” è una delle domande più comuni: nessuna indicazione di Google collega BreadcrumbList al ranking. Influisce sulla presentazione nella SERP e sulla categorizzazione interna, non sulla posizione. Aggiungerlo non ti farà salire; non averlo non ti farà scendere. Il motivo per implementarlo è il segnale di categorizzazione più la possibile visualizzazione, a fronte di un costo tecnico basso.

Validazione e rilascio

Google prescrive un flusso semplice:

  1. Aggiungi le proprietà obbligatorie nel formato scelto, seguendo le indicazioni di posizionamento di Google.
  2. Valida con il Rich Results Test e correggi gli errori critici.
  3. Distribuisci prima su poche pagine, conferma con URL Inspection in Search Console, poi estendi il rilascio a tutto il sito.

Search Console ha un rapporto di miglioramento dedicato ai Breadcrumbs che, una volta online, mostra errori e avvisi sul sito: è lì che monitori la salute nel tempo.

Perché il rich result breadcrumb non viene mostrato?

Il markup valido è necessario ma non sufficiente. John Mueller ha descritto un utile modello a tre livelli per l’idoneità ai rich result (qui lo parafraso): primo, il markup deve essere tecnicamente valido; secondo, deve rispettare le policy sui dati strutturati di Google; terzo, esiste un segnale più ampio, di solito a livello di sito, di qualità/fiducia: Google si fida abbastanza del sito da mostrare risultati avanzati generati dal markup?

Mueller ha offerto anche una diagnosi approssimativa: esegui una query site: per il tuo dominio e controlla se lì compaiono i risultati avanzati. Se il miglioramento appare nelle query site: ma non nelle query normali, questo indica più un problema di qualità/fiducia del sito che un problema tecnico del markup.

Sui breadcrumb in particolare, Mueller ha ridimensionato il rischio di policy: il senso della sua osservazione è che i breadcrumb sono tra i tipi di dati strutturati più difficili da “sbagliare” in un modo che faccia scattare una policy, perché un percorso breadcrumb è piuttosto letterale. Se il rich result non compare, è più probabile un problema del livello di visualizzazione/qualità che una violazione della policy nel markup breadcrumb.

L’unico argine di policy che si applica davvero: le linee guida generali sui dati strutturati di Google richiedono che il markup rifletta contenuti reali presenti nella pagina. Non inventare un percorso breadcrumb che non corrisponde alla struttura effettiva del sito per forzare un rich result: il markup difforme può, in teoria, causare un’azione manuale.

Google mostra ancora i breadcrumb nella SERP? (una risposta onesta nel 2026)

Qui voglio essere prudente invece che sicuro, perché le fonti sono davvero in disaccordo. Alcuni post del 2025–2026 sostengono che Google abbia rimosso la visualizzazione dei breadcrumb (prima desktop, poi mobile); altre guide datate 2026 descrivono BreadcrumbList come uno dei tipi di schema più stabili, con il percorso ancora visibile. La documentazione Google sui breadcrumb, a metà 2026, limita ancora la funzione al “desktop in all regions and languages where Google Search is available” e non contiene un avviso di dismissione.

Non risolverò il disaccordo con un categorico “Google lo mostra” o “è morto”: la visualizzazione è in evoluzione e le affermazioni di seconda mano (alcune basate su screenshot incorporati o osservazioni di una sola regione) non sono una base affidabile. Il mio consiglio parte dalla decisione: implementalo comunque. Il valore di categorizzazione non dipende dal rendering visibile, il costo è basso e non c’è uno svantaggio. Poi controlla le tue SERP per il tuo insieme di query, nelle superfici e regioni che ti interessano, invece di fidarti dello screenshot di un post.

(Se cerchi soprattutto l’angolo navigazione e UX — breadcrumb visibili come link interni, flusso di PageRank, accessibilità — è un tema fratello su questo sito, nella sezione website structure. Questa pagina resta deliberatamente sul markup.)

Bing e gli altri motori

BreadcrumbList è un tipo standard schema.org, non un tipo proprietario di Google, e Bing dichiara da tempo di supportare il vocabolario schema.org (JSON-LD, Microdata, RDFa) per i dati strutturati in generale. Non ho trovato una pagina Bing dedicata al breadcrumb schema, quindi descriverei il supporto Bing come supporto generico a schema.org, senza promettere un rich result specifico per i breadcrumb. Il markup scritto per Google è valido anche per Bing; se e come Bing mostri un miglioramento breadcrumb è una questione separata e meno documentata.

In sintesi

  • Struttura minima valida: BreadcrumbList → array itemListElement di ListItem, ciascuno con position (da 1), name e item; item è facoltativo solo sull’ultimo.
  • Google raccomanda il percorso utente, non la struttura dell’URL; homepage e pagina corrente sono facoltative.
  • Non è un fattore di ranking; il markup valido non garantisce mai la visualizzazione.
  • La visualizzazione nella SERP è davvero contestata nel 2026: implementa per il valore di categorizzazione e verifica i tuoi risultati.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.