EN
JP
KRパンくずリストSEO完全ガイド｜設置方法・構造化データ・階層設計を解説
パンくずリストとは、現在表示しているページがウェブサイト内のどこに位置しているかを示す階層型の案内です。「ホーム ＞ SEO ＞ 内部対策 ＞ パンくずリスト」のように、上位ページから現在のページまでを順番に表示します。利用者はパンくずリストを見ることで現在地を把握し、一つ上のカテゴリや関連する上位ページへ簡単に移動できます。
SEOにおけるパンくずリストの役割は、検索順位を直接上げるための特殊な設定ではありません。利用者がサイト内を移動しやすくなること、検索エンジンがリンクを通じてページを発見できること、ページ同士の階層関係を伝えやすくなることが主な役割です。Googleも、パンくずリストはページのサイト階層上の位置を示し、利用者がサイトを理解して探索する際に役立つと説明しています。
また、パンくずリストをBreadcrumbListの構造化データで記述すると、Googleがページの階層を理解するための追加情報を提供できます。ただし、2025年1月23日以降、Googleはモバイル検索結果でパンくずリストを表示せず、ドメイン名だけを表示する仕様へ変更しました。デスクトップ検索結果では引き続きパンくずリストが表示される可能性があるため、現在も正しく実装する価値があります。
1. パンくずリストとは
パンくずリストを適切に設計するには、単なるページ上部のリンク一覧ではなく、サイト構造を利用者へ伝える案内として理解する必要があります。表示位置、階層、リンク文字、現在ページの扱いによって、使いやすさと検索エンジンへの伝わり方が変わります。
1.1 パンくずリストの役割
パンくずリストは、利用者に現在のページがどのカテゴリに属しているかを示します。検索結果や外部サイトから下層ページへ直接訪問した利用者は、トップページから順番に移動してきたわけではありません。そのような利用者に対しても、サイト全体の中での現在地をすぐに伝えられます。
Googleは、パンくずリストをページのサイト階層上の位置を示す案内として説明しています。最後の項目から一階層ずつ上へ移動できるため、戻るボタンとは異なり、サイト構造に沿った移動を提供できます。
1.2 名称の由来
パンくずリストという名称は、物語の登場人物が帰り道を見つけるためにパンくずを落とした話に由来します。ウェブサイトでは、利用者が通ってきた経路や、現在地までの階層を示す案内としてこの名称が使われています。
ただし、実際のSEO施策では、必ずしも利用者が通ってきた履歴を表示するわけではありません。多くのサイトでは、閲覧履歴ではなく、ホーム、カテゴリ、下位カテゴリ、現在ページという固定された階層を表示します。
1.3 一般的な表示形式
一般的なパンくずリストは、ホームから現在ページまでを左から右へ並べます。それぞれの階層は「＞」「/」「›」などの区切り記号で分け、現在ページ以外の項目にはリンクを設定します。
| 階層 | 表示例 | リンク |
|---|---|---|
| 第1階層 | ホーム | あり |
| 第2階層 | SEO | あり |
| 第3階層 | 内部対策 | あり |
| 現在ページ | パンくずリストSEO | なし、または自己参照を避ける |
区切り記号は文字だけで表現することもできますが、視覚的な装飾として疑似要素を使用する方法もあります。読み上げ支援機能が不要な区切り記号まで読み上げないよう、見た目と文書構造を分けて実装することが重要です。
1.4 パンくずリストと主メニューの関係
主メニューは、サイト内の主要カテゴリや重要ページへ移動するための全体的な案内です。一方、パンくずリストは、現在ページの上位階層を示す局所的な案内です。両者は役割が異なるため、主メニューがあってもパンくずリストが不要になるわけではありません。
主メニューにはサイト全体で共通するリンクを置き、パンくずリストには現在ページと関係する階層だけを置きます。パンくずリストへキャンペーンページや問い合わせページなど、階層と無関係なリンクを追加すると、現在地を示す役割が曖昧になります。
1.5 パンくずリストとサイトマップの関係
パンくずリストは、現在ページから上位階層へ移動するための案内です。HTMLサイトマップは、サイト内の主要ページを一覧で案内するページであり、XMLサイトマップは検索エンジンへURL一覧を伝えるファイルです。
| 項目 | パンくずリスト | HTMLサイトマップ | XMLサイトマップ |
|---|---|---|---|
| 主な対象 | 利用者と検索エンジン | 主に利用者 | 主に検索エンジン |
| 主な目的 | 現在地と上位階層を示す | 主要ページを一覧表示 | 登録対象URLを通知 |
| 表示場所 | 各ページ | 独立した案内ページ | XMLファイル |
| リンク範囲 | 現在ページの上位階層 | サイト全体 | 登録対象URL |
これらは代替関係ではありません。パンくずリストを実装したからXMLサイトマップが不要になるわけではなく、XMLサイトマップがあるから内部リンクを省略してよいわけでもありません。
2. パンくずリストがSEOに与える効果
パンくずリストを設置しただけで検索順位が必ず上がるわけではありません。しかし、内部リンク、クロール、階層理解、利用者体験を改善する要素として、SEOの土台を支える働きがあります。
2.1 ページの発見を助ける
Googleはリンクを使って新しいページを発見し、ページ同士の関連性を理解します。パンくずリストのリンクが通常のa要素として実装されていれば、検索エンジンが上位カテゴリページをたどれる状態を作れます。
一方、JavaScriptのクリック処理だけで移動させる実装や、リンク先を持たない文字列では、通常の内部リンクとして十分に機能しない場合があります。上位階層へ移動させる項目は、クロール可能なURLを持つリンクとして記述してください。
2.2 サイト階層を伝えやすくする
パンくずリストは、ページがどのカテゴリに含まれるかを明示します。たとえば、商品ページに「ホーム ＞ 家電 ＞ 掃除機 ＞ 商品名」と表示すれば、その商品が家電カテゴリ内の掃除機に属することを利用者へ伝えられます。
ただし、Googleがサイト階層を判断する材料はパンくずリストだけではありません。主メニュー、カテゴリリンク、本文リンク、関連商品リンクなど、サイト全体のリンク関係も分析されます。Googleは、電子商取引サイトの構造を理解する際、URL構造よりもページ間のリンク関係を分析すると説明しています。
2.3 上位カテゴリへ内部リンクを集める
下層ページすべてからカテゴリページへパンくずリンクを設定すると、上位カテゴリへ継続的に内部リンクが集まります。多数の商品ページを持つ電子商取引サイトでは、商品からカテゴリへ戻る経路として特に有効です。
ただし、リンク数だけを増やす目的で不要な階層を追加してはいけません。Googleは、サイト内で多くのリンクを受けるページを相対的に重要なページとして理解する場合がありますが、実際の情報構造に合ったリンクであることが前提です。
2.4 利用者の回遊を助ける
検索から記事や商品ページへ直接訪問した利用者は、読み終えた後に関連カテゴリを見たい場合があります。パンくずリストから上位カテゴリへ移動できれば、サイト内検索や戻る操作を使わずに関連情報を探せます。
回遊率や滞在時間を機械的に上げることが目的ではありません。利用者が必要なページへ短い操作で移動できる状態を作ることが重要です。不要なページを何度も経由させる設計は、数値上の閲覧ページ数が増えても良い体験とはいえません。
2.5 検索結果でページの文脈を伝える
Googleは、パンくずリストの構造化データを検索結果上の表示に利用する場合があります。デスクトップ検索では、長いURLの代わりにサイト内の階層が表示されることで、利用者がページの内容や所属カテゴリを判断しやすくなる可能性があります。
ただし、正しい構造化データを実装しても、検索結果への表示は保証されません。Googleは、構造化データが利用可能な検索表示の資格を与えるものであり、必ず表示される機能ではないと説明しています。
3. パンくずリストの種類と違い
パンくずリストには、階層を示す形式、閲覧履歴を示す形式、商品属性を示す形式があります。SEOとサイト構造の理解を目的とする場合は、階層型が中心になりますが、サイトの性質によってほかの形式が補助的に使われます。
3.1 階層型パンくずリストとは
階層型パンくずリストは、サイトの上位階層から現在ページまでを表示します。「ホーム ＞ 記事カテゴリ ＞ 小カテゴリ ＞ 記事名」のように、サイト管理者が定義した情報構造に基づいて表示されます。
| 項目 | 階層型パンくずリスト |
|---|---|
| 表示内容 | サイト内の固定階層 |
| 主な用途 | 記事、商品、サービス、資料 |
| SEOとの関係 | 内部リンクと階層理解を支援 |
| 表示の安定性 | 訪問経路に関係なく一定 |
| 推奨場面 | 多くの一般的なウェブサイト |
Googleが案内するBreadcrumbListも、ページのサイト階層上の位置を表すものです。SEOを意識したパンくずリストでは、基本的に階層型を優先します。
3.2 履歴型パンくずリストとは
履歴型パンくずリストは、利用者が実際に閲覧したページの順序を表示します。「検索結果 ＞ 比較ページ ＞ 商品ページ」のように、同じページでも利用者の訪問経路によって内容が変わります。
| 項目 | 履歴型パンくずリスト |
|---|---|
| 表示内容 | 利用者が通過したページ |
| 主な用途 | 戻る操作の補助 |
| SEOとの関係 | 固定階層を伝えにくい |
| 表示の安定性 | 訪問経路によって変化 |
| 主な注意点 | 検索エンジン向け階層表示には不向き |
履歴型はブラウザの戻る操作と役割が重なりやすく、ページの固定された階層を示しません。そのため、構造化データとしてのパンくずリストには、履歴ではなくサイト上の論理的な階層を使用するほうが適しています。
3.3 属性型パンくずリストとは
属性型パンくずリストは、商品や検索結果に適用した条件を表示します。「靴 ＞ レディース ＞ 黒 ＞ 24センチ」のように、カテゴリと絞り込み条件を組み合わせます。
| 項目 | 属性型パンくずリスト |
|---|---|
| 表示内容 | カテゴリ、色、サイズ、価格帯など |
| 主な用途 | 商品検索、絞り込み検索 |
| SEOとの関係 | 条件付きページの整理が必要 |
| 表示の安定性 | 選択条件によって変化 |
| 主な注意点 | URL重複や組み合わせ増加 |
属性をすべてリンク化すると、色、サイズ、価格、ブランドの組み合わせごとに大量のURLが生成される場合があります。検索需要と独自価値のない組み合わせまで登録対象にすると、重複やクロール負担を増やすため注意が必要です。
3.4 階層型と履歴型の違い
階層型は「このページがサイト内のどこにあるか」を示し、履歴型は「利用者がどこを通ってきたか」を示します。同じ商品ページでも、階層型の表示は原則として一定ですが、履歴型の表示は利用者ごとに変化します。
| 比較項目 | 階層型 | 履歴型 |
|---|---|---|
| 基準 | サイト構造 | 閲覧履歴 |
| 表示内容 | 原則として固定 | 利用者ごとに変化 |
| 上位カテゴリ | 明確に示せる | 必ずしも示せない |
| 構造化データ | 適している | 通常は適さない |
| SEOでの優先度 | 高い | 低い |
SEOのために一つだけ実装する場合は、階層型を選びます。履歴型を追加する場合も、固定階層のパンくずリストを置き換えず、別の戻り導線として扱うほうが分かりやすくなります。
3.5 階層型と属性型の違い
階層型はサイト管理者が定義した親子関係を示し、属性型は利用者が選択した条件を示します。商品が一つのカテゴリに所属していても、複数の色、用途、価格帯を持つため、属性型では複数の見せ方が生まれます。
| 比較項目 | 階層型 | 属性型 |
|---|---|---|
| 基準 | カテゴリ階層 | 商品や検索の条件 |
| URL数 | 比較的管理しやすい | 組み合わせで増えやすい |
| 現在地 | 明確 | 条件によって変化 |
| 適したページ | 記事、商品詳細 | 絞り込み結果 |
| 重複対策 | 比較的単純 | 正規URLや登録制御が重要 |
属性型を導入する場合は、表示上の便利さと検索登録対象を分けて考えます。利用者が使える絞り込み条件であっても、そのすべてを検索結果へ登録する必要はありません。
4. Google検索結果におけるパンくず表示
パンくずリストのSEOを考えるときは、ウェブページ上の表示とGoogle検索結果上の表示を分ける必要があります。ページ上で役立つパンくずリストが、必ず同じ形で検索結果に表示されるわけではありません。
4.1 デスクトップ検索での表示
Googleは、デスクトップ検索結果でパンくずリストを表示する場合があります。ページのURLをそのまま表示する代わりに、サイト名とカテゴリ階層が表示されれば、利用者はページの文脈を判断しやすくなります。
表示される階層や文字列は、必ずしもページ上の表示と完全に一致するとは限りません。Googleは構造化データ、ページ内容、サイト構造などを基に検索結果を生成するため、実装者が表示内容を完全に固定することはできません。
4.2 モバイル検索での表示変更
Googleは2025年1月23日から、モバイル検索結果にパンくずリストを表示せず、ドメイン名だけを表示する変更を全言語・全地域で展開しました。小さな画面ではパンくずが途中で切れ、利用者に十分な情報を提供できないことが変更理由として説明されています。
| 検索環境 | パンくず表示 |
|---|---|
| デスクトップ検索 | 表示される可能性がある |
| モバイル検索 | 2025年1月以降は非表示 |
| ページ上のパンくず | 端末に関係なく実装可能 |
| 構造化データ | 引き続きGoogleが対応 |
モバイル検索結果で表示されなくなったからといって、ページ上のパンくずリストを削除する必要はありません。サイト内移動、階層理解、デスクトップ検索表示では引き続き役割があります。
4.3 構造化データと表示保証の違い
BreadcrumbListを正しく記述すると、Googleがパンくずリスト情報を利用できる状態になります。しかし、構造化データの実装は検索結果への表示を保証するものではありません。
Googleは、検索履歴、地域、端末、検索内容など複数の要素に応じて検索結果の形式を選びます。リッチリザルトテストで有効と判定されても、通常のURL表示や別の検索表示が選ばれる場合があります。
4.4 検索結果用と画面表示用の違い
画面上のパンくずリストは、利用者がクリックして移動するためのものです。構造化データは、パンくずの各項目、順序、名前、URLを検索エンジンへ明示するための記述です。
| 項目 | 画面上のパンくず | 構造化データ |
|---|---|---|
| 主な利用者 | ウェブサイト訪問者 | 検索エンジン |
| 表現方法 | HTMLとCSS | JSON-LDなど |
| クリック | 可能 | 直接は操作しない |
| 視認性 | 画面上に表示 | 通常は画面に表示しない |
| 内容 | 利用者が確認可能 | 画面内容と一致させる |
構造化データだけを追加し、画面上にはパンくずリストを表示しない実装は避けるほうが安全です。Googleの構造化データ品質指針では、利用者に見えない内容を記述しないよう求めています。
4.5 長いURLとの関係
パンくずリストを実装しても、URLを無理に階層と完全一致させる必要はありません。Googleは、サイト構造を理解する際にURL文字列だけでなく、ページ間のリンク関係を分析します。
ただし、利用者が理解しやすく、管理しやすい簡潔なURL構造を作ることには価値があります。Googleも、人が理解しやすい論理的で単純なURL構造を推奨しています。
5. SEOに強い階層設計
パンくずリストの品質は、元となるサイト階層の品質によって決まります。複雑で一貫性のないサイト構造を、パンくずリストの表示だけで修正することはできません。
5.1 一つの中心テーマでカテゴリを作る
カテゴリページには、同じ目的や主題を持つページをまとめます。「SEO」「広告」「人事」「会社情報」のように異なる目的のページを一つのカテゴリへ混在させると、カテゴリの意味が分かりにくくなります。
パンくずリストはカテゴリ名をすべての下層ページへ表示するため、曖昧なカテゴリ名はサイト全体へ広がります。カテゴリ名だけを見ても、どのような情報が含まれているか判断できる状態を作ってください。
5.2 階層を深くしすぎない
階層が深すぎると、パンくずリストが長くなり、利用者が現在地を把握しにくくなります。「ホーム ＞ 情報 ＞ マーケティング ＞ 集客 ＞ 検索 ＞ SEO ＞ 内部対策 ＞ パンくず」のような構造は、分類が細かすぎる可能性があります。
| 階層数 | 主な状態 |
|---|---|
| 2階層 | 小規模サイトや単純な構造に向く |
| 3～4階層 | 一般的な記事・商品サイトで管理しやすい |
| 5階層以上 | 大規模サイトでは必要な場合がある |
| 過度な階層 | 到達経路と管理が複雑になりやすい |
重要なのは、固定された理想の階層数ではありません。利用者がどの分類から目的ページを探すかを基準にし、意味のない中間カテゴリを作らないようにします。
5.3 空の中間カテゴリを作らない
パンくずリストの階層を整える目的だけで、内容のないカテゴリページを作成してはいけません。カテゴリ名と数件のリンクだけで、利用者への説明や選択肢がないページは、移動先として十分な価値を提供できません。
中間カテゴリには、カテゴリの説明、代表的な下位カテゴリ、選び方、主要ページへの導線を用意します。カテゴリ自体に検索需要がなくても、利用者が次のページを選べる案内ページとして役立つ内容が必要です。
5.4 親ページと子ページの関係を統一する
同じ記事が複数カテゴリに属する場合、パンくずリストの親をどこにするかを決める必要があります。ページごとに担当者が自由に親カテゴリを選ぶと、サイト内で階層の基準が変わります。
主題、利用者の探索経路、内部リンク構造を基準に、代表となる親カテゴリを一つ決めてください。複数のパンくず経路を構造化データで示すことも可能ですが、管理が複雑になるため、明確な理由がある場合に限定します。Googleの公式例でも、一つのページに複数のパンくず経路を記述する形式が案内されています。
5.5 URL階層と表示階層を無理に一致させない
/column/12345/のようなURLでも、画面上では「ホーム ＞ SEO ＞ パンくずリスト」と表示できます。パンくずリストは利用者にとって意味のある分類を示すものであり、URL文字列をそのまま分割して表示するものではありません。
一方、URLと表示階層が大きく異なる状態が大量に存在すると、運用担当者が管理しにくくなります。新規サイトでは、可能な範囲でカテゴリ、内部リンク、パンくず、URLの考え方をそろえておくと保守しやすくなります。
6. パンくずの名称とリンク文字
パンくずリストには、短く分かりやすい階層名を使用します。検索語を詰め込むことよりも、クリックした先に何があるかを利用者が判断できることが重要です。
6.1 カテゴリ内容を表す名称を使う
「お役立ち情報」「記事一覧」「その他」のような名称は、含まれる内容が分かりにくい場合があります。「SEO対策」「構造化データ」「採用ノウハウ」のように、カテゴリの中心テーマを表す名称を使用してください。
カテゴリ名は、パンくずリストだけでなく、ページタイトル、主メニュー、見出し、内部リンクにも使われます。名称を変更する場合は、サイト内の表記をまとめて更新し、同じカテゴリに複数の呼び方が混在しないようにします。
6.2 キーワードを詰め込まない
「SEO対策・検索順位向上・Google上位表示・集客改善」のように、複数の検索語をパンくずへ詰め込むと読みにくくなります。パンくずリストは説明文ではなく、階層を示す短い案内です。
Googleは、リンク文字について簡潔で、リンク先に関連し、前後の文脈を理解できる表現を推奨しています。パンくずでも、短く具体的なカテゴリ名を使用することが適しています。
6.3 同じ階層名を統一する
ページによって「SEO」「SEO対策」「検索最適化」のように異なる表記を使うと、同じカテゴリか別カテゴリか分かりにくくなります。表示名を一つ決め、パンくず、主メニュー、カテゴリ見出しで統一してください。
正式名称が長い場合は、短縮名を利用できます。ただし、短縮名が一般利用者に伝わらない場合は、カテゴリページの見出しや説明文で正式名称との関係を示します。
6.4 現在ページ名を長くしすぎない
記事タイトルをそのままパンくずの最終項目へ表示すると、スマートフォンで複数行になり、上位階層が見えにくくなる場合があります。タイトルが長いページでは、パンくず用の短い名称を別に設定する方法があります。
| ページタイトル | パンくず表示 |
|---|---|
| パンくずリストSEO完全ガイド｜効果と実装方法 | パンくずリストSEO |
| WordPressで構造化データを設定する方法 | WordPress実装 |
| 電子商取引サイトのカテゴリ設計完全版 | カテゴリ設計 |
短縮するときは、内容が別の意味にならないようにします。短すぎる「詳細」「方法」「解説」だけでは、現在ページを識別できません。
6.5 区切り記号をリンク文字に含めない
「SEO ＞」全体をリンクにするのではなく、「SEO」だけをリンクにし、区切り記号は別要素またはCSSで表示します。これにより、リンク文字がカテゴリ名だけになり、読み上げや操作時の意味も明確になります。
区切り記号にはaria-hidden="true"を使用する方法があります。ただし、パンくず全体の階層関係は順序付き一覧で表現し、見た目だけに依存しない構造にしてください。
7. HTMLでパンくずリストを実装する方法
画面上のパンくずリストは、意味のあるHTMLで実装します。nav、順序付き一覧、リンク、現在ページを示す属性を組み合わせることで、利用者と支援技術へ役割を伝えられます。
7.1 nav要素で案内領域を示す
パンくずリスト全体をnav要素で囲み、aria-labelで案内の種類を示します。ページ内に主メニューや目次など複数のnavが存在する場合でも、それぞれの役割を識別できます。
HTMLの実装例
<nav aria-label="パンくずリスト">
<ol class="breadcrumb">
<li class="breadcrumb__item">
<a href="/">ホーム</a>
</li>
<li class="breadcrumb__item">
<a href="/seo/">SEO</a>
</li>
<li class="breadcrumb__item">
<a href="/seo/internal/">内部対策</a>
</li>
<li class="breadcrumb__item" aria-current="page">
パンくずリストSEO
</li>
</ol>
</nav>
divだけでも見た目は作れますが、navを使うことで案内領域であることが明確になります。階層には順序があるため、ulよりもolが意味に合います。
7.2 a要素に実際のURLを設定する
上位階層の項目には、hrefを持つ通常のa要素を使用します。Googleは、href属性を持つa要素をクロール可能なリンクとして推奨しています。
クロール可能なリンク
<a href="/seo/">SEO</a>
避けたい実装
<span onclick="location.href='/seo/'">SEO</span>
JavaScriptを使う必要がある場合でも、基本となる移動先はhrefに設定してください。装飾や計測のためにクリック処理を追加する場合も、通常のリンク動作を壊さないようにします。
7.3 現在ページをaria-currentで示す
最後の項目にはaria-current="page"を設定し、現在表示中のページであることを示します。通常、現在ページへ自己参照リンクを設定する必要はありません。
現在ページの例
<li class="breadcrumb__item" aria-current="page">
パンくずリストSEO
</li>
自己参照リンクが直ちにSEO上の問題になるわけではありませんが、クリックしても同じページを再読み込みするだけです。利用者にとって意味のない操作になるため、文字列として表示する方法が分かりやすくなります。
7.4 CSSで区切り記号を表示する
区切り記号は、各項目のHTMLへ直接書く方法と、CSSの疑似要素で表示する方法があります。CSSを利用すると、読み上げ支援機能に不要な記号を読ませず、見た目だけを調整できます。
CSSの実装例
.breadcrumb {
display: flex;
flex-wrap: wrap;
gap: 0.5rem;
margin: 0;
padding: 0;
list-style: none;
}
.breadcrumb__item:not(:last-child)::after {
content: "›";
margin-left: 0.5rem;
}
.breadcrumb a {
text-decoration: underline;
text-underline-offset: 0.2em;
}
文字サイズを小さくしすぎたり、背景色との明度差を小さくしたりすると、利用者が読めません。パンくずリストを補助的な案内として扱いながらも、操作可能なリンクとして十分に見えるデザインにしてください。
7.5 長いパンくずをスマートフォンへ対応させる
長いパンくずを一行に固定すると、画面外にはみ出す場合があります。折り返しを許可する、途中の階層を省略表示する、横方向へ移動できるようにするなど、サイトに合った対応が必要です。
ただし、CSSで非表示にした階層と構造化データの内容が大きく異なる状態は避けてください。省略記号を使う場合も、利用者が必要に応じて全階層を確認できる仕組みを検討します。
8. BreadcrumbList構造化データの実装
BreadcrumbListは、パンくずリストを順序付きのページ列として記述するSchema.orgの種類です。通常はListItemを使い、各階層の位置、名称、URLを記述します。
8.1 JSON-LDで記述する
Googleは、構造化データの対応形式としてJSON-LD、マイクロデータ、RDFaを案内しており、JSON-LDを推奨形式としています。
JSON-LDの実装例
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "ホーム",
"item": "https://example.jp/"
},
{
"@type": "ListItem",
"position": 2,
"name": "SEO",
"item": "https://example.jp/seo/"
},
{
"@type": "ListItem",
"position": 3,
"name": "内部対策",
"item": "https://example.jp/seo/internal/"
},
{
"@type": "ListItem",
"position": 4,
"name": "パンくずリストSEO"
}
]
}
</script>
Googleの公式例では、最後の項目はitemを省略できます。現在ページのURLを記述する実装も見られますが、少なくともpositionとnameを正しい順序で設定してください。
8.2 positionを連続した数字にする
positionは、パンくずリスト内での順番を表します。Schema.orgは、記述順だけでは項目順を十分に示せないため、ListItemのpositionを使用するよう説明しています。
| 階層 | position |
|---|---|
| ホーム | 1 |
| SEO | 2 |
| 内部対策 | 3 |
| 現在ページ | 4 |
途中を飛ばして1、2、4、5と記述したり、すべて同じ数字にしたりしないようにします。テンプレートで自動生成する場合は、階層数に応じて連続した数字が出力されるか確認してください。
8.3 nameを画面表示と一致させる
構造化データのnameには、各階層の名称を設定します。画面上では「SEO」と表示しているのに、構造化データでは「検索エンジン最適化サービス」と記述するような大きな不一致は避けてください。
Googleの構造化データ品質指針では、構造化データはページ内容を正確に表し、利用者に表示されている内容と一致する必要があります。検索結果の見栄えだけを目的に、別の名称や無関係なキーワードを追加してはいけません。
8.4 itemに正規URLを使用する
各itemには、その階層を表すページの絶対URLを記述します。httpとhttps、末尾のスラッシュ、別ドメイン、転送URLが混在しないようにしてください。
正規URLを使う例
{
"@type": "ListItem",
"position": 2,
"name": "SEO",
"item": "https://example.jp/seo/"
}
構造化データ内のURL、画面上のリンク、正規URL指定、XMLサイトマップのURLを可能な限り統一します。転送先URLではなく古いURLを出力し続けると、保守状態を確認しにくくなります。
8.5 複数経路を記述する
一つのページが複数の階層から到達される場合、複数のBreadcrumbListを配列で記述できます。たとえば、一冊の書籍が「受賞作品」と「ジャンル」の両方に属する場合です。Googleのパンくずリスト資料にも複数経路の記述例があります。
複数経路の例
<script type="application/ld+json">
[
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "書籍",
"item": "https://example.jp/books/"
},
{
"@type": "ListItem",
"position": 2,
"name": "小説",
"item": "https://example.jp/books/novels/"
},
{
"@type": "ListItem",
"position": 3,
"name": "作品名"
}
]
},
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "受賞作品",
"item": "https://example.jp/awards/"
},
{
"@type": "ListItem",
"position": 2,
"name": "2026年受賞作品",
"item": "https://example.jp/awards/2026/"
},
{
"@type": "ListItem",
"position": 3,
"name": "作品名"
}
]
}
]
</script>
複数経路を使う場合は、単にキーワードを増やす目的ではなく、実際に利用者が異なる分類からページを探す必要があるかを確認してください。
9. WordPressでパンくずリストを設置する方法
WordPressでは、テーマ、拡張機能、自作関数のいずれかでパンくずリストを実装できます。複数の機能から同時に出力すると重複するため、どの仕組みを使用するかを一つに決めます。
9.1 テーマの標準機能を確認する
最初に、使用中のテーマがパンくずリストを標準搭載しているか確認します。管理画面の外観設定、記事設定、SEO設定などに表示項目が用意されている場合があります。
テーマ機能を使用する場合は、画面上のHTMLだけでなく、BreadcrumbListの構造化データも出力されるか確認してください。構造化データが出力されなくても画面表示としては利用できますが、別の機能でJSON-LDを追加する必要があります。
9.2 SEO拡張機能を使用する
SEO拡張機能には、パンくずリストのHTMLや構造化データを生成する機能があります。カテゴリ、投稿タイプ、固定ページ階層などを自動的に読み取り、テンプレートへ出力できます。
ただし、複数のSEO拡張機能を同時に有効化すると、BreadcrumbListが重複して出力される可能性があります。ソースコードとリッチリザルトテストを確認し、同じパンくずが二重に記述されていないか確認してください。
9.3 テンプレートへ出力位置を追加する
拡張機能によっては、パンくずリストを表示するための関数や短縮記述をテーマへ追加する必要があります。一般的には、記事タイトルの前、主内容の開始前などに配置します。
PHPによる出力位置の例
<?php
if (function_exists('display_breadcrumbs')) {
display_breadcrumbs();
}
?>
実際の関数名は使用するテーマや拡張機能によって異なります。存在確認をせずに関数を呼び出すと、機能を停止した際にエラーが発生するため、条件分岐を入れてください。
9.4 固定ページと投稿で階層を分ける
投稿ではカテゴリ階層を使い、固定ページでは親子関係を使うなど、ページ種類によって階層の取得方法が異なります。すべてのページを同じ処理で出力すると、固定ページに投稿カテゴリが表示されるような誤りが起こる場合があります。
| ページ種類 | 一般的な階層 |
|---|---|
| 投稿 | ホーム ＞ カテゴリ ＞ 記事 |
| 固定ページ | ホーム ＞ 親固定ページ ＞ 子固定ページ |
| 商品 | ホーム ＞ 商品カテゴリ ＞ 商品 |
| 投稿者 | ホーム ＞ 投稿者一覧 ＞ 投稿者名 |
| 検索結果 | ホーム ＞ 検索結果 |
タグ一覧、日付別一覧、検索結果などをパンくずへ含める場合は、それらのページを検索登録対象にするかどうかも併せて確認してください。
9.5 更新後の重複出力を確認する
テーマや拡張機能の更新によって、以前は出力されていなかった構造化データが自動追加される場合があります。更新後は、画面上のパンくずとJSON-LDの数を確認してください。
重複したBreadcrumbListがすべて同じ内容なら直ちに重大な問題になるとは限りませんが、管理上不要です。異なる階層が同時に出力されると、どの経路が正しいか分かりにくくなるため、一つの出力元へ統一します。
10. 電子商取引サイトのパンくず設計
商品数やカテゴリ数が多い電子商取引サイトでは、パンくずリストが重要な移動経路になります。一方、商品が複数カテゴリへ所属しやすく、絞り込みURLも増えるため、親カテゴリの決定とURL管理が必要です。
10.1 商品の代表カテゴリを決める
一つの商品が「家電」「掃除用品」「新商品」「特価商品」に属する場合、パンくずへどのカテゴリを表示するかを決めます。キャンペーンや在庫状況で変わるカテゴリよりも、商品の恒常的な分類を代表階層にするほうが安定します。
| カテゴリ種類 | 代表階層への適性 |
|---|---|
| 商品種別 | 高い |
| 用途 | 条件によって使用 |
| ブランド | サイト設計による |
| 新商品 | 一時的なため低い |
| セール | 一時的なため低い |
代表カテゴリを決めず、訪問経路によってパンくずが変わると、同じ商品ページの階層が安定しません。商品管理画面に「主要カテゴリ」を設定できる仕組みを用意すると運用しやすくなります。
10.2 カテゴリページへ説明を追加する
商品一覧だけのカテゴリページでも利用はできますが、選び方、商品の違い、対象者、よくある質問などを追加すると、上位階層の案内ページとしての価値が高まります。
商品からパンくずを通じてカテゴリへ戻った利用者は、類似商品を比較したい可能性があります。カテゴリページには、絞り込み、並び替え、代表商品、比較軸を用意し、次の商品を探しやすくしてください。
10.3 絞り込み条件を階層と混同しない
「掃除機 ＞ コードレス ＞ 白 ＞ 2万円以下」のうち、「コードレス」は恒常的な商品分類になり得ますが、「白」「2万円以下」は一時的な検索条件である場合があります。すべてを同じ階層として扱う必要はありません。
条件付き一覧をパンくずへ表示する場合は、戻り操作として有用か、検索登録する価値があるかを分けて判断します。組み合わせURLをすべて内部リンク化すると、大量のURLが生成されるため注意してください。
10.4 在庫切れ商品の階層を維持する
一時的な在庫切れで商品ページを残す場合は、既存のパンくず階層も維持します。カテゴリから商品を完全に外すと、内部リンク経路がなくなり、孤立ページになる可能性があります。
販売終了商品については、後継商品、類似カテゴリ、修理情報など、利用者が次に必要とするページへ案内します。単にトップページへ転送すると、商品を探していた利用者の目的と一致しません。
10.5 内部リンク数だけを目的にしない
Googleは、電子商取引サイトのページ重要度を理解する際、ページ間のリンク関係を分析し、一般に多くのサイト内リンクを受けるページを相対的に重要と判断する可能性があると説明しています。
しかし、重要カテゴリへリンクを集めるためだけに、無関係な商品をそのカテゴリへ所属させてはいけません。利用者が商品を探す分類と一致していることを優先し、パンくずを順位操作のためのリンク枠として使用しないようにします。
11. スマートフォン表示と利用しやすさ
スマートフォンでは画面幅が限られるため、階層が長いパンくずリストは読みづらくなります。省略、折り返し、横移動を使い分けながら、上位ページへ移動できる機能を維持します。
11.1 文字を小さくしすぎない
パンくずリストを補助情報として扱うために、本文より少し小さく表示することはあります。しかし、極端に小さい文字や薄い色を使うと、利用者が読めず、リンクを操作できません。
リンク同士の間隔も確保し、隣の階層を誤って押さないようにします。パンくずの文字が折り返されても、どの区切りまでが一つのリンクかを判別できるデザインにしてください。
11.2 折り返しを許可する
階層数が少なく、各名称が短い場合は、複数行へ折り返す方法が単純です。flex-wrap: wrapを使用すれば、画面幅を超えた項目が次の行へ移動します。
折り返しの例
.breadcrumb {
display: flex;
flex-wrap: wrap;
align-items: center;
}
ただし、現在ページ名が長い場合は、最終項目だけで複数行を占有することがあります。パンくず専用の短縮名を用意する方法も検討してください。
11.3 横方向へ移動できるようにする
一行表示を維持したい場合は、横方向へ移動できる領域として実装できます。上位階層を消さずに表示できますが、横に続きがあることを利用者へ伝える必要があります。
横移動の例
.breadcrumb {
display: flex;
overflow-x: auto;
white-space: nowrap;
padding-bottom: 0.5rem;
}
現在ページだけが最初から見えず、毎回横へ移動しなければならない設計は不便です。初期位置、表示方向、影の表現などを実機で確認してください。
11.4 途中階層を省略する
「ホーム ＞ … ＞ 内部対策 ＞ パンくずリストSEO」のように、中間階層を省略する方法があります。重要な上位入口と直近の親カテゴリを残せるため、非常に深いサイトで有効です。
ただし、省略した階層を完全にアクセス不能にしないようにします。省略記号を押すと全階層を表示する、横移動で確認できるなど、必要な利用者が階層を確認できる方法を用意します。
11.5 読み上げに配慮する
パンくずリストはnavとolを使い、現在ページにはaria-current="page"を設定します。区切り記号をCSSで表示すれば、「ホーム、大なり、SEO、大なり」のように不要な記号が読み上げられることを避けやすくなります。
読み上げを考慮した例
<nav aria-label="パンくずリスト">
<ol class="breadcrumb">
<li><a href="/">ホーム</a></li>
<li><a href="/seo/">SEO</a></li>
<li aria-current="page">パンくずリストSEO</li>
</ol>
</nav>
視覚上の位置だけで現在ページを示さず、HTML属性でも意味を伝えます。色だけでリンクと現在ページを区別するのではなく、下線や文字装飾も併用してください。
12. よくある実装ミス
パンくずリストは単純な機能に見えますが、自動生成、複数カテゴリ、拡張機能の重複などによって誤りが起こります。表示だけでなく、リンク先、構造化データ、正規URLまで確認する必要があります。
12.1 画面表示とJSON-LDが異なる
画面上では「ホーム ＞ SEO ＞ 記事」と表示しているのに、JSON-LDでは「ホーム ＞ マーケティング ＞ 記事」と記述されている状態です。テンプレートと構造化データを別々の機能が生成している場合に起こります。
Googleの構造化データ指針では、記述内容がページの表示内容を正確に表す必要があります。異なる階層を意図的に記述し、検索結果だけを変更しようとする実装は避けてください。
12.2 リンク先が転送やエラーになる
パンくずの上位カテゴリが削除され、リンク先が404エラーになっている場合があります。カテゴリ統合後に旧URLから新URLへ転送していても、内部リンクは新しいURLへ直接更新したほうが効率的です。
| 状態 | 対応 |
|---|---|
| 404エラー | 有効な上位ページへ修正 |
| 301転送 | 最終URLへ直接変更 |
| 302転送 | 意図を確認 |
| noindexページ | 上位階層として必要か確認 |
| 別ドメイン | 本当にサイト階層か確認 |
テンプレートで共通出力している場合、一つの誤りが数千ページへ広がる可能性があります。代表ページだけでなく、異なる投稿種類やカテゴリを抽出して確認してください。
12.3 positionの順番が間違っている
JSON-LD内のpositionが重複している、途中で飛んでいる、表示順と逆になっているなどの誤りです。ListItemでは、順番を示すためにpositionを使用します。
自動生成する場合は、階層配列の番号をそのまま出力し、最初を1にする処理を確認します。プログラム上の配列番号は0から始まることがあるため、そのまま出力するとposition: 0になる場合があります。
12.4 複数のBreadcrumbListが重複する
テーマ、SEO拡張機能、独自コードがそれぞれBreadcrumbListを出力すると、同一内容が複数存在します。異なる階層が出力される場合は、検索エンジンだけでなく開発者も正しい情報を判断しにくくなります。
ページのソースコードでBreadcrumbListを検索し、出力数を確認してください。不要な出力元を停止し、画面表示と構造化データを一つの階層情報から生成する仕組みにすると不一致を防げます。
12.5 存在しないカテゴリを記述する
検索結果へ特定のキーワードを表示させる目的で、実際には存在しないカテゴリ名やURLをJSON-LDへ追加してはいけません。構造化データはページ内容を正確に表す必要があります。
パンくずに含めたい重要なカテゴリがある場合は、先に利用者向けのカテゴリページと内部リンクを作成します。構造化データだけで仮想的な階層を作るのではなく、実際のサイト構造を改善してください。
13. パンくずリストを検証する方法
実装後は、見た目、リンク、構造化データ、検索エンジンからの取得状態を確認します。一つの検査だけですべての問題を発見できないため、複数の方法を組み合わせます。
13.1 リッチリザルトテストを使う
Googleのリッチリザルトテストでは、ページまたはコードを入力し、パンくずリストの構造化データが検出されるか確認できます。Googleは同ツールを、対応する検索表示を生成できる構造化データの公式検査手段として案内しています。
検出された項目を開き、各position、name、itemを確認します。「有効」と表示されても、誤ったカテゴリ名や古いURLが記述されている可能性があるため、内容まで確認してください。
13.2 URL検査で取得状態を確認する
Search ConsoleのURL検査を使い、Googleがページへアクセスできるか、登録可能な状態かを確認します。構造化データが正しくても、noindex、認証、robots.txtなどでページへアクセスできなければ検索表示には利用されません。
Googleの構造化データ指針でも、構造化データを含むページをrobots.txt、noindex、アクセス制御でGooglebotから遮断しないよう案内しています。
13.3 ソースコードを確認する
ブラウザで表示された画面だけでは、JSON-LDの重複や古いURLを見落とす場合があります。ページのソースコードを開き、BreadcrumbList、カテゴリ名、URLを検索してください。
JavaScriptで後から構造化データを追加している場合は、元のソースコードだけでなく、開発者機能の要素画面やリッチリザルトテストも確認します。利用している生成方法に応じて、検査場所を変える必要があります。
13.4 リンクを実際に操作する
ホーム、カテゴリ、親ページの各リンクを実際に押し、正しいページへ移動するか確認します。別タブで開く必要のない内部リンクへtarget="_blank"を付けていないか、スマートフォンで押しにくくないかも確認してください。
自動検査では、リンク先が200状態であることは確認できても、内容が正しいカテゴリかどうかまでは判断できません。人が画面を見て、パンくずの名称と移動先が一致しているか確認する工程が必要です。
13.5 ページ種類ごとに抽出検査する
一ページだけ正しくても、すべてのテンプレートが正しいとは限りません。投稿、固定ページ、商品、カテゴリ、タグ、検索結果、会員ページなど、ページ種類ごとに代表URLを選びます。
| ページ種類 | 主な確認点 |
|---|---|
| 記事 | カテゴリと記事名 |
| 固定ページ | 親子関係 |
| 商品 | 代表商品カテゴリ |
| カテゴリ | 上位カテゴリ |
| 多言語ページ | 言語別URLと名称 |
大規模サイトでは、階層数、URL、positionを自動取得し、異常な値を一覧化する方法も有効です。特定のカテゴリだけ親URLが空になるようなテンプレート不具合を早く発見できます。
14. パンくずリストの運用と改善
パンくずリストは、一度設置して終わる機能ではありません。カテゴリ統合、URL変更、商品移動、サイト再設計が行われるたびに、階層とリンクを更新する必要があります。
14.1 カテゴリ変更時にまとめて更新する
カテゴリ名やURLを変更した場合は、パンくず表示、構造化データ、主メニュー、カテゴリ見出し、内部リンク、XMLサイトマップを確認します。一部だけ古い名称が残ると、利用者が別カテゴリだと誤解する可能性があります。
変更前URLから変更後URLへ転送を設定した場合でも、パンくずのリンクは新URLへ直接更新してください。内部リンクが長期間転送を経由する状態を残さないようにします。
14.2 削除カテゴリの子ページを移動する
中間カテゴリを削除する場合は、そこに所属していた子ページの新しい親カテゴリを決めます。親を決めずにカテゴリだけ削除すると、「ホーム ＞ 記事」のように階層が急に浅くなり、関連カテゴリへの導線が失われます。
移動先がない場合は、新しいカテゴリを作るのではなく、既存カテゴリへの統合やページ自体の整理を検討します。パンくずを維持するためだけに、内容の薄いカテゴリを残す必要はありません。
14.3 表示名変更の影響を確認する
カテゴリ名を変更すると、パンくずリストを通じて多数のページのリンク文字が変わります。小さな変更でもサイト全体へ影響するため、意味、長さ、既存利用者の理解を確認してください。
変更前後で検索表示、カテゴリページへの訪問、サイト内検索語などを確認できます。ただし、パンくず名の変更だけで順位変化を断定せず、同時期のコンテンツ更新や市場変化も考慮します。
14.4 定期的にリンク切れを確認する
記事削除、商品終了、カテゴリ統合によって、パンくずのリンク先がエラーになる場合があります。共通テンプレートのリンクであれば影響範囲が大きいため、定期的に検査してください。
検査では、404エラーだけでなく、転送、別カテゴリへの誤リンク、noindexページへのリンクも確認します。状態コードが正常でも、ページ内容が階層名と一致しない場合があるため、代表ページは目視確認します。
14.5 サイト改修時に一時的な階層を残さない
開発環境のカテゴリ名、仮URL、試験用ページがパンくずに残ることがあります。本番公開前に、すべてのページ種類で実際のカテゴリ名とURLが出力されているか確認してください。
特にサイト移行では、旧ドメインURLがJSON-LDだけに残ることがあります。画面上のリンク、構造化データ、正規URL、画像URLなどを対象に、旧ドメインの文字列を一括検索すると発見しやすくなります。
15. パンくずリストSEOの実施手順
パンくずリストの改善は、構造化データだけを追加するのではなく、サイト階層、画面表示、リンク、検証、運用の順で進めます。先にJSON-LDを作っても、元のカテゴリ設計が不明確では正しい階層を記述できません。
15.1 現在のサイト階層を確認する
最初に、主要ページがどのカテゴリに属し、どのページからリンクされているかを確認します。主メニュー、カテゴリ一覧、URL、XMLサイトマップを比較し、階層の不一致を探してください。
| 確認対象 | 確認内容 |
|---|---|
| 主メニュー | 主要カテゴリが分かるか |
| カテゴリページ | 子ページを適切に案内しているか |
| URL | 管理しやすい構造か |
| 内部リンク | 親子関係と一致しているか |
| パンくず | 現在地を正しく示しているか |
同じページに複数の親候補がある場合は、利用者が最も自然に探す経路を代表階層として選びます。
15.2 画面上のパンくずを実装する
次に、nav、ol、li、aを使い、利用者が確認・操作できるパンくずリストを実装します。現在ページにはaria-current="page"を設定し、上位ページにはクロール可能なリンクを付けます。
表示位置は、主内容の開始前または記事タイトル周辺が一般的です。広告や大きな画像の後ろへ置くと見つけにくくなるため、ページへ到着した利用者が早い段階で現在地を確認できる位置にします。
15.3 BreadcrumbListを追加する
画面表示が正しいことを確認した後、同じ階層情報を使ってBreadcrumbListを生成します。各項目に連続したposition、表示と一致するname、正規URLのitemを設定します。
画面表示とJSON-LDを別々に手入力すると、将来のカテゴリ変更時に不一致が起こりやすくなります。可能であれば、一つの階層データからHTMLとJSON-LDの両方を生成してください。
15.4 複数の方法で検証する
リッチリザルトテストで構造化データを検査し、URL検査でGoogleからの取得状態を確認します。その後、実際の端末で表示、折り返し、リンク操作を確認してください。
「有効」という検査結果だけで完了にせず、カテゴリ名とURLが正しいかを目視します。検査ツールは構文上の問題を発見できますが、事業上正しい階層かどうかまでは判断できません。
15.5 更新手順を運用へ組み込む
カテゴリ名変更、URL移動、商品カテゴリ変更を行う際に、パンくずリストも確認する手順を運用表へ追加します。公開後の確認を担当者の記憶だけに任せると、構造化データだけ古い状態が残りやすくなります。
変更履歴には、変更日、対象URL、旧階層、新階層、転送設定、検証結果を記録します。サイト規模が大きい場合は、パンくずのURLとpositionを定期的に自動取得し、異常を検知する仕組みも有効です。
おわりに
パンくずリストは、検索順位を直接操作するための機能ではありません。しかし、利用者へ現在地を伝え、上位カテゴリへ移動しやすくし、検索エンジンが内部リンクを通じてページを発見できる状態を作る重要な要素です。特に、記事数、商品数、カテゴリ数が多いサイトでは、パンくずリストの品質がサイト全体の移動しやすさに影響します。
SEOを意識して実装する場合は、最初にサイト階層を整え、その階層を画面上のパンくずリストへ正確に反映します。その後、同じ内容をBreadcrumbListの構造化データで記述し、リッチリザルトテストとURL検査で確認してください。構造化データだけを追加し、実際には存在しないカテゴリや利用者に見えない階層を記述してはいけません。
2025年1月以降、モバイル版Google検索結果ではパンくずリストが表示されなくなりましたが、デスクトップ検索結果、サイト内移動、内部リンク、階層理解における価値は残っています。検索結果の見た目だけで設置の要否を判断せず、利用者が目的ページを発見し、関連ページへ移動するための案内として継続的に改善してください。
