パンくずリストは、読者が今いるページの位置と、上位の情報へ戻る手がかりを示す案内です。直前にどのリンクを押したかという訪問履歴とは分けて設計します。同じページを検索、一覧、関連記事のどこから開いても、サイト内の位置が理解できる並びを用意してください。まず実際に存在するページの関係を整理し、表示だけのために架空の階層を増やさないことが大切です。

サイトの情報構造から階層を選ぶ

トップ、カテゴリ一覧、詳細ページなどの関係を書き出します。URLに含まれる文字列と情報の階層は一致することもありますが、常に同じとは限りません。管理上のディレクトリ名をそのまま読者向けの見出しに使うのではなく、上位の案内先として意味があるかを確認します。

途中の項目を押しても関連する一覧へ戻れない場合、その階層が案内として役立つかを見直します。例えばサービスの詳細から戻る先が、対象のサービスを見つけられないページなら改善が必要です。パンくずの設計は、上位ページに何を載せるかの確認と一緒に進めると整理しやすくなります。

複数の分類を持つ記事の扱い

一つの記事が複数のテーマに属する場合、すべてを一列に並べると親子関係を誤って示すことがあります。主な掲載先を決めてパンくずに使い、別のテーマはカテゴリのリンクや関連記事として案内する方法があります。読者が理解するための階層と、横断的な分類を区別してください。

検索から開いた場合も位置が伝わるように、記事に付いた主なカテゴリを安定して使うことを検討します。アクセス元によって階層を変える設計を選ぶ場合は、共有したURLを直接開いたときや、再読込したときの動作まで確認します。戻る操作の代わりにパンくずを使わせる前提にはしないほうが明快です。

表示する名前と操作を決める

上位項目は移動先が分かる短い名称にします。現在のページ名は、本文のタイトルと意味を揃えます。長い記事名をすべて表示するとスマホで多くの行を使う場合があるため、折り返し、省略、表示範囲の選び方を確認します。省略によって今いる位置が分からなくならないかを実機で見てください。

区切りの記号だけで関係を伝えるのではなく、案内のまとまりとして理解できる実装にします。キーボードで移動できるか、現在のページとリンク先を区別できるかも確認します。見た目の矢印がリンク領域に含まれるかなど細かな操作を揃えると、押す場所の迷いを減らせます。

設計表と想定例

設計表には「ページ種別」「上位の案内先」「表示名称」「リンク先URL」「現在位置の名称」「主カテゴリの決め方」「スマホでの表示」を書きます。記事、実績、サービスなど種別ごとにルールを定めれば、ページが増えても担当者が判断しやすくなります。特殊なページは例外として明記します。

想定例として、AI活用のナレッジ記事がシステム開発にも関係する場合を考えます。ナレッジ一覧と主カテゴリを経由するパンくずを使い、システム開発の案内は本文の関連情報に置きます。「AI」と「システム」を親子のように並べるのではなく、情報の関係に応じて別の導線を用意する設計です。

構造化データと公開後の確認

パンくずの構造化データを設定する場合は、実際の画面で示す階層やURLと整合させます。画面には存在しない分類を検索向けだけに追加しないようにします。形式が正しくても検索結果での表示は保証されないため、実装の検証と表示状況の観察を分けて考えてください。

公開後は、上位項目を順に開いて目的のページへ到達するかを確かめます。サイトを移転したりカテゴリを変更したりしたときは、パンくずのリンク、正規URL、転送の関係も点検します。古いURLが残る場所は共通部品だけでなく、記事データや構造化データにもあるため、表示と元データを両方確認します。

よくある疑問

すべてのページにパンくずが必要でしょうか。サイト内の位置を理解する助けになるページで検討します。単独の案内ページなど階層が実質的にない場合は、無理に長い並びを作る必要はありません。ほかのナビゲーションとの役割も合わせて判断します。

URLを変えずにパンくずだけ整理できますか。情報の階層とURLの構成を分けて検討できる場合があります。ただし、表示する上位ページが実際に存在し、読者の目的に合う案内先かを確認します。階層を変える目的と影響を整理し、見た目の整列のためだけに不要なURL変更を増やさないようにしてください。

関連サービスと基礎資料

Webサイト制作の対象範囲もご確認いただけます。

本記事の手順・確認項目は一般的な検討のための提案です。AIを使って草案を作成し、構成・表現の点検を行っています。個別の契約・運用条件は実際の環境に合わせて確認してください。