パンくずリストとは｜LPと記事での要不要と作り方

｜広告運用ノウハウ公開中！

より詳しく知りたい方は資料をダウンロード！

サイトのページにはパンくずリストがあるのに、LPには付いていない。記事LPを作るときに入れるべきか分からない。Web担当やLP担当として、こうした迷いを感じたことはないでしょうか。

パンくずリストは、そのページがサイトの中のどこにあるかを示すリンクの列です。ユーザーが上の階層へ戻るための道具であり、Googleが検索結果での表示に使う情報でもあります。ただし、検索結果での表示は2025年1月からパソコン版だけになり、1枚もののLPに置くべきかについて公式の決まりはありません。

この記事では、Google 検索セントラル・MDN・W3C の公式文書（2026年10月28日時点の記載）をもとに、パンくずリストの定義と検索結果での扱い、LPと記事ページでの要不要の判断材料、アクセシビリティに配慮した作り方、構造化データ（BreadcrumbList）の書き方をまとめます。

1. パンくずリストとは｜サイトの中での現在地を示すリンクの列

1-1. ページがサイト階層のどこにあるかを示す

Googleは、ページに表示されるパンくずリストを「そのページがサイト階層内のどこに位置するか」を示すもので、ユーザーはサイトを理解し、移動できると説明しています。最後のパンくずから順にさかのぼることで、サイトの階層を1レベルずつ上に移動できます（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。

MDN は、パンくずリストをウェブサイトの各ページのヘッダーと本文の間に置かれることが多い構成要素としています。トップページからみて現在のページがどの階層にあるかや、現在のページに至るまでどのリンクをたどってきたかを知ることができる、という説明です（出典：Breadcrumb (パンくずリスト)｜MDN Web Docs）。

W3C の WAI-ARIA Authoring Practices Guide（APG）では、パンくずを「現在のページの親ページへのリンクを階層順に並べたリスト」と定義し、メインコンテンツの前に横に並べることが多いとしています（出典：Breadcrumb Pattern｜W3C WAI-ARIA Authoring Practices Guide）。

1-2. 「位置」を示すものと「たどった経路」を示すもの

MDN の説明には、階層上の位置を示す使い方と、ユーザーがたどってきたリンクの順番を示す使い方の両方が書かれています（出典：Breadcrumb (パンくずリスト)｜MDN Web Docs）。

検索結果に使うパンくずについて、Googleは、URL構造をそのまま反映させるのではなく、ユーザーがそのページにたどり着くまでの一般的な経路を示すことを勧めています（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。ユーザーごとの閲覧履歴ではなく、「多くの人がこの順にたどってくる」というカテゴリの並びを示す、という考え方です。

1-3. ユーザーにとっての役割

MDN は、パンくずリストが適切に機能していれば、ユーザーは現在位置を確かめられ、すでに見たページに簡単に戻れ、余計なクリックをせずに上の階層へ移動できるとしています（出典：Breadcrumb (パンくずリスト)｜MDN Web Docs）。

アクセシビリティの国際的なガイドライン WCAG 2.2 には、「一連のウェブページの中でのユーザーの位置に関する情報が利用できる」という達成基準 2.4.8（レベル AAA）があります。W3C の解説では、パンくずリストやサイトマップなどで文脈を示すことが挙がっており、深いページにリンクで直接来たユーザーにも役立つとされています（出典：Understanding SC 2.4.8: Location｜W3C）。広告や検索から記事に直接来たユーザーが、ほかのページへ移るときの手がかりになります。ユーザーの使いやすさ全体の改善は「UX改善とは？成果につなげる進め方と実践手法」で解説しています。

2. Google検索でのパンくずリストの扱い

2-1. 検索結果の表示URLに出る。2025年1月からパソコン版のみ

Google検索の結果に表示されるURL（表示URL）には、ドメインとパンくずリストという2つの部分があります（出典：Google 検索の視覚要素ギャラリー｜Google 検索セントラル）。

ただしGoogleは2025年1月23日に、モバイル検索結果にパンくずリストを表示しない変更を始めました。小さな画面では途切れてしまい、モバイルのユーザーには役に立たないと分かったためです。パソコン版の検索結果には引き続き表示され、モバイル版の表示URLはドメインのみになります。パンくずリストのマークアップを使っている場合も、何もする必要はないとされています（出典：モバイル版の検索結果に表示される URL 要素をシンプル化｜Google Search Central Blog）。

