「パンくずリスト」とは、ユーザーがWebサイト内の「現在どの位置にいるか」を階層順に示したナビゲーションのことです。
（例：ホーム > 会社概要 > アクセス）

サイト内での迷子を防ぐ役割があるほか、検索エンジンにサイト構造を正確に伝えるSEO効果もあります。

サービス紹介やコラムのページを増やしていくと、詳細ページからほかの情報へ進む道筋が分かりにくくなることがあります。検索や共有されたURLから直接訪れた人は、トップページを経由していないため、そのページがサイトのどこに属しているかを知りません。

このとき、ページの所属と上位ページへのリンクを示すパンくずリストが手がかりになります。企業サイトの担当者が見直す際は、設置の有無だけでなく、階層、名称、リンク先、スマートフォンでの見え方まで確認しましょう。この記事では、制作会社へ修正を依頼する前に整理したい内容を解説します。

パンくずリストは、現在のページに至る上位ページを階層順に並べたナビゲーションです。W3CのBreadcrumb Patternでも、サイト内の位置を把握するためのリンクの並びとして説明されています。[1]

たとえば、架空の企業サイトで「ホーム ＞ サービス ＞ 研修支援」と表示する場合、「研修支援」が現在地で、「サービス」は上位ページです。読者はサービス全体を見たくなったとき、そのリンクから一覧へ移動できます。

この形式では、利用者が直前に見たページを順に並べるのではなく、サイト内での所属を示します。検索結果から直接入った場合でも、同じページの位置関係を理解できるようにする考え方です。ブラウザの戻る操作と、上位ページへ移動する操作を分けて考えましょう。

パンくずが得意なのは、現在の詳細ページから、そのページが属するまとまりへ移動することです。別の事業を探すためのグローバルナビゲーションや、次に読む記事を選ぶための関連記事とは役割が異なります。パンくずを置いたからといって、ほかの案内を取り除く必要はありません。

たとえば、研修サービスを比較したい人には「サービス一覧」へのリンクが役立ちます。一方で、研修を申し込みたい人には問い合わせの案内が必要です。現在地の理解と次の行動を混同せず、それぞれに適した場所で案内します。階層がほとんどない小規模なサイトでは、パンくずを追加する前に、上位ページとして意味のあるまとまりがあるかを確かめましょう。

パンくずの表示を作る前に、主要なページをどのまとまりに置くか整理します。サービスの詳細はサービス一覧の下、導入事例の詳細は事例一覧の下というように、読者が上位ページへ進んだときに何を探せるかを確かめます。

確認には、ページ名とURLに加えて、上位ページの名前とURLを記録した簡単な一覧が使えます。実際のサイト構成を見ながら、上位ページに現在の詳細ページへの案内があるか、名前だけの分類が途中に入っていないかを見てください。

リンク先を用意していない分類名を、見た目をそろえるためだけにリンクとして置くのは避けたいところです。分類をまとめるページが必要なのか、階層を簡潔にするのかを先に決めると、修正内容が明確になります。

URLの文字列を切り分けただけでは、読者に分かりやすい分類にならないこともあります。Googleもパンくずについて、URL構造をそのまま再現するより、利用者が通常たどる経路を示すことを勧めています。[2]

以下は架空の企業サイトを使った設計例です。特定のサイトにこの階層があるという意味ではなく、読者が戻った先で探したい情報から考えるための例として見てください。 サービス紹介では「ホーム ＞ サービス ＞ 人材育成支援 ＞ 管理職研修」という並びが考えられます。ただし、「人材育成支援」のページに複数の関連サービスを比較できる情報がなければ、一段増やす理由は弱くなります。「ホーム ＞ サービス ＞ 管理職研修」の方が適切な場合もあります。階層を深くすることではなく、途中のページが案内として機能することを優先します。

事例では「ホーム ＞ 導入事例 ＞ 製造業 ＞ 研修導入事例」のように業種を軸にできます。この場合、製造業の一覧には、同じ業種のほかの事例へ進める導線が必要です。サービスごとの事例を見せたい場合は、業種を無理に経由させず「導入事例 ＞ 人材育成支援」のような分類を検討します。同じサイト内でも、サービス紹介と事例で同じ分類軸を使うとは限りません。

採用では「ホーム ＞ 採用情報 ＞ 中途採用 ＞ 募集職種」という並びが考えられます。応募者が雇用区分を間違えずに募集一覧へ戻れるかが確認点です。募集終了後に詳細ページを残す場合は、パンくずの戻り先までなくなっていないかを見直します。ページの公開終了と、上位ページの廃止は別々に判断してください。

いずれの例でも、管理部門の組織図をそのままサイトの階層にする必要はありません。社内では別部門が担当していても、読者が一つの目的で探す内容なら、共通の一覧から案内する方が自然な場合があります。ページを管理する部署と、閲覧者に見せる分類を分けて整理すると、担当部署の変更だけでパンくずを変える事態を避けやすくなります。

一つの事例が、業種別とサービス別の両方に該当することがあります。この場合は、何を軸に現在地を示すかを決めます。たとえば、事例一覧を共通の上位ページにする方法や、主となる分類をCMSで指定する方法が考えられます。

