BreadcrumbList スキーマ

TL;DR — BreadcrumbList は（通常 JSON-LD で記述する）コードで、サイト内のページの位置を示す経路 — Home > Category > Page — を Google に伝えます。Google はこの読みやすい経路を、扱いにくい URL の代わりに検索結果へ表示でき、ページがどのように分類されるかを理解するためにも使います。経路には少なくともいくつかのステップが必要で、各ステップに position、name、リンクを付けます。ただし最後のステップ（現在のページ）はリンクを必要としません。

BreadcrumbList スキーマとは

パンくずは、ページ上部付近にある小さなナビゲーション経路で、現在地を示します：Home > Shoes > Running Shoes。BreadcrumbList は、その経路を機械可読な形で記述し、検索エンジンが推測せず直接読み取れるようにする schema.org の型です。 Evidence for this claim Schema.org defines BreadcrumbList as an ItemList representing a chain of linked web pages. Scope: Schema.org vocabulary; Google has separate breadcrumb feature requirements. Confidence: high · Verified: 2026-07-14 Schema.org: BreadcrumbList

多くのサイトでは JSON-LD として追加します。ページの HTML に置く小さなコードブロックです。（Google は Microdata と RDFa も受け付けますが、推奨する形式は JSON-LD です。）

追加する価値がある理由

理由は二つあります。

1. 検索結果が読みやすくなる。 Google は生の URL の代わりに、検索スニペットへパンくず経路を表示できます。そのため、長いアドレスではなく example.com › Shoes › Running のように見せられます。 Evidence for this claim Google says breadcrumb markup can categorize page information and can be used in search-result breadcrumbs. Scope: Google Search breadcrumb documentation; display is not guaranteed. Confidence: high · Verified: 2026-07-14 Google: Breadcrumb structured data
2. Google がページを分類しやすくなる。 Google はパンくず経路を読み取ってページの位置を理解します。これが、同じページでも検索されたクエリによって異なる経路の下に表示されることがある理由です。

最低限必要なもの

BreadcrumbList には itemListElement という順序付きリストが入ります。経路の各ステップは ListItem で、次の三つを持ちます。

• position — 1 から始まるステップ番号。
• name — そのステップの呼び名（例：「Running Shoes」）。
• item — そのステップがリンクする URL。

唯一の例外は 最後 の item（現在のページ）です。すでに表示しているページなので、item URL は必要ありません。

よくある二つの誤解

• ランキング要因ではない。 Breadcrumb スキーマは検索結果の 見え方 と Google によるページの 分類 に影響しますが、ランキングを押し上げるものではありません。
• 経路は URL のフォルダーではなく、人がたどる方法に合わせる。 Google も実際にこれを推奨しています。URL がフラットな /product-123/ でも、ユーザーが Home > Shoes > Running を経由するなら、その ナビゲーション 経路をマークアップします。

覚えておきたい点がもう一つあります。スキーマを追加しても、人間の訪問者向けの表示パンくずはページに生成されません。それは自分で構築する別の HTML です。表示経路や内部リンクの価値など、パンくずのナビゲーションと UX の側面を知りたい場合は別のテーマで、このページはマークアップを扱います。

必須プロパティと任意プロパティの内訳、壊れたコード例と正しいコード例、検証方法、そして 2026 年にも Google がパンくずを表示するかについての率直な見方を知りたい場合は、Advanced タブへ切り替えてください。

TL;DR — BreadcrumbList はページのパンくず経路を構造化データとしてマークアップします（JSON-LD 推奨、Microdata／RDFa も対応）。役割は二つあります。Google のスニペットで URL の代わりにパンくず経路を表示する対象になることと、Google の言葉では、Google が “uses breadcrumb markup in the body of a web page to categorize the information from the page in search results,” (翻訳) 「ページ本文のパンくずマークアップを使って、検索結果におけるページ情報を分類する」ことです。そのため、一つのページがクエリごとに異なる経路の下に表示されます。必要な形は、BreadcrumbList.itemListElement が順序付き配列で、各 ListItem に position、name、item を持たせます。item は最後（現在）の item だけ省略できます。Google は、経路を URL 構造ではなく典型的なユーザー経路 に合わせるよう推奨し、ホームページと現在のページの ListItem はどちらも省略できると説明しています。これは ランキングシグナルではなく、有効なマークアップでもリッチ表示は 保証されません。また、リッチリザルトの対象資格は Mueller の三層（有効なマークアップ → ポリシー遵守 → サイト品質の信頼）を通ります。2026 年に Google が SERP でパンくずを安定して表示するかは本当に意見が分かれているため、分類の価値、低コスト、デメリットのなさを理由に実装し、自分の結果を確認してください。

