構造化データのパンくず実装方法｜JSON-LDの書き方と設計手順を解説

パンくずリストの構造化データを設定したものの、「本当にこの書き方で合っているの？」「JSON-LDのコードにミスがないか？」と不安を感じながら実装を進めている方は少なくありません。マークアップの記述ルール自体は決して複雑ではありませんが、コードの正しさだけを追いかけると、かえって表示不備の原因を見落としてしまうことがあります。

LLMO対策を専門にするAIコマース研究所の支援の中では、パンくずが正しく機能しない原因が「コードのミス」ではなく、その手前の「サイトの情報設計」にあるケースが多く見られます。

本記事では、JSON-LDによる具体的な実装方法と検証手順に加え、実装ミスを未然に防ぐための設計の考え方までを解説します。読み終える頃には、自社サイトのパンくず実装を、コードと設計の両面から見直せるようになっているはずです。

パンくずリストの構造化データとは？表示・SEOへの役割を整理

パンくずリストの構造化データとは、ページ上に見た目として表示されているパンくず（トップ＞カテゴリ＞記事、といった階層表示）の情報を、検索エンジンが理解できる形式で改めて記述したデータのことです。schema.orgが定義する「BreadcrumbList」というスキーマタイプを使い、各階層のページ名・URL・表示順序を機械的に読み取れる形にします。

HTML上のパンくずは人間が目で見て現在地を把握するための表示ですが、構造化データはあくまで検索エンジン向けのメタ情報という役割を担っています。両者は対立するものではなく、ユーザー向けのHTML表示と検索エンジン向けの構造化データを併用することが、Googleの公式ドキュメントでも推奨されています。

構造化データが正しく設定されていると、Google検索結果の表示欄にパンくず形式の階層が表示される場合があり、URLの羅列よりも直感的にページの位置づけを伝えられるという利点があります。

構造化データを実装する前に確認すべき4つの設計ポイント

構造化データの実装でつまずく原因の多くは、実はJSON-LDの記述ミスそのものではなく、「そもそもこのページをどの階層に位置づけるか」というサイトの情報設計が固まっていないことにあります。コードを書き始める前に、次の4つの問いに答えられるかを確認してください。

1つ目は「このページは何についてのページか」です。ページ単体のテーマを一文で言い切れるかを確認します。2つ目は「一つ上の概念は何か」で、そのテーマを包含するカテゴリを考えます。3つ目は「同じ階層に何が並ぶか」で、兄弟記事や兄弟カテゴリの存在を確認します。そして4つ目が「サイトとして何の専門家に見せたいか」で、最上位のテーマとの関係を確認する問いです。

AIコマース研究所の支援現場でも、この4つの問いに答えられないままパンくずのコードだけを実装しているサイトに数多く遭遇してきました。具体例として、本記事のテーマである「パンくず構造化データ」というキーワード自体を題材に考えてみます。

ページテーマは「パンくず構造化データ」、一つ上の概念は「構造化データ」、同じ階層に並ぶ兄弟はFAQやArticle、Productといった他の構造化データの種類、そして上位テーマは「SEO・LLMO対策」という形に整理できます。

このように4段階で言語化すると、パンくずに含めるべき階層の名称や順序が自然に定まります。逆に、この4問のどれかに詰まる場合は、パンくず単体の修正ではなく、サイト全体のカテゴリ設計を見直す必要があるサインだと捉えてください。生成AIによる検索でも、サイト構造が一貫して整理されているほど文脈理解が進みやすくなる傾向が、研究チームによる分析から見えています。

パンくずリストの構造化データ、3つの記述形式（JSON-LD／Microdata／RDFa）

パンくずリストの構造化データには、Googleがサポートする3つの記述形式があります。特別な理由がない限りは、後述するJSON-LD形式を選ぶことをおすすめします。

JSON-LDでの書き方とコード例（推奨形式）

JSON-LDは、scriptタグを使ってページ情報をひとまとまりのデータとして記述する形式です。HTML内のどこにでも設置でき、既存のHTML構造（liタグなど）を変更する必要がないため、管理のしやすさに優れています。GoogleのAIがサイト構造を素早く理解する助けにもなるとされており、迷ったらこの形式を選ぶのが基本方針です。

記述例は次のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "構造化データ",
      "item": "https://example.com/category/structured-data/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "パンくず構造化データ"
    }
  ]
}
</script>

構造化データを指定する際は、最低でも2つ以上のListItemを含むBreadcrumbListを定義する必要があります。また、コード内の記号はすべて半角で記述し、最後の要素の閉じ括弧の後にカンマを入れないよう注意してください。この末尾カンマの入れ忘れ・入れすぎは、実装現場で非常に多く見られるミスのひとつです。

Microdata・RDFaでの書き方とコード例

Microdataは、HTMLのリスト構造（olタグ・liタグなど）に直接専用の属性を書き込む形式です。既存のパンくずHTMLに手を加える形で実装できる一方、liタグの数だけ属性を重複して記述する必要があるため、階層が深いサイトほど記述量が増えコードが読みにくくなる傾向があります。

