BreadcrumbListは、プロパティの数こそ少ないものの「どこまで書くか」で判断を誤りやすい構造化データです。最後の階層だけitemを省略できる例外があり、それを途中の階層でやると必須プロパティ違反になります。本記事は、Google・schema.org公式ドキュメントにもとづき、必須プロパティの書き方と、公開後に崩れやすい運用上の注意点を解説します。
01この記事でわかること
- BreadcrumbListの必須プロパティ（position・name・item）と最低要素数
- コピペ可能なJSON-LD実装テンプレート
- 表示用パンくずUIと、schemaの記述内容を一致させる必要性
- 1ページに複数のパンくずパスを指定する方法
- 実装後の検証方法とよくある失敗パターン
02結論サマリー
BreadcrumbListとは、サイトの階層構造をAIやGoogleに伝えるための構造化データです。Google公式は、BreadcrumbListについて「最低2つのListItemを含めること」を必須条件として明記しています（出典: Google公式）。
各ListItemには、position（順番）・name（階層名）・item（URL）という3つのプロパティが基本セットになります。ただし最後の階層だけは、itemプロパティを省略できる例外があります。この例外を正しく理解しないまま実装すると、途中階層で必須プロパティ違反になりやすい点に注意が必要です。
03BreadcrumbListとは（基礎定義）
schema.org公式は、BreadcrumbListを「リンクされたウェブページの連なりからなるItemList」と定義しています（出典: schema.org公式）。各ページは少なくともURLと名前で記述され、通常は現在のページで終わる構成です（出典: schema.org公式）。
Google公式は、パンくずリストを「サイト階層におけるそのページの位置を示すもの」と説明しています（出典: Google公式）。この構造化データを実装すると、検索結果でパンくず表示が使われる場合があるとも案内しています（出典: Google公式）。まず必須プロパティを押さえたうえで、コピペ用のテンプレートに進みます。
04必須プロパティと最低要素数
BreadcrumbListとListItemの必須プロパティを、表に整理します（出典: Google公式）。
| 型 | プロパティ | 必須/推奨 | 内容 |
|---|---|---|---|
| BreadcrumbList | itemListElement | 必須 | ListItemの配列。最低2つ必要 |
| ListItem | position | 必須 | パンくずの位置。1から始まる整数 |
| ListItem | name | 必須 | ユーザーに表示される階層名 |
| ListItem | item | 必須（最後の階層を除く） | 該当階層のURL |
この最低2件という条件があるため、トップページの直下にある1階層だけのページでは、BreadcrumbListが成立しません。カテゴリを1つ挟む構成にするか、実装を見送るかの判断が先に必要になります。
05実装テンプレート——コピペ用JSON-LD
基本的な3階層のBreadcrumbListは、次のように書きます。JSON-LDの@context・@typeといった基本記法は、別記事『JSON-LDの書き方基礎｜3つの実装例で学ぶハンズオンガイド』で解説しています。
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "カテゴリ名をここに入力",
"item": "https://example.com/category/"
},
{
"@type": "ListItem",
"position": 2,
"name": "サブカテゴリ名をここに入力",
"item": "https://example.com/category/sub/"
},
{
"@type": "ListItem",
"position": 3,
"name": "対象ページのタイトルをここに入力"
}
]
}最後の階層（対象ページ自体）だけは、itemプロパティを省略できます。Google公式は、省略した場合はページ自体のURLが使われると説明しています（出典: Google公式）。上の例で3番目のListItemにitemがないのは、この仕様に沿ったものです。
なお、サイトのドメイン名（トップレベルのパス）やページ自体をListItemに含める必要はありません（出典: Google公式）。そのため、トップページの1つ下の階層から書き始める構成も選べます。手作業でのコード生成が負担な場合は、別記事『パンくずリストschemaをAIに実装させる実践プロンプト』が実践的な生成方法を紹介しています。
06表示用パンくずUIとの整合性
実装直後は問題がなくても、運用の中でずれていくのがこの整合性です。画面上の見た目が正しくても、schema側だけが古いまま残るケースがあります。
nameプロパティには、実際に画面に表示されているパンくずの文言と同じ値を入れてください。position番号は、画面上の並び順と一致させる必要があります。カテゴリ名を変更した際は、画面表示とschema両方を同時に更新する運用が欠かせません。
07複数パスへの対応
1つのページに、複数のナビゲーション経路が存在する場合もあります。例えば、商品ページがカテゴリからも検索結果からも到達できるケースです。
Google公式は、「サイト内のページに複数の到達方法がある場合、1ページに対して複数のパンくずパスを指定できる」と案内しています（出典: Google公式）。この場合、複数のBreadcrumbListオブジェクトを配列として並べて記述します。
[
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "カテゴリA",
"item": "https://example.com/category-a/"
},
{
"@type": "ListItem",
"position": 2,
"name": "対象ページのタイトル"
}
]
},
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "カテゴリB",
"item": "https://example.com/category-b/"
},
{
"@type": "ListItem",
"position": 2,
"name": "対象ページのタイトル"
}
]
}
]positionは経路ごとに1から振り直します。経路をまたいで通し番号にしないよう注意してください。
08公開前の検証——3つの確認ポイント
BreadcrumbListの不具合は、構文エラーよりも「画面との内容のずれ」で起きます。リッチリザルトテストで構文を確認したうえで、次の3点を人の目で突き合わせてください。
| 確認ポイント | 見る場所 | ずれているときの症状 |
|---|---|---|
| 構文・必須プロパティ | リッチリザルトテストの検出結果 | ListItemが検出されない、itemの欠落がエラーとして出る |
| 階層と並び順 | 画面のパンくずUIとJSON-LDのposition | 画面と検索結果で階層の順序が食い違う |
| 文言 | 画面のパンくずの文言とname | カテゴリ改名後、schema側だけ旧名称が残る |
検証ツールの詳しい使い方は、別記事『構造化データのテスト・検証ツールの使い方｜旧ツールとの違いも解説』で解説しています。テンプレートで一括出力しているサイトでは、階層の深さが異なるページを2〜3件抜き取って確認すると、テンプレート側の作り込みミスに気づけます。
09チェックリスト
- itemListElementに、最低2つのListItemを含めている
- 各ListItemのpositionが、1から始まる連番になっている
- nameの文言が、画面表示のパンくずと完全に一致している
- 最後の階層以外で、itemプロパティを省略していない
- サイトのドメイン名自体をListItemに含めていない
- 複数パスを記述した場合、経路ごとにpositionを1から振り直している
- Rich Results Testで、エラー・警告がないことを確認している
10よくある失敗
position番号がずれてしまう。階層の追加・削除のたびに手作業で番号を振り直すと、抜けや重複が起きやすくなります。カテゴリ構成を変更した際は、position番号を必ず見直してください。
最後の階層以外でitemを省略してしまう。省略できるのは最後の階層だけです。途中の階層でitemを省略すると、必須プロパティ違反になります。
画面表示とschemaの文言が食い違う。カテゴリ名をリニューアルした際、画面側だけ更新してschema側を古いままにしてしまうケースがあります。更新時は両方をセットで見直す運用にしておくと、この失敗を防ぎやすくなります。
11FAQ
Q. 1階層だけのBreadcrumbListは実装できますか？
できません。Google公式は、最低2つのListItemを含めることを条件として明記しています（出典: Google公式）。1階層しかない場合は、BreadcrumbListの実装自体を見送る選択肢もあります。
Q. パンくずの1つ目に「ホーム」を入れる必要はありますか？
必須ではありません。Google公式は、サイトのトップレベルのパスやページ自体をリストに含めることを求めていません（出典: Google公式）。画面のパンくずUIに「ホーム」を表示している場合は、表示との一致を優先して入れる判断が自然です。
Q. 画面にパンくずを表示していないページに、schemaだけ実装してもいいですか？
おすすめしません。Google公式は、ページに実際に表示されている情報について構造化データを記述するという原則を示しています（出典: Google公式）。階層を伝えたい場合は、まず画面側にパンくずUIを用意し、その表示内容をschemaに写す順序で進めてください。
Q. カテゴリ構成を変更したら、何を見直せばいいですか？
画面表示のパンくずUIと、BreadcrumbList schemaの両方を見直してください。特にposition番号とnameの文言は、変更のたびにずれやすい箇所です。
12まとめ
BreadcrumbListの実装で本当に負荷がかかるのは、コードを書く瞬間ではなく、その後の運用です。カテゴリの改名・階層の追加が起きるたびに、画面表示とschemaの両方を同時に直せる体制になっているかが分かれ目になります。
まず着手すべきは、テンプレート出力の見直しです。ページごとに手書きしている状態なら、カテゴリ情報から自動生成する形に寄せておくと、position番号のずれと文言の食い違いをまとめて防げます。
そもそもの階層設計から見直す場合は、別記事『内部リンク設計でトピッククラスターを作る方法｜実装6ステップ』が参考になります。サイト全体をAIが辿れる構造にする観点は、別記事『サイト構造とAIクローラビリティの関係｜設計手順を7ステップで解説』で扱っています。
