Why doesn’t Google display your breadcrumbs (Breadcrumbs)

Google does not display your breadcrumb navigation, usually because there are errors in the structured data code. Google requires strict compliance with Schema’s BreadcrumbList specification (JSON-LD format is strongly recommended).

Quick resolution steps:

1. Detect: Use the “Google Rich Results Test Tool” to scan your webpage URL, and fix all syntax errors marked in red.
2. Submit: After confirming there are no errors, request recrawl in Google Search Console (it usually takes 1 to 2 weeks to take effect).

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

Schema Structured Data Not Properly Added

Many pages already have frontend breadcrumbs, but what Google looks at is the parseable BreadcrumbList. Common problems are not “not written”, but missing fields in level items, discontinuous position sequence, links not being crawlable URLs, mismatch between visible page path and markup content, two conflicting data sets existing on the same page. Google also explicitly states: structured data must match page content to be eligible for search display; passing the testing tool does not guarantee it will actually be shown.

Did Google Understand It

The appearance of Home > Category > Page at the top of the page only indicates that 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 clear: it represents the page’s position in the site’s hierarchy, helping the search system understand the page’s path. Schema.org also explains that BreadcrumbList is a sequence of linked web pages arranged in order, with the order reconstructed based on position. Having 3 levels of text on the page does not equal the search system having obtained 3 usable nodes.

First, let’s look at the difference between the user side and the crawl side. What users see is the visual result; what the search system gets is the source code result. Navigation components may be assembled client-side by React, Vue, or theme templates. Just because the browser can see it after 0.5 seconds doesn’t mean Google gets the same content during its first crawl. If a page only has front-end generated text links without a stable output of BreadcrumbList, the search system needs to infer the path on its own; once directories, categories, and parameter pages coexist, the inference results will deviate.

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

Rich Results Test can only tell you “what type of rich results can be generated,” and it won’t judge which of the 3 paths represents the page’s true hierarchy for you. Just because a tool can parse it doesn’t mean the search result will adopt it.

This difference, when applied to real pages, usually manifests in the following scenarios:

• The page top has breadcrumbs, but the source code has no BreadcrumbList

• The page source code has BreadcrumbList, but the visible path is inconsistent with it

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

• The same page is output with 1 set of data each by theme, plugin, and app

• The intermediate levels are search pages, filter pages, or parameter pages, not formal URLs

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

If any 2 of the above occur simultaneously, Google parsing is no longer “reading a determined path” but “selecting the one that looks most like it from multiple signals.” Google’s structured data testing page also explicitly warns: Rich Results Test checks whether Google-supported results can be generated; general Schema validation requires a different validator. Neither is responsible for endorsing the search results.

You can break down “users can see” into 3 layers, then see which layer hasn’t been transmitted to 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 test passed”; from the search system’s perspective, neither situation has reached a level where it can be stably adopted.

There’s another often misunderstood point: when users don’t see Breadcrumb in search results, it’s not necessarily a page parsing failure. Google began globally adjusting the URL display method for mobile search results on January 23, 2025. Mobile and tablet results typically only show the domain name and no longer display URL hierarchy connected by >; desktop may still show breadcrumb-style paths.

In other words, “not showing” on mobile is sometimes a display strategy change, not that the page wasn’t understood. When troubleshooting, distinguish by device at least: desktop shows structure display, while mobile should first check whether it falls under Google’s display contraction.

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

To determine whether it was understood, don’t just focus on mobile results. Consider source code, testing tools, desktop SERP, and enhancement status in Search Console together. Google’s 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 a user’s perspective, the easiest mistake is equating “seeing navigation” with “search system getting structure.” The former depends on browser rendering, while 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, the canonical points to another collection page, and the JSON-LD is written as /women/jackets/. Users feel the path is fine when they click in because they 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 the canonical points to, the path will drift.

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

• position starts from 0, not 1, 2, 3

• name written with marketing copy, not navigation name

• item points to a 302 redirect page

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

• The 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 discover anomalies due to these 6 items, 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 the machine has 1 fewer anchor point for judgment.

There’s also the CMS scenario. WordPress, Shopify, headless CMS, and marketplace themes may all automatically output one set of breadcrumbs, while SEO plugins output a second set. Users only see the template’s one, but Google crawls two 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 usually check source code, so they easily keep thinking “what users see is enough.” When SERP doesn’t display it, or Search Console reports conflicts, they 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, not 301/302/404

• Run test: Can Rich Results Test recognize Breadcrumb

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

In these 6 steps, the first 2 confirm “whether it was transmitted,” the middle 2 confirm “whether what was transmitted is a formal path,” and the last 2 confirm “whether Google has the conditions to display.” Only doing step 1 gives you only the user interface answer.

Adding one more detail that’s often overlooked: Google recommends first using Rich Results Test to see which Google-supported rich results can be generated from the page; if you want to do general Schema validation, you should also use Schema Markup Validator. In other words, “general Schema shows no errors” and “Google recognizes Breadcrumb” are not the same thing. Many developers only run 1 general validator, and seeing valid JSON, they stop; in reality, whether Google recognizes Breadcrumb depends on the types, fields, and page conditions that Google itself supports.

So, users seeing breadcrumbs only proves the page interface is half done; for Google to have understood it, at least the other half needs to be satisfied: the source code has parsable BreadcrumbList, node order matches the page path, links are all formal crawlable URLs, current page matches the trail end, and the display device isn’t contracted by Google’s interface policy.