正確には何か

BreadcrumbList は schema.org の型です。schema.org はこれを、“an ItemList consisting of a chain of linked Web pages, typically described using at least their URL and their name, and typically ending with the current page.” (翻訳) 「リンクされた Web ページの連なりからなる ItemList で、通常は少なくとも URL と名前で記述され、通常は現在のページで終わるもの」と定義しています。実際には、経路のステップごとに一つずつ ListItem エントリを持つ、itemListElement の順序付き配列を含む BreadcrumbList を構築します。 Evidence for this claim Google's breadcrumb examples use ordered ListItem entries with position, name, and item, with documented flexibility for the final item. Scope: Google Search breadcrumb feature requirements; schema.org permits a broader vocabulary. Confidence: high · Verified: 2026-07-14 Google: Breadcrumb structured data

JSON-LD、Microdata、RDFa のいずれでも表現できます。Google が推奨し、自分なら既定にするのは JSON-LD です。一つの script ブロックに収まり、表示用マークアップと絡まず、テンプレート化とデバッグが最も簡単だからです。

パンくずマークアップの二つの役割

これは多くの競合ページが見落とす枠組みです。いきなり「この JSON-LD を貼る」と始めますが、パンくずマークアップには別々の役割が二つあります。

1. リッチ SERP 表示の対象になる。 Google は生の URL の代わりに、検索スニペットへパンくず経路を表示できます。ここで重要なのは 対象になる という言葉です。有効なマークアップは候補にするだけで、表示を保証しません（詳しくは後述します）。

2. Google が内部で読む分類シグナルになる。 Google のドキュメントからそのまま引用すると、“Google Search uses breadcrumb markup in the body of a web page to categorize the information from the page in search results.” (翻訳) 「Google 検索はページ本文のパンくずマークアップを使って、検索結果におけるページ情報を分類します。」これは過小評価されがちな半分です。同じ URL がクエリによって 異なる パンくず経路の下に表示される理由でもあります。Google は経路を単なる装飾ではなく文脈として使うため、表示パンくずが出ないクエリでもこの価値は存在します。

具体的には、Google のドキュメントは、同じページに 複数の別々な BreadcrumbList オブジェクトを置く形を示しています。ユーザーが現実的にたどり得る経路ごとに一つの完全な JSON-LD ブロックを置くのであって、クエリごとに適応する一つの経路ではありません。ページが複数のカテゴリから実際に到達可能な場合（EC ではよくあります）は、各経路を独自の BreadcrumbList としてマークアップし、すべての代替経路を個別に有効に保ちます。以下のルールどおり、各経路のすべての ListItem にそれぞれ position、name、item が必要です。一つの「主要」経路で、実際には記述していない経路の分類価値まで覆えるとは考えないでください。

必須プロパティと任意プロパティ

ここが正確さの骨格です。ここを正しくすれば、残りは細部です。

必須：

• BreadcrumbList.itemListElement — “An array of breadcrumbs listed in a specific order.” (翻訳) 「特定の順序で並べたパンくずの配列です。」経路のステップを順序付けるリストです。
• ListItem.position — “The position of the breadcrumb in the breadcrumb trail. Position 1 signifies the beginning of the trail.” (翻訳) 「パンくず経路におけるパンくずの位置です。位置 1 は経路の始まりを示します。」1 から始めて増やします。
• ListItem.item（name 付き）— 各ステップの URL とラベルです。最後の item だけは現在のページなので URL を省略できますが、それ以外のすべての item に必要です。

Google は最後の item の例外を明確に説明しています。“It is not required to include a breadcrumb ListItem for the top level path (your site’s domain or host name), nor for the page itself.” (翻訳) 「最上位の経路（サイトのドメインまたはホスト名）についても、ページ自体についても、パンくずの ListItem を含める必要はありません。」つまり ホームページと現在のページは、どちらも含めなくてかまいません。両方が必須だと思うのは、よくある誤解です。

意味のある経路には少なくとも二つの ListItem が必要です。1 ステップだけの「パンくず」は経路になりません。

ユーザー経路と URL 構造

ここは身につけておく価値のある細部です。Google が明示しているのに、多くのガイドが省いています。“We recommend providing breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure.” (翻訳) 「URL 構造をそのまま写すのではなく、ページへの典型的なユーザー経路を表すパンくずを提供することを推奨します。」

