A breadcrumb trail is the row of links that shows where the page you are reading sits in a site's hierarchy, and lets you climb back up one level at a time.
The thing to know before touching it is that the visible row and the BreadcrumbList markup Google reads are two separate objects, with rules that do not match. On the HTTP Archive's global sample, the Web Almanac 2024 found a BreadcrumbList in JSON-LD on 5.66% of pages: one in eighteen.
How a breadcrumb trail is built
Three parts: the parent pages, each with its own link; the separators, which are not clickable; and the current page, which closes the row without being a link. The GOV.UK Design System, the reference for UK government services, places breadcrumbs at the top of the page, before the <main> element, so that the skip link lets users jump past all the navigation, breadcrumbs included. It also takes a different line on the last item: since June 2020 its trail starts at the home page and ends with the parent section, leaving the current page out altogether.
For the separator, Nielsen Norman Group recommends the ">" sign, while noting that there is no functional difference between ">" and "/". It is a convention, not a rule.
The row you see and the markup Google reads follow different rules
This is where almost all implementation mistakes happen. Usability guidelines talk about the on-screen element, Google's documentation talks about structured data, and anyone who reads only one source ends up applying the right rule to the wrong object.
| Element | In the visible breadcrumb | In the BreadcrumbList markup |
|---|---|---|
| Link to the home page | The trail starts from the home page, but if a Home link is already in the global navigation, one of the two is enough (NN/g) | No ListItem is needed for the site's domain or hostname (Google) |
| Current page | Shown but never clickable: a link that goes nowhere is a usability error (GOV.UK leaves it out entirely) | Optional. If you include it you can omit item: Google uses the URL of the page containing the markup |
| Minimum number of items | Makes sense from three levels deep upwards | At least two ListItems, otherwise the BreadcrumbList is not valid |
| Multiple paths | Only one: two parallel trails take up space and confuse | Allowed: several BreadcrumbList objects on the same page |
| Items with no page behind them | Excluded: every item must be somewhere the user can go | Excluded: item requires a URL |
| Order | From the highest level to the lowest | position starts at 1 and continues without gaps |
Multiple paths are the clearest case. Google allows several BreadcrumbList objects on the same page when the page can be reached by different routes, and chooses which one to show based on the query. Nielsen Norman Group advises against showing two to the user and asks you to designate one canonical path. The two recommendations sit together: in the markup you declare both paths, on screen you show one.
The three types of breadcrumb, and which one holds up
| Type | Example | When it holds up |
|---|---|---|
| Hierarchical (or location-based) | Home > Shoes > Hiking > Model | Always, if the site has a real hierarchy. It is the only type that communicates the site structure to whoever scans it as well |
| Attribute-based | Home > Shoes > Women > Size 6 | On filterable catalogues, provided each product has a single primary category. Without one, the same product generates different trails depending on the filter |
| History-based | Home > Article 1 > Article 2 | Never. It duplicates the browser's Back button and changes with every session, so it cannot be declared in the markup |
On the third type Nielsen Norman Group has been explicit for twenty years: the breadcrumb shows the site hierarchy, not the session history. A history trail is useless in exactly the case where breadcrumbs are worth most, when someone lands on a deep page from an external link and has never seen the home page.
Since 23 January 2025 breadcrumbs no longer appear in mobile results
That day Caitlin Dorsey, a product manager on Google Search, announced on the Google Search Central blog that the visible URL in mobile results would be reduced to the domain alone. The reason given: the breadcrumb element is of little use to people searching on mobile, because it gets cut off on smaller screens. The change applies to all languages and regions where Search is available.
On desktop nothing has changed: the visible URL is still made up of domain and breadcrumb. The documentation has absorbed the change and now lists desktop only under feature availability. The markup is still supported, the breadcrumb rich result report in Search Console is still active, and the Rich Results Test still validates it. Google puts it plainly: sites using the markup do not need to do anything.
What has been lost is a portion of the mobile snippet, and with it the context that row gave to people weighing up a result before clicking. The internal links, the hierarchy signal and the orientation within the page are where they were.
BreadcrumbList markup, property by property
The format Google documents first is JSON-LD, and it has to be served in the initial HTML: if the client generates it after load, crawlers that do not execute JavaScript will not see it. The structure requires a BreadcrumbList with at least two ListItems, and each ListItem needs three properties.
position: an integer. Position 1 marks the start of the trail.name: the title of the level, the text the user reads.item: the URL of the page, in absolute form. It can be omitted on the last item, in which case Google uses the URL of the page containing the markup.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [{
"@type": "ListItem",
"position": 1,
"name": "Blog",
"item": "https://www.example.com/blog/"
},{
"@type": "ListItem",
"position": 2,
"name": "Technical SEO",
"item": "https://www.example.com/blog/technical-seo/"
},{
"@type": "ListItem",
"position": 3,
"name": "Breadcrumbs"
}]
}
</script>Two points in the documentation that hardly anyone applies. First: breadcrumbs should represent "a typical user path to a page, instead of mirroring the URL structure". This matters on e-commerce sites, where the URL often carries levels and parameters that mean nothing to a user. Second: you need no ListItem for the domain, so the markup can be shorter than the row you show on screen.
When you do not need breadcrumbs
The GOV.UK Design System recommends them to help users understand and move between the multiple levels of a website, and tells you not to use them on sites with a flat structure. Below that threshold they are decoration. Nielsen Norman Group reaches the same conclusion: on flat hierarchies of one or two levels, or on sites with a linear structure, they are not an orientation tool.
Two more uses to avoid, both flagged by GOV.UK: showing progress through a linear journey or transaction, such as an application or a payment, and adding a trail where other navigation, a sidebar for example, already tells users where they are. Progress through a form has its own patterns.
Then there is a rule that Nielsen Norman Group sets out in black and white and that audits find broken all the time: only pages that exist go in the breadcrumb. If your menu has a grouping label with no page behind it, it stays out of the trail. The markup requires a URL for item, and on screen an element that looks clickable but is not creates more confusion than the missing level.
Accessibility: three attributes and nothing more
The W3C pattern in the ARIA Authoring Practices asks for little: the trail sits inside a navigation landmark, the landmark is labelled with aria-label or aria-labelledby, and the link to the current page carries aria-current="page". If the last item is not a link, aria-current becomes optional.
<nav aria-label="Breadcrumb">
<ol>
<li><a href="/blog/">Blog</a></li>
<li><a href="/blog/technical-seo/">Technical SEO</a></li>
<li><a href="/blog/breadcrumbs/" aria-current="page">Breadcrumbs</a></li>
</ol>
</nav>Keyboard behaviour is the standard one for links: you move through the trail with Tab and Shift-Tab, open a page with Enter, and the separators stay out of the focus order because they are not interactive.
How to enable them on WordPress and how to check them
The most widely used SEO plugins already generate them, JSON-LD included. In Yoast SEO they are under Settings, Advanced, Breadcrumbs (Search Appearance in older versions), where you set the separator, taxonomy hierarchy and home page text; Rank Math and SEOPress have the equivalent. On a theme that does not support them natively, you add the function call to the template, above the title. On other CMSs with no dedicated plugin, you write them by hand.
Checking takes three steps, and all three are worth doing because they test different things. Google's Rich Results Test tells you whether the markup is eligible for rich results. The Schema Markup Validator at validator.schema.org checks syntax against the schema.org vocabulary, including properties Google ignores. The Breadcrumbs report in Search Console shows errors and warnings across every URL on the site, not a single page, and is the only one of the three that surfaces broken templates.
One check none of the three tools does: reread the row on screen and compare it with the JSON-LD. If the visible trail says one thing and the markup another, the signal reaching Google is contradictory, and no validator flags it because each version, taken on its own, is formally correct.
If the breadcrumb is hard to write, the problem is the architecture
The breadcrumb is the only internal link element that generates itself from the site structure: a thousand product pages across twenty categories produce a thousand links to the categories without anyone writing them. That is exactly why it works as a diagnostic tool.
When you cannot write the trail for a page without inventing a level that has no page behind it, or when the same page sits with equal standing in three different paths, the fault is not in the breadcrumb. It is in the hierarchy, and it shows up in the SERPs in less visible ways. In our SEO projects, the first thing we look at on a large site is not whether breadcrumbs are there, but whether they can be written without forcing anything: where they cannot, there is almost always a category problem that no on-page fix will solve.
Frequently asked questions about breadcrumbs
Yes. Since 23 January 2025 Google no longer shows the path in mobile search results, but it still supports the markup for desktop results and the breadcrumb rich result report in Search Console is still active. The main value of breadcrumbs, the internal links to category pages and the signal about the site hierarchy, never depended on the snippet anyway.
On screen, Nielsen Norman Group recommends starting the trail from the home page, and so does the GOV.UK Design System, but NN/g advises against duplicating the Home link in both the global navigation and the breadcrumb: one of the two is enough. In BreadcrumbList markup, Google's documentation states that you do not need a ListItem for the top-level path, meaning the site's domain or hostname.
No. The current page is shown but not made clickable, because a link that reloads the page you are on goes nowhere; the GOV.UK Design System leaves it out of the trail altogether. In the markup the last item is optional: if you include it you can omit the item property, and Google uses the URL of the page containing the markup.
For a BreadcrumbList to be valid, Google requires at least two ListItems. There is no formal upper limit, but the GOV.UK Design System recommends breadcrumbs for sites with multiple levels and advises against them on flat structures: on a flatter hierarchy the trail adds no orientation and takes up space, especially on mobile where it may wrap onto a second line.
They do different jobs. The HTML row orients the reader and creates internal links even without structured data. The BreadcrumbList markup is what makes the page eligible for the path display in desktop results and what feeds the Breadcrumbs report in Search Console: without markup that report stays empty even if the row is on screen.