Fields and hierarchies are written incorrectly

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

Let’s first look at the most common set of errors. The page source has 3 levels of paths, the frontend also displays 3 levels, but the JSON-LD only has 2 ListItems; or there are 4 levels total, but position is written as 1, 2, 4, 4. Schema.org’s description of BreadcrumbList is clear: position is used to restore order, with the default convention being ascending order. Once the position field has duplicates, skipped numbers, or reverse order, what the search system receives isn’t “4 pages in a chain” but “4 nodes with similar names but unstable relationships.”

Looking further, field errors aren’t just one or two spelling issues – more often the structural relationships aren’t fully documented. The following 6 types of situations occur very frequently:

• @type is written as ItemList, not BreadcrumbList

• itemListElement contains plain text instead of ListItem

• Only name, no item

• Has item, but the URL points to redirect chains, parameterized pages, or 404s

• position starts from 0, or uses strings in random order

• The last level is not the current page, but a parent category page

Google describes breadcrumbs as “a page’s position in the site hierarchy,” and Schema.org defines them as a series of linked web pages. Each level in the hierarchy needs to correspond to an understandable page – not just listing out names.

When users inspect on their own, the most easily overlooked issue is that the “visible page path” and “structured data path” are not the same set. The top of the page shows Home > Shoes > Running Shoes > Men, but the JSON-LD outputs Home > Men > Running Shoes. In the browser, these differ by only 1 level; to the search system, the site relationships have already changed. Google is very clear in the structured data documentation: markup is for search systems to understand content, not just for testing tools to pass syntax checks.

Another category of issues often arises from overlapping CMS, theme, and plugin outputs. One page has 2 sets of Breadcrumb data simultaneously, which is hard to spot visually because one might be in <script type="application/ld+json"> and the other might be Microdata. The final page doesn’t give Google 1 path, but 2 different versions of a path. With 4-level and 3-level hierarchies coexisting, the second level URL differs, and the last level name differs – the system must decide which is more trustworthy. Google’s testing page also notes that tools can only show “which Google-supported results can be generated,” not guarantee display.

Breaking down the issues at the field level makes them easier to locate. This table below can be used to check source code:

Each row in the table isn’t complex, but if 2 or more match, cases where search results don’t adopt the Breadcrumb will increase significantly. Especially for paths with 3 or more levels – once the second and third levels are swapped, the entire chain becomes quite skewed. What Google’s examples repeatedly emphasize is hierarchical order and node definition, not decorative syntax.

Continuing to investigate, a frequent question is whether “the last level should have a link.” Schema.org says this chain typically ends at the current page, and Google’s examples also include cases where the current page is the last item. In practice, what matters more isn’t “whether the last level has a link style,” but “whether the last level in the data clearly points to the current document.” If the page canonical is A but the Breadcrumb last item points to B, or if the last item name differs greatly from the <title> and h1, the system will struggle to bind the current document with the end of the chain.

You can perform manual checks in these 3 groups below, each taking 3 to 5 minutes to uncover most issues:

• Check Source Code

  • Find how many times BreadcrumbList appears

  • Count how many ListItem items there are

  • Check if position is continuous

  • Check if the last level corresponds to the current URL

• Check Page

  • How many levels does the top navigation show

  • Do category names exactly match JSON-LD

  • Has the current page name been abbreviated

  • Does the breadcrumb order match the directory tree

• Check Links

  • Does every level URL return 200

  • Are there multi-hop redirects

  • Are parameterized pages used instead of canonical pages

  • Is /category/ mixed with /collection/

After checking fields, the next step is to determine whether the hierarchy is the “real site hierarchy,” not the directory as editors are used to. A product page might be under 2 collections simultaneously, and an article might belong to 3 taxonomies. The frontend displays one path for user browsing; templates might output the most recent category relationship for convenience. The result is the same page showing 3 levels today and 4 levels tomorrow, or inconsistent between desktop and mobile.

This is why “passing the testing tool” doesn’t mean the fields and hierarchy are correct. The Rich Results Test mainly checks whether structured data can generate supported results and can provide previews; it won’t judge whether your site taxonomy is reasonable, nor whether a product page should be under Men > Running or Sale > Running. Code-level compliance only means parsing didn’t throw errors; whether site relationships are persistent, singular, and repeatable still requires going back to the page itself for verification.

Here’s a quick rule of thumb: for a 3-level path, at least 3 things must be simultaneously satisfied – the same 3-level names are visible on the page, there are 3 consecutive position values in the JSON-LD, and all 3 URLs are accessible official pages within the current site. Missing any one of these gives the search system reason not to display the chain you’ve written.

Unclear website hierarchy

Once the website hierarchy is messed up, the worst result is “can’t find the parent level, can’t understand where you are, can’t return to related pages.” Google states that breadcrumbs indicate a page’s position within the site’s hierarchy; URLs should also be as simple and understandable as possible; internal links affect crawling and relevance understanding. If the same page is attached under 2 to 4 paths, and the three sets of information—URL, navigation, and structured data—are inconsistent, Google often has more difficulty consistently displaying Breadcrumbs.

Cross-reference with Whole Site Information

Many pages already have BreadcrumbList implemented, and Rich Results Test passes, but breadcrumbs still don’t show in search results, or display inconsistently. The reason is often not in that piece of code itself, but in conflicting hierarchical signals across the entire site. Google’s explanation of breadcrumbs is clear: they indicate the page’s position in the site hierarchy, and users can navigate back to parent pages level by level along the path. Code is only part of the solution—visible page content, URLs, internal links, and category page relationships all communicate the same thing.

