パンくずリストとは？SEO効果と構造化データの実装・階層設計の判断【2026年時点】

パンくずリストは、サイト内のどの階層を見ているかを「トップ ＞ カテゴリ ＞ 現在のページ」の形で示すナビゲーションです。設置そのものは数行のHTMLで済み、成果を分けるのは階層をどう切るかという設計側にあります。この記事では、位置型・属性型・パス型という3方式の違い、BreadcrumbList構造化データの必須プロパティ、検索結果への表示がパソコン版に限られる2026年時点の仕様、nav要素とaria-currentで満たすアクセシビリティ要件までを実装の順序に沿って整理しました。属性型が重複URLを生む条件と、設置を見送る基準も条件付きで示します。

まとめ：階層設計を先に固め、構造化データは実装後に検証する順序

パンくずリストで先に決めるのは、マークアップの書式ではなく階層の切り方です。Googleの公式ドキュメントは、URL構造をそのまま反映させるのではなく、ユーザーがそのページにたどり着くまでの一般的な経路を示すことを推奨しています。ディレクトリ構造とユーザーの回遊経路が食い違うサイトでは、URLではなく経路のほうを採用してください。

実装は、HTMLのパンくずを先に置き、その表示内容と一致するJSON-LDのBreadcrumbListを後から添える順序が安全です。逆順で構造化データだけを整えると、表示とマークアップがずれたまま気付けません。検証はリッチリザルトテストと、サーチコンソールの拡張レポートの両方を通します。

効果の見積もりは控えめに置いてください。パンくずは単体で順位を押し上げる施策ではなく、クローラーに階層構造を伝え、ユーザーの離脱地点を1つ減らす下支えの位置づけです。2階層しかない小規模サイトでは効果が出ないため、設置を見送る判断も選択肢に入ります。

パンくずリストの定義と位置型・属性型・パス型で分かれる表示方式の違い

同じ「パンくず」でも、3方式は示している情報がまったく異なります。

現在地と経路を示すナビゲーションという定義と童話に由来する呼称

パンくずリストは、閲覧中のページがサイト構造のどこに位置するかを、上位階層へのリンクを並べて示すナビゲーション要素です。英語ではbreadcrumbと呼びます。呼称の由来はグリム童話「ヘンゼルとグレーテル」で、森で道に迷わないようにパンくずを落として帰り道の目印にした場面から来ています。

表示位置はページ上部、グローバルナビゲーションの直下が一般的です。ヘッダーが縦に長いサイトではファーストビューを圧迫するため、ページ下部に置く設計も成立します。ただし上下2か所に同じパンくずを重複配置すると、後述する構造化データとの対応関係が曖昧になるため、原則として1ページに1か所とします。

位置型・属性型・パス型という3方式の違いと採用が分かれる判断軸

3方式は、それぞれ別の情報を表示しています。混同したまま実装すると、意図しない経路を検索エンジンに伝えることになります。

採用の判断はほぼ決まっています。企業サイトやメディアは位置型を選んでください。ECサイトは属性型を併用しますが、条件の組み合わせが増えるほど後述する重複URLの問題が出ます。パス型は訪問者ごとに表示が変わるため、検索エンジンには安定した階層情報を渡せません。実装コストに見合わないので、新規に採用する理由はないと考えてよいでしょう。

サイトマップやグローバルナビとの役割の線引きと併用するときの前提

HTMLサイトマップはサイト全体の目次で、パンくずは現在地の1本の経路だけを示します。前者は「どこに何があるか」、後者は「いま自分がどこにいるか」に答える道具です。グローバルナビゲーションは全ページ共通の入口の並びで、これも現在地は示しません。3つは役割が重ならず、置き換え関係にもなりません。

併用の前提はひとつだけです。パンくずの階層名とグローバルナビのカテゴリ名を一致させてください。ナビでは「サービス」と呼び、パンくずでは「事業内容」と表示するズレがあると、ユーザーは同じ階層を別の場所だと解釈します。この統一は実装前、サイトマップの確定時に済ませておく作業です。

