Breadcrumb Navigation: Hierarchy, Accessibility, and Structured Data
Shusaku Yosa
Breadcrumb navigation shows where a page sits within a website and offers a route to relevant parent pages. A typical trail is Home, a category, and the current page. Design it around a meaningful content hierarchy rather than mechanically copying technical URL directories.
The visible website navigation, BreadcrumbList structured data, and Google's search-result presentation are three separate things to verify. Google removed breadcrumb URL presentation from mobile search results in January 2025, so implementation does not mean a breadcrumb will appear for every searcher or device.
Separate navigation, markup, and search presentation
Layer | Purpose | Verification |
|---|---|---|
Visible website trail | Show position and support navigation | Hierarchy, links, keyboard access, and screen-reader meaning |
BreadcrumbList markup | Describe the hierarchy in machine-readable form | Properties, URLs, order, and consistency with content |
Google search result | Presentation chosen under search conditions | Record device, query, date, and observed appearance |
Google's 23 January 2025 announcement says mobile results show the domain without the breadcrumb while desktop presentation continues. This does not instruct publishers to remove useful navigation from their own websites.
Valid structured data does not guarantee a particular search appearance. If click-through rate changes, review positions, queries, devices, titles, and competing results before attributing the change to breadcrumbs alone.
Design a logical hierarchy
Breadcrumbs supplement menus and site search. Choose parent pages that help a visitor understand the content and find related information. Technical directory names do not have to become visitor-facing category names.
There is no universal rule that a trail must contain three levels or becomes harmful after four. The appropriate depth depends on the website and how people explore it. Do not create empty categories merely to lengthen a trail.
A fictional editorial example
A business publication might place a GA4 setup article under Home, Web Analytics, GA4, and the article. The URL can still sit directly beneath the blog path. The important check is that the named parents are real, available pages that help visitors explore the topic.
Page type | Design approach | Question to test |
|---|---|---|
Single-topic article | Use a meaningful category and current article | Can visitors find related articles from the parent? |
Article spanning categories | Choose a useful primary trail or manage valid alternatives | Does each trail describe a real content relationship? |
Second page of a listing | Preserve the category relationship | Does pagination accidentally appear to be a new category? |
Translated article | Use parents and labels in the same language | Are people unintentionally sent to another language? |
Filtered or search result | Separate stable hierarchy from temporary conditions | Does the parent remain a sensible return destination? |
Google supports multiple appropriate breadcrumb trails for a page. This is not a reason to invent search-only relationships. Use routes that are meaningful and consistent with the content. A manageable primary trail is often a useful starting point.
Map the structured-data fields
Google's BreadcrumbList documentation describes supported formats and required fields. JSON-LD is not the only supported method; Microdata and RDFa are also options. A CMS extension still requires checking the actual generated output.
Field | Meaning | Check |
|---|---|---|
BreadcrumbList | The whole trail | Appropriate hierarchy for this page |
itemListElement | The sequence of entries | Order and count match the intended relationship |
ListItem position | Order in the trail | Integers beginning at one |
ListItem name | The hierarchy label | Understandable wording |
ListItem item | The entry’s URL | Correct available destination; optional for the final entry |
Google requires at least two ListItem entries for this representation. The final entry's URL can be omitted, in which case Google uses the containing page's address. Distinguish a valid optional field from an internal operating rule that always records it.
Labels need to be clear and consistent, not character-for-character copies of page titles. Avoid presenting title differences as an automatic penalty. Align destination addresses with the canonical URL policy.
Check accessibility and small-screen behavior
The W3C breadcrumb accessibility pattern describes a labeled navigation region and an ordered list. When the current page is a link, aria-current identifies it. When it is not a link, that designation is optional.
- Give the navigation a label that distinguishes it from other navigation.
- Make parent links keyboard-accessible with visible focus.
- Avoid unnecessary spoken separator symbols that obscure the labels.
- Test long names, zoom, and smaller screens.
- Distinguish the current location from actionable parent links.
- If intermediate levels collapse, preserve a usable way to access needed parents.
Do not make text extremely small to fit the trail or hide so much that location becomes unclear. Consider wrapping or meaningful shorter labels, then test actual page names. Visual neatness does not establish keyboard or screen-reader usability.
Verify three layers before accepting a release
- On the page, check meaningful hierarchy, working parent links, and understandable current position.
- In generated data, check detection, properties, and agreement with the page's meaning.
- In publication and search, verify destination availability and distinguish test results from observed search appearance.
A rich-results test can help detect supported structured data and errors. Passing it does not guarantee display. If a relevant Search Console report has no row, investigate report conditions and data availability rather than assuming that the markup failed.
A fictional redesign might rename a category in the visible trail while the generated markup still links to its old address. Check the visible labels, generated data, and destination together. Assign the correction to the component that actually creates the inconsistent value.
Troubleshoot recurring problems
Symptom | Inspect | Response |
|---|---|---|
A parent link returns 404 | Category moves, removals, and generated URLs | Update the intended destination and investigate migration rules |
Duplicate trails appear | Theme, plugin, and CMS output | Agree on the managed generator |
Language versions mix | Language-specific categories and URL mapping | Align the trail with the page language |
Markup validates but no breadcrumb appears in search | Device and search-presentation conditions | Check mobile specifications and the absence of a display guarantee |
The hierarchy changes with every filter | Temporary state mixed with stable classification | Review URL and taxonomy rules |
For missing parents, use the 404 restoration and migration guide. For temporary filter values, consult the URL parameter guide. Fixing one trail will not resolve an outdated taxonomy or a generator that repeats the same wrong destination.
A fictional release checklist
Suppose the acceptance set contains Japanese and English versions of article A and their parent categories. The editor checks classification and wording, the implementation owner checks generation, and a reviewer follows the actual links and keyboard route. A Japanese article leading to an English parent can need correction even when its structured-data syntax is valid.
Write acceptance conditions in observable terms: the intended parent opens in each language, current position is understandable, generated data describes the same relationship, and the required screen and interaction conditions remain usable. Record any search appearance separately; it is not a guaranteed release condition. This division helps identify whether a failure concerns content organization, implementation, or navigation.
Maintain the rule when content changes
Record the article URL, parent category, label, structured-data generator, and verification date. Repeat checks when publishing, moving categories, changing URLs, or adding languages. Maintain broader discovery routes with the sitemap workflow and the SEO fundamentals guide.
Assess whether people can understand their position and reach useful parent pages first. For search comparisons, align queries, countries, devices, and periods. Record observations without presenting breadcrumb changes as a guaranteed or isolated cause of ranking and click changes.