Your Breadcrumbs Are Confusing Google’s Site Hierarchy
On this page
- The mechanism: three hierarchies that disagree
- The common trigger: a redesign that kept the old URLs
- Resolution A: align the schema to the indexable URL path
- Resolution B: migrate the URLs to match the hierarchy
- The often-missed step: new parents need real content
- Why this reads as a ranking problem, not just a markup one
- A note on internal links as the third signal
- How to diagnose it
- Sources
- Related posts:
When your BreadcrumbList structured data, your URL path, and your internal-link patterns disagree about a page’s parent, Google receives contradictory signals about where the page sits in your site and may trust none of them. The page becomes hard to place in a topical cluster, which weakens its claim to topic authority and can deprioritize it. The classic trigger is a navigation redesign that reorganized categories visually but left the old URLs in place, so the schema now asserts one hierarchy, the URL implies another, and internal links reference both. Resolve it by making the breadcrumb schema match the actual indexable URL hierarchy, or by migrating the URLs to match the new structure, and then by giving the new parent categories real content.
The mechanism: three hierarchies that disagree
Breadcrumb schema is an explicit claim about a page’s parent chain. Suppose a sofa product page lives at /sofas/, but its JSON-LD BreadcrumbList asserts Home > Living Room Seating > Sofas, while internal links across the site point at both /sofas/ and /living-room-seating/sofas/. Google now has three different stories about where this page belongs: the URL path says one thing, the structured data says another, and the link graph says a third. Faced with conflicting architecture signals, Google does not reliably pick a winner; it can discount the lot, which weakens the topical clustering that helps the page rank for its category and undermines the parent’s authority over its children.
Two clarifications matter here. First, Google does not require breadcrumb markup to mirror the URL folder structure, its guidance is that breadcrumbs should represent a typical user path to the page. But the item URLs inside the BreadcrumbList must be the real, canonical, indexable URLs of each level. The problem is not “schema differs from URL folders” in the abstract; it is schema that points at parent URLs which do not match how the page is actually addressed and linked. Second, this is a consistency problem, not a too-many-links problem and not a hidden-content problem. The signals are not too numerous; they are contradictory.
The common trigger: a redesign that kept the old URLs
Most occurrences trace to the same decision. A team consolidates categories and rebuilds the navigation to reflect the new grouping, but keeps the existing URLs to avoid a migration. The visual nav and the new breadcrumb now describe the new hierarchy, while the URLs and a backlog of internal links still encode the old one. Nothing looks broken in a browser. Under the hood, you have just introduced the three-way contradiction, and the affected pages start drifting because Google can no longer confidently assign them a parent.
Resolution A: align the schema to the indexable URL path
The faster fix is to make the JSON-LD BreadcrumbList item URLs match the indexable, canonical URLs of each level. If the page is addressed at /sofas/, the schema’s parent chain should resolve to URLs that actually exist and are not redirects. Critically, the breadcrumb users see on the page can still display the fuller navigational path, Home > Living Room Seating > Sofas, because users read the visible trail, not the structured data. Visible breadcrumb and JSON-LD breadcrumb are allowed to differ in their display wording, as long as the schema’s item URLs are real indexable URLs. This is the band-aid: it removes the contradiction Google ingests without forcing a URL change.
Resolution B: migrate the URLs to match the hierarchy
The root fix is to make the URLs reflect the new structure: move /sofas/ to /living-room-seating/sofas/, map every old URL to its new one with a 301, update internal links to point at the final URLs (not through the redirect), and watch Search Console daily through the transition. Choose this path when the new structure is permanent and you want the URL, schema, and link graph to tell one consistent story going forward. A migration carries the usual re-crawl turbulence, so it is worth it only when the reorganization is settled.
| Choose | When |
|---|---|
| A: align schema to URLs | The reorganization may still change, or a migration is not justified yet. Lowest risk, fastest. |
| B: migrate URLs | The new hierarchy is permanent and you want URL, schema, and links unified. Higher effort, durable. |
The often-missed step: new parents need real content
Either path can leave you with new parent category pages that are little more than navigation shells. A category page with no substantial unique content is a thin page, and a thin parent cannot anchor a cluster or earn its own rankings. Give each new parent genuinely useful category content, what the category covers, how to choose within it, what distinguishes its subcategories, so it ranks in its own right and lends authority to its children rather than just listing links.
Frame the outcome honestly: a hierarchy conflict usually causes deprioritization and muddied clustering, not direct deindexing, which is a rare outcome. And breadcrumbs themselves are a symptom, not the disease. The disease is an architecture where URL, schema, and links disagree; the breadcrumb is just the most legible place that disagreement surfaces.
Why this reads as a ranking problem, not just a markup one
It is tempting to treat a breadcrumb mismatch as a cosmetic structured-data issue, a warning to clear in a validator. The reason it shows up as drifting rankings instead is that hierarchy is one of the inputs Google uses to understand topical relationships across your site. A clean, consistent parent chain tells Google that this sofa page belongs to a seating category that belongs to a furniture section, and that grouping helps each level borrow relevance from the others and compete for category-level queries. When the signals contradict, Google cannot confidently build that map, so the page loses the contextual lift its cluster would otherwise give it. The page does not necessarily fall out of the index; it competes as an isolated URL rather than as a member of an authoritative group, which is enough to soften its rankings on competitive category terms.
This is also why “just add breadcrumb schema” is the wrong instinct when a page is already underperforming. Adding more markup on top of an existing contradiction adds a fourth voice to an argument Google already cannot resolve. The work is reconciliation, making URL, schema, and links agree, not accumulation.
A note on internal links as the third signal
The internal link graph is the signal teams most often forget to clean up, because it lives in templates, old content, and navigation fragments rather than in one editable schema block. After a category reorganization, internal links commonly point at a mix of old and new URL forms, and every variant that resolves through a redirect or names a non-canonical parent reinforces the contradiction. Whichever resolution you choose, schema alignment or URL migration, finish the job by standardizing internal links to the final canonical URLs so the link graph tells the same story as the schema and the path. A crawler export of all internal links grouped by target makes the stragglers visible.
How to diagnose it
Extract the BreadcrumbList schema across the site with a crawler and diff each page’s asserted parent chain against its actual URL path. Where they disagree, check the internal links to that page and confirm whether they use one canonical URL or several variants. The set of pages where all three diverge is your work list. Standardize internal links to the final, non-redirecting URLs as part of whichever resolution you pick, and re-validate the breadcrumb item URLs to confirm each resolves to a live, canonical, indexable page rather than a redirect.
Sources
- Google Search Central: “Breadcrumb (BreadcrumbList) structured data”: https://developers.google.com/search/docs/appearance/structured-data/breadcrumb
- Schema.org: “BreadcrumbList”: https://schema.org/BreadcrumbList
- Google Search Central: “How Google interprets the URL structure”: https://developers.google.com/search/docs/crawling-indexing/url-structure