Google’s documentation on structured data is also clear: markup helps search engines understand page content, and visible content should remain consistent with the markup. If a page shows Home > Blog > Technical SEO but JSON-LD says Home > Resources > Search, the visible display and markup are saying two different things, and search engines receive two different hierarchical explanations. Even with 100% correct syntax, display may still be unstable.

“A breadcrumb trail on a page indicates the page’s position in the site hierarchy.” This Google statement is short, but it refers to site hierarchy, not a standalone script.

Let’s first look at the most common sources of conflict. A product page may simultaneously appear in 4 listing categories: Laptops, New Arrivals, Student Deals, Spring Sale; a documentation page may be accessible from 3 entry points: Docs, Help Center, AdminThere can be multiple entry points, but the parent should not keep changing. If users entering the same page from different entry points see different breadcrumbs each time, page ownership keeps shifting, and search engines have a harder time determining which path is the primary one. Google documentation provides examples of multiple breadcrumb trails, but the premise is that it must be authentic, visible, and consistent with the page relationship, not arbitrarily patching together code to fill a gap. The premise is that it must be authentic, visible, and consistent with the page relationship, not arbitrarily patching together code to fill a gap.

Moving further down, URLs are also site-level signals. Google’s URL structure documentation recommends that sites use simple, descriptive, human-readable URLs. If a page belongs in guides/technical-seo/ but the URL has long stayed at /resources/item?id=4839, users have a hard time judging its level from the URL alone, and search engines can’t get clear directory relationships. When 2 out of 3 of template, navigation, and URL don’t match, the page’s sense of position weakens.

Internal links continue to amplify this problem. Google explains that links serve both for page discovery and as relevance signals. If 60% of entry points within the site treat a page as a tutorial while 40% treat it as a case study, anchor text, context, and parent page relationships get mixed signals. A page that should only have 1 primary path ends up being described as having 2 to 3 different identities across the site. In this case, even perfectly correct Breadcrumb code is just compensating for already-forked site information.

You can condense the signals Google cross-references into a table to make troubleshooting easier:

Each row in this table is not extra decoration, but rather a testimony to the page’s position. If 3 out of 5 rows don’t match, search engines see conflict, not hierarchy.

Many teams fix schema first, then look at site structure—the order is often reversed. A more stable approach is to first check whether the page has a fixed primary ownership, then decide how to write BreadcrumbList. You can examine using these 2 groups:

• Page-level Checks

  • Does each page have only 1 primary parent

  • Does navigating to the parent page show 5+ sibling child pages

  • Do the current page title, URL, and breadcrumbs describe the same relationship

  • Is the page treated as a direct child by multiple top-level sections simultaneously

• Site-level Checks

  • Are parallel section names clearly bounded

  • Do similar templates consistently output the same path

  • Do old URLs, breadcrumbs, and links remain after directory migrations

  • Do XML sitemap, navigation, and body links all point the page to the same collection page type

When only looking at code, you can’t see the Group 2 issues; whereas Google, when crawling and understanding pages, encounters both Group 1 and Group 2 issues simultaneously.

There’s a very common site phenomenon: visible breadcrumbs look beautiful, but the parent page has no browsing value. For example, Home > Blog > SEO > Canonical Tags, but after clicking back to SEO, the page only has 4 old articles, with no filtering, no pagination, no related articles. Users treat this level as an empty shell page, and search engines also have difficulty treating it as a stable parent collection page. If the parent page lacks real content support, the breadcrumb path loses another layer of on-site evidence.

These issues are more likely to occur on large sites, especially those that have undergone 2+ content migrations. One redesign changed Blog to Learn, the next redesign split Learn into Guides and Insights, old article URLs weren’t fully migrated, templates weren’t unified, and old anchor texts remain in body content. The result is that a single page of content simultaneously retains ownership clues from 3 different periods. Users just feel “this page seems to have been moved a few times,” while what search engines read is residual historical directory information.

You can use the 30-page sampling method to quickly identify problems. Sample 30 deep pages, recording 6 items: URL, visible breadcrumbs, JSON-LD, main navigation ownership, body internal link sources, and parent page content quantity. If 8+ pages show 2 inconsistencies, the site’s hierarchical signals have already drifted apart; if 5+ pages show 3 inconsistencies, consolidate the site structure first—this is more useful than continuing to patch code. A 30-page sample isn’t large, but it’s enough to see whether templates are unified.

On mobile, you need to check one more time. In January 2025, Google began generally no longer displaying URL breadcrumb paths in mobile search results—only the domain name displays; desktop may still show hierarchical paths. With one less layer of external position hints in mobile results, the site’s own path needs to be even clearer. If the mobile template also hides breadcrumbs, users entering a deep page from search results will rely almost entirely on the page header and content context for their sense of location.

These situations below most easily lead people to think “the code has a problem,” when in reality it’s site information that hasn’t aligned:

• Rich Results Test passes, but SERP is unstable

  • Common cause: visible display and JSON-LD don’t match

  • Or the parent page itself lacks clear section support

• Breadcrumbs sometimes display, sometimes don’t

  • Common cause: page parent relationships aren’t fixed under the same template

  • Internal links send similar pages to two different collection pages

• Old paths still appear in search results

  • Common cause: historical URLs, historical anchor text, old template remnants

  • More common when page has been migrated 1+ times

