パンくずリストとは?ナビゲーションと構造化データの違い・設置の確認方法
2026年6月19日
著者: 与謝秀作
パンくずリストは、ページがサイトのどこに位置するかを伝え、上位の分類へ戻るための案内です。画面上のナビゲーションとGoogle向けの構造化データは関係しますが、同じものではありません。利用者に自然な経路を設計し、それぞれの層を確認しましょう。
パンくずリストの役割と通常のリンクとの関係
一般的なパンくずは「ホーム→ガイド→アクセス解析→記事」のように、現在地までの経路を示します。訪問者が検索から直接記事へ来ても、関連する上位情報に移れることが目的です。階層がほとんどない小さなサイトまで、全ページに機械的に設置するSEO要件ではありません。
上位の項目は移動できる通常のリンクにし、現在のページは現在地と分かる表示にします。リンク先のない分類を見た目だけで作ったり、全記事で同じ経路を出して内容と矛盾させたりしないでください。パンくず以外の一覧や本文リンクも、必要な案内として併用します。
画面のナビゲーションと検索表示用の構造化データを分ける
層 | 利用する側と目的 | 確認するもの | 保証しないこと |
|---|---|---|---|
画面のパンくず | 読者が現在地を理解し移動する | 表示ラベル、実際のリンク先、操作 | 設置だけで検索順位が上がる |
BreadcrumbList | 検索システムへ経路を機械可読で伝える | 項目、位置、名称、URL、テスト | 検索結果で必ず表示される |
通常のHTMLリンクは、構造化データがなくてもナビゲーションとして機能します。Googleのパンくず構造化データの説明にあるBreadcrumbListは、検索機能に向けて情報を整理する別の層です。マークアップを追加しただけで、読者が使う画面の案内が自動的にできるわけでもありません。
URL階層ではなく利用者に自然な経路を選ぶ
URLの文字列を機械的に切り分ける必要はありません。架空の記事URLがexample.com/guides/trafficで短くても、サイト上の説明が「ホーム→ガイド→アクセス解析→流入元の確認」なら、その経路で案内する設計が考えられます。URLの形と情報分類を区別しましょう。
架空の条件 | 経路の設計例 | 確認する理由 |
|---|---|---|
記事は短いURL | ホーム→ガイド→アクセス解析→記事 | 読者が上位の案内へ戻れる |
記事が複数カテゴリに属す | 主要な分類を決め、各表示で整合させる | 訪問経路でラベルが矛盾しない |
分類ページがない | 実在する上位ページで経路を組む | 存在しないカテゴリへリンクしない |
分類は読者が理解できる言葉で付けます。社内だけの部署名や管理コードを露出させず、記事を別カテゴリへ移した時は、画面とマークアップの両方を見直します。
BreadcrumbListの項目と必須条件を確認する
Googleの仕様では、BreadcrumbListのitemListElementに2つ以上のListItemが必要です。各項目はpositionとnameを持ち、通常はitemで対応URLを示します。最後の項目のitem URLは省略できます。画面上で現在ページをリンクにしない設計と、データ内のURL要件は別に確認してください。
3段階の架空例 | position | name | itemの扱い |
|---|---|---|---|
最初の項目 | 1 | ホーム | 実在するホームのURL |
次の項目 | 2 | ガイド | 実在するガイドのURL |
最後の項目 | 3 | 流入元の確認 | 現在ページのURL。最後は省略可 |
この表は項目を理解するための例で、そのまま使う完成コードではありません。実装担当と、公式の必須項目と例に照らして対応させます。形式の検証だけでなく、名称とリンク先が実際のページを正しく表しているかも確認しましょう。
モバイル検索とデスクトップ検索の表示の違い
Googleは2025年1月に、モバイル検索結果の見えるURL表示からパンくずを外す変更を発表しました。公式発表では、デスクトップ検索にはパンくず表示が残ると説明しています。これはサイト画面のパンくずやBreadcrumbListそのものを廃止する案内ではありません。
モバイル検索でパンくずが見えないことを、実装エラーや登録拒否の証拠にしないでください。検索の画面、端末、時点で表示は変わり得るため、何を確認したのかを記録します。検索結果の表示だけを理由に、有用なサイト内の案内を削除する必要もありません。
テストと公開後の状態を分けて点検する
- 画面のパンくずを読み、各リンクと現在地の表示を確認する。
- 実際のページに出力された構造化データを確認する。
- Rich Results Testで項目やエラーを調べる。
- 公開URLの取得状態をURL検査で確認する。
- 公開後のSearch Consoleレポートで検出された状態を追う。
テストで有効という結果が出ても、Googleが取得・登録・表示したとは限りません。Google検索の工程を分け、テスト日、公開版、最終取得、レポートの状態を別に記録します。テスト対象と本番URLが異なる場合も、同じ結果とみなさないでください。
複数カテゴリ・リンク切れ・本文との不一致への対応
症状 | 調べる箇所 | 対応と再確認 |
|---|---|---|
カテゴリ変更後も旧ラベル | CMS分類、共通部品、出力データ | 表示とデータを一緒に更新して照合 |
上位リンクが切れている | 分類ページのURLと転送 | 実在する適切な行き先を設定 |
複数分類で経路が混在 | 主要経路と生成ルール | 各経路の一貫性を確認 |
本文と主題が合わない | カテゴリと記事の内容 | 読者に自然な分類へ見直す |
公開前には、リンク、ラベル、項目順、実在するURL、確認者を一枚に残します。パンくずは順位保証の部品ではなく、サイトを理解して使うための案内です。まず一つの記事で上位へ戻る操作を試し、構造化データと照合するところから始めましょう。


