Breadcrumbs, Hierarchy, And How A Machine Works Out Where Your Product Actually Sits

Breadcrumbs, Hierarchy, And How A Machine Works Out Where Your Product Actually Sits

Breadcrumbs are the most patronised element in ecommerce. They get treated as a small usability nicety — a little trail near the top of the page, occasionally removed by a designer who thinks they clutter the layout, occasionally left in but styled at 11px in light grey.

I want to make a much bigger claim for them, because I think they’re one of the highest-leverage pieces of markup on a Shopify store and almost nobody treats them that way.

Breadcrumbs are how a machine works out **what kind of thing your product is**.

The problem breadcrumbs actually solve

Put yourself in a crawler’s position. It has fetched a page. The page has a title, some copy, images, a price, a buy button. From that it can extract a great deal — but there’s one thing it struggles with, and it’s the thing that matters most for recommendation: *where does this sit in the world?*

A human looking at your page for two seconds knows instantly that “the Kestrel 32” is a rucksack, that rucksacks are a kind of luggage, that this is the hiking sort not the school sort, and that it belongs to a family of similar products at similar prices. You know that from context, from the photography, from the surrounding page, from your entire life.

A machine has to reconstruct it. Product type helps. Collections help. Copy helps. But breadcrumbs state it explicitly, in order, as a hierarchy: `Home > Outdoor > Backpacks > Hiking Backpacks > Kestrel 32`.

That’s an unambiguous declaration of category membership at four levels of specificity, in machine-readable form, on every page. There is no other element on your site that does this as cleanly.

Why this matters more now than it did

When search was primarily about matching a query to a document, category context was a nice-to-have. The query “hiking backpack” and a page about a hiking backpack matched on words.

Recommendation works differently. When someone asks an assistant for “a hiking backpack around 30 litres for a woman under £150,” the system isn’t matching words to a document. It’s assembling a candidate set of *things of a particular type*, then filtering that set on attributes, then choosing.

To be in the candidate set, you have to be identifiable as a member of the category. Attributes only get evaluated after that. A product with brilliant specification data that a system hasn’t confidently categorised may never reach the point where its specifications are considered — it isn’t ranked lower, it isn’t in the shortlist.

Shopify’s own semantic search works on related concepts and categories, not just literal terms. The category signal you emit is an input to your own site’s search before it’s an input to anything external.

BreadcrumbList, done properly

The markup itself is genuinely simple — it’s one of the easiest structured data types to get right — which makes the fact that most stores get it wrong somewhat annoying.

`BreadcrumbList` is a JSON-LD object containing an ordered array of `ListItem` entries, each with a `position`, a `name` and an `item` URL. Position starts at 1. The final item is the current page.

The rules that matter:

**The trail must match what’s visible.** Structured data describing a hierarchy that isn’t on the page is markup for hidden content. Show the breadcrumbs.

**Positions must be sequential and correct.** Skipped or duplicated positions invalidate the whole object.

**Every intermediate step needs a real, working URL.** A breadcrumb pointing at a category page that 404s or redirects through three hops is worse than no breadcrumb.

**One trail per page.** If a product sits in five collections, pick a canonical trail. Multiple competing `BreadcrumbList` objects is a common Shopify problem — theme emits one, app emits another, they disagree.

Validate it in Google’s Rich Results Test, and validate it on more than one template.

The Shopify-specific mess

Here’s where it gets awkward on this platform specifically, and it’s worth understanding because it explains why so many stores have bad breadcrumbs despite good intentions.

Shopify products don’t live in a hierarchy. They live in collections, and collections are a flat, many-to-many structure. A product can be in “New In”, “Sale”, “Backpacks”, “Under £150” and “Gifts For Him” simultaneously, and none of those is inherently the parent.

So there’s no canonical trail to generate. Themes handle this in various ad hoc ways — most commonly by using whichever collection the visitor arrived through, which produces a *different* breadcrumb trail for the same product depending on the path taken. For a human that’s arguably helpful. For a crawler it’s a product that claims to be four different kinds of thing on four different visits.

The fix is to designate a canonical category per product — usually as a metafield — and generate the breadcrumb from that, consistently, regardless of navigation path. It’s not difficult. It does require deciding, product by product, what the canonical category actually is, which on a large catalogue is the real cost.

Hierarchy beyond the trail

Breadcrumbs are the visible expression of something larger, which is whether your store has a coherent structure at all.

Three things worth auditing alongside:

**Collection depth.** A completely flat structure — 60 collections all hanging off the homepage — gives a machine no information about relatedness. Some hierarchy, even two or three levels, communicates far more.

**Internal linking consistency.** If “Hiking Backpacks” is a real category, it should be linked from “Backpacks”, and products in it should link back. Structure that exists only in your breadcrumb markup and nowhere in your actual link graph is a weaker claim.

**Product type and category fields.** Shopify’s standard product taxonomy exists and is used by Catalog for syndication. Populating it consistently is separate from your collections and frequently neglected.

Together those four — breadcrumb markup, collection hierarchy, internal links, product taxonomy — are the same claim made four times. Agreement between them is what makes the claim credible.

The scale problem, honestly

Everything above is straightforward on one product. On 3,000 it’s a project, and it’s the specific kind of project that gets scoped, agreed, and then never started.

Designating a canonical category per product, populating a metafield, adjusting the theme to generate the trail from it, validating across templates, then re-checking after the next theme update — that’s the work. It’s not intellectually hard. It’s just genuinely long, and it competes with everything else you have to do this quarter.

This is the category of problem GEOptimisation exists for, and I’d rather describe the split plainly than pretend otherwise. The free tier will audit up to 25 pages and show you exactly where your breadcrumb markup is missing, inconsistent, duplicated or pointing at broken URLs. 

That diagnosis is yours, free, and you can absolutely take it away and implement it by hand. The paid tiers exist because the implementation across a full catalogue — breadcrumbs, schema, meta descriptions, product content, applied in bulk rather than one product at a time — is where this work normally dies.

Either way, run the audit. Breadcrumbs are the cheapest categorical signal you can send, and on most Shopify stores they’re currently sending a different answer every time somebody asks.

*Sources: Google structured data documentation (BreadcrumbList); Shopify Help Centre, Search & Discovery and product taxonomy documentation. Verify current requirements at developers.google.com.*