BreadcrumbのSEO

TL;DR — Breadcrumbはページ上部近くにある小さなナビゲーションの道筋です。Home > Category > Pageのように、サイト内の現在地を示します。SEOでは2つの役割があります。道筋の各リンクはGoogleがサイトを理解し価値を通すのに役立つ本物の内部リンクであり、背後の構造化データによって、Googleがデスクトップ検索結果で長いURLの代わりに読みやすい道筋を表示できます。

Breadcrumbとは

Breadcrumbは補助ナビゲーション要素です。通常はページ上部近くに道筋として表示され、サイト階層の現在地を示します。

Home > Books > Science Fiction > Award Winners

名前の由来は、HanselとGretelが帰り道を見つけるためにパンくずを落としたことです。現在のページより前にある各ステップはクリック可能なリンクなので、メニューを探し回らずに1つ上の階層へ移動できます。

SEOに役立つ理由

ここでは別々の2つのことが起きているため、分けて考える価値があります。

• 目に見えるリンク。 各Breadcrumbは通常の<a href>リンクです。つまり内部リンクの一種で、ページ同士をつなぎ、Googleがページを見つけて理解するのに役立ちます。GoogleのGary Illyesは、これらを他のリンクと同じように扱うと確認しています。
• 背後のコード。 構造化データ（小さなBreadcrumbListコード）を追加すると、Googleは生のURLの代わりに、デスクトップ検索結果でBreadcrumbの道筋を表示できます。より親切で、クリックを増やせる可能性があります。

Breadcrumbが表示される場所

2か所あります。

1. ページ上。 道筋自体が訪問者のナビゲーションを助けます。
2. Googleの検索結果。 デスクトップでは、URLの代わりにタイトルの上へ読みやすい道筋が表示されることがあります。（モバイルでは2025年1月に表示されなくなり、ドメインだけになりました。詳しくはAdvancedタブを参照してください。）

多くの人が間違えること

構造化データは本物のリンクを置き換えません。 BreadcrumbListコードを追加するだけで十分だと考える人がいますが、違います。GoogleのJohn Muellerは、構造化データ内のURLは通常の内部リンクと同じようには使われないと述べています。したがって、両方、つまりクリックできる実際のBreadcrumbリンクと、それを説明する構造化データが必要です。

JSON-LDテンプレート、2025年1月のモバイル変更、異なるBreadcrumbの種類、テスト方法まで実装の詳細を知りたいなら、Advancedタブへ切り替えてください。

TL;DR — Breadcrumbは2層で機能します。HTML層（目に見える<a href>リンク）は内部リンクであり、Gary IllyesはGoogleがBreadcrumbリンクをPageRank計算の「通常のリンク」として扱うと述べました。構造化データ層（BreadcrumbList JSON-LD）は、Googleのデスクトップスニペットに読みやすい道筋を表示し、エンジンが階層を読み取るのを助けます。ただしMuellerは、構造化データ内のURLは実際の内部リンクと同じようには使われないと明確にしています。スキーマはHTMLの代わりではありません。2025年1月にGoogleはモバイルSERPからBreadcrumbを削除しました（現在はルートドメインのみ）。デスクトップ表示、スキーマ処理、クロール、PageRankはすべて変わっていません。位置ベースのBreadcrumbを使い、サーバー側でレンダリングし、表示テキストをスキーマのnameに一致させ、Rich Results TestとSearch ConsoleのBreadcrumbsレポートでテストします。

Breadcrumbとは実際には何か

Breadcrumbは、サイト階層におけるページの位置を反映する補助ナビゲーションの道筋です。Home > Category > Subcategory > Current Pageのように表します。メインナビゲーションを置き換えず補完するため「補助」と呼ばれます。SEO上の価値は2つの異なる層から来ます。この記事では混同が多くのミスの出発点になるため、分けて扱います。

2層のアーキテクチャ

