Breadcrumb schema: 201 of 936 interior pages declared a trail, and 35 of those held one item

What is breadcrumb schema, and what does it have to carry?

Two documents define it and they agree on the shape while saying slightly different things about the intent.

schema.org, at release 30.1 dated 2026-09-16, says that a BreadcrumbList is 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". Two words in that sentence do most of the work. Chain means the items are ordered and connected, not a set. Ending with the current page means the last item is where the reader is standing, which is the fact that makes the rest of the trail mean anything. On the position property the same page says that "the first items in this list correspond to the top or beginning of the breadcrumb trail, e.g. with a site or section homepage", so the trail runs from the root downward and not the other way.

Google's breadcrumb documentation, carrying Last updated 2026-09-08 UTC, states that "a breadcrumb trail on a page indicates the page's position in the site hierarchy" and that "Google Search uses breadcrumb markup in the body of a web page to categorize the information from the page in search results". It names three properties on each entry: position, "the position of the breadcrumb in the breadcrumb trail", with the note that "position 1 signifies the beginning of the trail"; name, "the title of the breadcrumb displayed for the user"; and item, "the URL to the webpage that represents the breadcrumb". It then carves out the one exception that matters for counting: "if the breadcrumb is the last item in the breadcrumb trail, item is not required. If item is not included for the last item, Google uses the URL of the containing page."

Each entry is a ListItem, which schema.org defines as "an list item, e.g. a step in a checklist or how-to description", and whose item property it defines as "an entity represented by an entry in a list or data feed". So the whole structure is three fields repeated N times, with one documented licence to omit a field on the last entry. That is a small enough target that the failure modes below are not modelling disagreements. They are the markup saying something the site does not mean.

How many pages declared breadcrumb schema at all?

445 of the 936 interior pages carried no JSON-LD whatsoever, which leaves 491 that carried some. 201 of the 936 declared a BreadcrumbList inside it. Put the other way, 290 pages went to the trouble of publishing structured data and did not use it to say where the page sits, which is a choice rather than an oversight: those pages are describing an organisation, a product or an article and leaving the hierarchy to the navigation bar.

JSON-LD is not the only syntax, so this run looked for the other two as well. 32 pages carried a microdata BreadcrumbList, declared with an itemtype attribute pointing at schema.org, among them argentina.gob.ar, usa.gov, nsw.gov.au, cam.ac.uk, nature.com, bankofamerica.com and statefarm.com. Exactly one page, bma.org.uk, used RDFa. Counting all three syntaxes together gives 231 of 936 pages with a machine-readable breadcrumb, against 201 counting JSON-LD alone, so the older syntaxes add 30 pages and are concentrated in government and large institutional sites. That distribution matches what this blog found when it counted the syntaxes directly and saw 22 of 385 home pages carrying microdata. A survey counting only JSON-LD therefore undercounts breadcrumbs by about an eighth, which is a useful correction to hold against schema.org's own published domain counts, the ones behind this blog's finding that only 16 schema.org types reach 10 million domains.

The split by how a site is built is sharper than the split by how large the organisation is, and it runs the opposite way to intuition. 22 of the 33 WordPress small business sites in the corpus carried breadcrumb markup, and 18 of 29 local media sites did, both of which run on plugin ecosystems where a breadcrumb block is switched on by default. 0 of the 39 Webflow sites carried one, 1 of the 50 Wix and Squarespace sites did, and 3 of 38 single page app startups did. A plumbing firm on WordPress publishes better hierarchy markup than a funded software company on a visual builder, which is the same pattern this blog met when 117 of 612 home pages with JSON-LD carried a defect and the defect rate tracked the platform rather than the budget. Whether any of it reaches an AI crawler depends first on whether the page answers at all, which 326 of these hostnames did not.

123 of 235 pages showed a breadcrumb and marked none of it up

A breadcrumb usually exists on the page before anyone decides to mark it up, as a row of links under the header. So this run also counted the pages whose HTML names one: an element carrying an aria-label, a class or an id containing the word breadcrumb. 99 pages used an aria-label and 225 used a class or id, 235 pages in total.

123 of those 235 carried no machine-readable breadcrumb in any syntax. The trail is drawn, styled, given an accessible label on some of them, and then published in a form only a browser and a screen reader can use. 35 pages went as far as an aria-label naming the navigation as a breadcrumb, which is a deliberate accessibility decision, and still shipped nothing a parser could read. The reverse case exists too and is larger than expected: 119 pages declared a BreadcrumbList and carried no such marker anywhere in the raw bytes, which is what a framework does when the markup is generated from a route table rather than from the component that draws the trail.

This is a floor and not an estimate, and the definition is worth stating plainly because the word breadcrumb is doing the identifying. A page that renders a trail without ever using that word in an attribute is not counted, and a page with a stylesheet class left on an empty container is counted when nothing is drawn. Neither error is measurable from the raw bytes, and no JavaScript was executed here, so a trail injected after load was not seen at all. What the number supports is narrow and still useful: on at least 123 pages, the site had already built the hierarchy and had already named it in its own HTML, and the step from there to a BreadcrumbList is a template change rather than a content decision. That is the same shape as 84 of 1,091 home pages offering a crawler no internal link at all, where the navigation existed and only the machine-readable half was missing, and it is why seeing what a bot is actually sent tends to be more informative than looking at the page.