言い換えると、パンくず経路は ナビゲーション の記述であり、ディレクトリ の記述ではありません。両者がずれる、つまり URL がフラットなのに分類が深い場合、タグページ、または商品が複数の経路から到達可能な複雑なファセットナビゲーションでは、URL のフォルダーではなく、ユーザーが実際にたどる経路をマークアップします。これは、一つの商品が複数のカテゴリ経路に正当に属する EC サイトで特に重要です。そこは ファセットナビゲーション と URL 構造が複雑になりやすい場所でもあります。ページのマークアップには主要なユーザー経路を選びます。

ランキング要因ではない

「ランキングに役立つか」は検索者からよく出る質問なので、明確に言いましょう。Google のガイダンスには BreadcrumbList とランキングを結び付ける記述がありません。 SERP の表示と内部分類に影響しますが、掲載順位には影響しません。追加しても順位は上がらず、追加しなくても順位が抑えられるわけではありません。実装する理由は、分類シグナルと表示される可能性を低い実装コストで得られることです。

検証して展開する

Google が示す手順は単純です。

1. 必須プロパティを追加する。 選んだ形式で、Google の配置ガイダンスに従います。
2. 検証する。 リッチリザルトテストで確認し、重大なエラーを修正します。
3. 少数ページから展開する。 まず数ページへ導入し、Search Console の URL 検査で確認してからサイト全体へ展開します。

Search Console には専用の Breadcrumbs 拡張レポートがあります。公開後にサイト全体のエラーと警告を表示するので、継続的な健全性を監視する場所になります。

パンくずのリッチリザルトが表示されないのはなぜか

有効なマークアップは必要ですが、それだけでは十分ではありません。John Mueller は、リッチリザルトの対象資格全般について有用な三層モデルを示しています（ここではその枠組みを要約します）。第一にマークアップが技術的に有効であること、第二に Google の構造化データポリシーに準拠していること、第三に通常はサイト全体に及ぶ、より広い 品質／信頼 シグナルです。つまり、Google が構造化データから拡張結果を表示するほどサイトを信頼しているかどうかです。

Mueller は大まかな診断方法も示しています。自分のドメインに対して site: クエリを実行し、そこでリッチリザルトが表示されるか確認します。site: クエリでは拡張結果が表示されるのに通常のクエリでは表示されないなら、技術的な問題よりも、マークアップではなくサイト品質／信頼の問題である可能性が高くなります。

パンくずについて、Mueller はポリシーリスクを低く見積もっています。パンくずはかなり文字どおりの構造化データ型なので、ポリシーに抵触する形で 間違える のが難しい部類だ、という趣旨です。パンくずのリッチリザルトが表示されない場合は、パンくずマークアップ自体のポリシー違反より、表示または品質の層が原因である可能性が高いという安心材料として扱います。

適用される唯一のポリシー上の土台は、Google の 一般的な構造化データガイドラインです。マークアップは実際のページ上のコンテンツを反映しなければなりません。リッチリザルトを不正に得るため、実際のサイト構造と一致しないパンくず経路を捏造しないでください。ガイドラインから外れたマークアップは、原則として手動対策の対象になり得ます。

Google は 2026 年も SERP にパンくずを表示するのか（率直な回答）

ここでは自信満々に断定せず、慎重でありたいと思います。出典が本当に一致していません。2025〜2026 年の一部の記事は Google がパンくず表示を削除した（まずデスクトップ、次にモバイル）と主張し、別の 2026 年付けのガイドは BreadcrumbList をパンくずがまだ表示される 比較的安定した スキーマ型の一つと説明しています。Google 自身のパンくずドキュメントは、2026 年半ばの時点でも、この機能を “desktop in all regions and languages where Google Search is available” (翻訳) 「Google 検索を利用できるすべての地域と言語のデスクトップ」に適用するとしており、廃止の注記はありません。

この意見の相違を、「Google は表示する」または「もう終わった」と平板に解決するつもりはありません。表示側は目に見えて変化中で、画像に埋め込まれたスクリーンショットや単一地域での観測に依存する二次的な主張は、信頼できる根拠になりません。推奨は意思決定を先にすることです。それでも実装してください。 分類の価値は表示経路の描画に依存せず、実装コストは低く、デメリットもありません。そのうえで、ブログ記事のスクリーンショットを信じるのではなく、重要な検索面と地域で自分のクエリ集合の SERPを確認します。ライブで決着していない問いに対する正直な姿勢です。