第1層 — HTML。 目に見えるBreadcrumbは、実際の<a href>アンカーリンクを含む<nav>です。これが内部リンクであり、価値を通す部分です。Gary Illyesは2017年に直接質問され、GoogleはBreadcrumbを好み、「PageRank computationなどで通常のリンクとして」扱うと答えました。したがってBreadcrumbはサイト全体に広がる体系的な内部リンクパターンです。各商品ページはカテゴリへ、各カテゴリはハブへリンクする、といった具合です。重要なハブページへPageRankを分配し、クローラーに深いページへの一貫した経路を与えます。

第2層 — 構造化データ。 BreadcrumbList JSON-LDは道筋に注釈を付け、Googleが（a）デスクトップ検索スニペットに読みやすい道筋を表示し、（b）複数のナビゲーション経路が同じページへ通じる場合を含め、階層をよりよく理解できるようにします。結果の見た目に影響するのはこちらです。

落とし穴は、第2層によって第1層が不要になると考えることです。そうではありません。John Mueller は 2022 年に、“just because there is structured data in a page somewhere, I wouldn’t see that as a replacement for normal internal linking,” (翻訳) 「ページのどこかに構造化データがあるからといって、通常の内部リンクの代わりとは考えない」と明確に述べ、さらに “even if in the structured data, you also provide URLs, we don’t use those URLs in the same way as we would use normal internal links.” (翻訳) 「構造化データで URL も提供していても、通常の内部リンクと同じようには使わない」と説明しました。スキーマで本物の HTML リンクを省略する近道はありません。両方を実装します。

Breadcrumbの種類

• 位置ベース（階層）。 ページがサイト構造のどこにあるかを示し、訪問者ごとに同じです。標準的で、SEOに本当に役立つ唯一の種類です。
• 属性ベース。 ページの特徴を示し、ECサイトやファセットナビゲーションで一般的です（Home > Shoes > Running > Size 10）。属性フィルタリングで商品へ到達できる場合に役立ちます。
• 履歴ベース（経路）。 個々のユーザーのクリックストリーム（「ここから来ました」）を反映します。ユーザーごとに異なり一貫しないため、信頼できる階層シグナルになりません。SEOでは避けます。

どれを使うべきか？ Google自身の指針が軸になります。URL構造の文字どおりの複製ではなく、典型的なユーザーナビゲーション経路を反映するBreadcrumbを提供します。実際には位置ベースが多くのサイトを満たします。訪問経路に関係なく、すべての訪問者が見る安定した経路だからです。属性ベースは、典型的な経路が本当に属性を通る、フィルタ済み／ファセットページで使う例外です。履歴ベースは指針を満たしません。典型的な経路ではなく、あるユーザーの経路だからです。

GoogleがSERPでBreadcrumbを使う方法

BreadcrumbListマークアップが存在し有効なら、Googleはデスクトップ結果の緑色のURLをBreadcrumbの道筋に置き換えられます。Googleはマークアップを「検索結果の情報を分類する」ために使い、表示はデスクトップでSearchが提供されるすべての地域と言語に対応します。標準的な注意点として、少なくとも2つのListItemエントリーが必要で、有効なマークアップでもリッチリザルト表示を保証しません。

2025年1月のモバイル変更 — 実際に変わったこと

2025 年 1 月 23 日、Google は “no longer show breadcrumbs on mobile search results in all languages and regions where Google Search is available (they continue to appear on desktop search results).” (翻訳) 「Google 検索を利用できるすべての言語と地域のモバイル検索結果でパンくずを表示しない（デスクトップ検索結果では引き続き表示する）」と発表しました。理由として、パンくず要素は “isn’t as useful to people who are searching on mobile devices, as it gets cut off on smaller screens.” (翻訳) 「小さな画面では途中で切れてしまうため、モバイル端末で検索する人にはそれほど役立たない」と説明しました。モバイル結果には経路ではなくルートドメイン（例：example.com）が表示されます。

ここが重要です。「Breadcrumbはまだ重要か」というパニックが広がった理由でもあります。

