WEBサイトパンくずリストをマークアップしても、検索結果に出るとは限らない ── BreadcrumbListの実装と、Rich Results Testで確認する14項目（2026年9月時点）
パンくずリストをマークアップしても、検索結果に出るとは限らない ── BreadcrumbListの実装と、Rich Results Testで確認する14項目（2026年9月時点）
目次
01 何が起きたか — 「パンくず」の構造化データは、公式情報でどう定義されているか
Googleが示す定義
Google Search Centralは、パンくずリストの構造化データについて「Breadcrumb（BreadcrumbList）structured data」というページで解説を続けている(Breadcrumb (BreadcrumbList) structured data)。冒頭では、パンくずの役割をこう定義している。
"A breadcrumb trail on a page indicates the page's position in the site hierarchy, and it may help users understand and explore a site effectively."
（訳: ページ上のパンくずの表示は、そのページがサイト階層のどこに位置しているかを示すもので、ユーザーがサイトを効果的に理解し、探索する助けになることがある。）
本記事執筆時点で、このページの最終更新日は2025年12月10日（UTC）と表示されている。書式そのものが大きく変わったという記載はないが、ページの内容は今も更新され続けている前提で読む必要がある。関連する構造化データ全般のガイドライン（04章で扱う）は、さらに新しい2026年7月10日（UTC）付けで更新されており、パンくず単体のページだけを確認して満足すると、隣接するページの更新に気づかないことがある。
出典
本記事の公式情報は、すべてGoogle Search Central・Search Consoleヘルプ・schema.orgの該当ページから、確認できた範囲のみを引用している。確認できなかった部分は「公式には明記されていない」と明示する。
軸になっているのは3つのプロパティ
公式情報を読み解くと、パンくずの構造化データを組み立てる際に押さえるべき要素は、大きく3つに絞られる。パンくずの各階層を並べるリストそのもの、それぞれの階層が何番目に位置するか、そしてユーザーにどう表示するかという名前の3点だ。この3点の関係は、次の03章で表として整理する。マークアップの形式自体は、JSON-LD・RDFa・Microdataのいずれでも認められているが、公式情報のサンプルコードはJSON-LDで統一されているため、本記事もJSON-LDを前提に進める。
WEBディレクターの立場からこの記事を読むときは、実装そのものよりも「何を確認すれば済むか」を先に押さえておくと、あとの章が読みやすくなる。確認すべきことは大きく2つに分かれる。1つはマークアップの文法が正しいか、もう1つはそのマークアップが、実際に検索結果へ影響しているかどうかである。前者はページのソースやRich Results Testで確認でき、公開前でも作業できる。後者はGoogleが実際にそのページをどう扱っているかに関わるため、公開後、Search Consoleのデータが揃うまで待つ必要がある。この2つを混同すると、「文法は正しいのに、なぜ表示されないのか」という疑問に、いつまでも答えが出ない状態になる。
02 なぜ・背景 — URLの階層と、パンくずの階層は別物
検索結果でのカテゴリ表示に使われる
Googleがパンくずマークアップを読み取る目的について、公式情報の「Examples」章にこう記載されている(前掲のBreadcrumb structured dataガイド)。
"Google Search uses breadcrumb markup in the body of a web page to categorize the information from the page in search results."
（訳: Google検索は、検索結果の中でそのページの情報をカテゴリ分けするために、ウェブページ本文中のパンくずマークアップを使用する。）
つまりパンくずの構造化データは、単に「このページの下に、このページがある」という位置関係を示すだけではない。検索結果の見え方そのものに関わる情報として、Googleが読み取る対象になっている。
「URLの階層をそのまま反映する」は推奨されていない
公式情報の「Guidelines」章には、実装時の注意として次の一文がある(同ガイド Guidelines章)。
"We recommend providing breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure."
（訳: URLの構造をそのまま反映するのではなく、そのページへのユーザーの典型的な経路を表すパンくずを提供することを推奨する。）
この一文は、実装を始める前に読んでおく価値がある。URLの階層（フォルダ構成）とパンくずの階層は、同じものである必要がないということだ。たとえば、あるページが技術的な理由で深いディレクトリに置かれていても、ユーザーが実際にそこへたどり着く経路（トップページ→カテゴリ一覧→そのページ、のような順序）が別にあるなら、パンくずはその経路を表現してよい。カテゴリやタグの構造そのものを整理する話は、当サイトが以前に扱った回でも触れている(AI検索時代のトピッククラスターとは？)。パンくずは、その整理された階層を、Googleと読者の両方に見せる出口の1つにあたる。
03 この記事で出てくる用語
用語
BreadcrumbList：schema.orgが定義する構造化データの型のひとつ。schema.org公式は「BreadcrumbListは、リンクされたウェブページの連鎖からなる項目リストであり、通常は少なくともURLと名前で説明され、通常は現在のページで終わる」と定義している(BreadcrumbList - Schema.org Type)。
用語
ListItem：BreadcrumbListの中に並ぶ、それぞれの階層を表す要素。1つのListItemが、パンくずの1段（たとえば「トップページ」や「カテゴリ」）に対応する。
必須プロパティは3つ、条件付き必須が1つ
公式情報を突き合わせると、BreadcrumbListとListItemが持つプロパティは、必須と条件付き必須の2種類に分かれる。下の表に整理した。
| プロパティ | 必須区分 | 内容 |
|---|---|---|
| itemListElement | 必須 | ListItem（各階層の項目）を並べた配列。BreadcrumbList全体を構成する本体 |
| position | 必須 | そのListItemが、パンくずの中で何番目に位置するかを示す整数（1から始まる） |
| name | 必須 | ユーザーに表示される、その階層の名前（テキスト） |
| item | 条件付き必須 | そのページのURL。最後の項目（現在のページ）についてだけ省略できる |
最後のitemを省略できることの意味
公式のサンプルコードでも、3番目（最後）のListItemだけitemプロパティが書かれていない例が示されている(前掲のBreadcrumb structured dataガイド)。これは「現在開いているページのURLを、そのページ自身の中にもう一度書く必要はない」という考え方に基づくと読める。ただし省略が必須というわけではなく、最後の項目に自分自身のURLを書いても、それ自体が誤りになるわけではない。どちらの書き方も許容されている。
04 型別 — 適用範囲・この対策が保証しないこと・手順
🅰 適用範囲 — 階層が複数あるサイトほど効く
パンくずの構造化データが特に効くのは、カテゴリやタグで記事・商品を分類しているサイトだ。ECサイトの商品ページ、複数カテゴリを持つブログ、マニュアルやFAQのような階層型のドキュメントサイトが該当する。一方、トップページと個別ページの2階層しか持たない小規模なサイトでは、パンくず自体を用意する必要性が薄い。ページ数が少なく、階層の複雑さがないサイトでは、パンくずマークアップの優先度は他の対策より下がる。
複数のカテゴリから同じページへたどり着けるサイトでは、もう一点の判断が必要になる。02章で引用した「典型的なユーザーの経路」という推奨は、ページが複数の位置を持ちうる場合、そのうち最も一般的にたどられる経路を選ぶという意味でもある。すべての経路を並べて書くのではなく、代表的な1つの経路に絞る判断が求められる。
ただし、公式情報には「複数のパンくずトレイル」を1つのページに持たせる方法も別途 用意されている。
"If there are multiple ways to navigate to a page on your site, you can specify multiple breadcrumb trails for a single page."
（訳: サイト内のあるページへ複数の経路でたどり着ける場合、1つのページに対して複数のパンくずトレイルを指定できる。）
実装するときは、JSON-LDを配列にしてBreadcrumbListオブジェクトを複数並べる形になる。ただし、これは「代表的な1つの経路に絞る」推奨と矛盾するものではない。あくまで、複数の経路のどれもがユーザーにとって同じくらい典型的だと判断できる場合の選択肢であって、迷ったときの既定の答えではない。まずは1本の経路に絞れないかを先に検討し、それでも絞りきれない場合の手段として位置づけるほうが実装は安定する。
公式情報のガイドラインには、パンくずの実装が、より基本的なGoogle Search Essentialsと、04章末で扱う一般的な構造化データのガイドラインの両方に従うことを前提としている旨も明記されている(Google Search Essentials)。パンくずだけを単独で正しく実装しても、サイト全体がインデックス登録の基本要件を満たしていなければ、そもそもGoogleに読まれる機会自体が少なくなる。
🅱 この対策が保証しないこと
実装の前に、最も重要な限界を押さえておく。Googleの構造化データ全般に関するガイドラインには、次の記載がある(General structured data guidelines)。
"Important: Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly according to the Rich Results Test."
（訳: 重要: Rich Results Testで正しくマークアップされていると判定されたページであっても、その構造化データが検索結果に表示されることをGoogleは保証しない。）
つまり、BreadcrumbListを文法どおりにマークアップし、Rich Results Testでエラーがゼロになったとしても、それだけで検索結果にパンくず形式の表示が出るとは限らない。表示するかどうかはGoogleのアルゴリズムが個別に判断する。マークアップは「表示される可能性の条件を満たす」ための作業であって、「表示を確定させる」作業ではない。この違いを取り違えると、正しく実装したのに表示されないという状態を、実装の誤りだと誤解してしまう。
🅲 手順 — 書く・確かめる・見張る、の3段階
実装の流れは、書く・確かめる・見張るの3段階に分けられる。第一に、自分のサイトの実際のページ遷移（ユーザーが実際にたどる経路）を洗い出し、02章の推奨に沿ってJSON-LDでBreadcrumbListを書く。公式情報の例は<head>タグの中に<script type="application/ld+json">を置く形で統一されているが(前掲のBreadcrumb structured dataガイド)、CMSやテンプレートの仕組みによっては、本文側で自動的に出力される場合もある。どちらの場合でも、最終的にページのソースに正しく出力されているかを確認する点は変わらない。第二に、Rich Results Testに公開前後のURLを貼り付け、文法エラーと警告がないかを確認する(Rich Results Test)。第三に、Search ConsoleのURL検査ツールで、Googleが実際にインデックスしたバージョンのページにも同じBreadcrumbListが含まれているかを確認する(URL Inspection tool)。この3段階のうち、Rich Results Testは公開前でも使えるが、URL検査ツールはGoogleに一度読み込まれた後でなければ、正確な情報が返らない点に注意する。
05 自分のサイトで確認するチェックリスト
3つの観点で構成した
ここまでの内容を、今日から手を動かせる作業に翻訳した。観点は、現状の把握（自分のサイトに何があるかを数える）、文法の確認（Rich Results Testでの検証）、実際の反映確認（Search Consoleでの確認）の3つに分かれる。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されない。
実務のヒント
BreadcrumbListのマークアップを自分でゼロから書くのが難しい場合は、当サイトの🔧 WEBサイト・構造化データ自動作成ツールで、たたき台となるJSON-LDを作成できる。
- 自分のサイトでパンくずが画面に表示されている代表的なページを3つ書き出す
- そのページのパンくず表示（トップページ→カテゴリ→記事、のような並び）が、URLのフォルダ構成と一致しているか確認する
- ブラウザでページのソースを開き、
application/ld+jsonのスクリプトの中に"@type":"BreadcrumbList"が含まれているか確認する - 見つかったBreadcrumbListのitemListElementに、ListItemがいくつ含まれているか数える
- 各ListItemに、position・name・itemの3つが揃っているか、1件ずつ確認する
- 最後のListItem（現在のページ）だけ、itemプロパティが省略されているか、書かれているかを確認する
- Rich Results Testに対象ページのURLを貼り付け、BreadcrumbListがエラーなしで検出されるか確認する
- Rich Results Testの結果画面に、警告（Warning）が表示されていないか確認する
- Search ConsoleのURL検査ツールで同じページを検査し、Googleに登録されているバージョンにも同じBreadcrumbListが含まれているか確認する
- Search Consoleの左メニューから拡張性のレポート一覧を開き、Breadcrumbsのレポートがあるか確認する
- Breadcrumbsレポートで、有効なアイテムの件数とエラーのあるアイテムの件数をそれぞれ書き出す
- 各ListItemのnameの文言が、実際にページ上で見えている見出しやメニューの表記と一致しているか確認する
- 複数のカテゴリからたどり着けるページが1つあれば、そのパンくずが最も典型的な経路を表しているか確認する
- 検索結果で自分のサイトのページを検索し、パンくず形式のURL表示が出ているかどうかを目で確認する
14項目の内訳と、かかる時間の目安
最初の2項目は現状の把握、3番目から9番目までは文法の確認、10番目から14番目まではSearch Consoleでの反映確認に対応している。すべてに目を通す時間の目安は、パンくずを持つページ1つあたり15分程度である。パンくずを持つページが複数のテンプレートにまたがる場合（記事ページと商品ページなど）は、テンプレートごとに1回、この一覧を確認するとよい。同じテンプレートを使い回しているページは、1つのページで確認できれば、他のページも同じ構成になっている可能性が高い。ただし、テンプレートが同じでもカテゴリの階層だけ個別に上書きされている場合があるため、テンプレートを信頼しきらず、実際に複数のページで確認しておくと取りこぼしが減る。
06 表示を確かめる手段の比較
4つの手段、それぞれの向き不向き
BreadcrumbListが正しく表示されているかを確かめる方法は、1つではない。以下は、それぞれの手段が「何が分かって、何が分からないか」を整理した表である。
| 手段 | 分かること | 分からないこと・限界 |
|---|---|---|
| Rich Results Test | マークアップの文法が正しいか、公開前でもその場で確認できる | 実際に検索結果へ表示されるかどうかは判定しない |
| URL検査ツール （Search Console） | Googleが実際にそのページをどう認識しているか、登録済みのバージョンを確認できる | まだ登録されていないページは確認できず、反映まで時間もかかる |
| Breadcrumbs レポート（Search Console） | サイト全体で、エラーや警告のあるページを一覧で把握できる | 反映まで数日かかり、その場ですぐの結果ではない |
| ブラウザで ソースを直接見る | 環境を問わず、いつでもその場でJSON-LDの中身を確認できる | 文法エラーの有無や、Google側の解釈までは分からない |
この表からわかるとおり、1つの手段だけで確認が完結するわけではない。実装した直後はRich Results Testで文法を確かめ、公開してGoogleに読み込まれた後はURL検査ツールで登録済みのバージョンを確かめ、サイト全体を継続的に見るならBreadcrumbsレポートを定期的に開く、という組み合わせが現実的だ。公式情報の「Rich result status reports」も、有効なアイテムとエラーのあるアイテムを視覚的なグラフで示す設計になっており(Rich result status reports)、単発の確認ではなく継続して見張る用途を想定していると読める。
4つの手段の使い分けで迷ったときは、確認したいことが「今この瞬間の文法」なのか、「Googleが実際に読んだ結果」なのかで選ぶとよい。前者ならRich Results Testで十分で、公開作業のたびに待つ必要はない。後者はGoogleがそのページを再度クロールするまで結果が変わらないため、URL検査ツールで「インデックス登録をリクエスト」を使っても、反映には時間差がある前提で確認のタイミングを決める。
07 自社サイトで確認したこと
ブログ記事とSEO記事で、パンくずの階層の深さが違った
実際に、自社サイトの公開ページを開いて、application/ld+jsonの中身を確認してみた。AI Ronのブログ記事のページでは、BreadcrumbListに3つのListItemが含まれ、position 1が「トップページ」、position 2が「AI Ronのブログ」、position 3が記事タイトルという構成だった。一方、seo_articleの記事ページでは、BreadcrumbListに含まれるListItemが2つで、position 1が「トップページ」、position 2が記事タイトルという構成になっており、中間のカテゴリに相当する階層が無かった。
どちらも、03章の表に整理した必須プロパティ（position・name・item）はすべて揃っており、Rich Results Testで見ればエラーは出ない構成である。schema.orgの定義が「少なくとも2つ以上のListItem」を前提にしていることを踏まえれば、どちらの実装も仕様は満たしている。
2階層でも仕様は満たしている、が伝わる情報は減る
ただし、2階層のパンくずでは「このページが、どのカテゴリの下にあるか」という情報が、構造化データの中に含まれない。02章で引用した「Googleは検索結果の中でカテゴリ分けにパンくずを使う」という説明を踏まえると、中間のカテゴリ階層を持たないパンくずは、Googleに渡す情報そのものが少ない状態にあると考えられる。これが実際の表示にどう影響するかは、07章の性質上、公式に明記された基準ではなく自分のサイトで確認できた構造の違いにとどまる。中間階層を追加するかどうかの判断は、サイトの分類体系がどこまで固まっているかによって変わるため、本記事では断定しない。
2つの構成を並べてみると、共通するのはどちらも文法上は正しいという点である。Rich Results Testに両方のページを貼り付けても、エラーは検出されないはずだ。つまり「Rich Results Testを通ったこと」は、パンくずが持っている情報の量までは保証しない。文法の正しさと、Googleに渡している情報の豊かさは、別の軸で確認する必要がある。この違いは、05章のチェックリストで「ListItemがいくつ含まれているか数える」という項目を、あえて「エラーがないか確認する」という項目とは別に立てている理由でもある。
08 このテーマの、これまで
構造化データの出力そのものを、値ごとに確かめた回
構造化データは「出力されていること」と「正しい値が入っていること」が別だという内容を、datePublished・og:type・用語ハイライト・sitemapの4つの値で確かめた回がある(archives/128)。この回では、出力そのものは存在していたにもかかわらず、値の中身までは誰も確認していなかった箇所が4つ見つかっている。あわせて、sitemap・canonical・内部リンク・末尾スラッシュという4つの整合性を、手元のコマンドで確かめる方法を扱った回もある(archives/39)。BreadcrumbListも同じ構造化データの一種であり、「マークアップした」ことと「正しい値が入っている」ことを分けて確認する必要がある点は共通している。07章で確認した2階層と3階層の違いも、両方とも「出力そのものは存在していた」ケースであり、値の中身（含まれる階層の数）まで見なければ気づけなかった点で、この回と同じ構造をしている。
「測定中」は、測っていないことと同じだった回
「測定中」というラベルを付けたまま、実際にはその確認を長期間していなかった事例を、公開から52日分のログを開いて確かめた回がある(archives/135)。また、確認して「0件」という結果が出たとき、それを安心材料として扱ってよいとは限らないことを確かめた回もある(archives/130)。本記事の05章のチェックリストも、一度実行して終わりにせず、サイトの構造を変えるたびに開き直す運用を決めておくことが、同じように重要になる。パンくずの実装は、サイトを作った時点で一度組み込めば終わり、という性質のものではない。カテゴリの構成を見直したとき、記事を別のカテゴリへ移したとき、あるいはサイト全体のディレクトリ構成を変えたときには、そのつどBreadcrumbListの中身が実際の経路と一致しているかを確認し直す必要がある。
現在の貴方のIPアドレス
このサイトで書いている人
