Why Google Doesn’t Display Your Breadcrumbs

Google not displaying your breadcrumbs is usually because the structured data code contains errors. Google requires strict adherence to Schema’s BreadcrumbList specification (JSON-LD format is strongly recommended).

Quick Fix Steps:

1. Detect: Use the “Google Rich Results Test” tool to scan your page URL and fix all syntax errors highlighted in red.
2. Submit: After confirming everything is correct, request a recrawl in Google Search Console (usually takes 1 to 2 weeks to take effect).

Note: Even if the code is 100% correct, whether it ultimately displays is still dynamically determined by Google’s algorithm based on page weight, but ensuring 0 errors in the underlying code is the foundation.

Schema Structured Data Not Added Correctly

Many pages already have frontend breadcrumbs, but what Google reads is the parsable BreadcrumbList. The common problem is not “not writing it,” but rather missing fields in hierarchy items, non-consecutive position order, links that are not crawlable URLs, visible page paths that don’t match the markup content, and two conflicting data sets existing on the same page. Google has also explicitly stated: structured data must be consistent with page content to be eligible for search display; passing the testing tool does not guarantee it will be displayed.

Has Google Understood It

Seeing Home > Category > Page at the top of the page only means the frontend rendered a navigation trail; what Google reads is a completely different set of information: HTML links, JSON-LD, Microdata, internal link relationships, canonical, and crawlable status. Google Search Central’s definition of Breadcrumb is very clear: it represents the page’s position in the site hierarchy, for search systems to understand the page path. Schema.org also explains that BreadcrumbList is a sequence of linked web pages ordered by position reconstruction. Having 3 levels of text on the page does not equal the search system having obtained 3 usable nodes.

Going one step further, the issue with many sites is not “not showing to users,” but “the display layer and data layer are not the same path.” The page top shows Home > Men > Shoes > Running, but JSON-LD outputs Home > Shoes > Running, and there’s another set of Microdata in the source code written as Home > Sale > Running. Users can only see 1 path, but the search system receives 2 to 3 versions.

Rich Results Test can only tell you “which types of rich results can be generated,” it won’t judge which of the 3 paths represents the page’s true hierarchy for you. The tool being able to parse doesn’t mean the search result will adopt it.

This difference, when placed on real pages, usually appears in the following scenarios:

• Breadcrumbs appear at the top of the page, but BreadcrumbList is not in the source code

• The page source code has BreadcrumbList, but the visible path doesn’t match it

• The page has 4 levels of paths, but structured data only has 2 levels

• The same page outputs 1 set of data from theme, plugin, and application each

• Intermediate levels are search pages, filter pages, or parameter pages, not official URLs

• The last level name differs greatly from the current page title

When any 2 of the above occur simultaneously, Google parsing is no longer “reading one definitive path” but “selecting the most likely one from multiple signals.” Google’s structured data testing page also makes this very clear: Rich Results Test checks if Google-supported results can be generated; general Schema validation requires a different validator. Neither is responsible for endorsing search results.

You can break down “visible to users” into 3 layers, then check which layer isn’t reaching Google:

Once the visual layer is normal but the source code layer is missing, users will say “I clearly made breadcrumbs”; when the source code layer is normal but the site layer is chaotic, developers will say “the code passed testing”; from a search system perspective, both situations haven’t yet reached a state of stable adoption.

There’s another commonly misunderstood point: users not seeing Breadcrumb in search results doesn’t necessarily mean page parsing failed. Google began global adjustments to mobile search result URL display on January 23, 2025, where mobile and tablet results typically only show the domain name, no longer displaying URL hierarchies connected by >; desktop may still show breadcrumb-style paths.

This means that “not showing” on mobile is sometimes a display policy change, not that the page wasn’t understood. When troubleshooting, at least distinguish between devices: check structural display on desktop, first check if mobile falls under Google’s display contraction.

This affects many webmasters’ judgment. Users viewing an internal page on desktop can see the complete path; then searching the brand term on phone only sees the domain name, so they think Breadcrumb is broken. In reality, the page structured data may be completely normal, just the mobile SERP no longer displays that path.

To determine whether it was understood, don’t just focus on mobile results; examine source code, testing tools, desktop SERP, and enhancement status in Search Console together. Google’s help documentation doesn’t treat “display” as an inevitable result; it says “can help users understand and explore a site effectively,” not “will display upon submission.”