• 変わったこと： モバイルの視覚的スニペット。道筋ではなくルートドメインが表示されます。
• 変わっていないこと： デスクトップSERPのBreadcrumbは引き続き表示され、構造化データは処理され、Search ConsoleのBreadcrumbsレポートも機能し、Rich Results Testでマークアップをテストできます。クロール、内部リンク、PageRankの価値も完全に変わっていません。Googleは対応不要と明言しています。引き続きBreadcrumbListを使ってください。

私の見方では、SERP表示はもともとBreadcrumbを使う3つの理由の中で最も小さいものでした。内部リンクの価値（PageRank、クロール経路）とUXの価値は少しも動いていません。モバイルスニペットの見た目の変更だけを理由にBreadcrumbを削除するのは誤りです。

BreadcrumbList構造化データの実装

JSON-LDを使います。Googleが推奨する形式で、マークアップとは別に保守しやすいからです。（MicrodataとRDFaも引き続きサポートされます。古いdata-vocabulary.org語彙は非推奨なので、schema.orgを使います。）

必須の形：

• BreadcrumbList.itemListElement — ListItemオブジェクトの配列。
• ListItem.position — 1から始まり、昇順の整数。
• ListItem.name — 表示テキスト。
• ListItem.item — 絶対URL。Googleが現在ページのURLを使うため、最後のBreadcrumbでは省略可能です。

完全なテンプレートはCheat Sheetsタブにあります。

よくある実装エラー（しかも頻繁に起きます）：

• 最後ではないBreadcrumbでitemが欠落している。
• 絶対URLが必要な場所で相対URLを使っている。
• positionの整数が連番になっていない。
• 目に見えるBreadcrumbテキストがスキーマのnameと一致しない。
• Googlebotが実行しない可能性のあるクライアント側・JSのみのレンダリング。初期HTMLにBreadcrumbが含まれるようサーバー側でレンダリングする。
• トラッキングパラメーター付きの非canonical URLへリンクしている。
• 非推奨のdata-vocabulary.orgマークアップを使っている。

テストと監視

• Rich Results Test（search.google.com/test/rich-results）— デプロイ前後にマークアップを検証し、エラーを見つけます。
• URL Inspectionツール（Search Console）— Googleが実際にライブページを取得し解釈した方法を確認します。
• Search Console › Enhancements › Breadcrumbs — 2025年1月の変更後も機能するレポートで、リリース後にサイト全体の有効／無効アイテムを監視します。公開後、クロールとインデックス登録が追いつくまで数日待ちます。

「有効」の範囲を正直に保ちます。Googleの一般的な構造化データガイドラインによれば、検証に合格することで、サポートされる表示の対象になる資格を得ます。しかしBreadcrumbが表示されること、ランキングが上がること、トラフィックが増えること、AI生成回答がページを引用することは保証しません。Rich Results Testがきれいに通ることを「既知のエラーなし」と扱い、結果の約束とは考えないでください。

BreadcrumbとBing

BingはBreadcrumbListを含む共有のschema.org語彙をサポートし、同じマークアップからBreadcrumbリッチリザルトを表示できます。実務上の要点は、1つのJSON-LDブロックを実装すればGoogleとBingの両方に使えることです。Bing専用のBreadcrumb形式を保守する必要はありません。

ベストプラクティス

• 構造化データだけでなく、本物のHTMLリンクを使う。 スキーマは内部リンクを置き換えません。
• 現在のページにはリンクしない。 最後のBreadcrumbは現在いるページです。
• 表示テキストをスキーマのnameに一致させる。 2つの層が一致するようにします。
• サーバー側でレンダリングする。 Googlebotが最初に受け取るHTMLにBreadcrumbを入れます。
• タクソノミーと一貫させる。 典型的なナビゲーション経路を反映するBreadcrumbは、きれいな階層を強めます。
• 深いページだけでなくハブやカテゴリページにも置く。 階層を強め、サイト全体で深いコンテンツを見つけやすくします。

不要な場合

