SEO
BreadcrumbList schema generator (JSON-LD)
By Charles Summers · Updated · Free, no signup
Short answer
BreadcrumbList does not add a rich result. It replaces the raw URL line above your title in the results with a readable path such as Home > Shop > Waterproof jackets, which is a clarity gain rather than a size gain. The rules are few and strict: position must be an integer starting at 1 with no gaps, every item except the last carries an item URL, the last carries a name and position only, and the trail should mirror the visible breadcrumb on the page and reflect site hierarchy rather than the route the visitor happened to take.
Use the schema markup generator
Why breadcrumbs need a different approach
Breadcrumbs are the cheapest and most reliable markup on this tool, and also the most modest. Nothing expands, nothing gains stars, no extra lines appear. What changes is the line above your title: instead of a truncated URL with slugs and hyphens in it, a searcher sees a readable path through your site. On a deep ecommerce URL that is a real improvement in legibility, and on a shallow site it is barely noticeable.
It is worth knowing that a breadcrumb-style display can appear without any markup at all, derived from your URL structure. The markup is what lets you control the labels rather than accepting whatever the path segments happen to say, which matters most when your URLs carry IDs, abbreviations or a taxonomy your customers do not use. Getting it right is a couple of rules about integers and a decision about which path to publish when a page genuinely sits in several.
It runs entirely in your browser. Nothing you type is sent to a server, no account is required, and there is no usage limit, because there is no cost per run to control.
Positions are integers, and the last crumb is different
The structure is a list of ListItem objects and there are exactly three things to get right. position is an integer starting at 1 and incrementing with no gaps and no repeats. It should be a number in the JSON, not a string, and the ordering that matters is the position values rather than the order the items happen to appear in the array. name is the label a human reads. item is the URL of that step.
The exception is the final crumb, which represents the page the reader is already on. It takes a position and a name but no item, because there is nowhere to link to. Including a self-referential item on the last crumb is not fatal and Google tolerates it, but the documented pattern omits it, and consistency on something this cheap is worth having. This is the single most common difference between hand-written breadcrumb markup and the pattern in the documentation.
The other structural decision is where the trail starts. Home as the first crumb pointing at your root is conventional and readable. Starting at the first category and omitting home is also fine, since the domain is already visible in the result. What is not fine is a trail that starts halfway through the hierarchy with no explanation, because it implies a structure your site does not have.
One good habit avoids a whole class of bug: generate the breadcrumb markup and the visible breadcrumb component from the same data, in the same request. The failure mode when they are generated separately is not dramatic, it is drift. Somebody renames a category in the navigation, the visible trail updates, the JSON-LD keeps the old label for eighteen months, and nobody notices because nothing errors.
Hierarchy, not history: the trail is a property of the URL
The most consequential mistake in breadcrumb markup is philosophical rather than syntactic. A breadcrumb should describe where a page sits in the site, not how this particular visitor arrived at it. Session-based trails, where the crumbs reflect the sequence of pages someone clicked through, are a legitimate interface pattern and a bad thing to mark up, because they make the same URL emit different structured data to different visitors, which means the markup no longer describes the page.
The test is simple: given a URL and nothing else, can you produce the trail deterministically? If yes, it is a hierarchy and it is safe to mark up. If you need to know what the visitor did before arriving, it is history, and it belongs in the interface only.
Faceted and filtered pages are where this gets genuinely difficult, and the answer follows from the indexing decision rather than from the markup. If a filtered view is indexable in its own right, it deserves a trail ending at itself. If it is canonicalised to the unfiltered category, then whatever crumbs render for the user, the markup should describe the canonical page, because that is the URL a search system is being asked to represent. Emitting breadcrumbs on thousands of filter permutations that all canonicalise elsewhere generates a great deal of markup describing pages that are not intended to appear anywhere.
Then there is the page that honestly belongs in more than one place: a jacket that lives under Waterproofs and under Womens and under a Sale collection. The vocabulary permits multiple BreadcrumbList blocks on one page, one per genuine path, and a system will pick one to display. Use that when the paths are real, and do not use it to list every category a product has ever been tagged with, because a page with nine competing trails has effectively told nobody where it lives.
What it changes, what it does not, and how to see it
Being precise about the payoff keeps expectations honest. What you gain is the URL line above the title rendered as a labelled path rather than as a raw address, on both desktop and mobile. What you do not gain is vertical space, a visual element, a star, an image, or any additional line of text. Nobody should expect a measurable traffic step change from shipping this, and anybody promising one has invented the number.
The realistic case rests on two things. First, on a URL like /shop/c/44821/p/9930-a the difference between that string and "Home > Waterproofs > Womens" is substantial, and legibility in a result is a genuine if unglamorous factor in whether someone clicks. Second, the trail restates your site's taxonomy in a form that requires no crawling to reconstruct, which is a small clarity gain for anything trying to understand how your categories relate.
It also has an unusual property among schema types: it is nearly impossible to get into trouble with. There is no rating to fabricate, no price to contradict, no external record to disagree with, no lifecycle to maintain. The worst outcome from a mistake is a trail with wrong labels, which is embarrassing rather than dangerous. That combination of low risk and low ceiling is exactly why it belongs in the template on day one and never on a roadmap.
- Check the enhancement report, not just the test tool. Breadcrumbs get their own section in Search Console, and the errors it reports, usually a missing name or a malformed item URL, are template-wide by nature rather than one-off.
- Watch for relative URLs in item. A path fragment resolves to nothing for a parser reading the JSON on its own. Every item needs the full absolute URL.
- Do not let position start at 0. Developers index from zero by habit and the specification starts at 1. It is a one-character bug that invalidates the whole list.
- Labels should match the words on the page. If the navigation says "Waterproofs" and the markup says "Outerwear, technical", you have published two taxonomies and picked neither.
- Google may still choose its own. Your markup is a strong input, not a guarantee, and a result showing a different path than you specified is not necessarily a bug in your JSON.
Numbers worth knowing
| Metric | Typical | What it means |
|---|---|---|
| What it changes in the result | the URL line, not the result size | The raw address above your title becomes a labelled path. No extra height, no visual element, no star. A clarity gain rather than a real-estate gain, and worth planning around as such. |
| position numbering | integers from 1, no gaps | A number in the JSON rather than a string, starting at 1 rather than 0. Zero-indexing out of developer habit is a one-character bug that invalidates the entire list. |
| item on the final crumb | omitted | The last entry is the page the reader is already on, so it carries a position and a name only. Including a self-link is tolerated but is the most common divergence from the documented pattern. |
| Breadcrumb display without markup | possible, derived from the URL | A path-style display can appear from URL structure alone. The markup is what gives you control over the labels, which matters most when your URLs contain IDs or internal abbreviations. |
Mistakes that quietly cost you results
- Marking up the visitor's click path instead of the site hierarchy
- Session-based trails make one URL emit different structured data to different people, so the markup stops describing the page. The test is whether you can derive the trail from the URL alone. If you cannot, keep it in the interface and mark up the hierarchy instead.
- Generating the visible breadcrumb and the JSON-LD from separate code
- They drift. Somebody renames a category, the navigation updates, and the markup keeps the old label for a year because nothing errors when they disagree. Build both from one data structure in one request so a rename cannot land in only one of them.
- Emitting breadcrumbs on every faceted filter combination
- If the filtered view canonicalises to the unfiltered category, the markup should describe the canonical page. Thousands of trails for URLs that are not meant to appear anywhere is noise, and it makes the report harder to read when a genuine error does show up.
- Publishing a separate trail for every category a product is tagged with
- Multiple BreadcrumbList blocks are legitimate when a page genuinely sits in two paths, such as by brand and by category. Nine competing trails is not extra coverage, it is a page that has declined to say where it lives.
What does the output look like?
This is the exact output the tool produces from the example inputs. It is generated by the same code that runs when you click the button, so what you see here is what you get.
Frequently asked questions
Does the trail have to match a breadcrumb the user can see on the page?
It should, and the general structured data guidelines about representing page content point that way even though the breadcrumb documentation is less explicit than the FAQ rules are. The stronger practical argument is that a visible breadcrumb is useful in its own right for navigation and for internal linking, and building both from the same data is what stops them drifting apart. Markup with no visible counterpart is a trail asserting a structure that no visitor to the page can perceive.
Should the first crumb be Home, or the first real category?
Either works and the difference is small. Home pointing at your root is conventional and reads clearly. Starting at the top category is also defensible, since the domain is already shown in the result and the extra crumb adds little. What matters is picking one and applying it site-wide from the template, because a mixture across sections looks like two different sites and gives you nothing in exchange.
What should a blog post use for its trail?
Whatever structure a reader would actually recognise, which for most blogs means Home, then the section or category, then the post. If your blog has no real taxonomy, a two-level trail is more honest than inventing a category layer for the markup to describe. Avoid using tags as crumbs when a post carries several, since the choice between them becomes arbitrary and different posts end up with structurally inconsistent trails.
Can I use breadcrumbs on a page that has no parent, like the homepage?
There is no point. A single-item list containing only the page you are on describes no path and adds nothing, and the homepage is already the root everything else points at. Breadcrumbs earn their place from about the second level down, and they earn most on deep pages where the URL is otherwise an unreadable string of IDs and slugs.
How long after shipping should the path show up in results?
It depends entirely on when those URLs are next crawled and processed, which for a large site can be uneven across sections. The enhancement report in Search Console will start counting valid items before the display changes everywhere, so that is the better place to confirm the markup was accepted. If the count is climbing and the result still shows a raw URL on a page you checked yesterday, the answer is usually patience rather than a fix.
Related free tools
- Schema Markup Generator SEO
- Schema Markup Generator for article pages SEO
- Schema Markup Generator for product pages SEO
- Schema Markup Generator for faq pages SEO
- Schema Markup Generator for local business SEO
- Schema Markup Generator for events SEO
- Schema Markup Generator for software apps SEO
- SEO Meta Tag Generator for local business SEO
- SEO Meta Tag Generator for blog posts SEO
- SEO Meta Tag Generator for comparison pages SEO
- CAC Payback Period Calculator for marketplaces Analytics
- CAC Payback Period Calculator for agencies Analytics
Some links on this site are affiliate links, which means Hacking Demand may earn a commission if you buy through them at no extra cost to you. This does not influence which tools are listed. The tools on this page are free and have no affiliate relationship of any kind.