広告から来るユーザーの多くがスマートフォンでLPを見ている場合でも、検索結果のパンくずの表示はパソコンの検索結果だけに関わる、という点は押さえておきましょう。

2-2. 構造化データがなくても、GoogleはURLから学習する

Googleは、URL中の言葉に基づいて自動的にパンくずリストを学習しており、技術的には構造化データで影響を与えることもできると説明しています。そのため、ユーザーの役に立ちそうな言葉をURLに含めるよう勧めています（例：https://www.example.com/pets/cats.html）（出典：Google 公式 SEO スターター ガイド｜Google 検索セントラル）。長いID番号ではなく意味のある単語をURLに使うことも、URL構造のベストプラクティスに挙がっています（出典：Google 検索における URL 構造のベスト プラクティス｜Google 検索セントラル）。

2-3. 構造化データで検索結果のパンくずを指定できる

パンくずリストの構造化データ（BreadcrumbList）を使うと、検索結果に出すパンくずを指定できます。Google検索は、検索結果内のページの情報を分類する際に、ページの本文内のパンくずリストのマークアップを使います（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。構造化データは、ページに関する情報を検索エンジン向けに標準化して伝える形式です（出典：構造化データ マークアップとは｜Google 検索セントラル）。書き方は5章で扱います。

3. LPと記事ページでの要不要｜公式に決まりはない

3-1. 置く・置かないを決めた公式の文書はない

Google 検索セントラル、MDN、W3C の文書を確認したかぎり、「LPにはパンくずリストを置くべき」「置かなくてよい」と決めた記述はありません。Googleは、サイトを論理的に整理することを勧めつつ、整理されていなくても検索エンジンはおそらくそのまま把握すると書いています（出典：Google 公式 SEO スターター ガイド｜Google 検索セントラル）。

そのため、要不要はページの作りから判断することになります。判断材料は次の2つです。

3-2. 判断材料1：そのページに「上の階層」があるか

公式の定義では、パンくずリストは「サイト階層内の位置」や「親ページへのリンク」を示すものです（1-1）。つまり、示す対象は親にあたるページです。

1枚もののLPで、カテゴリや一覧のような上の階層のページが存在しない場合、パンくずに並べられる親ページはありません。一方、ブログの記事や、カテゴリ・一覧ページから入れる記事LPのように、親ページがあるなら、パンくずで位置を示せます。

広告から1枚のLPだけに送る作りか、サイトの一部としてページを置く作りかの違いは「LPとホームページの違いは？どちらを作るか判断する基準」で整理しています。

3-3. 判断材料2：検索結果に出すページか

検索結果のパンくずのために構造化データを入れるかどうかは、そのページを検索結果に出すかで決まります。noindex が設定されたページは、Googlebot がそれを検出すると検索結果から完全に削除されます（出典：noindex を使用してコンテンツをインデックスから除外する｜Google 検索セントラル）。Googleも、パンくずの構造化データを入れたページが noindex タグなどでブロックされていないことを確かめるよう書いています（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。

広告の配信先としてだけ使い、検索結果に出さないLPなら、構造化データを入れても検索結果には使われません。この場合に考えるのは、ページ上のパンくずがユーザーの移動に役立つかどうかだけです。

3-4. 記事ページ・記事LPの場合

ブログのようにカテゴリと記事が並ぶ作りでは、記事ページは親ページを持ちます。Googleは、どのページにもサイトのナビゲーションからリンクをたどって到達できるようにし、メニューからカテゴリページへ、カテゴリページから個別のページへリンクすることを勧めています（出典：e コマースサイトの構造を Google が把握できるようにする｜Google 検索セントラル）。パンくずリストは、この「親ページへのリンク」を各ページに置く方法の一つです。

一方、広告から1本の記事LPに直接送り、そこから申し込みへ進ませる作りでは、上の階層がないこともあります。記事LPの構成の考え方は「【2026年】アフィリエイト向け記事LPの作り方とは？｜2026年の広告規制を勝ち抜く構成と作り方」で解説しています。

4. パンくずリストの作り方｜HTMLとアクセシビリティ

ここでは、W3C APG の Breadcrumb Pattern と、Googleのドキュメントに沿った作り方を順に見ていきます。

4-1. nav要素で囲み、aria-labelでラベルを付ける

