What this BreadcrumbList validator does
Paste your BreadcrumbList JSON-LD and this tool checks whether it is built the way Google requires to show a breadcrumb trail in search results. It parses the block, walks the itemListElement array, and inspects each ListItem for the right fields, the right shape, and the right position order. The output tells you, item by item, whether the breadcrumb is valid and rich-result eligible, or where exactly it falls apart.
A breadcrumb in search replaces the raw URL under your result with a clean hierarchical path, like Home, then a category, then the page. It signals site structure to both searchers and crawlers. The markup that powers it is small but finicky, and the most common reason breadcrumbs silently fail to appear is a structural slip in the itemListElement array that no human notices by eye. This validator catches those slips.
The itemListElement array, checked position by position
The heart of a BreadcrumbList is itemListElement, an ordered array where each entry is a ListItem describing one step in the trail. The validator confirms this array exists, is actually an array, and is not empty. Then it reads each ListItem in turn. A valid ListItem needs a @type of ListItem, a position, a name, and an item that identifies the page that step links to.
Position is where most breadcrumbs break. The validator checks that positions are present on every item, that they are integers, that they start at one, and that they increase by one with no gaps and no duplicates. A trail that jumps from one to three, repeats two, or starts at zero is invalid even if every field is otherwise filled in. The validator reports the exact offending positions so you can renumber them rather than hunt through the whole array.
ListItem fields the validator inspects
For each ListItem the validator confirms name is present and is a human-readable label, the text a searcher will actually see in the breadcrumb. An empty name, a name that is just a URL, or a missing name all fail. It then checks the item value. The item should identify the destination page, either as a URL string or as an object carrying an @id that is the page URL and, in the object form, its own name. The validator accepts both shapes and flags an item that is missing or points nowhere usable.
There is one deliberate exception the validator understands. The final ListItem, the current page, does not need a linkable item, because it represents where the user already is. Google allows the last crumb to omit item or leave it without a working URL. The validator treats a missing item on the last position as acceptable while still flagging a missing item on any earlier position, so you are not warned about a non-problem on the trailing crumb.
String items versus object items
The item property accepts two shapes, and the validator understands both so it does not falsely flag the one you chose. In the older, simpler shape, item is just a URL string and the human label lives in the sibling name property on the ListItem. In the newer, more explicit shape, item is an object with its own @id holding the page URL and its own name repeating the label. Google accepts both, but mixing them inconsistently across crumbs in the same trail is a smell the validator points out, because a trail that switches styles partway through is harder to maintain and easier to break.
When item is an object, the validator checks that the @id is a real, absolute URL and not an arbitrary identifier, because for breadcrumbs the @id is expected to be the page the crumb links to. A common error is putting a fragment, a made-up id token, or a relative path in @id and assuming Google will resolve it. It will not. The validator also confirms that, in the object shape, the inner name is present, since the ListItem name and the item name should agree rather than contradict each other. If the two disagree, the validator warns you so you can pick one source of truth for the label.
Multiple breadcrumb trails on one page
Some pages legitimately belong to more than one path, such as a product reachable through two different category routes, and Google permits more than one BreadcrumbList on a page to express that. The validator handles the case where you paste several BreadcrumbList objects at once, scoring each trail on its own and keeping their position sequences separate. A frequent mistake is letting positions leak across trails, where the second trail continues numbering from the first instead of restarting at one. Each independent trail must start its own count at position one.
When you do ship multiple trails, make sure each one represents a genuine, navigable path and that the primary trail matches the breadcrumb your interface actually shows. Extra trails that describe routes a user cannot really follow add noise rather than clarity, and Google generally chooses one to display anyway. The validator's per-trail scoring helps you confirm each is independently valid, but the editorial judgment of which paths are worth declaring is still yours to make.
How to read the validation result
Results separate hard errors from advisories. An error means the breadcrumb is invalid and will not produce a rich result, such as a broken position sequence, a missing name, or an item array that is not an array at all. Each error names the position and the field so you can fix it directly. Treat every error as blocking; Google will not render a breadcrumb that contains one.
Advisories flag things that are valid but worth a second look, like a relative URL that should be absolute, a name that looks like a raw slug rather than a friendly label, or a trail whose order does not seem to descend a real hierarchy. These will not necessarily stop the rich result, but they often mean the breadcrumb you show will read worse than it could. Clean up advisories when you can; clear all errors before you ship.
Common mistakes specific to breadcrumb markup
Out-of-order or non-contiguous positions are the number one failure, usually introduced when someone inserts or deletes a crumb and forgets to renumber the rest. The second is using URLs as names, which produces an ugly, unreadable breadcrumb even when it technically validates. The third is relative URLs in item; breadcrumb links must be absolute, with protocol and domain, or Google cannot resolve them.
A subtler mistake is a breadcrumb that does not match the page's real location. The trail should reflect the actual navigational path to the page, and it should agree with any visible breadcrumb on the page itself. A markup trail that claims a different hierarchy than the page shows is a structured-data mismatch. Another frequent issue is a single-item BreadcrumbList, which is pointless: a trail of one is not a trail, and a meaningful breadcrumb has at least two levels. Finally, watch for confusing BreadcrumbList with a generic ItemList; they share the array structure but Google treats them as different features with different requirements.
One more recurring problem is the trail that does not actually descend a hierarchy. A breadcrumb is meant to read from broad to specific, home first and the current page last, each step a real parent of the next. Trails that list siblings, that put the current page in the middle, or that jump between unrelated sections confuse both users and crawlers even when every field validates. The validator's advisories nudge you toward a trail that tells a coherent top-down story, because a structurally valid breadcrumb that describes a nonsensical path is still a poor breadcrumb. Fix the logical order, not just the field syntax.
Why breadcrumbs matter for SEO and AI search in 2026
Breadcrumb markup does double duty. In classic search it improves the look of your result and can lift click-through by showing a tidy path instead of a long URL. For crawlers and AI systems it spells out where a page sits in your site's hierarchy, which helps them understand topical relationships and your information architecture without having to infer it from links alone.
As AI engines summarize and cite pages, an explicit hierarchy helps them place your content in context, distinguishing a deep specialist page from a top-level overview. A correct BreadcrumbList is one of the lowest-effort, highest-clarity structured-data signals you can ship, which is exactly why it is worth validating carefully rather than assuming a generated block is fine. Small structural errors here are common and invisible until you check.
What to do after validation passes
Once the validator reports no errors, run the same JSON-LD through Google's Rich Results Test on the live page to confirm end-to-end eligibility, then deploy. Make sure the breadcrumb markup matches the breadcrumb your users see on the page; the two should describe the same path. Request indexing so Google re-evaluates the page and picks up the new markup sooner.
A few days later, check Search Console's breadcrumb enhancement report to confirm Google has parsed the trail and is not reporting issues. If you run a templated site, validate one representative page per template rather than every URL, since the structure repeats; fixing the template fixes them all. Whenever you change your site's category structure or URL hierarchy, re-validate, because breadcrumbs go stale the moment the paths beneath them move.