本当にフラットなサイト、つまり階層のない少数ページ、1階層だけのパンフレットサイト、独立したランディングページでは、Breadcrumbの利益はほとんどありません。2階層以上の階層があるサイト（ほとんどのコンテンツサイト、ニュースサイト、ドキュメント、ECカタログ）なら、Breadcrumbは価値を発揮します。

Breadcrumbはサイトをつなぐ方法の一部です。より広い内部リンク、URLとフォルダー構造、サイト全体のナビゲーションと並び、人とクローラーが階層を移動する方法を形作ります。

AI要約

Advanced版を圧縮すると、次のようになります。

• Breadcrumbは階層ナビゲーションの道筋。 Home > Category > Pageのように、2層で機能します。目に見えるHTMLの<a href>リンクと、BreadcrumbList JSON-LDです。
• HTML層＝内部リンク。 Gary Illyes（2017年）：GoogleはBreadcrumbリンクをPageRank計算の通常のリンクとして扱う。
• 構造化データ層＝SERP表示＋階層シグナル。 ただしJohn Mueller（2022年）：構造化データのURLは通常の内部リンクと同じようには使われない。スキーマはHTMLリンクの代わりではない。両方を使う。
• 2025年1月： GoogleはモバイルSERPからBreadcrumbを削除（ルートドメインのみ）。デスクトップ表示、スキーマ処理、Search ConsoleのBreadcrumbsレポート、クロール、PageRankは変わっていない。対応不要。
• 実装： JSON-LD。position（1からの整数）、name、item（絶対URL、最後のアイテムでは省略可）を持つListItemのitemListElement。data-vocabulary.orgは非推奨なのでschema.orgを使う。サーバー側でレンダリングする。
• 種類： 位置ベース（SEO標準）、属性ベース（EC／ファセット）、履歴ベース（ユーザー別でSEO向きではない）。
• テスト： Rich Results Test。監視： Search Console › Enhancements › Breadcrumbs。Bingも同じschema.orgマークアップを読みます。

公式ドキュメント

検索エンジンとschema.orgによる一次資料です。

Google

• Breadcrumb（BreadcrumbList）構造化データ — 必須プロパティ、JSON-LD例、複数経路の指針、テスト手順。
• モバイル検索のBreadcrumbを簡素化（2025年1月23日） — モバイルSERPに道筋を表示しなくなった発表。
• Rich Results Test — BreadcrumbListマークアップを検証。
• リッチリザルトレポートの概要（Search Consoleヘルプ） — 公開後の有効／無効Breadcrumbアイテムを監視（BreadcrumbはSearch Consoleが追跡するEnhancementsレポートの1つ）。

Schema.org

• BreadcrumbList — 通常は現在のページで終わる、リンクされたページの連鎖を表す語彙。
• ListItem — position、name、item。

Bing／Microsoft

• 構造化データでサイトをマークアップ — BreadcrumbListを含む、Bingのschema.orgマークアップ対応。

ソースからの引用

Googleによる公式発言です。各ディープリンクはソースページの引用箇所へ移動します。

Gary Illyes、Google — BreadcrumbリンクはPageRankを通す（2017年）

• “We like them. We treat them as normal links in, e.g., PageRank computation.” (翻訳) 「私たちは Breadcrumb を好みます。たとえば PageRank の計算では、通常のリンクとして扱います。」 — Gary Illyes、Breadcrumb ナビゲーションリンクについて。 報道を読む

John Mueller、Google — 構造化データは内部リンクの代わりではない（2022年3月16日）

• “So just because there is structured data in a page somewhere, I wouldn’t see that as a replacement for normal internal linking.” (翻訳) 「ページのどこかに構造化データがあるからといって、通常の内部リンクの代わりとは考えません。」 文脈へ
• “Even if in the structured data, you also provide URLs, we don’t use those URLs in the same way as we would use normal internal links.” (翻訳) 「構造化データで URL も提供していても、通常の内部リンクと同じようには使いません。」 文脈へ

Google Search Central Blog — 2025年1月のモバイル変更

