When a retrieval system pulls a chunk of your page to answer a question, it gets the text. It does not automatically get the context: which section of your site this came from, what category it belongs to, what sits above it.
Breadcrumb markup supplies that context in a form a machine reads directly. It is one of the few schema types that is genuinely quick to implement, works site wide from a template change, and is skipped by a large share of sites that have otherwise done their schema homework.
What the Markup Actually Declares
BreadcrumbList schema describes an ordered path from a starting point to the current page.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Blog",
"item": "https://notioncue.com/blog"
},
{
"@type": "ListItem",
"position": 2,
"name": "Technical",
"item": "https://notioncue.com/blog/technical"
},
{
"@type": "ListItem",
"position": 3,
"name": "Breadcrumb Schema and Site Hierarchy"
}
]
}The final item conventionally omits item because it is the current page. Positions are explicit integers, which removes any need to infer order.
This is a small amount of markup that answers a question nothing else on the page answers directly.
Visible Breadcrumbs and Marked Up Breadcrumbs Are Different Things
Plenty of sites show a breadcrumb trail visually and never mark it up. A parser sees a row of links separated by chevrons and has to guess at their relationship.
Plenty of others mark it up and hide it visually, which is technically valid and which I would avoid. Schema that does not correspond to something on the page is the mismatch risk covered in the schema errors guide, and the visible version helps human readers anyway.
Do both. Show the trail, mark it up, keep the labels identical between the two.
Hierarchy Reinforces Topical Clusters
Breadcrumbs and the cluster architecture in the topical authority guide are the same idea expressed at different layers. Clusters organise content by relationship. Breadcrumbs declare that organisation in a machine readable format on every single page.
If you have built genuine clusters, breadcrumbs make the structure explicit rather than something an engine has to reconstruct from internal links. If you have not built clusters, breadcrumbs will faithfully describe a flat structure, which is honest and not especially useful. The markup declares your architecture. It does not improve it.
URL Path Is Not the Only Valid Trail
Breadcrumbs do not have to mirror your URL structure and often should not. A post at /blog/some-article can carry a breadcrumb trail through Blog and then Technical even though the URL has no category segment.
This is useful for sites with flat URLs, which is a common pattern that trades hierarchy for shorter addresses. Breadcrumb markup restores the hierarchy signal without touching URLs, which means it does not require the migration risk covered in the migration guide.
What matters is that the trail is accurate and consistent. A page appearing under different trails on different visits is worse than no trail.
Pages With Multiple Legitimate Paths
Ecommerce hits this constantly. A product sits in several categories and any of them is a defensible breadcrumb.
Schema.org permits multiple BreadcrumbList objects for exactly this case. In practice I would pick one primary trail and use it consistently rather than emitting several, because consistency is the more valuable signal and multiple trails reintroduce ambiguity.
Pick the path most people would take to find the item, and pick the same one every time.
Where This Sits in Priority Order
Honestly, below the things that break outright. If AI crawlers cannot reach your content, per the crawlers guide, breadcrumbs are irrelevant. Same if your content is trapped behind client side rendering.
But among schema types it has an unusually good effort to value ratio. One template change, applies everywhere, no per page work, no ongoing maintenance. The schema markup guide covers where it fits alongside the types that need per page attention.
Verifying It
Schema validators confirm the markup parses. They do not confirm a crawler received it, which is a separate failure when schema is injected client side.
The NotionCue AI Crawler Audit checks the server response rather than the rendered DOM, which is the distinction that catches this. Worth running after any template level schema change since those either work everywhere or fail everywhere.
Start your free NotionCue trial and check a few pages from different sections. Template inconsistencies show up fast when you compare a blog post against a product page.
If you implement one thing from this post, make it consistency. A breadcrumb trail that changes depending on how a page was reached is worse than not having one, because it actively contradicts itself.
Common Questions
Do breadcrumbs still produce rich results in Google?
Breadcrumb display in search results has been supported for a long time and was not part of the deprecation wave that removed FAQ and HowTo rich results, covered in the FAQ deprecation guide.
Should the homepage be the first breadcrumb item?
Optional and it makes little difference. Some implementations start at Home, others start at the first meaningful section. Consistency across your site matters more than which convention you pick.
Do breadcrumbs help if my site is genuinely flat?
Less. They describe structure rather than create it. If everything sits one level below the homepage, the markup will say so accurately and contribute little.