【2026年】パンくずリストとは？設計・設置と構造化データの確認点

パンくずリストは、閲覧中のページがサイト内のどの分類に属するかを示し、上位のカテゴリへ移動できる案内です。SEOではページ間の関係を伝える役割があります。設計では、読者に意味のある分類と戻り先を決め、画面のリンクと構造化データをそろえることが大切です。

本記事では、法人サイトの記事とサービス、ECサイトの商品を例に、分類・表示・実装・点検を順に解説します。パンくずを付けるだけで検索順位が上がるとは限りません。読者が迷わず関連情報へ進める状態を作り、そのうえで検索エンジンへ分類を伝えましょう。

パンくずリストの意味と役割を理解する

現在地と関連情報への戻り先を示す

たとえば、検索から「棚卸しの進め方」という記事へ直接訪れた人は、そのサイトのトップページを見ているとは限りません。「ホーム ＞ お役立ち情報 ＞ 在庫管理 ＞ 棚卸しの進め方」と表示されていれば、この記事が在庫管理の情報に属すると分かります。「在庫管理」を選ぶと、同じ分野の記事一覧へ移動して別の疑問も調べられます。

ここでいう「戻る」は、直前に見たページへ戻る操作とは違います。検索結果から来た人にも、別の記事から来た人にも、分類上の戻り先を示します。記事内の目次は同じページの見出しへ移動する案内、パンくずはサイト内の上位ページへ移動する案内です。URLもページを識別する情報ですが、文字列を区切るだけでは読み手に分かる分類名や一覧へのリンクにはなりません。

種類は何を示したいかで選ぶ

パンくずは、分類の位置、商品の属性、閲覧した履歴など、表示の基準によって分けられます。分類を示す経路と、実際に通った履歴を区別すると、自社サイトに必要な案内を選びやすくなります。

パンくずリストの種類と向く場面

位置型を採用しても、URLのディレクトリをそのまま再現する必要はありません。また、複数の属性を持つからといって、すべてを画面に並べる必要もありません。初めて訪れた人が関連情報を探せるかを基準に、表示する分類を絞ります。

SEOでは内部リンクと階層の文脈を整える

上位カテゴリへのリンクは、サイト内のページを結ぶ内部リンクです。分類名とリンク先の内容が一致していれば、読者にも検索エンジンにもページの関係を伝えやすくなります。構造化データは、その分類情報を一定の形式で記述するものです。画面の案内、リンク先の内容、データの記述を一緒に整えることが、パンくずに取り組む基本になります。

一方、設置だけで順位やクリック率の改善を約束できるものではありません。まず、関連する一覧へ移動できるという役割を満たしましょう。本文中の関連リンクや全体ナビゲーションとは目的を分けると、パンくずへ情報を詰め込みすぎずに済みます。

関連記事：【2026年】SEOの内部リンクとは？設置場所・リンク先・アンカーテキストの考え方

ユーザーの分類に合う階層と経路を決める

法人サイトでは情報を探す目的を分ける

たとえば在庫管理を支援する法人サイトなら、サービス案内は「ホーム ＞ サービス ＞ 在庫管理支援」、解説記事は「ホーム ＞ お役立ち情報 ＞ 在庫管理 ＞ 棚卸しの進め方」と設計できます。話題は共通でも、サービスを探す人は支援内容の一覧へ、知識を調べる人は同分野の記事一覧へ戻れる方が自然です。

「サービス」と「お役立ち情報」がサイト内で並列の分類なら、「ホーム ＞ サービス ＞ お役立ち情報 ＞ 棚卸しの進め方」と並べるのは避けます。これでは記事全体がサービスの下に属するように見えるためです。記事の親はお役立ち情報に直し、在庫管理支援の案内は、読者が支援を検討する本文の文脈で設けます。営業上つなぎたいページと、分類上の親ページは分けて考えます。

ECでは商品種別と用途を別の経路にする

同じ「折りたたみ作業台」でも、商品種別から探す人と、梱包作業に必要な道具を探す人では、見たい一覧が異なります。たとえば「ホーム ＞ 作業用品 ＞ 作業台 ＞ 折りたたみ作業台」と「ホーム ＞ 用途から探す ＞ 梱包作業 ＞ 折りたたみ作業台」という経路が考えられます。

採用の前提は、それぞれの上位ページで対象商品や関連商品を実際に探せることです。「作業台 ＞ 梱包作業」と分類軸をつなぐだけでは、梱包作業全体が作業台の下に属するように見えます。異なる切り口は無理に一本へつなげず、意味の通る経路ごとに設計することを推奨します。複数経路の価値は本数ではなく、戻った先で読者が探し直せるかで判断します。

分類設計で優先すること

分類の打ち合わせでは、代表ページを一つずつ選び、現在ページから親へ戻ったときに何が見えるかを確かめます。名前だけで判断せず、一覧の掲載対象まで説明できる状態にすると、編集担当と実装担当の認識がそろいます。URLを変更するかどうかは別の検討事項として扱い、表示経路を整えるためだけに変更を始めないようにしましょう。

表示位置・ラベル・リンク先をそろえる