APG では、パンくずをナビゲーションのランドマーク領域（<nav> 要素）に入れ、aria-label または aria-labelledby でラベルを付けるとしています。例では <nav> に aria-label="Breadcrumb" を付け、パンくずの部分だと識別でき、見つけやすくなると説明しています（出典：Breadcrumb Pattern｜W3C WAI-ARIA Authoring Practices Guide、Breadcrumb Example｜W3C WAI-ARIA Authoring Practices Guide）。

4-2. olで順番に並べ、リンクはa hrefで書く

パンくず専用のHTML要素はありませんが、一般的に <ol>（順序付きリスト）で階層構造を表します（出典：Breadcrumb (パンくずリスト)｜MDN Web Docs）。APG の例も、リンクを順序付きリストで構成しています（出典：Breadcrumb Example｜W3C WAI-ARIA Authoring Practices Guide）。

各項目のリンクは <a href="…"> で書きます。Googleは、リンクが href 属性を持つ <a> 要素の場合に限り、通常はリンクをクロールできるとしています。href のない <a> や、スクリプトのイベントでリンクのように動かすタグからは、URLを信頼できる形で取り出せません（出典：Google の SEO リンクに関するベスト プラクティス｜Google 検索セントラル）。

4-3. 現在のページにaria-current="page"を付ける

APG では、現在のページへのリンクに aria-current を "page" にして付けるとしています。現在のページを表す要素がリンクでない場合、aria-current は任意です（出典：Breadcrumb Pattern｜W3C WAI-ARIA Authoring Practices Guide）。

4-4. 区切り記号はCSSで付ける

「›」や「/」などの区切り記号について、APG の例では CSS で追加しています。区切りは見た目の表現で、パンくずであることはラベル付きの <nav> ですでに伝わっているため、スクリーンリーダーに読み上げさせると冗長になるという理由です（出典：Breadcrumb Example｜W3C WAI-ARIA Authoring Practices Guide）。

なお、APG の例のコードは本番環境向けのものではなく、使う前に支援技術でテストする必要があると明記されています（出典：同上）。

4-5. 並べるのはURLの階層ではなく、ユーザーのたどる経路

1-2のとおり、Googleはパンくずに URL 構造をそのまま反映させるのではなく、ユーザーがたどる一般的な経路を示すよう勧めています。また、最上位のパス（ドメイン名やホスト名）やページ自体を構造化データの項目に含める必要はないとしています（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。スマートフォンの画面幅でパンくずが折り返したり見切れたりしないかも、LPの表示確認とあわせて見ておきましょう。スマートフォンでの表示の整え方は「LPレスポンシブ対応の方法｜スマホ最適化でCVRを上げる7つの施策」で解説しています。

5. パンくずリストの構造化データ（BreadcrumbList）の書き方

5-1. 必須プロパティ

Googleのドキュメントでは、パンくずリストを指定するには、少なくとも2つの ListItem を含む BreadcrumbList を定義するとしています。Googleがサポートするプロパティは次のとおりで、ドキュメントに載っているのは必須プロパティだけです（推奨プロパティの記載はありません）。

対象	プロパティ	内容（Googleの説明）
BreadcrumbList	itemListElement（必須）	決まった順序で並べたパンくずの配列。各パンくずを ListItem で指定する
ListItem	item（必須）	パンくずが表すページのURL。リストの最後のアイテムなら必須ではなく、ない場合はそのページのURLが使われる
ListItem	name（必須）	ユーザーに表示されるパンくずのタイトル
ListItem	position（必須）	パンくずリスト内の位置。1が最初

出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル

schema.org では、BreadcrumbList を「リンクされたウェブページの連なりからなる ItemList で、通常は少なくともURLと名前で記述され、通常は現在のページで終わる」と定義しています（出典：BreadcrumbList｜Schema.org）。

5-2. JSON-LDで書く例

形式は JSON-LD・RDFa・microdata のどれでも書けます。Googleのドキュメントの JSON-LD の例は、「Books › Science Fiction › Award Winners」の3つのパンくずを、position 1〜3 の ListItem で表し、最後の「Award Winners」だけ item を省いています（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。

同じ形で、ブログの記事ページを書くと次の図のようになります。値は説明用の例です。