• “Starting today, we’re rolling out a change to no longer show breadcrumbs on mobile search results in all languages and regions where Google Search is available (they continue to appear on desktop search results).” (翻訳) 「本日から、Google 検索を利用できるすべての言語と地域のモバイル検索結果でパンくずを表示しない変更を展開します（デスクトップ検索結果では引き続き表示されます）。」 引用箇所へ
• “We found that the breadcrumb element isn’t as useful to people who are searching on mobile devices, as it gets cut off on smaller screens.” (翻訳) 「パンくず要素は小さな画面では途中で切れてしまうため、モバイル端末で検索する人にはそれほど役立たないことが分かりました。」 引用箇所へ

Google Search Central文書 — マークアップの目的

• “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.” (翻訳) 「ページ上のパンくず経路は、サイト階層におけるページの位置を示し、ユーザーがサイトを効果的に理解して探索する助けになります。」 引用箇所へ

Breadcrumb実装チェックリスト

両方の層が正しいことを確認する手順です。

• 目に見えるBreadcrumbが、テキストやJSだけではなく、<a href>リンクを持つ本物の<nav>である。
• WAI-ARIAのBreadcrumbパターンに従い、ラベル付きナビゲーションランドマーク（例：aria-label="Breadcrumb"を持つ<nav>で順序付きリストを囲む）として道筋が公開されている。
• 道筋で現在のページにaria-current="page"が付いている。
• BreadcrumbList JSON-LDが存在し、サーバー側（初期HTML）でレンダリングされている。
• ListItemエントリーが少なくとも2つある。
• position整数が1から始まり、欠落なく昇順である。
• 最後ではないすべてのListItemに絶対item URLがある（最後は省略可）。
• item URLがcanonicalである（トラッキングパラメーターや非canonicalな派生がない）。
• 目に見えるBreadcrumbテキストがスキーマのnameと一致している。
• 非推奨のdata-vocabulary.orgではなく、schema.org語彙を使っている。
• 現在のページが自分自身のBreadcrumbでリンクされていない。
• Breadcrumbがタクソノミーと整合した典型的なナビゲーション経路を反映している。
• Rich Results Testで検証し、ライブURLをURL Inspectionで確認している。
• 公開後、Search Console › Enhancements › Breadcrumbsで無効アイテムを確認している。

メンタルモデル

1. 2層、2つの役割。 HTMLリンクはリンクの役割（PageRank、クロール経路）を担います。構造化データは表示＋階層シグナルの役割を担います。問題を診断するときは、どちらの層が壊れているかを考えます。価値の欠落ならHTMLリンク、SERPの道筋の欠落や誤りならJSON-LDを確認します。

2. スキーマは注釈であり、置き換えではない。 BreadcrumbListはすでに存在するリンクを説明します。それ自体が内部リンクの集合ではありません。Muellerのルールでは、構造化データのURLは通常の内部リンクのようには使われません。実際のBreadcrumbリンクを削除して「スキーマだけを残す」ことはしないでください。

3. 表示と価値は別。 SERPのBreadcrumbは目に見える成果ですが、持続的な価値は内部リンクとUXです。だから2025年1月のモバイル削除は結果の見た目を変えましたが、Breadcrumbが行うことは変えませんでした。

4. 履歴ではなく位置。 SEOでは、Breadcrumbはユーザーがどこから来たか（ユーザーごと）ではなく、ページがどこに位置するか（全員に一貫）を示すべきです。階層はシグナルですが、クリックストリームは違います。

5. 層を一致させる。 表示テキスト、スキーマのname、canonical URLはすべて一致すべきです。一見有効なBreadcrumbが表示されなかったり無効と報告されたりする最大の理由は不一致です。

BreadcrumbList JSON-LD — テンプレート

これをページの<head>または<body>に、サーバー側でレンダリングして入れます。nameテキストを目に見えるBreadcrumbに合わせ、絶対canonical URLを使います。Googleが現在ページのURLを使うため、最後のアイテムではitemを省略します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Books",
      "item": "https://example.com/books"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Science Fiction",
      "item": "https://example.com/books/sciencefiction"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Award Winners"
    }
  ]
}
</script>