165 of 202 trails named no level between the root and the page

The 201 pages carried 202 trails between them, one page, seota.com, publishing two. Sorted by length the distribution is short and it does not have much of a tail: 2 trails held no items at all, 35 held one, 128 held two, 28 held three, 7 held four, 1 held five and 1 held six. The median is 2 and the mean is 2.05.

A two item trail is home page plus this page. It is valid, it satisfies every requirement in both specifications, and it conveys nothing beyond the fact that the page is on the site, which the URL already said. 165 of the 202 trails are at most that, counting the two empty ones and the 35 single item ones. Only 37 trails named an intermediate level, which is to say only 37 pages out of 936 published a machine-readable statement that this page belongs to that category. The longest, at six items, is icmr.gov.in, and the second longest at five is fibilaw.com.

The beginning of the trail is looser than the specifications suggest too. 149 of the 196 trails that declared a first URL start at the site root. The other 47 start somewhere deeper, which schema.org allows by naming a "site or section homepage" as the top, but which means the trail no longer describes the whole path from the root. Several of them start at a section that is itself several levels down, so a consumer stitching a site map together from breadcrumbs gets disconnected fragments rather than a tree.

None of this is a defect, and that is the point worth carrying away. A short trail is correct markup that happens to carry very little information, and it counts the same as a full one in any survey of adoption. It is the same distinction as the difference between a page carrying JSON-LD and a page carrying JSON-LD that says something, which is why 103 of 385 pages with JSON-LD named no organization was a more useful number than the adoption rate beside it, and why 70 of 146 markup values were not on the page mattered more than the count of blocks that carried them.

The 35 trails that stop before they reach the page they are on

schema.org says a breadcrumb list typically ends with the current page. 110 of the 202 trails end at a URL that matches the page it was served from, and another 72 omit the last item's URL entirely, which Google's documentation explicitly permits and reads as the containing page. That leaves 18 trails whose final declared URL is a different page from the one carrying them.

The single item trails are where this concentrates. gov.uk, on its cookies page at /help/cookies, publishes a BreadcrumbList whose only entry is named Home with an id of https://www.gov.uk/, so the machine-readable claim is that the reader is on the home page. ons.gov.uk does the same on its own cookies page. ama-assn.org, thuisarts.nl, thenationalnews.com and redis.io each publish a one item trail naming the home page while serving an interior article or resource. On redis.io the page in question was a 2026 research resource, and the trail says Home.

23 of the 35 are a different and more defensible case: the single item names the page itself, so the trail is a chain of one that starts and ends in the same place. 9 of those 23 are documentation sites where the landing page of the docs is both the root of its section and the page being served, being gotenberg.dev, netboot.xyz, replicad.xyz, verdaccio.org, pdfme.com, woodpecker-ci.org, codehooks.io, foalts.org and gtfstohtml.com. Nothing is false there. There is simply nothing to say yet, and the markup says it anyway. The last 2 of the 35, siigo.com and visitmalta.com, name a step and give it no address at all, which is the exemption Google allows on a final item applied to a trail with nothing else in it.

Then there are the longer trails that end elsewhere. scripps.org serves an article and ends its trail at the parent section. costco.com, on a product page at /p/-/4000282374, publishes three items ending at a category page, so the product itself never appears in its own breadcrumb. icmr.gov.in, the six item trail, is not a hierarchy at all: its items are Home, Circulars, Employment Opportunity, Results, Press Release and Tender, which is the top level navigation menu serialised as a path, served on a page at /homepage. A consumer reading that trail learns that the site has six sections and nothing about where the reader is.

What a parser finds inside the 202 trails

Beyond the shape of the trail there are the values inside it, and 45 of the 202 trails fail at least one check that needs no judgement. The individual cases are small in number and specific enough to be worth naming, because each one is a template bug rather than a difference of opinion.

Two trails are empty. metlife.com serves /global/ with a BreadcrumbList whose itemListElement is a literal empty array, sitting next to a perfectly complete WebPage node, and spekit.com does the same on a product page. The markup is present, valid JSON, correctly typed, and holds nothing.

One trail contains a blank node identifier where a URL belongs. interpol.int, on its What is INTERPOL page, writes the first item's id as _:b1. The JSON-LD 1.1 specification, a W3C Recommendation dated 16 July 2020, says that blank node identifiers begin with _: and identify a node within the scope of a document, so this is an internal placeholder that escaped into published output. Resolved against the page it becomes https://www.interpol.int/Who-we-are/_:b1, which answered HTTP 503 when this run requested it.