<ol itemscope itemtype="https://schema.org/BreadcrumbList">
  <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
    <a itemprop="item" href="https://example.com/">
      <span itemprop="name">ホーム</span>
    </a>
    <meta itemprop="position" content="1" />
  </li>
  <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
    <a itemprop="item" href="https://example.com/category/structured-data/">
      <span itemprop="name">構造化データ</span>
    </a>
    <meta itemprop="position" content="2" />
  </li>
</ol>

RDFaはMicrodataと似た構造ですが、vocabやpropertyといった異なる属性名を用いる点が特徴です。HTML5に限らずさまざまな文書形式で利用されており、Microdataと同様にHTML本体に属性を埋め込む形で実装します。

どちらの形式も機能面ではJSON-LDと同等に評価されますが、保守のしやすさという観点からは、既存のHTML構造に手を加えずに済むJSON-LDが優位です。

実装後に必ず行うべき3つの検証方法

構造化データは、記述ミスが一つあるだけでも検索エンジンに正しく認識されません。実装後は必ず複数の方法でチェックする習慣をつけてください。

リッチリザルトテストでの確認手順

リッチリザルトテストは、Googleが提供している無料の検証ツールです。ページを公開する前や、コードを書き換えた直後の確認に適しています。対象の「URL」または「コード」を入力して実行すると、「〇件の有効なアイテムを検出しました」という緑色の表示が出るかを確認できます。

もし警告やエラー、あるいは「アイテムが検出されませんでした」という結果が出た場合は、カンマの不足や全角記号の混入といった記述ミスがないか、コードを見直す必要があります。

Search Consoleでの継続的なチェック方法

Search Consoleは、公開済みのページを検索エンジンがどのように認識しているかを継続的に確認できるツールです。管理画面のメニューから「パンくずリスト」に関するレポートを開くと、サイト全体のパンくずリストの状態が一覧で表示されます。

「有効」と表示されていれば問題ありませんが、「エラー」が出ている場合は、どのページで問題が発生しているかを特定し、個別に修正する必要があります。リッチリザルトテストが公開直後のスポット確認に向くのに対し、Search Consoleはサイト運用中の継続的なモニタリングに向いているという役割の違いを押さえておくと効率的です。

検索結果にパンくずリストが表示されない場合に考えられる原因

構造化データを設定したにもかかわらず検索結果に反映されない場合、原因は主に次の5つに絞られます。

1つ目はコードの記述ミスです。JSON-LDでは末尾カンマの有無や、全角記号の混入によるエラーが特に多く見られます。

2つ目は画面上に表示されているパンくずの文字列と、構造化データ内の記述内容が一致していないケースです。表示側と構造化データ側でテキストが食い違っていると、検索エンジンが情報を正しく紐づけられません。

3つ目は検索エンジン側の反映待ちです。設定してすぐに検索結果へ反映されるわけではなく、Search Consoleからインデックス登録をリクエストした上で、数日から数週間程度様子を見る必要があります。

4つ目はガイドライン違反です。ユーザーに見えない隠しテキストを構造化データに含めるといった使い方は避けてください。

5つ目は、検索結果上部にAIによる回答が表示されるケースです。従来のパンくず表示とは異なる形式で引用元が示される場合があり、構造化データ自体は正しく機能していても、見た目上の表示が変化することがあります。

パンくずリストの構造化データでよくある実装ミスと注意点

これまでに紹介した検証方法と原因の整理を踏まえると、実装時に注意すべきポイントは「コードの正確性」と「表示内容との整合性」の2軸に集約されます。JSON-LDを使う場合は、半角記号の徹底とカンマの位置、そしてBreadcrumbListに最低2つ以上のListItemを含めることを基本チェック項目として押さえてください。

加えて、階層の途中を省略してしまうミスにも注意が必要です。たとえば「ホーム＞パンくず構造化データ」のように中間の「構造化データ」カテゴリを飛ばして記述すると、見た目のパンくずと構造化データの内容が一致しなくなり、原因2に該当するエラーの温床になります。

AIコマース研究所の支援現場では、こうした階層の省略や重複が、単一ページの記述ミスよりもサイト単位で横断的に発生しているケースの方が多く見られる傾向があります。これは、先述した「4つの設計ポイント」がテンプレート単位で固まっていないまま、ページごとに個別実装を重ねてしまうことが背景にあることが多いためです。

LLMO対策会社を選ぶ際に構造化データ周りで確認すべきチェックポイント

構造化データの実装状況を自分たちだけでチェックしきる自信がない場合、外部の支援を検討する際には次の観点を確認しておくと、依頼先選びで失敗しにくくなります。