Condensing the execution level further makes it easier to implement:

• Prioritize Unifying 4 Locations

  • Visible breadcrumbs

  • JSON-LD

  • URL pattern

  • On-site primary entry links

• Prioritize Removing 3 Types of Interference

  • Empty directories with only 3-4 child pages

  • Directories that differ from adjacent sections by only synonyms

  • Old paths still heavily linked from internal links after migration

• Prioritize Checking 3 Types of Pages

  • Deep product pages

  • Documentation pages

  • Help center pages

These 3 types of pages most depend on “who the parent is,” and are most likely to have path conflicts left over from template reuse and historical migrations.

There’s one more point often overlooked: structured data is not a display guarantee. Google’s structured data documentation says “helps Google understand content” and “eligible for rich results,” not “will display if written.” A page marked as understandable doesn’t mean search results will definitely use that breadcrumb. If other site signals are more chaotic, display may be suppressed or rewritten.

So when handling these types of issues, the mindset is better shifted from “is my code wrong” to “is the whole site telling the same path.” When URLs, visible breadcrumbs, internal links, parent pages, and main navigation all point the page to the same level, the Breadcrumb code is supplementing the explanation; if the previous items each say something different, no matter how tidy the code is, it’s just writing the conflict more formally.

Less Ambiguity

When users enter a deep page, they first look not at the code, but at “where am I now, what was above me, and where will I go if I go up one more level.” Google’s definition of Breadcrumb also centers on this: it represents the page’s position in the site’s hierarchy, allowing users to navigate back up the path level by level. If a page is attached to 3 paths, with navigation written one way, URLs written another, and structured data written yet another, users read 3 versions of position information, and search engines also read 3 versions.

A common mistake on sites is not having too few levels, but too many level labels with boundaries that are too close together. A content center that simultaneously includes Guides, Resources, Learn, and Insights can be distinguished by internal teams, but external users often need an extra 5 to 10 seconds to determine the differences. Nielsen Norman Group has long focused on whether labels match user language and whether classifications align with how users group content as key information architecture evaluation criteria; in user research, card sorting is commonly used to verify whether section names match user understanding rather than internal team terminology.

A single page having multiple parent pages is common in retail, SaaS, and documentation sites. From an operational perspective, it can simultaneously go into New Arrivals, Laptops, Student Deals; from the user’s perspective, these 3 entry points are not 3 levels, but 3 types of affiliation. Google Docs allows multiple breadcrumb trails, but only on the premise that paths are authentic, clear, and visible to users. If a page template supports multiple paths, the frontend should still display 1 main path, otherwise the same page today looks like it belongs to A when entering from A, and tomorrow looks like it belongs to B when entering from B.

Here’s a look at the 6 positions on a page that most easily conflict with each other:

• Main header navigation

• Breadcrumb text

• URL path

• Section term in H1 heading

• Related recommendations module

• JSON-LD BreadcrumbList

As long as 2 of these positions are inconsistent, users will hesitate when returning to the previous level; when 3 positions are inconsistent, the sense of path is usually already scattered. Google also recommends that URLs use a simple, understandable, and logical structure, providing the same hierarchical cues to users and search engines.

Going further, ambiguity often comes from “middle layers being too thin.” Many websites stretch their hierarchy to 5 or 6 levels, looking complete on the surface, but in reality the intermediate pages only have 3 to 4 sub-pages, or are even just transitional directories. When users click back to the previous level, they see a collection page with little content, weak filtering, and insufficient context; dwell time is usually very short. More levels aren’t always better; once pages exceed 4 to 5 levels, reading paths lengthen, and label differences may not be large enough to offset the increased comprehension cost.

Baymard Institute provided a very useful ratio in e-commerce usability research: 20% of desktop sites don’t have breadcrumbs on product pages, and on mobile the percentage without product page breadcrumbs reaches 65%; additionally, 36% of e-commerce sites don’t provide complete category paths. If users land on a deep product page from external search results, ads, emails, or social platforms, without a complete path they have difficulty determining which category the page belongs to, and it’s not easy to return to the same category listing to continue browsing.

When page affiliation is ambiguous, the first impact is usually not on homepage traffic, but on deep access pages. External entry points bring users to /blog/technical-seo/breadcrumb-guide, but the header highlights Resources, breadcrumbs are written as Home > Learn > Search, and related recommendations are all Case Studies; users will spend an extra 2 to 3 steps confirming whether this page belongs to the blog, learning center, or case library. Every additional judgment reduces the willingness to return to listings, continue browsing, and click adjacent content.

A more reliable approach is to keep only 1 main affiliation path for each type of page, and allow it to appear in multiple entry points—but entry points are not the same as parent pages.

• Product pages: 1 main category, 2 to 3 auxiliary collection pages

• Article pages: 1 main section, 0 to 2 topic aggregation pages

• Documentation pages: 1 documentation tree path, other modules only serve as recommendation entry points

• Help pages: 1 help center category, related questions module does not change parent-child relationships

With this approach, users see the same main path regardless of entry point; search engine crawl signals for hierarchy are also more stable.

Section naming should also be compressed to a range users can distinguish at a glance. Among 4 parallel sections, each name should be able to explain its difference within 2 seconds. For example, the boundaries between Docs, Blog, Guides, and Case Studies are usually easier to distinguish than Resources, Learn, Insights, and Knowledge. The problem with the latter isn’t length, but semantic overlap. When users categorize, if more than 3 out of 8 test participants put the same piece of content in different sections, the section names need to be changed.

