What Is Breadcrumb Schema Markup?
The least glamorous type in this section and one of the most reliably useful. It describes something structural rather than promotional, which is why it has survived while the more attractive enhancements have been withdrawn.
What It Asserts
Where a page sits within the site's structure. It states a position in a hierarchy rather than a claim about quality, which makes it the most modest assertion in this section and among the hardest to abuse.
What the statement contains. An ordered path.
The sequence of sections a page sits beneath, from the top of the site down to the page itself. Each step named and in order, describing containment rather than relatedness.
What it does not claim. Anything evaluative.
Nothing about importance, quality or relevance. A page deep in a structure is not asserting it is minor, only that it sits where it sits.
Why that makes it unusual here. Little to gain by lying.
Most abuse in this subject involves claiming something flattering. There is nothing flattering to claim about a hierarchy, which is part of why this type has a clean reputation.
What it is describing. A real thing or nothing.
The hierarchy exists in how the site is organised, else it does not exist at all. Block three covers what happens when somebody describes one that is not there.
It Still Displays
This remains one of the more dependable enhancements. A result can show a readable path in place of the page address, which is genuinely useful and makes this type worth implementing.
What the reader sees. A trail instead of an address.
Rather than a long address with slashes, the result shows the sections a page sits under in plain words. Somebody scanning results can tell what kind of page they are about to open.
Why that matters commercially. Context before the click.
A result reading as a guide within a named section tells somebody more than an address does. It is a small clarity gain repeated on every result, which is the true scale of the benefit.
Why this one survived. It describes structure.
The enhancements that have been withdrawn were promotional: stars, expandable questions, step lists. Those attracted abuse because they were attractive. A path is neither, so nobody bothered to game it.
The qualification that still applies. Eligibility is not appearance.
Correct markup makes a page eligible rather than guaranteeing the treatment. That rule holds for every type in this section, including the dependable ones.
The pattern worth noting. Structural types last.
Across everything withdrawn in recent years, the types describing what something is have endured better than the ones decorating how it looks.
It Has To Match The Actual Structure
The path should reflect where the page genuinely sits. Inventing a hierarchy to look organised is both false and pointless, which is an unusual combination worth dwelling on.
What inventing looks like. A described structure with nothing behind it.
Markup asserting that a page sits under a section, where the site has no such section, no page for it and no way to reach it. The path exists only in the description.
Why it is false. The usual reason.
It states something untrue about the site. That is the same rule governing every type here, arriving in its least tempting form.
Why it is also pointless. Nothing is gained.
Unlike a fabricated rating, an invented hierarchy offers no advantage worth having. Somebody doing it has taken a risk for nothing, which is why it usually happens by accident rather than design.
How the accident happens. A template guessing.
Something generating breadcrumbs from address segments can describe sections that were never real, particularly where addresses contain words that look like categories.
What to check. Can you click it.
Every step in the path should be a page somebody can reach. Where a step goes nowhere, the markup is describing a structure the site does not have.
Which Means Structure Comes First
A site with no coherent hierarchy has nothing to describe. That makes this markup unusually dependent on work that has nothing to do with markup.
What a coherent structure looks like. Sections that mean something.
Pages grouped by subject, each group with a page of its own, then every page belonging clearly to one group. Simple to state and frequently absent.
What incoherent looks like. A flat pile.
Everything sitting directly beneath the home page, else grouped by when it was made rather than what it is about. There is no path to describe because nothing contains anything.
Why that is a bigger problem than the markup. Readers are lost too.
A structure nobody can describe is a structure nobody can navigate. The missing markup is a symptom rather than the complaint, which is the useful thing this type reveals.
What to do about it. Organise, then describe.
Deciding what your sections are and which pages belong in each is the actual work. The markup afterwards takes minutes and states what you decided.
Where the detail sits. Elsewhere.
Our advanced material covers information architecture properly, including how to decide sections. This page only makes the point that the description depends on it.
Visible Breadcrumbs Are Not Required
The markup and any visible trail on the page are separate things. You can have either without the other, which surprises people given how strict the matching rule is elsewhere.
Why this type is different. The structure is visible anyway.
Elsewhere the rule is that markup must describe something shown on the page. Here the thing being described is the site's organisation, which is evident from the navigation and the address rather than needing a trail.
What a visible trail adds. Convenience.
A clickable path lets somebody move up a level without hunting through navigation. Useful on deep sites and largely unnecessary on shallow ones.
When to add one. Depth.
Where a site has several levels and people arrive on inner pages from search, a visible trail genuinely helps them orient. On a small site it adds clutter for little benefit.
What must still be true. The path is real.
Whether or not it is shown, the described hierarchy has to be the site's actual one. Not displaying it does not loosen that.
The version to avoid. Two that disagree.
A visible trail saying one thing and markup saying another is worse than either alone. It is a common result of the two being maintained separately.
It Breaks During Restructures
Changing a site's structure leaves breadcrumb markup describing a hierarchy that no longer exists. Nothing announces it. It is one of the quieter casualties of a rebuild.
What happens. The description outlives the structure.
Sections get merged, renamed or removed. The markup keeps asserting the old arrangement, naming sections that have gone and paths that lead nowhere.
Why nobody notices. The pages still work.
Every page loads, the navigation is fine and nothing reports an error. The only thing wrong is a description nobody is looking at.
What makes this type especially vulnerable. Restructures are exactly what change it.
Most markup survives a redesign because the facts do not move. A breadcrumb describes the one thing a restructure exists to alter, so it is wrong by definition afterwards.
When to check it. After any structural change.
Merging sections, renaming a category, moving pages between areas or changing the address pattern. Each of those invalidates paths. Our site migrations material covers what else goes at the same time.
What a check involves. One page per section.
Open a page from each part of the site and confirm the described path matches where it now lives. That is a short task after a rebuild and it never happens on its own.
Our Own Standard
Every page we build carries this markup. The path it describes reflects the section structure the site is organised around. On this page you can check that in the address bar.
How our sites are organised. By subject.
Each subject has a hub page, with every guide on that subject sitting beneath it. The structure is decided before anything is written, which is why the paths are describable.
What that produces. Three levels, usually.
The home page, the subject hub and the guide. Deep enough to be meaningful and shallow enough that nobody gets lost, which suits the businesses we work with.
Why we decide it first. Retrofitting is painful.
Imposing a structure on pages that already exist means changing addresses, which means redirects and risk. Deciding at the outset costs nothing.
What it sits alongside. Two other locked descriptions.
Every guide also carries an article description and a questions description. Those three are fixed on every informational page across the programme.
The business description. Separate again.
The organisation itself is described once site-wide rather than per page, which organisation markup covers.
Organise first.
Describe it
second.
A site with no coherent hierarchy has nothing to describe. A structure nobody can describe is one nobody can navigate either. We decide the sections before anything is written, which is why the paths on every page we build are real and clickable.
On every page we build:
Every step in the path should be a page you can actually click.
Every guide.
One practice.
What structured data is, which types apply to your business, how to test it, where the results features come from and what to do when nothing appears.