構造化データは、ページに表示されている内容と一致させる必要があります。ページ上のパンくずと、構造化データの name・item の並びが同じになっているかを確かめます（出典：Google 検索上の構造化データ ガイドライン｜Google 検索セントラル）。

5-3. 1つのページに複数の経路があるとき

サイト内でそのページへ移動する方法が複数ある場合は、1つのページに複数のパンくずリストを指定できます。Googleの例では「書籍 › サイエンス フィクション › 受賞作」と「文学 › 受賞作」の2つを、同じページに指定しています（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。

5-4. テストとSearch Consoleでの確認

公開前は、リッチリザルト テストでコードを検証して重大なエラーを直し、URL 検査ツールでGoogleからの見え方を確かめます。その際、robots.txt、noindex タグ、ログイン要件でページがブロックされていないことを確認します（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。リッチリザルト テストは、URLのほかにコードを貼り付けてテストすることもできます（出典：リッチリザルト テスト｜Search Console ヘルプ）。

公開後は、Search Console の [拡張機能] にあるパンくずリストのレポートで、有効な項目と無効な項目を確認します（出典：リッチリザルト レポートの概要｜Search Console ヘルプ）。Googleは、新しいテンプレートを公開したりコードを更新したりしたあとに、無効な項目が増えていないかを見るよう勧めています（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。

6. パンくずリストでよくある失敗例

6-1. 失敗例1：URLのフォルダ構成をそのままパンくずに並べる

症状：管理のために /lp/2026/campaign-a/ のようなフォルダ構成でページを置いているとき、そのフォルダ名をそのままパンくずに並べると、「2026」のようにユーザーが目にしても意味の分からない項目や、一覧ページが存在しない項目が並ぶ。

原因：Googleは、パンくずリストに URL 構造をそのまま反映させるのではなく、ユーザーがそのページにたどり着くまでの一般的な経路を示すことを勧めています（出典：パンくずリスト（BreadcrumbList）の構造化データ｜Google 検索セントラル）。管理用のフォルダ名は、ユーザーのたどる経路とは別物です。

対策：パンくずには、ユーザーが実際に開けるカテゴリや一覧ページだけを、たどる順に並べます。リンク先のページがない項目は外します。

回避策：パンくずの項目は、URLから自動で作るのではなく、サイトのカテゴリ構成から決めます。URLに意味のある単語を使う（2-2）ことと、パンくずの項目を決めることを分けて考えると、管理の都合がユーザーに見える形で出ることを防げます。

6-2. 失敗例2：区切り記号を文字としてHTMLに入れ、navで囲まない

症状：「ホーム > ブログ > 記事」のように区切り記号を文字としてHTMLに書き、<div> などで並べると、スクリーンリーダーが区切り記号まで読み上げ、どこがパンくずなのかも伝わりにくくなる。

原因：APG の例では、区切り記号を CSS で追加し、スクリーンリーダーに読み上げさせないようにしています。パンくずであることは、ラベルを付けた <nav> で伝えます（出典：Breadcrumb Example｜W3C WAI-ARIA Authoring Practices Guide）。区切りを文字で書き、<nav> を使わないと、この2つがどちらも満たされません。

対策：パンくず全体を aria-label を付けた <nav> で囲み、中を <ol> と <li> で並べます。区切り記号は CSS で表示し、現在のページには aria-current="page" を付けます。

回避策：パンくずのHTMLを部品として1つ作り、毎回それを使います。新しいページを作るたびに手で書くと、区切りやラベルの書き方がページごとにばらつきます。部品を作ったら、支援技術でテストしてから使い回します。

6-3. 失敗例3：パンくずの項目をJavaScriptのクリックで動かす

症状：パンくずの各項目を <span onclick="…"> のように、クリックしたときのJavaScriptで移動させる作りにすると、Googleがリンクとしてたどれず、親ページへのリンクとして扱われない。

原因：Googleは、通常、href 属性を持つ <a> 要素の場合に限りリンクをクロールできるとしています。スクリプトのイベントでリンクとして機能するタグからは、URLを信頼できる形で取り出せません（出典：Google の SEO リンクに関するベスト プラクティス｜Google 検索セントラル）。ナビゲーション用に、ほかのHTML要素でJavaScriptのイベントを使わないよう書かれています（出典：e コマースサイトの構造を Google が把握できるようにする｜Google 検索セントラル）。

