Breadcrumbs & Site Architecture for SEOs

We spend a lot of time staring at spreadsheets, obsessing over “Flat vs. Deep” site architecture. We draw neat little pyramids on whiteboards, putting the Homepage at the top and the long-tail products at the bottom. It looks organized and logical.

But the actual web doesn’t look like a pyramid. It looks like a bowl of spaghetti. Links go everywhere. Related posts link to products, products link to policies, and the footer links to everything.

Breadcrumbs are your attempt to impose order on that chaos. They are the visible skeleton of your website.

Graphs vs. Trees

Here is the reality of site architecture – the internet is a Graph. Nodes (pages) are connected to other nodes by edges (links) in a non-hierarchical mesh.

But human brains and search engine spiders prefer Trees. We like parent-child relationships. We want to know that “Running Shoes” lives inside “Footwear,” which lives inside “Men’s.”

Breadcrumbs are the mechanism that forces your messy Graph into a tidy Tree.

The Polyhierarchy Dilemma

Let’s say you sell a “Wireless Gaming Headset.”

• Does it belong in Audio > Headphones?
• Does it belong in Gaming > Accessories?
• Or does it belong in Gifts > Under $100?

In the database, it belongs to all of them. It’s a polyhierarchical entity. But a breadcrumb trail is linear. It can usually only show one path.

Primary Paths

This forces you to make a choice. You have to designate a “Primary Category.”

If a user navigates to the headset via the “Gaming” menu, but your breadcrumb says Home > Audio > Headphones, you have made a statement.

You have told the user (and Google) that despite how they got here, this product semantically belongs to the Audio department.

This is a powerful signal. It consolidates authority. Instead of splitting your link equity across three different category pathways, you funnel the structural importance through a single, primary lineage.

Don’t Trust the DOM

In the old days, Google tried to parse your breadcrumbs by reading the > symbols in your HTML. That was messy.

You need to explicitly feed the bot the hierarchy via JSON-LD.

The specific type is BreadcrumbList.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Men's Clothing",
      "item": "https://example.com/mens/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Jackets"
    }
  ]
}

The “Position” Integer Matters

See that "position": 1? That is not optional.

You are explicitly defining depth. You are telling the crawler that “Men’s Clothing” is level 2.

This helps the algorithm calculate the “click depth” of your content without actually having to crawl the links. You are handing them the map key.

URL Structure and Breadcrumbs

There is a pervasive myth that your URL needs to match your breadcrumbs.

• URL – example.com/product/gaming-headset-v2
• Breadcrumb – Home > Gaming > Accessories > Headsets

This is perfectly fine. In fact, it is often better.

Keep your URLs flat and short. They are permanent identifiers.

If you bake the category into the URL (example.com/gaming/accessories/headsets/product-name), you are creating a migration nightmare if you ever decide to reorganize your categories.

Let the Breadcrumb Schema handle the hierarchy. Let the URL handle the identity.

The “Mobile” Conflict

Designers hate breadcrumbs on mobile. They take up valuable vertical screen real estate. The common instinct is to hide them with display: none on small screens.

Important 2025 Update: As of January 2025, Google no longer displays breadcrumbs in mobile search results at all, only the domain name appears. However, you should still implement breadcrumb structured data on mobile, as it helps Google understand your site hierarchy even if it doesn’t appear in search results.

From a technical SEO perspective, hiding breadcrumbs completely is still problematic.

Google’s structured data guidelines explicitly state – “Don’t mark up content that is not visible to readers of the page.” This means your BreadcrumbList schema should only mark up breadcrumbs that are actually visible to users.

The solution:

1. Scrollable Breadcrumbs – Keep them in a single line that overflows horizontally. Users can swipe left/right to see the full path. This keeps them visible while saving vertical space.
2. Collapsed / Expandable Design – Use a hamburger menu or “…” pattern that expands to show the full breadcrumb trail when tapped. As long as the content is accessible to users (even if collapsed by default), it can be marked up with structured data.
3. Avoid Hidden Schema Only – Do not include BreadcrumbList schema for breadcrumbs that are completely hidden with display: none or removed from the mobile DOM. This violates Google’s guidelines and could be considered deceptive markup.

Your structured data should always reflect what users can actually see and access on the page.

Conclusion

Breadcrumbs are a categorization enforcement tool.

They solve the fundamental tension between the way databases work (tags, facets, multiple parents) and the way search engines work (strict hierarchies).

Don’t let your CMS auto-generate them based on the user’s session history. A breadcrumb that changes based on click path (Home > Search Results > Product) is useless for SEO. It needs to be static, authoritative, and hierarchical.

Anchor your content to a parent. defining the parent defines the child.