You can check by the following 3 groups, which is faster than page-by-page review:

• Page Relationships

  • Does each page have 1 main parent

  • Are breadcrumbs stable at 2 to 4 levels

  • Can the previous level page genuinely accommodate the current page

  • Is the current page stuffed into multiple top-level sections

• Naming Relationships

  • Can parallel section names be distinguished at a glance

  • Does the same term repeatedly transform across navigation, URL, and H1

  • Do labels use internal team terminology

  • Is content overlap rate between two sections over 30%

• Template Relationships

  • Are frontend breadcrumbs 100% consistent with JSON-LD

  • Are URLs consistent with the main path

  • Are related recommendation modules distorting page type

  • Is mobile deleting the complete path

Content overlap rate is a very useful detail here. If 15 or more out of 50 consecutive articles can “reasonably” be placed in two parallel sections, the section boundaries are usually already blurry; if 20 or more out of 50 products are both like Accessories and like Tools, the section definitions also need rewriting.

Mobile requires an additional check. Starting January 2025, Google no longer broadly displays URL breadcrumb paths in mobile search results, only showing the domain name; desktop may still display hierarchical paths. When users enter a page from search results on their phone, the location cues provided by external result pages decrease, making the in-site path even more important. If the mobile template removes breadcrumbs and only leaves a back arrow, users see only “back to previous page” instead of “back to previous category level.”

When consolidating, you can prioritize removing 3 types of intermediate layers:

• Empty directory pages with fewer than 5 sub-pages

• Directory pages whose name differs from the parent level by only a synonym

• Transition pages with virtually no independent entry traffic in 90 days

After deletion, unify the remaining levels across 4 places:

• Visible breadcrumbs

• URL

• In-site main entry links

• Structured data

Keeping 4 positions consistent in their wording makes the path more stable for users and the hierarchy more coherent for Google. Structured data itself only helps search engines understand page content; if the visible frontend information is chaotic, markup alone can hardly compensate long-term.

Here’s a more actionable approach. Sample 30 deep pages, recording 6 items: main parent, URL, breadcrumb, H1, related recommendation category, and mobile display. If 9 or more pages show 2 inconsistent items, or 5 or more pages show 3 inconsistent items, don’t add new levels—first consolidate the old paths.

Page not fully crawled or indexed

You have added BreadcrumbList, but Google first needs to get a crawlable, renderable, indexable version of the page before considering using it in search results. As long as the page falls under “Discovered – currently not indexed”, “Crawled – currently not indexed”, or Google chose a different canonical URL, breadcrumbs may not display; Submitting a sitemap or passing Rich Results Test does not equal being indexed or displayed.

What state does Google consider the page to be in

Don’t look at the Breadcrumb JSON-LD first, and don’t look at the rich results test yet. First look at these 4 fields in URL Inspection in Search Console: Indexing, Page fetch, Google-selected canonical, Last crawl time. Google has separately listed this group of information not for the sake of nice formatting, but because they correspond to 4 different stages: discovering the URL, crawling the page, determining the canonical version, and deciding whether to include it in the index. As long as one stage fails, breadcrumbs may not appear in search results.

The first mistake many sites make here is treating “Google knows about this URL” as “Google can consistently display this URL”. These are not the same thing. Google is very clear in the crawl and index FAQ: Both crawling and indexing take time and are affected by multiple factors, with no guarantees. This is also why you submitted 500 URLs in a sitemap, and 48 hours later only some may have entered the index while others remain in “Discovered – currently not indexed”. This status means Google has found the URL but hasn’t started effective crawling yet.

Next, look at “Crawled – currently not indexed”. This status is even easier to misunderstand because the page has already been crawled, looking like “one step away from going live”. Google’s explanation of crawling budget for large sites provides a more accurate framework: Not every crawled page will be indexed; after crawling, it still needs evaluation, consolidation, and suitability judgment.

In other words, Google having read your page doesn’t mean it’s willing to put this version into the main index. For breadcrumbs, the consequence is this: Google may have read your BreadcrumbList, but since the page itself hasn’t entered the available index, it still won’t be used in SERPs.

Going further, look at “Google-selected canonical”. This is often more informative than index status. Google’s documentation on canonical is very explicit: Search results typically point to the canonical page; even if you wrote rel="canonical" yourself, Google may choose another URL based on content quality, duplication level, or inconsistent signals. So you check https://example.com/blog/breadcrumbs-guide/, but what Google actually adopts is https://example.com/resources/breadcrumbs-guide/, or a version with a trailing slash, fewer parameters, and shorter path.

The table below is suitable for reading alongside the statuses in Search Console, no need to rely on intuition anymore:

The most easily overlooked item in the table is Rich results. URL Inspection does display rich results analysis, but it’s only one layer of “what identifiable markup the page contains”. Google separates index status and rich results analysis in their public documentation for a simple reason: the former answers “can the page enter Google’s search system”, while the latter only answers “can the markup be parsed”. When you see Breadcrumb as valid in the tool, it only confirms there are no obvious syntax issues; it cannot replace “URL is on Google”.

Then look at “Last crawl time”. This field is not decorative information. Suppose you fixed the canonical on March 1, changed the server response code on March 2, and changed breadcrumbs from JS injection to server-side output on March 3, but URL Inspection shows Last crawl time is still stuck at February 25, then Google is still seeing the old version. Google is very clear in the “Request recrawl” documentation: URL Inspection can request recrawl, but there are submission quotas, and submitting the same URL multiple times won’t make it crawl faster.