ナビゲーションと UX の観点、つまり内部リンクとしての表示パンくず、PageRank の流れ、アクセシビリティを知りたい場合は、サイト構造で扱う姉妹テーマを参照してください。このページは意図的に マークアップ に絞っています。

Bing とその他の検索エンジン

BreadcrumbList は Google 独自のものではなく、標準の schema.org 型です。Bing は長年、構造化データ全般について schema.org の語彙（JSON-LD、Microdata、RDFa）をサポートすると説明してきました。Bing にパンくずスキーマ専用のドキュメントページは見つけられなかったため、Bing の対応はパンくず専用のリッチリザルト保証ではなく、一般的な schema.org 対応として説明します。Google 用に書いたマークアップは Bing でも有効ですが、Bing がパンくず拡張を表示するか、どのように表示するかは、別の、より文書化されていない問題です。

要点

• 最小限の有効な構造は、BreadcrumbList → itemListElement 配列 → ListItem です。各 item に position（1 から）、name、item を付け、item を省略できるのは最後の item だけです。
• Google は URL 構造ではなくユーザー経路を推奨します。ホームページと現在のページは含めなくてもかまいません。
• ランキング要因ではありません。 有効なマークアップでも表示は 保証されません。
• 2026 年の SERP 表示には本当に意見の相違があります。分類の価値を理由に実装し、自分の結果で確認してください。

AI 要約

Advanced 版を短くまとめます。

• BreadcrumbList = ページのパンくず経路を表す schema.org 型で、JSON-LD（推奨）として追加します（Microdata／RDFa も使えます）。
• 役割は二つ： (1) Google のスニペットで URL の代わりにパンくず経路を表示する対象になること、(2) 分類シグナルになることです。Google は “uses breadcrumb markup in the body of a web page to categorize the information” (翻訳) 「ページ本文のパンくずマークアップを使って情報を分類する」と説明しているため、同じページがクエリによって異なる経路の下に表示されます。
• 必須の形： BreadcrumbList.itemListElement は ListItem の順序付き配列で、各 item に position（1 から）、name、item が必要です。item を省略できるのは最後（現在のページ）の item だけです。
• 含めなくてもよいもの： ホームページと現在のページです。Google はどちらも必須ではないと説明しています。
• URL 構造ではなくユーザー経路： パンくずは典型的なユーザー経路を表すよう Google が推奨しています。フラットな URL、タグページ、ファセットナビゲーションで重要です。
• ランキング要因ではありません。 表示と分類に影響しますが、掲載順位には影響しません。
• Rich Results Test で検証し、URL 検査で確認してから展開します。Search Console の Breadcrumbs レポートで監視します。
• リッチリザルトのトラブルシューティング（Mueller の層を要約）： 有効なマークアップ → ポリシー遵守 → サイト品質／信頼です。site: クエリは大まかな診断で、そこで表示され通常のクエリで表示されないなら、マークアップより品質を示します。
• 2026 年の表示には意見の相違があります。 削除を主張する出典と継続を主張する出典があり、Google のドキュメントは廃止注記なしでデスクトップに適用するとしています。それでも実装し、自分の SERP を確認します。
• Bing： schema.org を広くサポートします。専用の Bing パンくずドキュメントは見つかっていないので、検索エンジン間の対応はパンくず固有の保証ではなく一般的な対応として扱います。

公式ドキュメント

BreadcrumbList マークアップの一次資料です。

Google

• Breadcrumb（BreadcrumbList）構造化データ — 必須プロパティ、JSON-LD／Microdata／RDFa の例、ユーザー経路の推奨、検証と展開の手順。
• 一般的な構造化データガイドライン — マークアップは実際のページ上のコンテンツを反映しなければならず、違反は手動対策につながり得るというポリシー上の土台。
• リッチリザルトテスト — 展開前後に BreadcrumbList マークアップを検証するツール。

schema.org

• schema.org/BreadcrumbList — 「リンクされた Web ページの連なりで、通常は現在のページで終わる」という型の定義。
• schema.org/breadcrumb — BreadcrumbList を WebPage に関連付ける breadcrumb プロパティ。
• schema.org/ListItem — 各ステップに使う item 型（position、name、item）。

Bing／Microsoft

Bing にパンくずスキーマ専用のドキュメントページは見つかりませんでした。Bing は構造化データ全般について schema.org の語彙（JSON-LD、Microdata、RDFa）を広くサポートし、BreadcrumbList は標準の schema.org 型です。そのため同じマークアップは Bing でも有効ですが、引用できるパンくず専用の Bing リッチリザルト保証はありません。

