Breadcrumb markup Google renders, and the trail it ignores
Breadcrumb markup is the schema type that visibly changes a search result. It needs at least two rungs, three properties per rung, and a trail the page really shows.
BreadcrumbList is the structured-data type that visibly changes a search result: Google can render the trail — Books, then Science Fiction, then Award Winners — in place of the bare URL path under the title. It needs at least two rungs to say anything, because a one-item list is a page pointing at itself and describes no path. Each rung carries three properties: item, name and position. Google's own guidance allows the last rung's item to be omitted, and uses the containing page's URL when it is.
Google lists three required properties on each ListItem in a breadcrumb: item, the URL of the page that rung represents; name, the title displayed to the user; and position, the 1-based place of that rung in the trail, where position 1 is the start. The list itself requires itemListElement, which is one of the few places Google states a hard requirement rather than a recommendation. Two of the three properties have documented exceptions, and knowing them prevents both a false error and a wrong fix.
| Property | What it holds | When it may be omitted |
|---|---|---|
| item | The URL of the page that rung stands for | On the last rung, where Google uses the containing page's URL |
| name | The title of the rung as a person reads it | When item is a Thing that carries its own name |
| position | The 1-based place in the trail, starting at 1 | Never |
| itemListElement | The rungs themselves, on the list | Never |
Emitting the final rung's URL anyway is the safer of the two readings. Both are accepted, but a list in which every position carries an item never trips a validator that expects one, and the cost of including it is a few bytes. Market4's generator takes that route deliberately, and it refuses to emit anything at all below two rungs — a single-rung breadcrumb is not a trail, and no result row is improved by it.
One page can carry several breadcrumb trails, and Google documents the case explicitly: when there are multiple ways to navigate to a page, each route can be published as its own BreadcrumbList. A page about award-winning science fiction might sit under Books, then Science Fiction, and also under Literature. Google picks the trail that fits the query, which is the point of publishing both — the same page arrives from different searches and the breadcrumb categorises it in the context of the search that found it.
A cache is invalidated when its source changes. A block of JSON-LD pasted into somebody's codebase is not. The only thing that can notice is a record of what was handed out.
Markup does not persuade an answer engine to quote a page. It removes the guesswork about who wrote the page, when, for whom, and where it sits on the site.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Multiple trails are worth the effort only when the site genuinely has multiple paths. Inventing a second hierarchy to fill the markup produces a trail no visitor can follow, which is the category of error Google treats as misleading structured data. The trail in the markup should be a trail the page actually shows.
Breadcrumb markup earns its place because it changes something a person sees. Most schema types on a software blog are eligibility plumbing — they carry facts in a parseable form and draw no rich result of their own. The breadcrumb replaces the URL line in the result with words the reader chose, which affects whether the result looks like a page about their question or like a path segment ending in a slug. It also costs nothing at runtime, because every value in it is already on the page.
No. Breadcrumb markup changes how a result is presented, not where it sits. Google renders the trail in place of the URL line, which can affect whether somebody clicks, but the position in the results is decided by everything else. Adding breadcrumbs to a page that does not rank produces a better-looking result nobody sees.
It may, and including it is the safer choice. Google's guidance says item is not required on the last rung and that it will use the containing page's URL when the property is absent. Both forms are accepted. A list where every position carries an item is less likely to be flagged by a third-party validator that applies the requirement uniformly, and the extra property costs nothing.
Nothing useful. A single-rung list describes a page pointing at itself, which is not a path and gives Google nothing to render in place of the URL. Market4's generator returns no block at all in that case rather than emitting a list that cannot earn anything. If a page genuinely has no parent, it does not need breadcrumb markup.
Yes. Google documents publishing more than one BreadcrumbList for a page that can be reached by more than one route, and picks the trail that suits the query. This is worth doing when the site really has two hierarchies, such as a document that belongs to both a product area and a topic. It is not worth inventing a second path that the site's navigation does not offer.
Publishing writes to a database and tells search engines about an address. Preflighting is the step that asks the server answering that address whether it serves a page. What to check, which findings block an announcement, and why the check must never fail a publish.