After time, look at “Page fetch”. Google Search Console documentation lists it separately because crawling success depends not just on whether the homepage can load, but also on whether Google gets a complete page. There are 4 common problems here: HTTP not 200, intermittent timeouts, overly long redirect chains, and blocked resources.

Google’s explanation of redirects mentions that 301, 302, meta refresh, and JavaScript redirects all become part of the canonical signal; you think both users and search engines have reached the same page, but Google may actually evaluate the redirect destination as the main version. As long as the path is rewritten, the breadcrumb path will also change accordingly.

Taking one step further, site structure also changes what you see in URL Inspection. Google repeatedly emphasizes in the crawling and indexing documentation that both “discovering content” and “parsing content” depend on how the site exposes pages to Google. For a directory site with 50,000 URLs, if it only submits sitemaps without stable internal links, Google’s speed of discovering URLs and crawling priority will be affected; conversely, a site with only 300 articles where each article gets 3 to 8 internal links from category pages and related article modules will usually enter the crawling queue more smoothly.

You don’t need to guess the algorithm details here; you just need to check whether the statuses of 50 URLs in the same directory are consistent in Search Console: if 35 out of 50 are stuck at “Discovered – currently not indexed”, the problem is mostly not with breadcrumb code, but with page discovery and crawl allocation.

Adding another layer of judgment: don’t just check a single URL, sample a group of URLs. A more reliable approach is to sample 10 to 20 from the same type of page, such as all article pages or all product pages, and record 5 fields: Indexing, Last crawl, User-declared canonical, Google-selected canonical, Page fetch. You’ll quickly see patterns. If 9 out of 12 pages have “Google-selected canonical” pointing to category pages, it means Google doesn’t view this batch of pages as independent results; if 11 out of 15 pages are “Crawled – currently not indexed”, it means crawling has occurred but page uniqueness or signal consistency isn’t sufficient.

Another common misconception is treating sitemap submission rate as indexing rate. Google’s FAQ has clearly stated that submitting a sitemap does not guarantee all URLs will be crawled or indexed.

Sitemaps are more like “notification entry points”, not “indexing commands”. If a sitemap contains 2,000 URLs but only 620 are in a valid index state in Page Indexing, the remaining large number of URLs may still be in discovered, crawled-not-indexed, duplicate, or excluded states. For Breadcrumbs, presence in the sitemap almost cannot replace the index verdict from URL Inspection. What you really need to see is whether Google currently treats this page as an “available indexed page”, “candidate duplicate page”, or “URL not yet entered into the indexing process”.

The troubleshooting sequence can be compressed into a list for easy reference:

• First look at Indexing verdict: is it URL is on Google.

• Then look at Google-selected canonical: is it the URL you want it to rank.

• Then look at Last crawl time: is Google still seeing an old version.

• Then look at Page fetch / robots / noindex: are there access or indexing restrictions.

• Finally, look at whether breadcrumb markup and page hierarchy are consistent.

If you’re on a content team working with developers, you can set clearer thresholds: only when a URL simultaneously meets 200 successful crawl, no noindex, Google-selected canonical is the current page, Indexing verdict is on Google, Last crawl is updated after the revision is it worth continuing to check breadcrumb display issues. If any of the previous items don’t meet the criteria, fix the page status first. This approach to troubleshooting saves a lot of time and avoids misdiagnosing “Google doesn’t treat this page as a formal indexed page” as “breadcrumbs code wasn’t written well”.

Which Version Does Google Catch

The problem with many sites is not “whether there’s a breadcrumb on the page.” For the same URL, what users see in the browser is the page after client-side rendering is complete; what Google often gets first is the raw HTML, and then it decides whether to enter the rendering process. Google documents separate crawling, rendering, and indexing into independent stages, and the reason is very practical: HTML, rendered DOM, canonical, redirects, and structured data may provide different signals at different stages.

Let’s look at the most common type first: the above-the-fold content returns a simplified HTML, with the navigation chain and Breadcrumb JSON-LD inserted by the frontend script 1–3 seconds later. Users can see the complete path when refreshing the page, and developers can also see it in the browser Elements panel, but Google doesn’t always get the same result. What Google’s documentation says about JavaScript-generated structured data is clear: you can generate structured data using JavaScript, but pay attention to rendering and implementation methods. Another document adds that rendering may fail, especially when relying on script redirects or post-injection.

What you “see” on the page doesn’t mean Google “gets” it during the first crawl.
The breadcrumb appears in the browser at 2 seconds, which doesn’t prove Google already read it at the raw HTML stage.

This leads to the second issue: canonical is inconsistent before and after rendering. Google has updated related documentation in recent months, with clearer wording than before: if the site uses client-side rendering, canonical information should be as clear as possible; it’s best to put canonical in the HTML source code, and don’t let JavaScript modify it. Google also added that if you can’t write canonical in the raw HTML, it’s better to only set it with JavaScript once, rather than having “two sets” before and after.

This table best explains why “the version you see” and “the version Google uses” diverge:

The third row in the table deserves the most attention. Google has said in the canonical documentation that it considers multiple signals when selecting canonical; even if you explicitly specify one version, Google may choose another due to content quality or consistency issues. When troubleshooting breadcrumbs, if the page URL, canonical in head, and rendered canonical have more than 2 inconsistencies, the site hierarchy Google reads can easily diverge from what you see on the frontend.

