パンくずリストと BreadcrumbList 構造化データ

パンくずリストは、「ホーム > カテゴリ > 現在のページ」のように、サイトの階層のどこにいるかを示すナビゲーションです。利用者は現在地を把握して上位階層へ戻れ、クローラーはサイト構造を理解し、Google の検索結果にはパンくずとして表示されることがあります。HTML は nav と順序リスト ol で組み、BreadcrumbList 構造化データ（JSON-LD）を添えると、階層が機械にも正確に伝わります。

執筆: JIT株式会社公開: 2026年7月17日

パンくずリストとは何ですか？

パンくずリストは、サイトの階層構造の中で現在のページがどこにあるかを「ホーム > カテゴリ > 現在のページ」の形で示すナビゲーションです。利用者が今どこにいて、どうやって上の階層へ戻れるかを一目で伝えます。多くはページ本文の冒頭付近に置かれ、各階層がリンクになっています。

パンくずリストという名前は、童話「ヘンゼルとグレーテル」で、帰り道が分かるように落としたパンくずに由来します。 Web では、サイトのトップから現在のページまでの道筋を、たどってきた順に並べて見せる帯状のナビゲーションを指します。たとえば ホーム > 解説 > パンくずリスト のように書き、ホームと解説はリンク、末尾の現在ページはリンクにしません。

役割は 2 つに整理できます。1 つは「今どこにいるか」を示すこと、もう 1 つは「1 つ上の階層へすぐ戻れること」です。深い階層のページにいきなり検索やリンクから着地した利用者にとって、パンくずは「このページは何の下にあるのか」を教える唯一の手がかりになることがあります。置く場所は本文の冒頭付近、h1 の直前か直後が一般的です。

パンくずリストにはどんな効果がありますか？

効果は 3 つです。利用者が現在地を把握して上位階層へ戻れること、クローラーがサイトの階層構造を理解できること、そして Google の検索結果にサイト階層（パンくず）として表示されうることです。順位そのものを上げる機能ではありませんが、利用者にも検索エンジンにも構造を正しく伝えます。

パンくずの効果は、利用者・クローラー・検索結果の 3 方向に働きます。それぞれ性質が違うので、分けて理解しておくと過大な期待も過小な評価もしなくて済みます。

利用者の現在地把握 — 深いページに着地しても、上位階層へワンクリックで戻れる。回遊のきっかけになり、離脱を減らす
クローラーのサイト構造理解 — 検索エンジンは、パンくずのリンク関係からページ同士の親子関係を読み取る。内部リンクの一種として、階層を伝える役割も担う
検索結果でのパンくず表示— Google は、URL の代わりにサイト階層（ホーム > 解説 …）を検索結果に表示することがある。長い URL よりも、どこのページかが伝わりやすくなる

ここで正直に線を引いておきます。パンくずは検索順位そのものを上げる機能ではありません。Google は構造化データをランキング要因として使わないと説明しています。効果は「利用者が迷わない」「検索結果での見え方が良くなる」「機械が構造を誤解しない」という間接的なものです。順位を狙って付けるものではない、と理解しておくと判断を誤りません。

HTML ではどう書きますか？

nav 要素の中に順序リスト ol を置き、各階層を li とリンクで並べます。順序に意味があるため ul ではなく ol を使い、nav には aria-label を付けてパンくずだと分かるようにします。現在のページはリンクにせず、aria-current="page" を付けたテキストにするのが一般的です。

パンくずは「順序のあるリンクの並び」です。順序に意味があるので、箇条書きの <ul> ではなく順序リストの <ol> を使います。全体を <nav> で囲み、aria-label="パンくずリスト" を付けると、スクリーンリーダーが「これはパンくずのナビゲーションだ」と読み上げられます。現在のページはリンクにせず、aria-current="page" を付けたテキストにします。

パンくずの HTML（nav + ol）

<nav aria-label="パンくずリスト">
  <ol>
    <li><a href="/">ホーム</a></li>
    <li><a href="/guide">解説</a></li>
    <!-- 現在のページはリンクにせず、現在地であることを示す -->
    <li aria-current="page">パンくずリストと BreadcrumbList 構造化データ</li>
  </ol>
</nav>

区切りの > や / は装飾なので、独立した <li> にしないでください。区切りを li にすると、3 段のパンくずのつもりが li 5 個になり、「項目数」を数える機械判定が狂います。区切りは CSS の擬似要素で描くか、aria-hidden="true" を付けた <span> にして、li の数＝パンくずの段数を保つのが安全です。

BreadcrumbList 構造化データはどう書きますか？

BreadcrumbList は、パンくずの階層を JSON-LD で機械可読に書いたものです。itemListElement に ListItem を position 順に並べ、各項目へ name（階層名）と item（その URL）を入れます。最後の現在ページは item を省略してよく、Google はこれを読んでサイト階層を正確に把握します。

HTML のパンくずは人間向けの表示です。これに BreadcrumbList 構造化データ（JSON-LD）を添えると、Google が階層を推測せずに正確に読めます。itemListElement に ListItem を並べ、それぞれへ順番（position）・階層名（name）・その階層の URL（item）を書きます。

