BreadcrumbList schemaの書き方｜必須3項目と例外【図解】

パンくずリストの構造化データは、書くプロパティが少ないので簡単そうに見えます。ところが実際にやってみると、「どこから書き始めるのか」「どこまで書くのか」で手が止まります。

そういうところで迷ったまま、この記事にたどり着いた方が多いのではないかと思います。しかもこの構造化データは、書いた瞬間よりも書いたあとのほうが崩れます。カテゴリの名前が変わるたび、階層が増えるたびに、画面とコードが少しずつ食い違っていくためです。

この記事は、BreadcrumbListをこれから書く方に向けて書きました。必須の項目とコピペ用のテンプレート、省略できる例外、そして公開後に崩れる場所まで、図解と会話をはさみながら進めます。

この記事では、ある会社のマーケティング部の2人と、専門家の会話をはさみながら進めます。あなたに近い立場の人の質問から読んでいただいて構いません。

• 若葉さん（Web担当2年目）— 「そもそも、それって何ですか？」を聞く役
• 高梨課長（マーケ課長）— 「誰が、どれくらいの手間でやるんですか？」を聞く役
• 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役

01そもそもBreadcrumbList schemaの書き方は、AI対策として何のためにあるんですか？

若葉さん

若葉さんの発言

あの、パンくずって画面に出ていますよね。それとは別に、コードにも書かないといけないんでしょうか。

鈴木さん

鈴木さんの発言

いい質問です。画面のパンくずは人が見るもの、構造化データは機械が読むもの。同じ情報を、読む相手ごとに用意しておくと考えると分かりやすいですよ。

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

Google公式は、パンくずリストを「サイト階層におけるそのページの位置を示すもの」と説明しています。実装すると、検索結果でパンくず表示が使われる場合があるとも案内しています。

たとえて言うなら、駅の通路にずらりと並ぶ案内看板です。看板に書かれた文字がname、何枚目に立っているかがposition、その看板が指し示す先がitemにあたります。看板を読む人が「いま自分はどこにいるのか」を掴むのと同じことを、機械にもさせているわけです。

02BreadcrumbListの必須3項目は、AI検索対策として何を書けばいいんですか？

BreadcrumbListとListItemの必須プロパティを、表に整理します。

覚え方は、名前の暗記より問いのほうが速いです。1段ぶんのListItemは、何番目に立っているか。なんと書いてあるか。どこへ連れていくか。この3つに答えているだけです。

もうひとつ、先に押さえておきたい条件があります。ListItemは最低2つ必要だ、という点です。この条件があるため、トップページのすぐ下にある1階層だけのページでは、BreadcrumbListが成立しません。カテゴリを1つ挟む構成にするか、実装を見送るかの判断が先に来ます。

03BreadcrumbList schemaの書き方のテンプレートは、AIOでそのまま使えますか？

若葉さん

若葉さんの発言

表は分かりました。実際のコードは、そのままコピペして使ってもいいものなんでしょうか。

鈴木さん

鈴木さんの発言

大丈夫です。 ここでは3階層の例を用意しました。囲みの中の日本語とURLを、自社のものに置き換えれば動きます。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "カテゴリ名をここに入力",
      "item": "https://example.com/category/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "サブカテゴリ名をここに入力",
      "item": "https://example.com/category/sub/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "対象ページのタイトルをここに入力"
    }
  ]
}

読みどころは、入れ物の関係です。いちばん外側にあるのが経路そのもの、その中に段の並びがあり、さらにその中に1段ぶんの情報が入ります。JSON-LDの@contextや@typeといった基本の書き方に不安がある方は、別記事『JSON-LDの書き方入門｜3つのコピペ例で今日から書ける【図解つき】』を先に読むと迷いません。

手作業でコードを起こすのが負担な場合は、別記事『パンくずリストschemaをAIに実装させる実践プロンプト』が生成のしかたを紹介しています。

04BreadcrumbList schemaで最後の階層だけitemを省けるのは、AI検索最適化でどういう理屈なんですか？

上のテンプレートで、3番目のListItemだけitemがありません。これは書き忘れではなく、仕様に沿ったものです。最後の階層、つまり対象ページ自身については、itemを省略できます。Google公式は、省略した場合はページ自体のURLが使われると説明しています。

理屈はシンプルです。最後の段が指す先は、いま読んでいるページそのものです。だからURLを書かなくても、機械の側で補えます。逆に途中の段は、どこを指すのか外からは決められません。ここでitemを省くと、必須プロパティの欠落になります。

省略できるのは最後の段だけ、と覚えてしまうのがいちばん確実です。「省ける」という記憶だけが残っていると、途中の段でも省いてしまい、あとで原因の分からないエラーに悩むことになります。

05トップページやドメイン名は、LLMOのパンくず（BreadcrumbList schema）に入れなくていいんですか？

書き始めをどこにするかも、よく迷うところです。結論から言うと、サイトのドメイン名（トップレベルのパス）やページ自体をListItemに含めることは、Google公式から求められていません。トップページの1つ下の階層から書き始める構成も選べます。

とはいえ、機械的に省けばいいという話でもありません。判断の軸は画面に何が出ているかです。画面のパンくずに「ホーム」を表示しているなら、表示との一致を優先して入れる、という判断のほうが自然になります。

06画面のパンくずとschemaの文言は、AI検索最適化でどこまでそろえるんですか？

高梨課長

高梨課長の発言

実装した直後は合っていたはずなんです。それが、いつの間にかずれていることがあって。

