Do Breadcrumbs Earn Their Space on a Deep Site?

Do breadcrumbs earn their space on a deep site?

On a genuinely deep site, yes. On the five page marketing site where most of them appear, no. The deciding factor is whether a visitor can arrive at a page without knowing where it sits, and on a site with three levels of hierarchy and a thousand items, that happens constantly.

Breadcrumbs answer a different question from the one people think they answer. They are not a back button and they are not navigation. They are an orientation device, and orientation is only valuable when somebody is disoriented.

I bring this up because breadcrumbs are one of those patterns that get added by default, occupy a strip across the top of every template, and never get evaluated again. Anything on every page deserves the question of whether it is doing work.

What is a breadcrumb actually for?

Telling a visitor where they landed. Google's own documentation puts it plainly: a breadcrumb trail on a page indicates the page's position in the site hierarchy, and it may help users understand and explore a site effectively.

Notice the framing. Position, then exploration. That order matters, because the value of the trail is mostly in the first word. Somebody arriving from search on a deep article has no idea what surrounds it, and a single line of text can convert a page that appeared out of nowhere into a page that clearly belongs somewhere.

The exploration part is real but secondary. Most people will not click the breadcrumb. They will read it and form a mental model of your site, which changes how they interpret everything else on the page, including whether you seem like a serious operation.

When do breadcrumbs stop being worth the pixels?

When the hierarchy is one level deep. If every page on your site is a direct child of the homepage, the breadcrumb says home and then the page name, which is information the visitor already has from the navigation and the heading.

That is the version I would delete. It costs vertical space above the fold, it adds a row of small grey text that competes with the actual heading, and it communicates nothing. A pattern that carries no information is not neutral, it is noise with a maintenance cost.

The threshold I use is two real levels below the root plus enough items that a visitor could plausibly arrive without context. A blog with categories and hundreds of posts clears that easily. A services page and an about page do not.

What does Google do with breadcrumb markup?

It reads BreadcrumbList structured data, and the requirements are small. Google's documentation says BreadcrumbList requires itemListElement, an array of ListItem objects, and that each ListItem requires position, an integer indicating the breadcrumb's order, name, the displayed title text, and item, the URL, which is not required for the final item.

That last detail is the one people trip on. The final item does not need a URL, which matches how the pattern works visually, where the current page is shown but is not a link. The markup and the design agree, which is not always the case with structured data.

I would be careful about promising what this looks like in search results. Rich result presentation changes, and I have not fetched a current statement about display, so I am not going to describe one. Implement it because the hierarchy is real, not because you have been promised a particular appearance.

What if a page belongs in more than one place?

Then say so, because the specification allows it. Google's documentation states that if there are multiple ways to navigate to a page on your site, you can specify multiple breadcrumb trails for a single page, and illustrates it with a books example reachable through two different category paths.

This is genuinely useful on a content site, where an article often belongs to a topic and to a format at the same time. A tutorial about schema markup sits under tutorials and under technical SEO, and both are true.

Visually, though, I would still show one. Two trails stacked at the top of a page is a design problem pretending to be an information architecture solution. Pick the path that best explains where the reader is, show that one, and let the markup carry the rest if you genuinely need it to.

Where should the breadcrumb sit on the page?

Above the page heading, below the main navigation, in the content column rather than full bleed. That placement reads as belonging to the page rather than to the site chrome, which is correct, because the trail changes per page while the navigation does not.

What I would avoid is putting it below the heading, which is increasingly common and which I think inverts the logic. By the time a reader has processed a large heading they have already decided what the page is. Orientation arriving afterwards is orientation arriving late.

On mobile, keep it and let it truncate from the left rather than wrapping to two lines. A wrapped breadcrumb takes as much vertical space as a small paragraph and earns none of it. If truncation makes it meaningless, that is a signal your hierarchy names are too long, which is a naming problem rather than a layout one.

Should the last item be a link?

No. The last item is the page the visitor is already on, and a link to the current page is a small trap. It looks clickable, it does nothing useful, and it teaches the reader that your links are unreliable.

Style it as plain text, ideally in the same colour as body copy rather than the link colour, and let the preceding items carry the affordance. Google's own requirement that the final item does not need a URL lines up with this, which is a pleasant case of the technical and the visual pointing the same way.

The related convention worth keeping is not linking the item that equals the current category either, when the current page is that category page. Same principle. A breadcrumb should never offer a route to where you already are.

How do you design one that does not look like debris?

Make it quieter than everything around it and give it room. The failure mode is a breadcrumb styled at the same weight as the navigation, which makes the top of every page look like two menus fighting.

Small type, reduced contrast while staying readable, a separator that is not visually louder than the words it separates, and real space between the trail and the heading below it. The trail should be findable when looked for and ignorable when not, which is a harder design brief than it sounds and is mostly achieved by restraint.

Treat it as part of the same family as your other structural aids rather than as a one off. On a long article the breadcrumb and a table of contents are answering neighbouring questions, where am I in the site and where am I in the page, and they should look like they were designed by the same person.

What should you do next?

Count the levels in your hierarchy. If the answer is one, delete the breadcrumb and take the space back. If the answer is two or more and you have enough content that people arrive deep, keep it and check that the markup matches what is on screen.

On that last point, I want to be accurate about what Google requires. The documentation I fetched does not state that breadcrumbs have to be visible on the page, so I am not going to tell you it does. My own position is that you should mark up the trail you actually show, because markup that describes a structure the visitor cannot see is a divergence you will forget about and someone else will inherit.

Then look at the rest of your navigation with the same question, since breadcrumbs are usually a symptom of hierarchy nobody has examined recently. I have written about navigation patterns across mega menus, sticky bars and mobile, and about how click depth behaves on a large blog, and both of those matter more than the trail itself.

If you have a site deep enough that people genuinely get lost and you would like a second opinion on the structure rather than the styling, reach out. That is usually the more interesting conversation anyway.