BreadcrumbList の JSON-LD

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "解説",
      "item": "https://example.com/guide"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "パンくずリストと BreadcrumbList 構造化データ"
    }
  ]
}

BreadcrumbList の主要プロパティ
プロパティ	必須	書き方の注意
`itemListElement`	必須	`ListItem` を `position` 順に並べた配列
`ListItem.position`	必須	1 から始まる整数。階層の順序を表す
`ListItem.name`	必須	その階層の表示名。画面のパンくずと一致させる
`ListItem.item`	現在ページ以外は必須	その階層の URL。最後の現在ページは省略してよい

最後の現在ページで item を省略できるのは、「今いるページ自身へのリンクは不要」という考え方によります。省略しても Google は正しく解釈しますし、自分自身の URL を書いても間違いではありません。どちらでも構いませんが、省略するなら全ページで統一しておくと、テンプレートが単純になります。

HTML のパンくずと構造化データは一致させる必要がありますか？

必ず一致させます。画面に表示していない階層を構造化データにだけ書くのは、Google のガイドライン違反です。階層名・順序・URL の 3 点を画面の nav と JSON-LD でそろえ、片方だけを変更して食い違わせないようにします。両方を同じデータから生成すると、そもそもずれません。

構造化データの大原則は、「画面に表示していることを、機械可読に言い直すだけ」です。パンくずも例外ではありません。画面には「ホーム > 解説」しか出していないのに、構造化データにだけ「ホーム > 解説 > カテゴリ > …」と存在しない階層を足すと、 Google のガイドライン違反になり、手動対策の対象になり得ます。得をするどころかリスクを負う行為です。

そろえるべきは階層名・順序・URL の 3 点です。画面のパンくずと JSON-LD を、別々の場所で別々に管理していると、片方だけ直して食い違う事故が起きます。最も確実なのは、1 つの配列データから、表示用の <ol> と JSON-LD の両方を生成することです。データが 1 つなら、ずれようがありません。このサイトの解説ページも、同じ仕組みでパンくず表示と BreadcrumbList を同一のデータから出しています。

ありがちな誤りは何ですか？

多いのは、順序リストに ol ではなく ul を使う、区切りの「>」を li にして階層数を狂わせる、現在ページまでリンクにする、そして画面と構造化データがずれる、の 4 つです。特に区切り文字を li に入れると、3 段のつもりが li 5 個になり、リストの判定を誤らせます。区切りは装飾として扱います。

ul で組む — パンくずは順序が意味を持つので ol が正しい。ul だと「順序のない箇条書き」という誤ったマークアップになる
区切り文字を li にする — > や / を独立した li にすると、階層数が水増しされ、リスト判定を誤らせる。区切りは装飾扱いにする
現在ページをリンクにする — 末尾の現在ページは、自分自身へのリンクになるだけで意味がない。aria-current="page" を付けたテキストにする
画面と構造化データがずれる — 名前・順序・URL のいずれかが食い違うと、Google はどちらを信じるべきか分からなくなる。同じデータから両方を出す
1 段しかないのに付ける — トップページ直下のページで「ホーム」だけのパンくずは情報量がゼロ。階層が 2 段以上あるときに意味を持つ

いずれも「見た目は正しく出ているのに、機械には正しく伝わっていない」種類の誤りです。ブラウザで見て問題なさそうでも、リストの組み方や構造化データの中身までは目視で気づきにくいので、次の確認手順で機械にチェックさせるのが確実です。

書いたパンくずはどう確認しますか？

Google のリッチリザルトテストと Schema Markup Validator で、BreadcrumbList が正しく認識されるかを確認します。加えてブラウザの検証ツールで、nav 内の ol が画面のパンくずと一致しているかを目視します。公開後は Search Console のパンくずレポートで、全ページ分のエラーをまとめて監視できます。

リッチリザルトテスト（search.google.com/test/rich-results） — Google が BreadcrumbList を認識できるか、必須プロパティが欠けていないかを判定する
Schema Markup Validator（validator.schema.org） — schema.org の語彙として正しいかを検証する。Google 固有の要件ではなく、記法そのものを見る
ブラウザの検証ツール — nav 内の ol が、画面のパンくずと名前・順序・リンク先まで一致しているかを目視する
Search Console のパンくずレポート — 公開後、実際にクロールされたエラーがまとまって見える。テンプレートの不具合は、ここで全ページ分が一度に分かる

機械でできるのは「BreadcrumbList が構文として正しいか」「必須プロパティがそろっているか」までです。階層の切り方が利用者にとって自然かどうかは、最後は人が判断します。まずは構文エラーとプロパティ欠落をゼロにし、次に画面と構造化データの一致を確認する、という順で進めると迷いません。より広い構造化データの全体像は構造化データ（JSON-LD）の書き方を、Q&A を機械に読ませる考え方は AI に回答として引用される文章の構造を参照してください。