クロール経路の補強と検索結果表示に効くパンくずリストの実効範囲

パンくずが何に効いて何に効かないかを、Googleの公式記述の範囲で切り分けます。

クローラーへ階層構造を伝える内部リンクとしてのパンくずの働き

パンくずは全ページから上位階層へ向かう内部リンクです。下層ページが増えるほど、カテゴリページに集まるリンクの本数が自動的に増えます。手作業でリンクして回る必要がなくなる点が、内部リンク施策としての実利です。

クロール面では、深い階層のページに複数の入口ができます。トップページからのリンク階層が5層あるサイトでも、パンくず経由なら中間のカテゴリページからたどり直せるためです。ただし新規ページの発見速度そのものはXMLサイトマップと内部リンク全体の設計で決まります。パンくずは経路を補強する部品で、クロール頻度を直接引き上げる仕組みではありません。

検索結果でのパンくず表示がパソコン版に限られる2026年時点の仕様

Google検索セントラルのパンくずリスト構造化データのドキュメント（最終更新2026年2月20日UTC）は、この機能について「パソコン版に対応したもので、Google検索を利用できるすべての地域と言語でご利用いただけます」と記載しています。つまり検索結果でのパンくず表示は、現時点でデスクトップ向けの機能として説明されています。

ここを取り違えている解説記事が多くあります。モバイルの検索結果でパンくずが並ぶ前提でクリック率の改善を見積もると、モバイル流入が7割を超えるサイトでは想定が外れます。表示上の見返りはパソコン向けと考え、モバイルについてはページ内での回遊のしやすさに投資の理由を置いてください。

回遊率や滞在時間への影響を過大に見積もらないための実務上の線引き

パンくずのクリック率は、ページ内の他の導線と比べて高いものではありません。記事下の関連記事や本文中のリンクのほうが押されます。パンくずが効くのは、検索結果から直接下層ページに着地した訪問者が「このサイトは何を扱っているのか」を判断する瞬間です。

効果測定でも、クリック数だけを追うと判断を誤ります。見るべきは下層ページの直帰率と、カテゴリページへ遷移した割合です。設置前後で直帰率が数ポイント動けば十分な成果で、二桁の改善を見込む施策ではありません。改善幅が小さいからこそ、実装と保守のコストを抑える設計に寄せます。

BreadcrumbList構造化データの必須プロパティとJSON-LD実装の手順

仕様は公式ドキュメントに明記され、押さえる要件は多くありません。

itemListElementとListItemに求められる3つの必須プロパティ

BreadcrumbListの必須プロパティは itemListElement の1つで、これは順序付きのパンくずの配列です。配列の各要素である ListItem には、item（パンくずが指すページのURL）、name（ユーザーに表示されるパンくずのタイトル）、position（リスト内の位置）の3つが必須として定義されています。

記述形式はJSON-LDを使ってください。GoogleはJSON-LDを推奨しており、HTMLの構造から独立して書けるため、デザイン変更でマークアップが壊れにくくなります。構造化データ全般の考え方と実装範囲については、構造化データとナレッジグラフで検索エンジンに実体を伝える手順を整理した記事で扱っています。

最終項目のitem省略と2件以上という公式ドキュメントの実装要件

実装で迷いやすい2点も、仕様として答えが出ています。1つは現在のページの扱いです。公式ドキュメントは「パンくずがパンくずリストの最後のアイテムである場合、itemは必須ではありません」と明記し、最後のアイテムにitemが含まれていない場合はGoogleがそのページのURLを使うと説明しています。

もう1つは件数です。ListItemは最低2つ必要とされています。トップページ直下の第1階層ページで「トップ ＞ 会社概要」のように2件を並べる構成は要件を満たしますが、現在のページ1件だけのパンくずは無効になります。トップページ自体にパンくずを置く必要がないのは、この件数要件と、示すべき経路が存在しないという理由の両方からです。

到達経路が複数あるページで複数のパンくずリストを併記する判断