Then there’s redirects. Many sites write URL handling logic in the frontend: after opening /product/blue-shoes, the script then checks inventory, language, or country, and subsequently redirects to another address. Google’s explanation of JS redirects is straightforward: only use JavaScript redirects when server-side or meta refresh redirects are not possible; and while Google will try to render every URL it crawls, rendering may fail. This means that even if users can consistently reach the target page, it doesn’t mean Google necessarily sees the same redirect chain.

If the server returns a 200 for A,
JavaScript sends the user to B at 800 milliseconds,
Google may only process A, and is not obligated to always follow the script to B.

Going a bit further, resource fetching can also change what Google reads on the page. Many people think robots.txt only affects “whether a page can be crawled,” but resource files count too. Suppose your breadcrumb DOM depends on app.js, category paths depend on taxonomy.json, and CSS determines which navigation nodes are displayed. If one of these resources is blocked by robots.txt, the user end can still display normally through caching or other request paths, but Google may only get half the navigation structure.

Beyond resource blocking, there’s also the problem of “raw HTML being too empty.” Many JavaScript sites have only a single div id="app" in the initial HTML, with body content, categories, internal links, and breadcrumbs all generated only after the script runs. Google’s documentation on dynamic rendering is clear: dynamic rendering is only a temporary alternative, not a long-term solution; SSR, static rendering, or hydration are more recommended. The reason behind this is very practical—the less content in the raw HTML, the less information Google has in the early stages to determine the page’s topic, hierarchy, and duplicate relationships.

You can break down the sources of “version deviation” into a list to save time during troubleshooting:

• Breadcrumb not in raw HTML, only after rendering

• Canonical differs between HTML and after rendering

• Page returns 200, but script redirects user to another URL

• Parameter URL, trailing slash URL, and case URL coexist

• Resources blocked by robots.txt or permission settings

• Internal links point to A, canonical points to B, sitemap submits C

You’ll notice that many of these issues are not related to the breadcrumb code itself, but to ununified “version management” of the page. Google’s Breadcrumb documentation states that Breadcrumb represents the page’s position in the site hierarchy; the premise is that Google first confirms “which page this is, which canonical version it belongs to, and whether the path is stable.” If it sees a parameterized page, a page before redirect, a page with failed rendering, or a page demoted to a duplicate in a duplicate cluster, the path displayed in the SERP will likely not be the one you wrote in the JSON-LD.

Here’s a more practical example. A certain blog article has 4 accessible addresses:

For users, all 4 addresses can display the article content normally. For Google, these 4 addresses form a set of duplicate pages, and it needs to select one canonical first. Google’s documentation has explained that canonicalization is the process of “selecting a representative page from a group of duplicate pages.” Since it’s “selecting a representative page first,” breadcrumb display will naturally revolve around the representative page, not around each duplicate version separately.

In a group of duplicate pages, users can read the content by opening any 1.
Google only wants to remember 1 version in its index.
No matter how complete you write it on other duplicate pages, there’s no guarantee it will be used as the basis for SERP display.

Another point that’s easy to overlook: seeing “URL is on Google” in Search Console doesn’t mean Google is using the version you just modified. Google’s documentation on recrawling states that URL Inspection can request a recrawl, but it’s suitable for “a small number of URLs”; site-level updates are better suited for sitemaps. This means that if you changed breadcrumb hierarchy today, canonical tomorrow, and JS rendering logic the day after, Google may still be evaluating the page based on the version it crawled 3 days ago.

As long as Last crawl time hasn’t been updated, the content Google reads may still not be the page you’re seeing in your browser now. The most practical approach for troubleshooting this kind of problem isn’t to repeatedly refresh the rich result test, but to compare three versions of the same URL side by side:

1. The final page users see in the browser

2. The raw HTML in View Source

3. The canonical and crawl time shown in URL Inspection

If versions 1 and 2 are already different, look at version 3; if versions 2 and 3 don’t match, Google will be using yet another set. Breadcrumb display issues are often hidden in these three-layer differences. Google documentation doesn’t call this a complex concept; its approach has always been pragmatic: crawling, rendering, canonical, and structured data are independent of each other, but they influence one another.

Narrowing down the criteria will be more useful. Only when a page simultaneously meets all 5 conditions below is it appropriate to continue pursuing Breadcrumbs display issues:

• Raw HTML already contains a stable canonical

• Breadcrumb is visible in raw HTML or after stable rendering

• No redirects that can only be completed with JS

• Parameterized pages, trailing slash pages, and category alias pages are not competing simultaneously

• The canonical Google uses matches the URL you want to promote

How to troubleshoot this type of problem

Start by sorting them in order. Don’t jump straight to looking at the Breadcrumbs code. First, take 10–20 URLs of the same type from Search Console, and only look at 5 fields: Indexing verdict, Page fetch, Last crawl time, User-declared canonical, Google-selected canonical. Google’s URL Inspection data structure is already split by these fields, which shows they respectively correspond to indexing, crawling, timing, and canonical version—not a single master switch.

If 9 out of 15 article pages show Crawled - currently not indexed, don’t investigate breadcrumb hierarchy first.
If 7 out of 12 product pages have Google-selected canonical that’s not the current URL, don’t investigate JSON-LD first.

