パンくずリストとは：ページの階層表示と構造化データの正しい付け方

パンくずリストとは、サイト内で今いるページの位置を、上位の分類から順に示す案内のことです。製品ページなら、製品、カテゴリ、個別製品という経路を表示し、親のページへ戻れるようにします。

設定前に、各ページの親を決めてください。階層が曖昧なまま構造化データだけを追加しても、訪問者がどの分類へ戻ればよいかは決まりません。分類そのものの作り方はハブページと階層構造の設計⁠で扱っています。

このページでは、決まった階層を画面に出し、Googleが読めるBreadcrumbListへ書き添え、公開後に確かめる手順を説明します。

画面には、どんな経路を出す？

産業用ポンプを扱うメーカーの製品ページを例にします。下の表は説明用の構成で、実在する会社の製品構成ではありません。

画面では、製品とポンプをリンクにし、今いる耐食ポンプは現在地と分かる表示にします。読者が検索から直接来たときにも、同じカテゴリの製品へ戻れます。

パンくずは閲覧履歴ではありません。会社概要から製品へ来た人にも、検索から来た人にも、サイト内での位置を示します。戻るボタンと同じ働きにはしません。

Googleのパンくずの公式仕様は、URLのフォルダをそのまま再現するより、利用者がたどる一般的な経路を勧めています。管理上の番号や、読者が使わない社内の部署名を挟まないようにします。

狭い画面では、何を確かめる？

短い分類名を使い、長い記事タイトルをそのまま各段へ入れないようにします。正式な製品名を省略すると別製品になるなら、名前を勝手に縮めず、画面側で改行できる設計にします。

矢印も含めて一行へ固定すると、スマホの幅を超えることがあります。表示を一行に収めるためだけに、必要な分類を消すことも避けます。折り返した後に、どの語がリンクか、経路の順番が分かるかを確認してください。

見た目だけでなく、製品、カテゴリ、現在地の順に操作します。リンク先が存在するか、現在地が別の製品を指していないかまで試します。本文から関連する製品へ進むリンクの書き方は内部リンクとアンカーテキスト⁠へ進めます。

BreadcrumbListは、どう書く？

先ほどの製品ページに対応するJSON-LDの例です。URLは説明用のものです。実装時は、自社の正式なURLと、画面に表示している名前へ置き換えます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "製品",
      "item": "https://example.com/products/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "ポンプ",
      "item": "https://example.com/pumps/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "耐食ポンプ"
    }
  ]
}
</script>

最後の項目はitemを省略しています。Googleは、この形ではその構造化データを含むページのURLを使うと説明しています。それより前の項目は、リンク先を省略しません。

JSONの項目名は、翻訳せず仕様のまま使います。positionには先頭を1とした整数を入れます。画面の並びを変えたときは、データの順番と番号も同じように直してください。

必須・推奨プロパティは、どこを区別する？

Googleの説明では、BreadcrumbListに少なくとも二つのListItemを入れる必要があります。対応するプロパティの表は次の内容です。

これらはGoogleの表では必須項目です。ただし、最後のitemは省略できます。itemをURL文字列ではなく、名前を持つThingとして記述する方式では、項目側のnameを省略できる例外もあります。上のコードはURL文字列を使うため、nameを各項目に記載しています。

確認した公式ページには、この型のための別の推奨プロパティ表はありません。一般的なschema.orgの項目を、Google向けに全部必須として追加しないでください。トップの項目と、現在のページ自体も、必ず含める条件ではありません。

複数のパンくずは、どんなときに使う？

同じ製品を、製品の種類からも用途からも探せるサイトを考えます。種類からは製品、ポンプ、耐食ポンプ。用途からは用途、薬液移送、耐食ポンプという経路です。どちらも実際に案内できる分類なら、経路を分けて表せます。

Googleは公式仕様で、一つのページに複数のBreadcrumbListを記述する例を公開しています。JSON-LDではリストのオブジェクトを配列に並べ、各経路を独立したリストにします。番号も経路ごとに1から付けます。

二つの経路を一列につなぐと、製品分類の下に用途分類が属するような別の階層になります。実際のサイトがそうなっていないなら、混ぜないでください。

分類を増やすほどよいわけでもありません。現状で一つの親から十分に探せるなら、その経路を正しく表示します。複数の検索語を入れたいという理由だけで経路を作る必要はありません。

プラグインが出していれば、確認は不要？

自動出力でも、元のカテゴリ設定が間違っていれば、そのまま誤った経路が出ます。製品を別の分類へ移したときや、カテゴリ名を変えたときは、画面とJSON-LDの両方を見ます。

私たちは暦の自社メディアで、FAQを構造化データにだけ入れ、画面に出していなかったことがありました。その後、画面にも答えを出す形へ直しました（出典は自社の作業記録）⁠。パンくずでも、機械向けの出力があるだけで読者への案内が完成したとは判断しません。

構造化データ全体の役割は構造化データの基本と画面との一致⁠で説明しています。同じプラグインやテンプレートから重複して出ているなら、出力元を整理し、一方だけ古い分類を残さないようにします。

公開後は、どこで検証する？

コードをリッチリザルトテスト⁠へ入れ、パンくずを認識できるか確かめます。ここでエラーがなくても、リンク先の分類が読者に正しいかまでは判定できません。画面との照合は残ります。

手順は、構造化データの検証ツールの使い分け⁠で確認できます。公開後はSearch ConsoleのURL検査でGoogleが取得できるかを見て、パンくずのレポートに問題があれば、代表ページから出力元を直します。

Google検索のパンくず表示は、現行の公式仕様ではパソコン向けです。スマホの検索結果に出ないことを、ただちに実装エラーとは判断できません。サイト内でのパンくず表示とは別の話です。

正しく設定しても、検索結果での表示は保証されません。読者が親の分類へ戻れ、画面とデータが一致し、検証で問題がない状態を完了条件にします。サイト設計の整備では、個別ページの追加や移動後にも、この条件を繰り返し確認してください。

仕様・出典の確認日：2026年10月23日⁠。