鈴木さん

鈴木さんの発言

そこがこの構造化データの本番です。崩れるのは書いた瞬間ではなく、運用の中なんですよ。カテゴリの改名が、いちばんよくある引き金です。

nameプロパティには、実際に画面に表示されているパンくずの文言と同じ値を入れます。position番号は、画面上の並び順と一致させます。そしてカテゴリ名を変更したときは、画面表示とコードの両方を同時に更新する運用が要ります。

崩れ方には特徴があります。画面のほうは、見た目ですぐ気づくので直ります。取り残されるのは、目に見えないコードの側です。片方だけを直せる状態にしておかないというのが、いちばん効く予防になります。

071つのページに経路が2本あるとき、BreadcrumbList schemaはAI対策ではどう書き分けるんですか？

1つのページに、たどり着く道が複数ある場合もあります。商品ページが、カテゴリからも別の一覧からも開けるケースです。

Google公式は、サイト内のページに複数の到達方法がある場合、1ページに対して複数のパンくずパスを指定できると案内しています。この場合は、複数のBreadcrumbListオブジェクトを配列として並べて記述します。

[
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "name": "カテゴリA",
        "item": "https://example.com/category-a/"
      },
      {
        "@type": "ListItem",
        "position": 2,
        "name": "対象ページのタイトル"
      }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "name": "カテゴリB",
        "item": "https://example.com/category-b/"
      },
      {
        "@type": "ListItem",
        "position": 2,
        "name": "対象ページのタイトル"
      }
    ]
  }
]

ここでの注意は番号の振り方です。positionは経路ごとに1から振り直します。経路をまたいで通し番号にすると、それぞれの経路が何段目から始まるのか分からなくなります。階層設計そのものを見直したい場合は、別記事『トピッククラスターの作り方｜内部リンク設計6ステップで解説【図解つき】』が参考になります。

08公開後にBreadcrumbListが崩れるのは、AI検索のどこを見れば分かりますか？

高梨課長

高梨課長の発言

崩れる場所が決まっているなら、そこだけ見る運用にしたいです。どこを見ればいいでしょうか。

鈴木さん

鈴木さんの発言

起きた変更の種類で、取り残される場所が変わります。画面は直る、コードは残る。この非対称を頭に入れておくと、見る場所が絞れますよ。

カテゴリ名をリニューアルしたとき、画面側だけを更新してコード側を古いままにしてしまうケースがあります。階層の追加・削除でも同じです。手作業で番号を振り直していると、抜けや重複が起きます。

見るべき症状も、ずれの種類ごとに決まっています。ListItemが検出されない、あるいはitemの欠落がエラーとして出るなら、構文と必須プロパティの問題です。画面と検索結果で階層の順序が食い違うなら、position番号を疑います。カテゴリ改名のあとにコード側だけ旧名称が残っているなら、nameの更新漏れです。

09BreadcrumbList schemaの書き方を確かめる順番は、AI検索対策でどう決めるんですか？

不具合の見つけ方にも順番があります。構文が通っているかを機械に見てもらい、そのあと画面との突き合わせを人の目でやる。この順にすると手戻りが減ります。

1. 構文と必須プロパティを見る — リッチリザルトテストの検出結果を見ます
2. 階層と並び順を見る — 画面のパンくずとコードのpositionを突き合わせます
3. 文言を見る — 画面のパンくずの文字と、nameが同じかを見ます

検証ツールの詳しい使い方は、別記事『構造化データのテストツール入門｜今使うべき2つの使い分け方【図解つき】』で解説しています。あわせて押さえておきたいのは、この先の線引きです。Google公式の案内は、検索結果でパンくず表示が使われる場合がある、という書き方になっています。テストが通ることと、表示に出ることは同じではありません。

10パンくず（BreadcrumbList schema）をテンプレートで一括出力するのは、AIOの運用として安全なんですか？

高梨課長

高梨課長の発言

うちはページごとに手書きしています。数が増えてきたので、そろそろ限界かもしれません。

鈴木さん

鈴木さんの発言

そこは自動生成に寄せたほうが楽になります。ただし切り替えたあとに、抜き取りの確認だけは入れてください。テンプレート側の作り込みミスは、全ページに同じ形で出ますから。

BreadcrumbListの実装で本当に負荷がかかるのは、コードを書く瞬間ではありません。その後の運用です。カテゴリの改名や階層の追加が起きるたびに、画面とコードの両方を直せる体制になっているかが分かれ目になります。

まず着手すべきは、テンプレート出力の見直しです。ページごとに手書きしている状態なら、カテゴリ情報から自動生成する形に寄せておくと、position番号のずれと文言の食い違いをまとめて防げます。

切り替えたあとの確認は、全ページを見る必要はありません。階層の深さが異なるページを2〜3件抜き取って突き合わせると、テンプレート側の作り込みミスに気づけます。サイト全体をAIが辿れる構造にする観点は、別記事『サイト構造とクローラビリティ｜AIに読まれる7つの手順【図解でわかる】』で扱っています。

11よくある質問

12まとめ｜今日やる3つのこと

BreadcrumbListに書くのは、position・name・itemの3つです。ListItemは最低2つ、そして最後の段だけitemを省けます。テンプレート自体は短く、コピペで動きます。

負荷がかかるのは、そのあとです。画面とコードのどちらか片方だけを直せる状態になっていると、カテゴリ改名や階層の追加のたびに少しずつ食い違っていきます。今日やることは、そこを塞ぐ3つです。