出典からの引用

Google と schema.org による記録に残る説明です。逐語引用には、出典ページの該当箇所へのリンクを付けています。

schema.org — BreadcrumbList とは何か

• “A BreadcrumbList is an ItemList consisting of a chain of linked Web pages, typically described using at least their URL and their name, and typically ending with the current page.” (翻訳) 「BreadcrumbList は、リンクされた Web ページの連なりからなる ItemList で、通常は少なくとも URL と名前で記述され、通常は現在のページで終わります。」 — schema.org。 引用箇所へ移動

Google — 分類シグナル

• “Google Search uses breadcrumb markup in the body of a web page to categorize the information from the page in search results.” (翻訳) 「Google 検索はページ本文のパンくずマークアップを使って、検索結果におけるページ情報を分類します。」 — Google Search Central のドキュメント。 引用箇所へ移動

Google — URL 構造ではなくユーザー経路

• “We recommend providing breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure.” (翻訳) 「URL 構造をそのまま写すのではなく、ページへの典型的なユーザー経路を表すパンくずを提供することを推奨します。」 引用箇所へ移動

Google — ホームページと現在のページは任意

• “It is not required to include a breadcrumb ListItem for the top level path (your site’s domain or host name), nor for the page itself.” (翻訳) 「最上位の経路（サイトのドメインまたはホスト名）についても、ページ自体についても、パンくずの ListItem を含める必要はありません。」 引用箇所へ移動

Google — プロパティの意味

• itemListElement について：“An array of breadcrumbs listed in a specific order.” (翻訳) 「特定の順序で並べたパンくずの配列です。」position について：“The position of the breadcrumb in the breadcrumb trail. Position 1 signifies the beginning of the trail.” (翻訳) 「パンくず経路におけるパンくずの位置です。位置 1 は経路の始まりを示します。」 — Google Search Central のドキュメント（パンくず構造化データリファレンス）。

壊れた BreadcrumbList — なぜ失敗するのか

一見すると正しそうですが、実際にはいくつか問題のある JSON-LD ブロックです。注記を読む前に問題を見つけてください。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "name": "Shoes",
      "item": "https://example.com/shoes/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "item": "https://example.com/shoes/running/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Trail Runner 5",
      "item": "https://example.com/shoes/running/trail-runner-5/"
    }
  ]
}

問題点：

• 最初の item に position がない。 すべての ListItem に position が必要で、経路は 1 から始めなければなりません。
• 位置が重複し、1 から始まっていない。 二つの item が position: 2 を持ち、position: 1 がありません。位置は 1 から始まる連続した昇順でなければなりません。
• 二番目の item に name がない。 name は各ステップで必須です。item URL だけでは不十分です。
• 最後の item に item URL がある。 これは 無効ではありません が、URL を省略できる唯一の場所が最後（現在のページ）なので、多くの実装では省略します。

正しい形

同じ経路を正しく書いた例です。現在のページから二つ上の階層までを、1 から昇順の位置で並べ、すべてのステップに name を付け、最後（現在のページ）の item では item を省略しています。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Shoes",
      "item": "https://example.com/shoes/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Running Shoes",
      "item": "https://example.com/shoes/running/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Trail Runner 5"
    }
  ]
}

確認する点：

• position は 1 → 2 → 3 と進む。 経路順に各 ListItem へ一つずつ付けます。
• すべてのステップに name がある。
• 最後の item では item を省略している。 現在のページなので許可される唯一の省略です（含めてもかまいませんが、任意です）。
• ホームページの ListItem がない。 Google は最上位／ドメインのステップを任意としています。ユーザーの実際の経路を反映する場合だけ Home ステップを含めます。
• 経路はナビゲーションを反映し、必ずしも URL のフォルダーを反映しない。 ここではたまたま一致していますが、商品の URL がフラットな /trail-runner-5/ でも、Google が表すよう推奨しているユーザー経路として Shoes > Running Shoes > Trail Runner 5 をマークアップします。

どちらかのブロックを リッチリザルトテストに入れると、壊れた例ではエラーが検出され、正しい例では合格することを確認できます。

避けるべき BreadcrumbList の誤りと神話