プロパティ早見表

早わかり

• 形式：JSON-LD（推奨）。data-vocabulary.orgは非推奨 → schema.orgを使う。
• SERP表示：2025年1月以降はデスクトップのみ。モバイルはルートドメインを表示する。
• モバイルでもスキーマは処理される。変更後も対応不要。
• テスト：Rich Results Test。監視：Search Console › Enhancements › Breadcrumbs。
• 同じマークアップがBingにも使える（共有schema.org語彙）。

目に見えるBreadcrumbリンクなしのスキーマ

BreadcrumbListは道筋を説明しますが、ナビゲーションを置き換えません。ユーザーとクローラーには、同じ階層をたどる通常のHTMLリンクを提供します。非表示のスキーマだけの構造を公開するのではなく、目に見えるコンポーネントにマークアップを追加します。

ユーザーのクリック履歴に基づく道筋

履歴ベースのBreadcrumbは、ユーザーがどのように到達したかによって変わります。アーキテクチャ上の安定した1つの位置を示さないため、内部リンクと構造化データの基礎には向きません。SEOには位置ベースの階層を使います。

実在しない行を発明する

Home > Shoes > Running > PageのようなBreadcrumbは、/shoes/や/shoes/running/が有用で到達可能なカテゴリでなければ誤解を招きます。リンクされた各祖先は本当の移動先であるべきで、道筋を完全に見せるためだけに追加したラベルではいけません。

HTMLとJSON-LDを食い違わせる

目に見える道筋が1つの内容を示し、構造化データが異なる階層やURLを名前付けしていると、実装は2つの物語を語ります。同じ階層ソースから両方を生成し、一緒にテストします。

Breadcrumbの変更をURL移行の近道にする

BreadcrumbのURLを変更しても、古いアドレスをリダイレクトしたり、canonicalを更新したり、他の場所のリンクを修正したりはしません。ナビゲーション、スキーマ、リダイレクト、canonical化を別々のリリースチェックとして扱います。

例：HTMLとJSON-LDで1つの階層

以下の目に見えるリンクと構造化データは、同じ簡略化した経路を説明します。現在のページはナビゲーション内のテキストであり、最後のListItemがその名前を持ちます。

<nav aria-label="Breadcrumb">
  <ol>
    <li><a href="/">Home</a></li>
    <li><a href="/shoes/">Shoes</a></li>
    <li aria-current="page">Trail shoes</li>
  </ol>
</nav>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type":"ListItem","position":1,"name":"Home","item":"https://example.com/"},
    {"@type":"ListItem","position":2,"name":"Shoes","item":"https://example.com/shoes/"},
    {"@type":"ListItem","position":3,"name":"Trail shoes"}
  ]
}
</script>

これは説明用のマークアップであり、Googleが特定の結果にBreadcrumbを表示するという約束ではありません。

誤解を招く道筋の例

Home > Sale > Popular > Shoes > Trail shoes

「Sale」と「Popular」が安定した祖先ではなく一時的なフィルターなら、道筋は販売促進の状態と階層を混ぜてしまいます。耐久性のある位置ベースの道筋は通常、Home > Shoes > Trail shoesに近くなります。販促経路は別のリンクとして残せます。

プロンプト：テンプレート全体でBreadcrumbを整合させる

Review the visible breadcrumb HTML, BreadcrumbList JSON-LD, canonical URL, and expected
site hierarchy below. Return one row per position with the visible label/URL, schema
label/URL, expected label/URL, and a mismatch finding. Check that positions are ordered,
ancestor URLs are absolute in JSON-LD, the current page is represented consistently,
and every linked ancestor is a real destination. Do not invent missing hierarchy
levels. Provide corrected HTML and JSON-LD only from the supplied expected hierarchy.

Expected hierarchy:
[PASTE POSITION | LABEL | CANONICAL URL]