From the user perspective, the easiest mistake is treating “seeing navigation” as “the search system has the structure.” The former depends on browser rendering, the latter depends on semantic markup and crawl stability. A common example: an e-commerce page displays Home > Women > Jackets > Waterproof at the top, but the actual URL is /collections/sale/products/x, canonical points to another collection page, and JSON-LD is written as /women/jackets/. Users feel the path is fine when they click in because the page can return to the previous level; Google sees 3 different parent relationships, and the site hierarchy is no longer fixed.

Schema.org’s requirements for BreadcrumbList mention “typically ending with the current page” – if this “current page” is not the same object as what canonical points to, the path will drift.

Now looking at some source code layer details that often don’t affect user reading but do affect machine understanding:

• position starts from 0 instead of 1, 2, 3

• name written with marketing terms instead of navigation names

• item points to a 302 redirect page

• Page has 4 directory levels but only outputs the first 2

• Last item doesn’t correspond to the current document

• Breadcrumbs change with different entry points; Entry A is 3 levels, Entry B is 4 levels

Users will almost never notice these 6 items as anomalies, but the search system relies on them to determine “whether this is a stable link.” Schema.org documentation is very specific: position is used to reconstruct item order, and BreadcrumbList consists of linked web pages, typically requiring at least URL and name. Missing 1 dimension means 1 fewer judgment anchor point for the machine.

There’s also the CMS scenario. WordPress, Shopify, headless CMS, and template marketplace themes may all automatically output a set of breadcrumbs, then SEO plugins output a second set. Users only see the template’s one, but Google crawls both or even three sets. If the second set is hidden in <script type="application/ld+json"> and the third comes from old Microdata, the frontend team doesn’t normally check source code, so they easily keep thinking “users seeing it is enough.” When SERP doesn’t display or Search Console reports conflicts, they finally discover that the same name on the page corresponds to two different parents.

You can use a very short checklist to separate “users see” from “Google understands”:

• In browser: Does the top show a clear 3 to 5 level path

• Check source code: How many times does BreadcrumbList appear

• Compare with current page: Does the last item correspond to the current URL

• Check intermediate levels: Does each level return 200 instead of 301/302/404

• Run tests: Can Rich Results Test recognize Breadcrumb

• Compare devices: Are desktop SERP and mobile SERP displayed the same way

Among these 6 steps, the first 2 confirm “whether it was transmitted,” the middle 2 confirm “whether it transmitted official paths,” and the last 2 confirm “whether Google has conditions to display.” Only doing step 1 gives you only the user interface answer.

Adding another detail that’s often overlooked: Google recommends first using Rich Results Test to see which Google-supported rich results can be generated on the page; if you want general Schema validation, you also need to use the Schema Markup Validator. This means “no general Schema errors” and “Google recognized Breadcrumb” are not the same thing. Many developers only run 1 general checker, see that JSON is valid, and stop; actually, whether Google recognizes Breadcrumb depends on Google’s own supported types, fields, and page conditions.

So users being able to see breadcrumbs only proves half of the page interface is complete; for Google to have understood it, at least the other half must be satisfied: parsable BreadcrumbList in the source code, node order matching the page path, all links being official crawlable URLs, current page matching the chain end, and the display device not being contracted by Google’s interface policy.

Fields and Hierarchy Written Incorrectly

Many pages don’t completely lack breadcrumb markup, but are in a state where they “can be displayed by frontend but cannot be stably reconstructed by the search system.” Google’s Breadcrumb documentation requires using BreadcrumbList, with list items typically placed in itemListElement, and each level represented by ListItem; Schema.org also explicitly states that list order is reconstructed by position, and this chain typically ends with the current page. Missing 1 field, skipping 1 position, or the last level not landing on the current page – the code may still run, but that path may not be adopted in search results.

Let’s look at the most common mistakes first. The page source code has 3 levels of paths, the frontend display also has 3 levels, but JSON-LD only has 2 ListItems; or there are 4 levels total but position is written as 1, 2, 4, 4. Schema.org’s explanation of BreadcrumbList is very clear: position is used to restore order, with the default convention being ascending order. Once position fields are duplicated, skipped, or reversed, what the search system receives is not “a link of 4 pages” but “4 nodes with similar names but unstable relationships.”

Going further, field errors aren’t just one or two spelling problems; they’re mostly about structural relationships not being fully documented. The following 6 categories occur very frequently:

• @type written as ItemList instead of BreadcrumbList

• itemListElement contains plain text instead of ListItem

• Only has name, no item

• Has item, but URL points to redirect chain, parameter page, or 404

• position starts from 0, or uses string disorder

• Last level is not the current page but the parent category page

When Google describes breadcrumb paths in search results, it needs to reliably reconstruct the sequence through position. Any disruption in the sequence means the path cannot be displayed as a breadcrumb.