神話：“Adding BreadcrumbList schema will boost my rankings.” (翻訳) 「BreadcrumbList スキーマを追加すればランキングが上がる」。 上がりません。Google のガイダンスはパンくずマークアップを掲載順位と結び付けていません。SERP の表示と内部分類に影響しますが、順位には影響しません。ランキングを動かす施策ではなく、低コストで表示と分類を改善する施策として扱います。

神話：“I have to include a homepage step and a current-page step in every trail.” (翻訳) 「すべての経路にホームページのステップと現在のページのステップを含めなければならない」。 Google はどちらも必須ではないと明確に説明しています。最上位／ドメインのステップと現在のページの ListItem は省略できます。最初の実際のカテゴリから始まり、最後のステップで item URL を省略する経路でも完全に有効です。

誤り：1 から始まらない、番号を飛ばす、または重複する位置。 各 ListItem.position は経路順に、1 から始まる連続した昇順でなければなりません。同じ位置を持つ二つの ListItem や 2 から始まる経路は構造エラーとなり、検証に失敗します（壊れた例は Examples タブを参照）。

誤り：ステップから name を外す。 name はリンクがあるステップだけでなく、すべての ListItem で必須です。item URL だけの記述は、見落としやすいものの不完全なマークアップです。

誤り：ユーザーが実際にたどる経路ではなく URL フォルダー構造を写す。 Google は、経路が URL のディレクトリ構造ではなく、ページへの 典型的なユーザー経路 を表すよう推奨しています。これは、フラットな URL、タグページ、一つのページが複数のカテゴリ経路から到達できるファセットナビゲーションで特に問題になります。アドレスバーのフォルダーをそのまま繰り返すのではなく、マークアップには主要なユーザー経路を選びます。

神話：“Adding the schema puts a visible breadcrumb trail on my page for human visitors.” (翻訳) 「スキーマを追加すれば人間の訪問者向けの表示パンくず経路がページに現れる」。 そうはなりません。BreadcrumbList は機械可読な構造化データだけで、ページ上の表示されるクリック可能なパンくずは自分で構築する別の HTML です。表示ナビゲーションなしでスキーマだけを公開すると、分類シグナルとリッチリザルト対象資格は得られますが、ユーザー向けのページ上のパンくず UI は得られません。

誤り：実際のサイト構造と一致しない経路をマークアップする。 Google の一般的な構造化データガイドラインは、マークアップが実際のページ上のコンテンツを反映することを求めています。リッチリザルトを不正に得るため、実際の到達方法や分類と一致しないパンくず経路を捏造すると、単に表示されないだけでなく、原則としてガイドラインに基づく手動対策を招く可能性があります。

BreadcrumbList プロパティ一覧

必須構造

含めなくてもよいステップ

Google が受け付けるマークアップ形式

要点

• 有効な経路には 少なくとも二つの ListItem が必要です。1 ステップだけの「パンくず」は経路ではありません。
• 位置は単に一意であればよいのではなく、1 から始まるきれいな昇順でなければなりません。
• 経路は必ずしも URL のフォルダー構造ではなく、典型的なユーザー経路を表します。
• BreadcrumbList は ランキング要因ではありません。SERP の表示と分類だけに影響します。
• 有効なマークアップはリッチ表示の対象になる資格を与えますが、保証はしません。
• スキーマは人間の訪問者向けの表示パンくず経路を生成しません。その UI は別に作ります。
• 複数の経路から到達できるページには、クエリごとに適応する一つの経路ではなく、経路ごとに別々の BreadcrumbList オブジェクトを置けます。各オブジェクトは個別に有効でなければなりません。

BreadcrumbList を構築・確認するツール

JSON-LD を書いたら、まず私の Schema Markup Validatorを使います。ブロック（またはページ全体）を貼り付けると、schema.org の BreadcrumbList／ListItem 語彙と Google のリッチリザルト要件に対して重大度別の検査を行います。What Not to Do タブと Examples タブで扱う、position の欠落、位置の重複、name のない ListItem などの構造ミスを正確に検出し、コピーして貼り付けられる修正済み JSON-LD ブロックを返します。

私の Rich-Result Eligibility Checkerは、「JSON-LD として有効か」ではなく「この特定のページが Google のパンくずリッチリザルトの対象になるか」という別の問いに答えます。JSON-LD、HTML ページ、またはライブ URL を渡すと、Breadcrumb 型が対象になるかを示し、対象外なら不足している必須フィールドを正確に示します。

既存マークアップの修正ではなく空のページから始める場合は、私の Schema Markup Generatorが、手書きせずに BreadcrumbList を作るための専用フォームを提供します。各 ListItem の position、name、item を順に入力し、Google が必須とするプロパティと推奨するプロパティを入力中に示します。