Two trails put the values in keys that are not the keys. newyorklife.com writes each item as an object whose URL key is id rather than @id, so all three of its entries carry no resolvable address, and it writes its positions as the strings "1", "2" and "3" rather than as numbers. nyp.org wraps each item in a JSON array containing one object, so the name and the address are one level deeper than any consumer will look, and both of its entries read as nameless. Eight other sites also write positions as strings, among them tudelft.nl and busy.in. That syntax level detail decides more outcomes than modelling does, which is the finding a valid BreadcrumbList that scored zero on its syntax was built on.

Two trails start counting at zero. nhs.uk publishes a single item at position 0 inside a MedicalWebPage, and costco.com numbers its three items 0, 1 and 2, both of which contradict Google's statement that position 1 signifies the beginning of the trail. Four trails point at a hostname other than the one serving the page, all four being the www form against the apex or the reverse, on dtu.dk, logo.com.tr, fibilaw.com and verdaccio.org. Four more carry a literal #listItem fragment left on the end of an address by a template, on elderlawgroupwa.com, fornidental.com, villagedentaldtc.com and soulyrested.com.

Do the URLs a breadcrumb declares actually resolve?

A breadcrumb is a chain of links, so the addresses in it are checkable in a way that almost nothing else in structured data is. This run collected every distinct URL declared across the 202 trails, 335 of them, and requested each one once as LantadBot with redirects followed.

331 answered HTTP 200, which is a better result than the rest of this post would lead you to expect, and it is worth saying plainly because it is the inconvenient direction for the argument. Sites that mark up a breadcrumb at all are mostly generating it from real routes, and real routes mostly work. Four did not. hospitalangeles.com declares a three item trail whose middle entry, /directorio, answers 404 while the leaf it points to answers 200, so the site claims a category page it does not serve. bitrise.io does the same with /platform. woodpecker-ci.org declares its own address with a trailing slash, /docs/intro/, and serves the page at /docs/intro, where the slashed form answers 404. The fourth is interpol.int and its blank node.

16 more came back from an address other than the one declared, and they are not all the same thing. Four of the 16 are the #listItem fragments, which never reach the server at all because a fragment is not sent in a request, so those are a cosmetic defect rather than a redirect. That leaves 12 real redirects. Six are a host form mismatch, five of them on fibilaw.com declaring www against an apex that serves the site and one on verdaccio.org doing the reverse. The other six are ordinary section moves: seb.se declares a URL on its own hostname that now redirects to sebgroup.com, webmd.com declares an address ending default.htm that redirects to a cleaner path, and acehardware.com, libertymutual.com, otpbank.hu and diabetes.org each name a page that has moved. A breadcrumb that resolves through a redirect still works and still costs a round trip, and a consumer that does not follow redirects gets a 301 where it expected a page.

The comparison worth making is with the pages the trails point at rather than the trails themselves. A URL answering 200 is not the same as a URL serving the page it claims, which this blog measured when it found 125 of 1,094 sites answered a URL that does not exist with HTTP 200. That failure mode would be invisible here: a soft 404 in a breadcrumb chain answers 200 and reports as healthy in the 331.

What this does not show, and what Lantad scores

No part of this measurement says that marking up a breadcrumb produces a citation anywhere. Google's own documentation describes what Google Search does with the markup and says nothing about any answer engine, and no crawler vendor documents what its fetcher does with a BreadcrumbList. Requesting a third party site as LantadBot cannot establish what GPTBot or ClaudeBot extracts from it, so this post reports what 936 pages published and stops there. Anyone reading a causal claim into the adoption table is reading one that is not written.

Lantad's own treatment is worth stating because it is not flattering. SCHEMA_REQUIREMENTS in core/src/schema.ts names BreadcrumbList and requires exactly one property, itemListElement, and the presence check treats an empty array as absent. So of the 45 trails this post calls defective, Lantad's own scoring catches 2: the empty lists on metlife.com and spekit.com. gov.uk's trail of one pointing at the home page passes. costco.com's positions starting at zero pass. newyorklife.com writing id instead of @id passes, because the property is present and the check does not look inside it. That is a presence check, which is what the methodology describes it as, and this run is a reasonable argument for making it a shape check instead. The same softness is why three captured pages once scored full marks for schema while carrying almost nothing a reader would call a fact.

Four further limits apply to every figure above. The corpus is an editorial sampling frame rather than a random draw, so every rate supports a statement about these 1,419 hostnames and nothing wider. One page per site was read, chosen by taking the first internal link on the home page, so nothing here describes any other template on the same site, and 5 of the 936 redirected back to the root. No JavaScript was executed, so markup injected after load was not seen and every count is a floor, which matters more than usual on the 38 single page app pages read here, given that JavaScript supplied prose on 11 of 271 pages. And the values are claims the sites made about themselves on 22 September 2026 and may have changed since, the same caveat that applies to 95 of 111 article pages declaring an author and to 2 of 172 home pages carrying opening hours a machine could read.

What survives all of that is narrow and checkable. Hierarchy is a fact about a page that the page's text does not carry, entity confidence depends on facts a machine can resolve rather than infer, and on 123 pages the hierarchy was already drawn and already named and simply never declared. That last number is the only one here that is an instruction rather than an observation, and it is the cheapest AI visibility change on this list, because the markup is a serialisation of something the template already knows.