まず、コードの記述チェックだけでなく、サイト全体の情報設計（カテゴリ階層・兄弟ページの整理）まで踏み込んで診断してくれるかどうかです。パンくずの表示不備は、個別ページの修正だけでは再発しやすく、テンプレートやカテゴリ設計そのものを見直せる支援先かどうかが重要な判断基準になります。次に、JSON-LD・Microdata・RDFaといった記述形式ごとの特性を理解した上で、サイトの実装環境に合わせた形式を提案してくれるかどうかも確認しておきたいポイントです。

そして、Google検索だけでなくChatGPTやPerplexity、Google AI Overviewsといった生成AI検索エンジンでの見え方まで踏まえて助言できるかどうかも、2026年時点では確認しておく価値があります。生成AI検索は、サイト構造や情報の一貫性を手がかりにコンテンツを解釈する傾向があるとされており、パンくずを含む構造化データの整備は、こうした生成AI経由の露出にも一定の影響を持つ可能性があります。

こうした診断は、自己流のチェックリストだけでは見落としが生じやすい領域です。AIコマース研究所では構造化データを含むサイト全体の実装状況を確認できるLLMO無料診断を提供しています。「自分の実装で本当に合っているのか」という不安を感じている場合は、まず現状を客観的に確認するところから始めてみてください。

パンくずの構造化データに関するよくある質問

パンくずリストは構造化データを設定しないといけない？

必須ではありませんが、設定することを推奨します。構造化データがなくても見た目のパンくずは表示されますが、検索エンジンにサイト構造を正確に伝えられるかどうかに差が出るため、SEOやAI検索対策の観点からは設定しておく方が望ましいといえます。

パンくずリストはSEOにどのような効果がある？

検索エンジンにサイト階層を伝え、内部リンクを増やす効果があります。クローラーがサイト構造を正しく理解しやすくなるほか、ユーザーの回遊性向上にもつながり、間接的に評価が高まる傾向があります。

構造化データを設定するメリットは何ですか？

検索エンジンがページ内容やサイト構造を正確に理解しやすくなることが主なメリットです。パンくずの場合、検索結果に階層情報が表示される可能性があるほか、生成AI検索においても文脈理解を助ける材料になり得ます。

パンくずリストのHTML表示と構造化データは何が違う？

HTML表示は人間が見るための視覚的なナビゲーションで、構造化データは検索エンジン向けのメタ情報です。両者は別々に記述する必要があり、表示内容と構造化データの内容が食い違うとエラーの原因になるため注意が必要です。

パンくずリストはどこに設置するのが正しい？

一般的にはページの上部（ヘッダー直下）に設置します。ユーザーが現在地をすぐに把握でき、上位階層へも移動しやすい位置のため、コンテンツ本文より前に配置するのが基本です。

パンくずリストのデザインはSEOに影響しますか？

デザイン自体が直接の評価要因になることは確認されていません。ただし視認性が低いと回遊性が下がり、間接的にユーザー体験の評価へ影響する可能性があるため、階層が一目で分かる配色・区切り記号を意識すると良いでしょう。

パンくずリストは本当にいらない場合もある？

階層構造が浅い小規模サイトでは省略されることもあります。ただし、カテゴリ階層を持つコンテンツサイトやECサイトでは、サイト構造の伝達とユーザー導線の両面で設置するメリットが大きく、多くの場合は設置が推奨されます。

構造化データの実装は自社対応と外注どちらが良い？

コードの記述だけであれば自社対応も可能ですが、サイト全体の情報設計まで含めた見直しが必要な場合は専門家への相談が有効です。AIコマース研究所の支援現場でも、個別ページの修正よりカテゴリ設計から整理した方が再発防止につながるケースが多く見られます。

LLMOとは何ですか？

LLMOとは、ChatGPTやPerplexity、Google AI Overviewsなど生成AI検索エンジンに正しく認識・引用されるための対策を指します（Large Language Model Optimizationの略）。従来のSEOとは異なり、AIの文脈理解プロセスを踏まえた情報設計が重要になります。

パンくずリストの構造化データが正しく機能しているか自分で確認する方法は？

Googleのリッチリザルトテストとサーチコンソールの2つを併用して確認します。前者は公開前後のスポット確認、後者はサイト全体の継続的なモニタリングに向いており、両方を使い分けることでエラーの見落としを防げます。

構造化データの正しい設計と実装でパンくずの効果を最大化する

パンくずリストの構造化データは、JSON-LD形式での実装が基本であり、コード自体の書き方は決して難しいものではありません。しかし、表示不備や実装ミスの多くは、コードそのものよりも「このページは何についてのページか」「一つ上の概念は何か」といった、実装前の情報設計の段階に原因があるケースが少なくありません。

実装後はリッチリザルトテストやSearch Consoleを使って必ず検証し、表示されない場合は記述ミス・表示内容との不一致・反映待ち・ガイドライン違反・AI検索の影響という5つの原因から順に切り分けていくことが大切です。コードの正確性とサイトの情報設計、その両輪を意識することが、パンくずの構造化データを長期的に安定して機能させるための近道になります。