ここで大切なのは、担当者ごとの判断で表示が変わらないことです。「主な分類を選ぶ基準」「分類を変更したときに確認するページ」を記録しておきます。複数の所属を見せたい場合も、パンくずを長くつなげる前に、関連する分類へのリンクを別に設ける方が分かりやすいかを検討しましょう。

分類の変更は、一つの記事だけに影響するとは限りません。同じ分類のページをいくつか開き、表示名と戻り先がそろっているか確認します。以前の分類名が一部だけ残る場合は、記事の設定と共通テンプレートのどちらで管理されているかを制作会社に確認してください。

たとえば「人材育成」という分類を「組織と人材の支援」に変更する場合、まず名称だけを変更するのか、所属ページやURLも変えるのかを分けます。名称だけなら表示文字と構造化データの名称を確認し、URLも変えるならリンク先や転送の扱いを制作会社と整理します。パンくずの文字を直しただけで、リンク先まで更新されたとは判断しないでください。

複数の編集者が担当するサイトでは、分類を作る人、記事に分類を設定する人、公開後に確認する人を決めておきます。新しい分類を自由に追加できる運用では、意味の近い分類が並立することがあります。名称の一覧と利用条件を共有しておけば、どちらを選ぶべきか判断しやすくなります。

Googleの資料には、一つのページに複数のパンくず経路を記述する例もあります。[2] ただし、複数の経路を使えることと、必ず複数にした方がよいことは別です。実際に役立つ経路があるかを先に考え、画面で見せる経路と構造化データに記述する経路を制作会社へ説明できる状態にします。存在しない分類や無関係なキーワードを足す方法として使わないことが重要です。

パンくずの各名称は、移動先で使っている名称と対応させます。リンクに「サービス」と書かれているのに、移動先が一つの商品の詳細ページでは、読者が期待した情報を見つけられません。短くする場合も、意味が変わる省略は避けます。

現在のページは、上位ページへのリンクと区別できる見せ方にします。現在地をリンクにする場合と、文字として表示する場合で実装が異なるため、制作会社には見た目だけでなく、支援技術にも現在地が伝わるかを確認してもらいましょう。

W3Cのパターンでは、パンくずを名前の付いたナビゲーション領域に置き、現在ページへのリンクにはaria-current="page"を設定します。現在地がリンクでない場合、この属性は任意です。[1] 運用担当者がHTMLを直接編集する必要はありません。「上位ページへ進める」「現在地を見分けられる」「読み上げ時にパンくずの領域が分かる」という確認事項として渡し、実装方法は担当者とすり合わせます。

パソコンでは一行で収まっていても、スマートフォンでは長いページ名が折り返されたり、省略されたりします。実際に使われている長い名称のページを選び、途中の階層や現在地がどのように見えるかを確かめましょう。

短い名称のページだけを見て判断すると、例外を見落とします。カテゴリが深いページ、長いサービス名を使うページ、日本語と英数字が混在するページなど、表示条件が異なるものを確認対象に含めます。

省略を使う場合は、何が省かれたか、上位ページへどう進めるかが分かるかを確認します。横に動かせる表示にするなら、その操作に気づけるかも確かめます。どの方法が合うかはサイトの構成によるため、見た目だけで一律に決めず、代表的なページで比較するのがよいでしょう。

スマートフォンの実機に加えて、文字を拡大した状態でも確認します。リンク同士を押し分けられるか、本文や固定ヘッダーと重ならないかも記録してください。

表示を比較するときは、確認したページ、画面の向き、ブラウザ、文字サイズの設定を記録します。「スマートフォンで見切れる」だけでは、相手が同じ状態を再現できないことがあります。たとえば、縦向きで文字を拡大したときだけ現在地が本文と重なるなら、その条件と画面の記録を合わせて渡すと原因を絞りやすくなります。

長い名称を全て省略すれば解決するわけでもありません。「管理職向け研修」と「管理職向け研修の導入事例」が同じ省略表示になれば、別のページを区別しにくくなります。先頭を残すか、末尾を残すか、複数行にするかは名称の内容によって検討します。文字を小さくして無理に一行へ収めるより、読みやすさと移動のしやすさを保つ方法を選びましょう。

パソコンではマウスのクリックだけでなく、キーボードでリンクへ移動できるか、選択中のリンクが分かるかも確認します。読み上げを含む専門的な確認が難しい場合は、運用担当者が判断できる範囲と制作会社へ依頼する範囲を分けてください。見た目に問題がないことだけを、全ての利用者が使える証拠にはしないようにします。

画面上のパンくずが正しくても、検索エンジン向けの構造化データに古い名称やURLが残ることがあります。逆に、構造化データの検査に通っても、画面の文字が切れたり、リンク先が分かりにくかったりする問題まで解消したとは限りません。

GoogleのBreadcrumbList仕様では、少なくとも二つのListItemを並べ、各項目の名称、位置、URLなどを定められた条件に沿って記述します。最後の項目のURLは省略できます。制作会社には、リッチリザルトテストでの検査と実画面の確認を両方依頼しましょう。[2] 点検結果は「表示」「移動先」「構造化データ」に分けて記録すると、直す対象を整理できます。名称を変更したときは、どこから表示とデータが生成されるかを確認し、一方だけが古い状態にならないようにします。