対策：パンくずの各項目を <a href="リンク先のURL"> に書き換えます。クリック時の計測などでJavaScriptを使う場合も、href にリンク先のURLを入れたうえで付け加えます。

回避策：デザインの都合でリンクを <span> や <div> で作るテンプレートは避けます。公開前に、パンくずの各項目が href を持つ <a> 要素になっているかを、ブラウザの開発者ツールなどでHTMLを開いて確かめる手順を入れておきます。

7. Squad beyondの記事LPでパンくずリストを置くときの流れ

Squad beyondの公式FAQには、パンくずリスト専用の機能についての記述はありません。ここでは、FAQで確かめられる機能を使って、記事LPにパンくずを置き、検証する流れをまとめます。

7-1. 記事LPはbeyondエディターで作り、WidgetのHTMLを編集する

beyondエディターは、ブロックごとに装飾を加えて構成するエディターで、記事LPの作成で使いやすいとされています。HTMLエディターは、HTML・CSS・JavaScriptで直接コーディングできるエディターです。編集タイプは新規作成時にだけ選べて、あとから変更できません（出典：beyondエディターとHTMLエディターの違いについて｜Squad beyond FAQ）。

beyondエディターでは、Version編集画面の「Widget管理」からWidgetを追加し、「HTML編集」でHTMLやCSSを編集できます（出典：Widgetの使い方｜Squad beyond FAQ）。パンくずを置くなら、WidgetのHTMLに4章の形（<nav>・<ol>・<a href>・aria-current）で書き、区切り記号はCSSで付けます。HTMLエディターで作るページなら、本文のHTMLに同じ形で書きます。

7-2. 繰り返し使うならオリジナルWidgetとして登録する

同じWidgetを何度も使う場合や、チーム全体で共有したい場合は、オリジナルWidgetとして登録できます。既存のWidgetを「HTML編集」で直し、「Widgetとして登録」から名前を付けて登録します（出典：オリジナルWidgetを登録する｜Squad beyond FAQ）。パンくずの部品を一度作って登録しておけば、失敗例2のようなページごとのばらつきを防げます。

7-3. 検索結果に出すなら、noindexと構造化データを確かめる

Squad beyondのLP（beyondページ）は、タグ設定の「noindexを含める」が既定でONです。検索対象にするには、Version編集画面右側の「タグ設定」でOFFにして保存します（出典：beyondページを検索対象の配信ページにする｜Squad beyond FAQ）。ONのままのLPは検索結果に出ないため、パンくずの構造化データを入れても検索結果には使われません（3-3）。

検索対象にして BreadcrumbList の構造化データも入れる場合は、ページごとのタグ設定（head・body内に設置）を使います（出典：作成したページにタグを設置する｜Squad beyond FAQ）。構造化データ専用の機能はFAQに記載がないため、5章の JSON-LD をタグとして置き、ページ上のパンくずと並びが一致しているかを確かめます。

7-4. プレビューで表示とリンクを確かめる

Version編集画面の「プレビュー」では、リンクの設置箇所を確認できます。「作成中の確認用URL」では、「更新」を押す前の編集中のVersionを、Squad beyondのアカウントを持っていない人も確認でき、QRコードからスマートフォンでも見られます（出典：プレビューについて｜Squad beyond FAQ）。パンくずの各リンクが正しいページに飛ぶか、スマートフォンの画面幅で読めるかを、公開前にここで確かめます。

8. パンくずリストについてよくある質問

9. まとめ

• パンくずリストは、ページがサイト階層のどこにあるかを示し、親ページへ戻るためのリンクの列
• Google検索では表示URLの一部として出るが、2025年1月23日からモバイル版では表示されず、パソコン版のみ
• LPに置く・置かないの公式の決まりはない。上の階層があるか、検索結果に出すページかで判断する
• 作るときは、aria-label 付きの <nav>、<ol>、<a href>、現在のページに aria-current="page"、区切り記号は CSS
• 構造化データ（BreadcrumbList）の必須プロパティは itemListElement と、ListItem の item・name・position。ページ上の表示と一致させる

記事LPにパンくずを置くなら、部品を1つ作って使い回し、検索結果に出すかどうかとあわせて設定するのが近道です。Squad beyondなら、パンくずのWidgetをオリジナルWidgetとして登録し、noindexの設定とプレビューで公開前に確かめられます。

---

　

Squad beyondサービス紹介資料はこちらからダウンロード