パンくずリストとは？設計例・構造化データと表示の確認方法

画面のナビゲーションと検索結果を分ける

Googleは2025年1月23日の公式案内で、モバイルの検索結果ではドメインのみを表示し、デスクトップでは従来のパンくず表示を続けると説明しています。これはサイト内のパンくずを削除する指示ではありません。

構造化データが有効でも、検索結果で希望どおり表示される保証はありません。CTRの増減を確認する場合も、順位、語句、端末、タイトル、競合等の変化を考慮します。パンくずを足したことだけから順位やクリックの改善を断定しないようにします。

利用者に分かる論理的な階層を作る

パンくずは、通常のメニューやサイト内検索を補う手段です。トップ、主要カテゴリ、下位カテゴリ、記事や商品といった関係を、実際の内容に合わせて設計します。ディレクトリ名が技術上の都合で決まっている場合、それをそのまま人向けの分類名にする必要はありません。

「必ず3階層」「5階層以上はSEOで不利」といった一律の基準は置きません。必要な深さは、サイトの規模、内容、利用者の探し方によって変わります。項目を増やすためだけに空のカテゴリを作るより、移動先として意味のある上位ページを選びます。

架空のメディアサイトの例

架空の業務メディアで、GA4の設定記事なら「ホーム ＞ Web分析 ＞ GA4 ＞ 設定記事」が候補です。URLがブログ直下にあっても、内容上の分類としてこの経路を示すことはできます。ただし各上位ページが実際に公開され、そのテーマの記事を探せることを確認します。

複数の分類経路が妥当なページでは、Googleは複数のパンくずの記述を扱えます。ただし、検索用の経路だけを都合よく作るのではなく、利用者に意味があり、内容と整合する関係を選びます。通常は管理しやすい代表経路から始めると点検しやすくなります。

構造化データに必要な情報を整理する

GoogleのBreadcrumbListの公式説明で、利用できる形式と必要なプロパティを確認します。JSON-LDだけが唯一の方法ではなく、MicrodataやRDFaにも対応しています。CMSの拡張機能を使う場合も、実際に何を出力したかを確認します。

Google向けには少なくとも2つのListItemを用意し、ページの位置関係を表します。最後の項目のURLは省略でき、Googleは該当ページのURLを使います。仕様上の許容範囲と、社内でURLを必ず記録する運用ルールを混同しません。

ラベルはページのtitleと文字単位で一致しなければ罰がある、という説明にはしません。短くしても意味が分かる名前にし、同じカテゴリを別ページで異なる呼び方にして混乱させないようにします。URLは正規URLの方針と整合させます。

読み上げ・キーボード・小さな画面を確認する

W3Cのパンくずのアクセシビリティパターンでは、ナビゲーション領域としてラベルを付け、項目を順序付きリストで表す例を示しています。現在ページをリンクにする場合は、aria-currentで現在位置を示します。リンクにしない場合、この指定は任意です。

• メインメニュー等と区別できるナビゲーション名を用意する。
• 上位リンクへキーボードで移動でき、フォーカス位置が見える。
• 区切り記号を余分に読み上げず、階層名と関係が理解できる。
• 長い記事名でも、拡大や小さな画面で主要な情報を読める。
• 現在ページと移動先のリンクが視覚的にも分かる。
• 折り畳む場合は、隠れた上位経路に必要な方法でアクセスできる。

画面に収めるために文字を極端に小さくしたり、全項目を省略して位置が分からなくしたりしないようにします。表示の折り返しや短いラベルを検討し、実際のページ名の長さでテストします。見た目が整っていることと、読み上げやキーボードで使えることは別の確認です。

公開前に3層で検証する

1. 画面上：階層が正しく、上位リンクと現在位置が分かるかを確認する。
2. データ上：CMSの生成結果を検証し、構造化データが本文の意味と一致するかを見る。
3. 公開・検索上：リンク先の公開状態、Googleの検証結果、検索で見える範囲を分けて記録する。

リッチリザルトテストは、対応する構造化データの検出・エラー確認に使えます。テストが通ったことを、検索結果への表示の保証に置き換えません。Search Consoleの対応するレポートに行がない場合も、データや対象の条件を確認して判断します。

架空のリニューアルでは、カテゴリ名を変更した際に、記事上のパンくずは新名称でも、構造化データは旧URLを向いたままという不整合が起こり得ます。表示、生成データ、リンク先を同じチェック表で照合し、修正箇所と担当を記録してください。

よくある不具合の切り分け

リンク先が消えている場合は404エラーと復元・移転の判断、一時的な条件の値はURLパラメータの設計で確認します。パンくずだけ直しても、サイト全体の分類やリンク生成が古ければ、同じ問題が再発します。

架空の公開確認シート

記事Aの日本語版と英語版、各言語の親カテゴリを確認対象にしたとします。編集担当は分類とラベルを確認し、実装担当は生成元とデータを確認し、確認担当は実際のリンク先と操作を点検します。日本語版から英語の親カテゴリへ進んでしまう場合、構造化データの形式が正しくても、利用者の経路としては修正候補です。

合格条件は「日本語・英語とも、意図した親ページへ移動できる」「現在位置が分かる」「生成データがその関係を表す」「必要な端末・操作条件で使える」と書きます。検索でパンくずが表示されたことを公開の必須条件にはせず、観察できる場合に別欄へ記録します。形式チェックと利用者の確認を分けると、担当間の見落としを減らせます。

運用ルールを決め、内容の変更時に点検する

公開台帳に、記事URL、上位カテゴリ、表示ラベル、構造化データの生成元、確認日を残します。新規公開、カテゴリ移動、URL変更、言語追加のときに、同じ確認を行います。サイト全体の発見経路はサイトマップの確認手順、検索改善の基本はSEO対策の基本と合わせて管理します。

評価するときは、利用者が上位ページへ移動できるか、リンク切れがないか、現在位置を理解できるかをまず確かめます。検索表示やクリックの変化を追う場合は、語句・国・端末・期間をそろえ、パンくずの変更だけの効果と断定せず記録します。