なお、Googleの現行資料では検索結果のパンくず機能はデスクトップ対象で、構造化データによる表示は保証されません。スマートフォンの検索結果に出ないことだけで、サイト内のパンくずが故障しているとは判断できません。[2]

画面の点検では、代表ページを開いて、並びと現在地の表示を読み、上位ページのリンクを実際にたどります。リンク先が開くことに加えて、そのページに戻る意味があるかも見ます。アクセスできても、内容が異なる一覧へ進むなら、分類や設定を見直す必要があります。

構造化データの点検では、制作会社に対象URLと検査結果を残してもらいます。名称、並び順を示すposition、各項目が指すURLなどを確認し、報告された問題を整理します。[2] 検査が正常に終わった場合でも、担当者が期待した分類かどうかは別途判断が必要です。技術的に読み取れるデータでも、業種別の事例を誤ってサービス紹介の下に置いている可能性はあるためです。

検証用のコードで確認した後は、公開されたページにも同じ内容が反映されているかを確認します。CMSの設定、テンプレート、キャッシュなどが関係し、編集画面と公開画面の内容が異なる場合があります。原因を決めつけず、どの画面では新しく、どこでは古いかを伝えましょう。公開後の確認が終わるまでは、修正作業の完了と表示確認の完了を分けて管理すると見落としを減らせます。

検索結果の見え方は、サイト内の表示や検査結果だけで確定するものではありません。パンくずの設置や構造化データの追加だけを理由に、検索順位の上昇や検索結果での表示を約束することは避けます。まずは利用者が上位ページへ進めることと、公開ページの情報を正しく伝えることを確認の目的に据えましょう。

ページを追加するときは、本文や画像だけでなくパンくずも確認対象に入れます。次の項目を更新手順に加えておくと、同じ確認を繰り返しやすくなります。

・現在のページが意図した分類に所属しているか
・上位ページの名称とリンク先が対応しているか
・現在地と移動できるリンクを見分けられるか
・長い名称や文字拡大時に情報が隠れないか
・分類名やURLを変更した後、関連ページに古い表示が残っていないか
・表示と構造化データが、意図した同じ分類を表しているか
・修正後に誰が、どの代表ページを確認するか決まっているか

分類変更を伴う修正では、新規ページだけでなく既存ページも確認します。代表URLと画面の記録を残しておくと、テンプレートを変更した際にも同じ条件で見直せます。

「パンくずを直してほしい」だけでは、名称、リンク先、階層、表示崩れのどれを変えるのかが伝わりません。対象URL、現在の表示、期待する並び、移動先URL、確認した端末をまとめて渡しましょう。画面の問題なら、どの幅や文字サイズで起こるかも添えます。

たとえば、「この事例はサービス詳細ではなく事例一覧へ戻したい」「スマートフォンで上位カテゴリが隠れている」のように、読者が困る場面を書くと修正目的を共有しやすくなります。CMSの操作で直せるのか、共通テンプレートの修正が必要なのかも確認してください。

階層の修正なら、「対象は研修導入事例の詳細ページです。現在はサービス一覧へ戻りますが、ほかの事例を比較できるよう、導入事例一覧を上位にしたいです。期待する並びはホーム、導入事例、現在の事例名です」と伝えます。この説明に対象URLと戻り先URLを添えれば、何を変えないかも共有しやすくなります。事例本文やサービス紹介への関連リンクまで削除する依頼ではないことも明記できます。

表示の修正なら、「文字を拡大すると上位カテゴリと現在地が重なります。分類とリンク先は変えず、両方を読めて操作できる表示にしたいです」と伝えます。具体的な端末や再現条件を添え、修正後には同じ条件で確認します。画面幅だけの問題なのか、名称の長さも関係するのかを切り分けておくと、特定の一ページだけでなく共通の問題として検討できます。

完了報告を受けたら、依頼したページに加えて、同じテンプレートを使う別のページも開きます。一つの表示を直すための変更が、ほかの長い名称や深い階層に影響していないかを見るためです。確認したURLと条件を記録し、残った問題がある場合は新しい依頼として分けると、対応済みの範囲を共有しやすくなります。

パンくずリストは、詳細ページからサイト全体を理解するための小さな手がかりです。まずは重要な詳細ページを一つ開き、現在地が分かるか、上位ページへ無理なく進めるかを確認するところから始めてみましょう。

構造化データとは？中小企業ホームページでSEOと信頼性を高める基本
ホームページのヘッダー設計｜迷わず目的ページへ進めるナビゲーションの作り方
ホームページの内部リンク設計｜回遊率と問い合わせ導線を高める考え方

[1] W3C WAI ARIA Authoring Practices Guide Breadcrumb Pattern
[2] Google Search Central Breadcrumb structured data

参照日 2026年10月20日。分類の決め方、確認対象の選び方、依頼事項の整理は、本記事の運用提案です。対象サイトの個別実装や検索順位を検証したものではありません。