1つの記事が複数のカテゴリに属することがあります。公式ドキュメントは「ページに移動する方法がサイト内に複数ある場合は、1つのページに複数のパンくずリストを指定できます」として、複数のBreadcrumbListを並べる記述例を示しています。

ただし併記の判断は慎重にしてください。実装すべきなのは、複数の経路がどちらも主要な入口として機能しているケースです。たとえば製品を「業種別」と「機能別」の2軸で並べているサイトが該当します。一方、タグページのように補助的な分類が並ぶだけであれば、主経路の1本に絞ります。HTML側は1本しか表示しないのに構造化データだけ3本並べる構成は、表示との不一致として避けるべき実装です。

リッチリザルトテストと拡張レポートで実装のズレを検証する順序

検証は2段階で行います。第1段階はリッチリザルトテストで、URLを入力して構文エラーと必須プロパティの欠落を潰します。ここで通ったからといって、表示内容と一致している保証はありません。

1. リッチリザルトテストにURLを入れ、BreadcrumbListが検出されるかを確認する
2. 検出されたnameとpositionが、画面に表示されているパンくずの並びと一字一句一致しているかを目視で照合する
3. サーチコンソールの拡張レポートで、サイト全体のエラー件数と対象URL数の推移を追う

2番目の目視照合を省くと、テンプレートの条件分岐で片方だけカテゴリ名が変わるといった不一致が残ります。全ページを見る必要はなく、テンプレートの種類ごとに1URLずつ確認すれば足ります。

WordPressとフルスクラッチで分かれる実装方法と保守コストの差

実装手段の選択は、階層が今後変わるかどうかで決まります。

WordPressのテーマとプラグインで出力する場合の設定と注意点

WordPressでは、多くのテーマがパンくずの出力機能を持ち、SEO系プラグインも同等の機能を備えています。両方を有効にすると、HTMLのパンくずが二重に表示されたり、BreadcrumbListが2セット出力されたりします。テーマ側かプラグイン側のどちらか一方に寄せてください。

もう1つの注意点は、投稿が複数カテゴリに属する場合の挙動です。標準的な出力は複数カテゴリのうち1つを機械的に選び、その基準は実装依存のため、意図した主カテゴリと一致しないことがあります。カテゴリを1記事1つに運用で固定するか、主カテゴリを明示指定できる実装を選んでください。

HTMLとJSON-LDを二重に持つ構成でズレを防ぐ実装ルール

HTMLの表示とJSON-LDを別々に書くと、片方だけ更新される事故が起きます。カテゴリ名を「事例紹介」から「導入事例」に変えたときに、表示は変わったのに構造化データは旧名のまま、という状態です。

これを防ぐ実装ルールは1つです。表示とマークアップを同じデータソースから生成してください。テンプレート側でパンくずの配列を1度だけ組み立て、その配列をHTMLの描画とJSON-LDの生成の両方に渡す構造にします。テンプレートエンジンを使うフルスクラッチ開発なら数十行で済み、カテゴリ改称のたびに2か所を直す運用から解放されます。

nav要素とaria-currentで満たすアクセシビリティの要件

W3CのWAI-ARIA Authoring Practices Guideは、パンくずの経路をnavigationランドマーク領域の内側に置き、その領域をaria-labelまたはaria-labelledbyでラベル付けするよう定めています。ページ内には複数のnavigation領域が存在しうるため、ラベルがないとスクリーンリーダーの利用者はどのナビゲーションかを区別できません。

現在のページへのリンクには aria-current をpageに設定します。同ガイドでは、現在のページを表す要素がリンクでない場合、aria-currentの設定は任意です。パンくずの末尾はリンクにしない実装が一般的なので、その場合は属性を付けなくても要件を満たします。キーボード操作については固有の仕様は定義されておらず（Not applicable）、通常のリンクとしてタブ移動できれば問題ありません。区切り記号は装飾なので、画像ではなくCSSの疑似要素で描くと読み上げに混ざりません。