In the first round of investigation, only classify, don’t modify pages. Divide URLs into 4 groups based on status: URL is on Google, Discovered - currently not indexed, Crawled - currently not indexed, Duplicate / Google chose different canonical. Google’s official FAQ makes it clear: submitting a sitemap, publishing new pages, or making crawl requests do not guarantee when crawling or indexing will happen, so first understand the status distribution—this is more effective than guessing the cause for individual pages.

You can use the table below to log this, and you can spot the patterns in just 5 minutes:

If more than 30% of a specific page type fall into the same abnormal status, investigate based on that status category going forward—don’t mix all 4 types of problems together. You’re looking at distribution here, not individual page exceptions.

Next, look at Last crawl time. This field is easy to skip, but it determines whether Google sees the old or new version. Suppose you changed the canonical on March 10, and then changed breadcrumbs from JS injection to server-side rendering on March 11, but the URL Inspection shows the last crawl time is still March 4—then Google is still processing the old page. Google’s documentation on recrawling also states that resubmitting crawl requests only applies to a small number of URLs, and submitting multiple times won’t make crawling faster.

You changed the page code twice, but the Last crawl time hasn’t changed—don’t discuss “why hasn’t it updated yet” at this point.
Google hasn’t re-seen the page, so its performance in Search won’t sync with your local page.

Then look at Page fetch. Here there are only two ways to understand it: either the complete page was fetched, or it wasn’t. The issue isn’t just “the page loads.” Just because a user’s browser can open it doesn’t mean Google fetched the same version. What you need to check: whether the HTTP response code is 200, whether it first goes through 301/302, whether there’s a meta refresh, and whether resources are blocked by robots.txt.

The following list can be handed to developers or ops for verification:

• HTML response code: 200

• Non-canonical URL to canonical URL: 1 redirect 301

• Don’t keep multiple redirects long-term: e.g., http -> www -> https -> slash

• robots.txt should not block CSS/JS that breadcrumbs depend on

• Page should not change canonical on the client side

• Don’t host the same content on more than 2 stable, accessible URLs

Moving on to canonicals. Don’t just focus on User-declared canonical—also look at Google-selected canonical. Google’s documentation makes it very clear: even if you declare a canonical, Google may still choose another version due to content quality, duplication, or inconsistent signals. When investigating, compare at least 3 sets of URLs: the page URL, the declared canonical, and Google’s selected canonical. As long as two of these three differ, the Breadcrumbs display path may not match the hierarchy in your page.

If you see “Google chose different canonical,” don’t just change the tag. Check internal links first. Google’s documentation on duplicate URLs mentions that internal links themselves are one of the canonical signals. If a page links to A in the menu, B in the body content, and C is submitted in the sitemap, Google has no reason to trust only the one canonical in your head tag. When investigating, consolidating links to one version within the same template usually works more reliably than just changing the tag.

The canonical tag is like a “declaration”; internal links, redirects, sitemaps, and HTTPS versions are more like “continuously appearing signals”.
When 4 types of signals contradict each other, Google will choose its own version.

Next, look back at Discovered - currently not indexed. For this type of page, the issue is often not “low quality” but that the URL was found but crawling hasn’t reached it yet, or the internal signals are too weak. Google’s FAQ doesn’t give a fixed number of days as a promise, nor does it say sitemap submission will be processed within a few hours. In practice, check 3 things: whether this URL is in the sitemap, whether there are at least 2–3 internal links pointing to it, and whether it’s flooded in with a batch of parameterized pages. If new pages increase by hundreds or thousands at once, it’s common for Google’s crawl queue to slow down.

When troubleshooting this type, don’t fix the body content first—check the entry points:

• Does it appear in the XML sitemap

• Is the sitemap’s lastmod updated

• Can the page be discovered from category pages, related articles, or site search results

• Are there parameter pages like ?sort=, ?ref=, or ?color= flooding the crawl queue

• Are new pages only existing in the backend or as orphaned landing pages with no internal link entry points

Next, look at Crawled - currently not indexed. This type is more troublesome than discovered, because Google has already read the page but didn’t include it in the index. Don’t stop investigating at vague statements like “the content isn’t good enough”—look at whether the page type is highly templated. For example, if 20 product pages all have body text of only 80–120 words, with spec table similarity exceeding 70%, and the only variation is color or size, Google can easily treat them as low-differentiation pages. Even with a complete BreadcrumbList, the page itself may not enter the main index.

Here’s a simple checklist for this—no need for complex tools:

Only when you reach this point do you look at Breadcrumbs themselves. Keep the investigation simple—only do 3 sets of comparisons: visible navigation on the page, Breadcrumb markup in HTML/rendered source code, and Google’s final canonical URL. If any of these three don’t match, the SERP may not show the hierarchy you provided. Google’s documentation on Breadcrumb structured data says it “helps Google understand the page’s position in the site hierarchy,” not “if you write it, it will display.”

Visible navigation shows Home > Blog > SEO,
JSON-LD shows Home > Resources > Technical SEO,
but Google’s canonical is /guides/seo/....
With this combination, unstable paths in SERPs are common.

Write your investigation results into a one-page table—don’t just stop at verbal assessments. For each URL, record 8 items is sufficient: page type, status, last crawl time, declared canonical, Google canonical, response code, internal link count, and whether breadcrumbs are consistent. If you sample 20 URLs, you can usually spot where problems cluster in under 30 minutes. As long as you can see concentrated distribution in a column, the action order becomes clear: first fix indexing status, then fix canonical, then fix crawl completeness, and only look at Breadcrumb markup last.