ラベルは移動先の役割が分かる名称にする

「在庫管理」と「在庫管理支援」は似た名前ですが、前者を分野別の記事一覧、後者をサービス詳細とするなら役割が異なります。短いからという理由だけで両方を「在庫管理」に統一すると、読み手は行き先を予測しにくくなります。パンくずの文言は、移動先の見出しや掲載内容と照らして決めます。

同じ一覧を、ある記事では「お役立ち情報」、別の記事では「ブログ」と呼ぶような揺れも整理しましょう。長い検索語をすべて入れるより、情報のまとまりが伝わる自然な名称を優先します。現在ページは上位リンクと見分けられるようにし、どこまでが押せる案内かを分かりやすくします。

法人サイトのラベルと移動先の対応

ECの例では、「作業台」は作業台の商品一覧、「梱包作業」は梱包用途の商品一覧に対応します。同じ商品へ到達する経路でも、上位リンクの目的は異なります。対象商品が載っているかに加え、読者が比較したい関連商品へ進めるかを確認します。全商品一覧へリンクするだけでは、分類名が約束している範囲と合わない場合があります。

PCとスマホの両方で移動を試す

表示位置は、読者が現在地と戻り先を見つけやすいかで決めます。ページ上部に置く設計を出発点に、ヘッダーや本文との関係を確認します。スマホで下部に置く場合も、必要な場面で見つけられるかを実際に操作して判断しましょう。画面が狭いという理由で重要な分類を消す前に、名称や配置を見直します。

長い商品名や記事名があるページでは、折り返した文字同士が重ならないか、横スクロールを採用するなら最後の現在ページまで到達できるかを確認します。リンクの文字が読めても、隣のリンクを誤って押すほど密集していれば改善が必要です。文字が見えることと、期待したページへ操作できることを両方確認するのが表示点検の要点です。

テンプレートが同じでも、短い分類名だけのページでは不具合に気付けないことがあります。名称が長いページ、階層が深いページ、商品分類が複数あるページを選び、PCとスマホで確認する組み合わせに含めてください。

HTMLのナビゲーションと構造化データを分けて実装する

画面の案内とデータを同じ分類設計から作る

HTMLのパンくずは、読者が画面で見て操作する案内です。BreadcrumbListは、パンくずの並びを検索エンジンへ伝える構造化データです。JSON-LDを書き込むだけでは画面にリンクは表示されません。反対に、画面にリンクがあっても、意図した構造化データが出力されているとは限りません。

実装前に、分類名、順序、リンク先の組を確定しましょう。法人例なら「ホーム」「お役立ち情報」「在庫管理」「棚卸しの進め方」を一組として管理します。表示名とname、リンク先とitem、並び順とpositionを対応させると、別々に修正して経路が食い違う失敗を防ぎやすくなります。

法人の記事経路をHTMLとJSON-LDへ対応させる例

以下は説明用の予約ドメインexample.comを使った記入例です。実装時は、自社サイトに存在するページのURLへ置き換えます。HTMLはnavで案内の領域、olで項目の順序、aで上位ページへのリンクを示します。現在の記事はリンクなしとし、aria-currentで現在ページを示す例にしています。

<nav aria-label="パンくずリスト">
  <ol>
    <li><a href="https://example.com/">ホーム</a></li>
    <li><a href="https://example.com/knowledge/">お役立ち情報</a></li>
    <li><a href="https://example.com/knowledge/inventory/">在庫管理</a></li>
    <li aria-current="page">棚卸しの進め方</li>
  </ol>
</nav>

同じ経路をJSON-LDで記述すると、次の形になります。これは記事内で読むためのコード例です。サイトへ実装するときは、対象ページのHTMLにapplication/ld+json形式のscriptとして出力します。

<script type="application/ld+json">
{
  "@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/knowledge/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "在庫管理",
      "item": "https://example.com/knowledge/inventory/"
    },
    {
      "@type": "ListItem",
      "position": 4,
      "name": "棚卸しの進め方"
    }
  ]
}
</script>

法人例の分類から実装への対応表

Google向けのBreadcrumbListには、少なくとも2つのListItemが必要です。itemListElementに各項目を並べ、positionには1からの順序を指定します。この例のようにitemをURL文字列で指定する形では、表示名をnameに記述します。nameを持つThingをitemに指定する場合には、ListItem側のnameを省略できる例外があります。

最後の項目ではitemを省略でき、その場合は対象ページ自身のURLが使われます。最後のitemは省略可能であり、省略が必須ではありません。また、ホームや現在ページをListItemへ含めることも一律の必須条件ではありません。含めるかどうかにかかわらず、必要な項目数と分類としての意味を満たす形で設計します。

仕様の詳細：Google検索セントラルのパンくずリスト構造化データ

ECの複数経路は別々のリストへ対応させる

商品種別と用途の両方に意味のある分類があるなら、それぞれを別のBreadcrumbListで表せます。最後の商品は共通でも、途中の分類名とURLは経路ごとに分けます。次の表はJSON-LDの各項目に対応する設計例です。現在商品のitemも明記する形にして、同じ商品URLへ到達する関係を示しています。