URL階層と回遊経路が食い違うサイトでのパンくず設計と重複の抑制

ここからは設計側の判断です。実装より先に決めるべき論点が3つあります。

URL構造をそのまま反映せず一般的な経路を示すという原則の運用

Googleのガイドラインは「URL構造をそのまま反映させるのではなく、ユーザーが特定のページにたどり着くまでの一般的な経路を示すことをおすすめします」としています。CMSの都合でURLが平坦なサイト、逆にディレクトリだけ深いサイトでは、この原則が効きます。

判断の手順はこうです。まず解析ツールで、対象ページへの流入元と、その前後に見られているページを確認します。検索から直接着地する割合が高いページなら、サイト内の論理的な分類をそのまま階層にします。サイト内回遊で到達するページなら、実際に多くたどられている経路を採用してください。URLの階層とパンくずの階層が一致しなくても、Googleのガイドライン上の問題にはなりません。

属性型パンくずが生む重複URLとクロール効率の低下に対する対処

ECサイトで属性型を採用すると、絞り込み条件の組み合わせだけURLが生成されます。色3種、サイズ5種、価格帯4区分なら単純計算で60通り。ここに並び順のパラメータが加わると、実質的に同じ商品一覧が数百URLに増えます。クローラーの巡回予算が薄く広く分散し、肝心の商品詳細ページの更新検知が遅れます。

対処は2段構えにしてください。第1に、パンくずを出す絞り込み軸を主要な1〜2軸に限定し、それ以外の組み合わせページにはパンくずも構造化データも出力しない設計が適切です。第2に、組み合わせページ側でcanonicalを主要カテゴリに向け、必要に応じてrobots.txtでパラメータ付きURLのクロールを抑えます。全パターンにパンくずを付けて回遊性を高めようとする設計は、規模が大きいECほど裏目に出ます。

階層が深いECサイトでパンくずを3〜4層に畳むときの判断基準

商品分類が6層、7層と続くサイトでは、パンくずをそのまま並べると1行に収まらず、スマートフォンでは折り返しが3行に達します。表示上は3〜4層に畳むのが実務的な落としどころです。畳み方には優先順位があります。

• 最上位のトップは残す（サイト全体の入口として機能するため）
• 中間の抽象度が高い階層から省く（「商品」「カテゴリ一覧」など、単独では意味を持たない層）
• 現在のページの直上カテゴリは必ず残す（最も押される階層のため）

省いた中間層を構造化データにだけ残す実装は表示との不一致になるため、畳むなら両方から同じ階層を落とします。中間層への導線が要るなら、カテゴリページ内のサブカテゴリ一覧で担保するほうがユーザーの目にも入ります。

パンくずリストを設置しても効果が出ないサイトの条件と見送りの判断

最後に、設置しないという判断が正しい場面を条件付きで示します。

2階層しかないLPや小規模サイトでパンくずの設置を見送る具体的な条件

次の3条件がすべて当てはまるサイトでは、パンくずを設置しても得られるものがありません。総ページ数が20ページ未満であること、階層がトップと下層の2層で終わっていること、グローバルナビゲーションから全ページに1クリックで到達できること。この状態では、パンくずが示す経路は「トップ ＞ 現在のページ」の1パターンしか存在せず、ナビゲーションの内容と完全に重複します。

単一ページのランディングページも同様です。構造化データの要件であるListItem2件を満たすためだけに架空の中間階層を作るのは、本末転倒になります。導入すべきタイミングは、下層ページが増えてカテゴリ分けが必要になった時点です。サイト公開時点で無理に組み込む必要はありません。

パンくずより先に着手すべき内部施策の優先順位と判断するための目安

パンくずは内部施策の中で優先度が高い部類ではありません。先に手を付けるべきものが明確にあります。インデックスされていないページの解消、タイトルタグと見出し構造の整理、モバイルでの表示速度、そして本文中の内部リンク設計です。これらが未着手のままパンくずだけ整えても、順位への寄与はほぼ観測できません。パンくず以外のどの型に投資すべきかは、構造化データの投資優先順位と型ごとの判断基準で扱っています。