これらの検査に合格したら、Google 自身の リッチリザルトテストでページを実行します。Google が対象資格の判定に実際に使うツールなので、公開前の最終確認になります。

BreadcrumbList でよくある問題と修正方法

リッチリザルトテストまたは Schema Markup Validator が BreadcrumbList のエラーを示す

最も多い原因は What Not to Do タブと Examples タブで扱った構造ミスです。position のない ListItem、重複している位置、1 から始まらない位置、必須の name がないステップなどです。各 ListItem を順番に確認してください。修正はほぼ常に一つの壊れたステップであり、ブロック全体ではありません。

マークアップは正しく検証できるのに、パンくずのリッチリザルトが SERP にまったく表示されない

有効なマークアップは表示の対象になる資格を与えるだけで、表示を保証しません。リッチリザルトの対象資格について John Mueller が示した三層モデルは、ここにも概ね当てはまります。第一にマークアップが技術的に有効であること、第二に Google の構造化データポリシーに準拠すること、第三に通常はサイト全体に及ぶ品質／信頼シグナル、つまり Google が構造化データから拡張結果を表示するほどサイトを信頼しているかどうかです。Mueller の大まかな診断として、自分のドメインに site: クエリを実行し、そこでリッチリザルトが表示されるか確認します。site: クエリでは表示され通常のクエリでは表示されないなら、技術的な問題よりサイト品質／信頼の問題を示します。Mueller はパンくずについては、パンくず経路がポリシー上の意味で間違えにくい文字どおりの型であるため、ポリシーリスクも低いと別途説明しています。

スキーマを追加したのに、ページ上に表示パンくず経路がない

それはバグではなく想定どおりです。BreadcrumbList は機械可読な構造化データだけで、表示されるクリック可能なパンくず UI は生成しません。その HTML は別に構築する必要があります。スキーマとページ上のナビゲーションは、同じ経路を記述する別々のものです。

Google が 2026 年もパンくずのリッチリザルトを表示するか判断できない

これは決着した問いではなく、意見が分かれている問いです。2025〜2026 年の一部の出典は Google がパンくず表示を削除した（まずデスクトップ、次にモバイル）と主張する一方、別の出典は BreadcrumbList を、経路が現在も表示される比較的安定したスキーマ型の一つと説明しています。Google 自身のパンくずドキュメントは 2026 年半ばの時点でもデスクトップに適用するとし、廃止注記を載せていません。意見の相違にかかわらず実装し、表示経路の価値は描画に依存しないことを踏まえ、自分のクエリ集合の SERP をブログ記事のスクリーンショットではなく確認します。

Search Console の Breadcrumbs レポートに、修正済みだと思ったページのエラーや警告が表示される

Search Console には専用の Breadcrumbs 拡張レポートがあり、ページが公開され再クロールされるとマークアップのエラーと警告を表示します。修正済みのページにまだ表示される場合、修正が Google が実際にクロールしたライブページへ届いていないか、同じ経路の別の ListItem に構造上の問題があります。レポートが古いと決めつけず、ライブ URL をもう一度リッチリザルトテストにかけます。

BreadcrumbList の変更が機能したことを証明する

テスト 1：JSON-LD の構造検証

実行するテスト： 更新した JSON-LD を Schema Markup Validatorに貼り付けるか、ライブページを Google の リッチリザルトテストにかけます。 期待する結果： BreadcrumbList ブロックにエラーがないこと。最後の item を除くすべてのステップに position が 1 から連続した昇順であり、各 ListItem に name と item URL があること。 失敗の解釈： 必須または重複プロパティの指摘は、公開したマークアップのプロパティ自体が正しくないことを意味します。キャッシュやレンダリングの問題だと考えず、JSON-LD のソースを直接確認します。 監視期間： 即時。どちらのツールも、クロール待ちなしで送信されたマークアップを読み取ります。 ロールバック条件： 直接修正しても検証に失敗する場合は、テンプレート変更をロールバックし、最後に正常だった JSON-LD と再比較します。

テスト 2：ライブ URL のパンくずリッチリザルト対象資格

実行するテスト： ライブ URL を私の Rich-Result Eligibility Checkerにかけます。 期待する結果： Breadcrumb 型がリッチリザルトの対象として表示されます。 失敗の解釈： テスト 1 が合格した後に必須フィールドの欠落が示されるなら、取得されたライブページが検証したものと一致していません。まだデプロイされていないか、マークアップがステージングコピーにしか存在しない可能性を確認します。

