Breadcrumb schema: every property, and what breaks it

What breadcrumb schema actually does

It is the machine-readable version of the trail you already show on the page. One of the smaller pieces in the wider schema markup toolkit, and one of the few that still earns a visible change in the search result.

The type is BreadcrumbList. You give Google an ordered list of steps. Google swaps your URL in the result for that list.

Here is the part most posts skip. Google does not need your markup to show a trail. Its breadcrumb documentation says it can work out the path from URL structure on its own.

So this is not about creating a breadcrumb trail. It is about controlling one.

If your URLs read like /shop/?cat=19&id=4471, markup is the only way a reader sees "Shop › Sarees › Paithani" in the result instead. The on-page trail itself — where it sits, how it behaves on mobile, whether it should be clickable — is a separate design question, covered in our guide to breadcrumb navigation.

Is breadcrumb still a supported rich result?

Yes. Breadcrumb is one of the 25 structured data types Google Search currently supports, per Google's search gallery, last updated 16 October 2026.

That is worth saying plainly, because two types people still mark up are no longer on that list.

• FAQ — Google added the deprecation notice on 8 May 2026 ("will no longer appear in Google Search starting May 7, 2026") and removed the documentation entirely on 15 June 2026.
• HowTo — withdrawn earlier and also absent from the gallery.

Both are still valid schema.org. Both are still machine-readable context. Neither draws a rich result any more. Breadcrumb does.

One honest limit. Google's AI features guide, last updated 10 July 2026, states there are no additional technical requirements and no special structured data needed to appear in AI Overviews or AI Mode. Breadcrumb markup governs rich-result eligibility in Search. It is not an AI visibility tactic, and nobody should sell it as one.

The BreadcrumbList property table

Four properties. Google's breadcrumb structured data documentation marks all four as required, with one exception on item. There are no recommended-but-optional properties on this type — which makes it one of the easiest to get completely right, and one of the easiest to get silently wrong.

That is the whole type. A valid trail looks like this — three steps, numbered in order, with the final step carrying a name and no item:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1,
      "name": "Home",   "item": "https://example.in/" },
    { "@type": "ListItem", "position": 2,
      "name": "Sarees", "item": "https://example.in/sarees/" },
    { "@type": "ListItem", "position": 3,
      "name": "Paithani sarees" }
  ]
}

On digitalhangover.in that JSON-LD goes into AIOSEO > Schema > Custom Schema or your theme's head, never into the post body — a site snippet strips JSON-LD out of post content. If you would rather not hand-write it, our schema markup generator builds the block for you.

The two errors that break breadcrumb markup

Almost every broken breadcrumb we open is one of these two. Neither throws an obvious warning on the page, which is why they survive for months.

1. Non-sequential position values

position must be integers counting up from 1 with no gaps and no repeats. Templates break this constantly.

• Starting at 0 — a developer loops an array index straight into the field.
• Gaps — 1, 2, 4, because step 3 was a category the template hides for some products.
• Repeats — two steps both numbered 2 after a conditional branch runs twice.
• Strings — "position": "2" instead of 2.

The ordering is the only thing position exists for. Break the sequence and the trail has no defined order, so Google drops it and falls back to the URL. Your page still ranks exactly as before — you just lose the trail you thought you had.

2. Adding item to the final breadcrumb

This one is the opposite problem: people add a property that should not be there.

Google treats the last item in the list as the current page. It already knows that page's URL, because it is the page it is reading. So item is not needed on the final step — Google's documentation states you can omit it there.

Give the last step a name and nothing else. Two things go wrong when people insist on filling it in:

• A near-miss URL — trailing slash present or absent, http instead of https, a parameter attached — makes the final step point somewhere that is not quite this page.
• On a page with query parameters, the last item often ends up being the parameterised URL while the canonical is the clean one. That is a self-inflicted mismatch, and worth reading alongside how canonical tags pick the indexable version.

Leaving it out is not a shortcut. It is the documented, correct shape.

What we see go wrong on faceted and filtered pages

First-hand, from our own client work: faceted navigation is where breadcrumb markup falls apart most often, and it is almost never the schema's fault. It is the template underneath it.

Four patterns we keep finding on filtered listing pages:

1. The trail grows a step per filter. Tick three filters and the markup emits five, six, seven steps — one for each facet — so position runs past where the template's own logic expected to stop. Numbering breaks first; the trail disappears next.
2. Every filter combination declares a different trail for the same canonical page. The filtered URL canonicalises to the unfiltered category, but the breadcrumb markup still describes the filtered path. Google is reading a trail for a page it has consolidated away.
3. The last item points to the filtered URL. Exactly the error above, except the template produces it automatically on thousands of URLs at once.
4. Deep facet pages have a trail and nothing else. The markup describes a tidy three-step path, but no real internal link anywhere on the site reaches that page. Markup is not a link. A declared trail does not get a page crawled.

Our standing rule for filtered pages: mark up the path to the category, not the path to the filter combination. Match the trail to the canonical page, not to the parameters in the address bar. If the facets themselves need a strategy, that sits with faceted search rather than with the markup.

And the fourth pattern is the one to take seriously. A page with perfect breadcrumb markup and no inbound internal links is still an orphan page. Schema describes structure; it does not create it.

A five-minute check on your own trail

You do not need a crawl to find most of this. Pick three page types — a top category, a deep product or article, and one filtered listing URL — and work through them.

1. Read the positions. Do they go 1, 2, 3 with no gaps, no zero, no quotes around the numbers?
2. Check the last step. Does it have a name and no item? If it has an item, does that URL match the canonical character for character?
3. Count the steps against the page. The markup should mirror the trail a visitor sees. Extra invisible steps are a template leak.
4. Confirm the URLs are absolute. Relative paths in item are a common CMS default and they fail.
5. Check only one trail is emitted. Many WordPress setups output breadcrumbs from the SEO plugin and the theme. Two competing BreadcrumbList blocks on one page is the most common duplicate we clean up.

That last one matters more than it sounds. If your SEO plugin already emits BreadcrumbList — AIOSEO does — adding your own by hand creates a conflict rather than an improvement. Check what you already have before you write anything.

What a correct trail earns you

Breadcrumb markup is a small, finite, fully documented type with four properties and one exception. There is no judgement call in it. You either match the spec or you do not.

Get it right and the result stops showing a URL and starts showing a readable path — which tells a searcher where on your site they are about to land before they click. On a large catalogue or a deep guides section, that context is doing quiet work on every impression you already earn.