Visible HTML:
[PASTE BREADCRUMB HTML]

JSON-LD:
[PASTE BREADCRUMBLIST]

プロンプト：複数のページ種別にBreadcrumbルールを計画する

Create deterministic breadcrumb rules for these page templates. For each template,
state the parent source of truth, label source, URL source, behavior for the current
page, and treatment of filters or temporary campaign pages. Flag any page that has
multiple plausible parents for a human decision. Keep the trail location-based and do
not infer categories that are absent from the supplied taxonomy.

Templates and taxonomy:
[PASTE TEMPLATE | TAXONOMY FIELDS | EXAMPLE CANONICAL URL]

Breadcrumbを実装・テストするツール

• Schema Validator — 貼り付けたJSON-LDまたは完全なHTMLについて、語彙、必須プロパティ、グラフ参照、出荷前に修正できるマークアップ問題を確認します。
• Schema Generator — 構造化データの下書きが必要なとき、きれいな開始ブロックを生成します。ただし生成された道筋も、サイトの実際の目に見える階層と一致させる必要があります。
• Google Rich Results Test — URLまたはコードサンプルで、Googleがサポート対象のマークアップを解析できるか確認します。有効な結果は表示の約束ではなく、資格の証拠です。
• Search ConsoleのBreadcrumbs拡張レポート — 公開後、Googleが知っているページ全体の検出エラーを見つけます。自分のテンプレートをクロールする代わりにはなりません。
• 構造化データ抽出機能付きクローラー — 表示されるBreadcrumbリンク、JSON-LDの位置、canonical URL、ステータスコードをエクスポートし、テンプレートレベルの不一致を明らかにするスケーラブルな比較層です。

Breadcrumb実装を検証する

リッチリザルト表示だけでなくBreadcrumbの健全性を測る

検索でのBreadcrumb表示は、単独で信頼できるKPIではありません。Googleが表示を制御し、モバイル結果からBreadcrumbを削除したためです。実装、ナビゲーション、テンプレートのカバレッジを直接測定します。

自分で確認：Breadcrumb

Breadcrumbの役割と実装方法についての簡単な5つの質問です。それぞれ答えを選んでから、確認してください。

時間を使う価値のあるリソース

私の関連執筆

• SEOの内部リンク：完全ガイド — サイト全体の内部リンクパターンとしてのBreadcrumbの位置付け。
• サイトリンク：概要と獲得方法 — Googleが構造から作れる関連ナビゲーション表示。
• ウェブサイト移行：決定版ガイド — 移行時に変わる内部リンクの中のBreadcrumb。
• モバイルファーストインデックス：完全ガイド — 一部のモバイルテンプレートが省スペースのためBreadcrumbを削った理由。
• テクニカルSEO初心者ガイド — Breadcrumbが置かれる広い文脈。

私の講演

• How Search Works （SlideShare）— クロール、レンダリング、インデックス登録、ランキングの解説と、Breadcrumbのような構造シグナルの位置付け。（定型の免責事項：「This is my understanding of systems… not going to be 100% complete or accurate.」が適用されます。）

業界の資料

• Breadcrumb（BreadcrumbList）構造化データ （Google）— canonicalな実装リファレンス。
• モバイル検索のBreadcrumbを簡素化 （Google Search Central Blog）— 2025年1月のモバイル削除の発表。
• Googleがモバイル検索結果でBreadcrumbを表示しなくなった （Search Engine Land）— Barry Schwartzによる報道と影響評価。
• SEOのBreadcrumb：Googleのモバイル変更が意味すること （Sitebulb）— 変更に焦点を当てた解説。
• BreadcrumbはGoogleのランキング要因か？ （Search Engine Journal）— ランキング要因かという問いへの回答。
• Breadcrumbナビゲーションの有用性が増している （Nielsen Norman Group）— ユーザー調査での利点とデメリットがないことに関するUX研究。
• SEO Breadcrumbガイド （Search Engine Land）— 種類、ベストプラクティス、スキーマ。

変更履歴