What breadcrumbs are

Breadcrumbs are a chain of links showing the path from the site root to the current page:

Home → Shoes → Trainers → Nike Air Max 90

The name comes from the Hansel and Gretel tale, where breadcrumbs marked the way back. The function
is the same: move one level up without the back button and without going through the menu.

In e-commerce the element has two independent jobs, and both are measurable.

The UX job. A large share of traffic arrives from search, from advertising and from
marketplaces directly on a product page. That visitor never walked the catalogue
and has no context: they do not know whether similar models sit nearby, or which section they have
landed in. Breadcrumbs close that gap in one line and offer a short path to the listing, where
alternatives can be compared.

The SEO job. Breadcrumbs are internal linking at scale: each of
thousands of product pages links to its category and to every parent above it. Category pages gain
link weight and a steady flow of crawling, and the robot gets an explicit map of catalogue nesting.

Types of breadcrumbs

Type How it is built Upside Risks
Hierarchical From the catalogue structure: the parent categories of the current page Predictable, cacheable, ideal for internal linking Needs one canonical category for a product that sits in several
Attribute-based From the applied filters: Trainers — Nike — 42 Reflects the real context of the choice, handy in large catalogues Breeds URL combinations; without index control, duplicates and wasted crawl budget
History-based Repeats the visitor’s path through the site Matches in-session navigation exactly Duplicates the back button, useless for search entries, not cacheable, unusable in markup

The default choice for an online store is hierarchical breadcrumbs. Attribute-based trails are
added on top in catalogues with developed faceted search, where filter landing pages are
deliberately promoted in search. History-based trails are rare in practice: they are unpredictable
and deliver neither an SEO effect nor reliable UX.

ℹ

If a product physically sits in several categories, pick one for the breadcrumbs — the same one
named in the canonical URL of the product page. Otherwise a single product
generates several different paths, and the markup starts contradicting the canonical.

BreadcrumbList markup

Search engines understand breadcrumbs only through Schema.org
structured data — a visual chain in the layout is not enough. The
BreadcrumbList markup describes the elements of the path and their order:

BreadcrumbList
├── ListItem position=1 → name: "Home",     item: /
├── ListItem position=2 → name: "Shoes",    item: /shoes/
├── ListItem position=3 → name: "Trainers", item: /shoes/sneakers/
└── ListItem position=4 → name: "Nike Air Max 90"   (current page, no link)

What it buys you: in the results, instead of a long URL such as
site.com/catalog/shoes/sneakers/nike-air-max-90-12345, the engine shows a readable path,
site.com → Shoes → Trainers. That snippet is easier to parse and usually
earns a higher CTR, especially on mobile, where a long URL gets truncated anyway.

Practical requirements for the markup:

  • position runs strictly from the root to the current page, with no gaps.
  • Names in the markup match the visible breadcrumb text.
  • Absolute URLs in item.
  • The markup is present on every page type — product pages, listings and articles, not only
    products.
  • Validation through a structured data testing tool and the search console after release.

Common mistakes

Breadcrumbs duplicate the main menu. If the trail simply repeats top-menu items in the same
form, it adds no information while taking up space. Breadcrumbs should reflect actual page nesting,
including levels that the menu does not contain.

Filter trails breed duplicates. Attribute breadcrumbs generate links to filter combinations.
Every such link is an invitation for the robot to crawl one more page. In a large catalogue that
runs to tens of thousands of URLs, and the crawl budget goes on
combinations instead of new products. The fix: index only the filter combinations that have real
demand, and keep the rest out of both the index and the breadcrumbs.

The trail eats the first screen on mobile. Five levels with long names on a narrow screen turn
into three lines above the heading. The visitor sees navigation instead of the product. The fix is
scrolling without wrapping, or truncating the middle of the path, while the markup stays complete.

Breadcrumbs rendered only in JavaScript. If the trail appears after a script runs and is absent
from the HTML response, part of the link benefit is lost. Breadcrumbs belong in the source HTML.

The last element links to the current page. A useless click for the visitor and a redundant
self-link for the robot.

Implementation checklist

Check Target
Breadcrumbs on product pages, listings and articles Yes, on every page type
Present in the source HTML Yes, not only after JavaScript
BreadcrumbList markup Valid, ordered from the root
Agreement with the canonical URL The path follows the canonical category
The last element Plain text, no link
Behaviour on a 360–390 px screen No more than one line
Indexing of attribute trails Only filter combinations with demand
Tap targets At least 44 px high on mobile

It is also worth watching breadcrumbs in analytics: the share of sessions with a click on the trail,
and the browsing depth after such a click. If breadcrumbs are used noticeably more often than the
menu, that is a signal the catalogue structure reads better from the bottom up — and that the menu
itself should be rebuilt.