商品分類経路の対応

用途分類経路の対応

二つのリストを設ける場合も、両方の一覧と商品の所属関係を点検します。単に同じデータが二重に出ている状態と、異なる分類を正しく表現している状態は区別してください。商品が載っていない一覧をitemに指定しても、読者が探すための経路は整いません。

導入方法は既存の出力を確認して選ぶ

CMSを使っている場合は、新しい機能を足す前に、既存テーマやプラグインが何を出力しているかを調べます。画面のパンくずとJSON-LDの出力元が別なら、どちらを修正するかを整理します。CMSや契約が有料であることだけでは、必要な機能が標準で備わっているとは判断できません。自社の構成と利用中の機能に合わせて選びましょう。

テスト結果と実際の表示を別々に確認する

構文・導線・表示を分けて判定する

リッチリザルトテストでは、構造化データが検出されるか、必須項目などにエラーがないかを確認します。コード例の検証に加え、実装後は公開URLでも確認してください。編集画面で入力できていても、公開ページへ同じ形で出力されているとは限りません。

続いて、PCとスマホでパンくずのリンクを一つずつ開きます。移動先のURLだけでなく、一覧の掲載内容まで照合しましょう。構文が正常でも、分類とリンク先が正しいとは限りません。最後に、文字切れ、押しやすさ、現在ページの識別を確認します。これらはテストツールの結果だけでは判定できない部分です。

法人サイトの確認票の記入例

この場合、編集担当が「在庫管理分野の記事一覧が期待する戻り先」と確定し、実装担当が画面のhrefと構造化データのitemを確認します。両方が同じ誤ったURLなら両方を直し、片方だけ違うなら不一致の出力元を修正します。修正後は再テストとリンク操作を行い、確認票の判定を更新します。

ECサイトの確認票の記入例

用途の一覧に商品がないときは、コードだけを変更する前に、分類の定義を確認します。梱包作業に使う商品として載せる方針なら一覧の掲載対象を修正し、対象外なら用途経路から外すことが考えられます。分類担当と実装担当が別々に判断すると、次の更新で食い違いが再発するため、決定した理由も残しましょう。

修正する順序の目安

全ページを同じものとして扱わず、サービス詳細、記事、商品詳細などテンプレートごとの代表を選びます。複数経路や長い名称のページも加え、未点検を正常へ含めないようにしてください。修正したページだけでなく、同じ出力元を使う別のページでも再発していないかを見ると、個別修正で終わらず運用へつなげられます。

検索結果の表示とサイト内の使いやすさを評価する

検索表示とサイト内ナビゲーションは別に評価する

Google検索のパンくず表示機能は、PC版に対応しています。スマホの検索結果での表示と、スマホでサイトを閲覧するときのパンくずの使いやすさは、別に考えます。検索結果の見え方にかかわらず、サイト内で分野別の記事一覧や用途別の商品一覧へ移動できる価値はあります。

構造化データに問題がなくても、検索結果にパンくずが必ず表示されるわけではありません。検索に出ないことだけを理由に、意味の通る分類を変更し続けるのは避けましょう。まずサイト内の導線と公開ページの出力を確かめ、次にクロールや検証の状態を確認します。

表示されないときの切り分け

公開後は、Googleがページへアクセスできるかも確認します。テンプレートを変更した直後に検索結果が変わらなくても、再クロールやインデックスの再登録には時間がかかる場合があります。Search Consoleで構造化データの状態を監視し、新しいテンプレートの公開後に無効な項目が増えていないかを見ます。

検索表示の記録には、対象ページ、確認日、検索語、端末、表示された経路、Search Consoleの状態を残します。たとえば「サイト内導線は正常、構文は正常、検索表示は未確認」と分けて記入すれば、何を確認し直すべきかが明確です。表示を確認できた場合も、検索語や端末が違う結果と無条件に比較しないようにしましょう。

順位やクリック率を追う際は、同じ時期の記事更新、検索需要、ほかのサイト改修も確認します。パンくずの変更と同時に数値が動いただけでは、単独の成果とは判断できません。読者が正しい一覧へ移動できるかと、検索でどう表示されるかを分けて記録することが、改善の判断に役立ちます。

設計・実装・運用の担当を決める

小規模なサイトで一人が兼ねる場合も、作業は分けて確認します。分類を決めた人の想定だけで合格にせず、初めて訪れた人のつもりで記事や商品から上位ページへ移動してみてください。カテゴリ追加や商品移動の際には、一覧内容とパンくずの両方を更新する担当も決めておきます。

社内で方針がまとまらないときは、代表ページ、現在の分類図、望ましい経路、確認票を整理すると相談が進みます。「パンくずを付けたい」だけでなく、「分野別一覧へ戻れない」「商品分類と用途分類が混ざる」など、読者が困る場面を具体化することが大切です。サイト設計と内部施策をまとめて見直したい場合は、下記のトミラの支援内容・資料をご覧ください。相談時には、分類整理とテンプレート改修のどこまでを依頼したいかを伝え、対象サイトでの具体的な対応範囲を確認しましょう。

トミラ　SEO運用代行コンサルティング