判断の目安は、サーチコンソールでインデックス未登録のページが全体の1割を超えているかどうか。超えているなら原因の特定が先です。内部施策全体の優先順位づけは、クロール・インデックス・UXの3分類で施策を並べたSEO内部対策の解説で扱っています。パンくずは、その中で「サイト構造が固まった後に一度だけ入れる」性質の作業です。

サイト構造そのものを設計し直す場合に外部委託を決める判断の線引き

パンくずの階層をどう切るか決められないとき、本当の課題はパンくずではなくサイト構造にあります。カテゴリの粒度がばらばら、同じ内容のページが別カテゴリに散在している、URLの階層と実際の情報設計が3世代分ずれている。こうした状態で表示だけ整えても、示す経路そのものが正しくありません。

外部に出す線引きは、対象ページ数と分類の再設計が必要かどうかで引いてください。50ページ未満で分類がおおむね機能しているなら、社内でカテゴリ名を統一してテンプレートを直すだけで足ります。300ページを超え、カテゴリの統廃合とURLの変更を伴うなら、リダイレクト設計まで含めて外部の手を借りる範囲です。当社ではサイト構造の見直しを含むSEO内部施策とキーワード設計を、制作・改修とあわせて請け負っています。既存サイトの階層を棚卸ししたうえで、パンくずを含む内部リンクの設計から実装まで通して対応できます。

よくある質問

パンくずリストの導入時に検索されることが多い論点を5つ挙げます。

パンくずリストを設置すると検索順位は上がりますか？

パンくずリスト単体で順位が上がる仕組みはありません。Googleはパンくずのマークアップを、検索結果内のウェブページからの情報を分類する用途で使うと説明しています。順位への寄与は、上位カテゴリへの内部リンクが全ページに増えることによる間接的なものに留まります。順位改善が目的なら、インデックス状況の解消や本文の内部リンク設計を先に見直してください。

構造化データだけ入れればHTMLのパンくずは不要ですか？

両方を置いてください。Googleのドキュメントは、ページ本文内のパンくずリストマークアップを使うと記載しており、表示内容とマークアップの一致を前提にしています。HTMLの表示がないまま構造化データだけを置く構成は、ユーザーには何の情報も与えません。

トップページにもパンくずリストは設置すべきですか？

不要です。BreadcrumbListはListItemを最低2つ必要とするため、トップページ単独では要件を満たしません。サイトの起点であり、そこに至る上位階層が存在しない以上、示すべき経路もありません。トップページ以外のすべてに設置する構成が標準的な設計です。

パンくずリストが検索結果に表示されないのはなぜですか？

原因は3つに分かれます。1つ目は、検索結果でのパンくず表示がパソコン版向けの機能として案内されている点で、モバイルの検索結果を見ている場合は仕様上の挙動です。2つ目は構造化データの不備で、リッチリザルトテストで必須プロパティの欠落を確認します。3つ目は、マークアップが正しくてもGoogleが表示形式を決めるため、必ず表示される保証はないという性質によるものです。

パンくずリストとHTMLサイトマップはどちらを優先すべきですか？

役割が違うため比べる対象ではありませんが、着手順を1つ選ぶならパンくずです。パンくずは全ページに自動で入るのに対し、HTMLサイトマップは1ページを作って更新し続ける運用が発生します。ページ数が100を超えて全体像が把握しにくくなった段階で、追加を検討してください。検索エンジン向けにはXMLサイトマップが別途必要です。

関連記事

• SEO対策とは？仕組み・3つの施策と成果までの進め方を実務目線で解説：内部施策がSEO全体のどこに位置づくかを俯瞰できます。
• キーワード選定のやり方とは？3つの評価軸と実践手順・失敗例を解説：階層名に使うカテゴリ語を決める前段の作業です。
• AI Overview対策とは？AIに引用される記事構造と企業サイトの打ち手：構造化データとサイト構造がAI検索での引用にどう関わるかを扱います。