テスト 3：Search Console の Breadcrumbs 拡張レポートが修正を反映する

実行するテスト： Search Console → 拡張 → Breadcrumbs で、対象 URL を確認します。 期待する結果： ページがエラー／警告の区分から外れ、エラー数が 0 の有効なページとして表示されます。 失敗の解釈： Google の再クロール後も指摘されるなら、修正が Google が実際にクロールしたライブページへ届いていないか、同じ経路の別の ListItem に構造上の問題があります。ステージングではなくライブ URL に対してテスト 1 を再実行します。 監視期間： Google の再クロールとレポート更新には数日からおよそ 1 週間かかることがあります。Search Console のデータはライブページに遅れて反映されます。 ロールバック条件： エラー数が減らず、別のテンプレート共有ページで増える場合は、変更が他ページのマークアップを壊した兆候です。展開を止めます。

テスト 4：ライブ SERP に実際にパンくず経路が表示される

実行するテスト： パーソナライズの偏りを避けるため、プライベート／シークレットウィンドウで、ページがランクインするクエリを手動検索し、生 URL の代わりにパンくず経路が表示されるか確認します。 期待する結果： 経路がスニペットに表示されます。 失敗の解釈： Search Console のステータスが有効でも、経路が表示されないことは必ずしも修正失敗ではありません。2026 年の表示は意見が分かれており、対象資格があっても保証されません。Search Console がエラー／警告を示す場合はテスト 1 または 3 に戻ります。 監視期間： Google は表示までの固定期間を示していません。対象資格が通った直後に表示されると期待せず、数週間にわたり定期的に確認します。 ロールバック条件： 表示という Google が管理する判断について、マークアップ側でロールバックする条件はありません。Search Console の手動対策レポートがページを指摘した場合だけ見直します。

BreadcrumbList マークアップの継続 KPI

指標：有効な item 数（Search Console Breadcrumbs レポート） 分かること：エラーのない BreadcrumbList マークアップを現在持つページ数。KPI のカバレッジ側です。 取得方法：Search Console → 拡張 → Breadcrumbs。 基準／現実的な範囲：普遍的な目標はありません。実際のパンくず経路があり、マークアップを付けるべきページ総数を自社の基準にし、有効な item 数がそこへ向かって推移するか追跡します。 頻度：月次、またはパンくずマークアップに触れるテンプレート／CMS を変更した直後。

指標：エラー／警告 item 数（同じレポート） 分かること：構造上の問題があるページ数。カバレッジとは別の品質側の KPI です。 取得方法：同じ Breadcrumbs レポートのエラー／警告区分。 基準／現実的な範囲：正直な目標は 0 だけです。0 以外は統計的なノイズではなく、実際に壊れたページです。 頻度：月次、そしてマークアップテンプレートに触れるデプロイの後は必ず確認します。

指標：テンプレート横断のリッチリザルトテスト合格率 分かること：たまたま確認したページだけでなく、BreadcrumbList を持つべきすべてのページテンプレートが正しく実装されているか。 取得方法：テンプレートごとに 1 URL を抽出し、リッチリザルトテストまたは私の Schema Markup Validator で確認します。 基準／現実的な範囲：これはテンプレート単位の二値の有効性チェックであり、見栄えの指標ではないので、守れる目標は 100 % です。一つのテンプレートが失敗すれば、そのテンプレートから作られるすべてのページが壊れます。 頻度：テンプレート変更後、その他の場合は四半期ごとのスポットチェック。

指標：ランキングクエリのサンプルにおけるパンくず表示の有無 分かること：マークアップが有効なページでリッチ表示が実際に SERP へ描画されているか。2026 年のパンくず表示が不安定な状況で、正直に追跡する方法です。 取得方法：プライベート／シークレットウィンドウで、自分のランキングクエリから一貫したサンプルを定期的に確認します。Common Issues タブで扱った Mueller の site: と通常クエリの診断も使います。 基準／現実的な範囲：表示は意見が分かれ、Google が裁量で決めるため、引用できる固定値はありません。外部目標ではなく、自分の表示率を時系列の傾向として追跡します。 頻度：表示の状況がまだ不安定なので、四半期ごと。

自分で確認する：BreadcrumbList スキーマ

BreadcrumbList マークアップの仕組みについての簡単な 5 問です。それぞれ回答を選んでから確認してください。

変更履歴