パンくずリストの実装方法は、大きく「HTMLで手書きする」「CMS・プラグインで自動生成する」「構造化データ(BreadcrumbList)でマークアップする」の3つに分けられます。結論として、多くのサイトでは見た目のHTML実装とJSON-LDによる構造化データを併用するのが基本であり、これによりリッチリザルト表示やAI検索(LLMO)での機械可読性も高まります。本記事ではコピペで使えるコード構成の考え方と、CMS別の実装方法、リッチリザルトテストでの検証手順、よくあるトラブルの対処法までを網羅的に解説します。
- パンくずリストの3つの実装方法とサイトに合った選び方
技術レベル・CMSの有無・ページ数を軸に、HTML手書き・CMS・プラグイン・構造化データのどれを選ぶべきかが判断できます。
- 構造化データ(BreadcrumbList)の正しい書き方
Google推奨のJSON-LDに必要な必須プロパティと記述ルールを理解し、リッチリザルト表示につなげられます。
- 実装後の検証方法とよくある失敗の対処法
リッチリザルト テストやSearch Consoleでの確認手順と、表示されない場合の原因切り分けができます。
パンくずリストの実装方法は3つ|結論と選び方早見表

パンくずリストの実装方法は、HTMLで手書きする方法、CMSやプラグインで自動生成する方法、構造化データ(BreadcrumbList)でマークアップする方法の3つに整理できます。見た目の実装と構造化データは目的が異なるため、多くの現場ではこの2つを併用するのが基本です。
①HTML手書き②CMS・プラグイン③構造化データの全体像
①のHTML手書きは、nav要素やol要素を使って見た目のパンくずリストを自分でコーディングする方法です。②のCMS・プラグインは、WordPressのテーマ標準機能やYoast SEOなどのプラグインが自動的にパンくずを生成する方法で、コーディングの手間を減らせます。③の構造化データは、見た目とは別にGoogleへ「このページの階層はこうだ」と伝えるためのマークアップで、検索結果にリッチリザルトとしてパンくずを表示させるには構造化データの実装が欠かせません。
技術レベル×CMS有無×ページ数で選ぶ判断軸
どの方法を選ぶべきかは、実装者の技術レベル、CMSを使っているかどうか、サイトのページ数によって変わってきます。判断に迷う場合は、以下の早見表を参考にすると選びやすくなります。
| 状況 | おすすめの実装方法 | 理由 | 難易度 |
|---|---|---|---|
| WordPressを利用中 | プラグイン(Yoast SEO等) | JSON-LDまで自動生成される | 低 |
| 独自CMS・静的サイト | HTML手書き+JSON-LD | 好きな箇所に柔軟に設置できる | 中 |
| React/Next.jsなど動的サイト | コンポーネント化+構造化データ生成 | ルーティング情報から動的に生成しやすい | 中〜高 |
| ページ数が非常に多い大規模サイト | CMS・プラグイン+構造化データの自動出力 | 手動更新の漏れを防げる | 低〜中 |
3方法は排他ではなく併用が基本
3つの実装方法は「どれか1つを選ぶ」ものではなく、目に見えるパンくずリスト(HTMLまたはCMS)と、目に見えない構造化データ(JSON-LD)を組み合わせるのが基本の考え方です。見た目だけを整えても検索結果には反映されず、構造化データだけを入れても画面上のナビゲーションがなければユーザビリティは向上しません。
実装方針を決める前に、次の観点をチェックしておくと迷いにくくなります。
- CMSを使っているか、独自開発かを確認したか
- コーディングできる担当者がいるか確認したか
- 見た目のパンくずと構造化データの両方を用意する前提で計画したか
TechSuite株式会社の「AI検索パートナーズ」は、業種や規模、既存のCMS環境が企業ごとに異なることを踏まえ、パンくずリストの実装方法や運用フローをテンプレートに頼らず個別に設計し、導入から実装まで伴走しています。

まずは自社の環境を確認し、HTMLと構造化データを併用する前提で実装方針を決めるのが近道です
そもそもパンくずリストとは?役割と設置メリット


パンくずリストとは、ユーザーがサイト内のどの階層にいるかを示すナビゲーション表示のことです。童話「ヘンゼルとグレーテル」で道に迷わないよう落としたパンくずに由来しており、階層構造を持つサイトで特に効果を発揮すると言われています(出典)。
定義と名前の由来
パンくずリストは「ホーム>カテゴリ>記事タイトル」のように、トップページから現在のページまでの道筋を階層順に表示する要素です。ユーザーが自分の現在位置を把握しやすくなるだけでなく、検索エンジンにもサイトの階層構造を伝える役割を持っています。
3つの種類:位置型・属性型・パス型
パンくずリストは大きく位置型(階層型)・属性型・パス型の3種類に分けられます(出典)。それぞれ表示する内容や向いているサイトが異なるため、自社サイトの構造に合わせて選ぶことが望ましいです。
| 種類 | 表示内容 | 向いているサイト |
|---|---|---|
| 位置型(階層型) | トップからの階層順(ホーム>カテゴリ>記事) | ブログ・企業サイトなど多くのサイト |
| 属性型 | 色やサイズなど絞り込み条件の履歴 | ECサイトの商品一覧ページ |
| パス型 | ユーザーが実際に辿った履歴 | 検索結果からの回遊が多いサイト |
設置メリット:ユーザビリティ・SEO・リッチリザルト
設置の主なメリットは、ユーザビリティ向上、サイト構造の明確化、離脱率の低減、そして構造化データによる検索結果表示の強化です(出典)。構造化データを正しくマークアップすると検索結果にパンくずがリッチリザルトとして表示され、クリック率の向上につながる可能性があります。
TechSuite株式会社の「AI検索パートナーズ」は、自社サイトにおいてAI Share of Voiceが高水準を維持しており、支援先でもAI Overviewの引用率が改善した実績があります。パンくずリストのような階層情報の整備は、生成AIがサイト構造を正確に理解するうえでも一定の役割を果たすと考えられます。



パンくずリストはユーザーのためだけでなく、検索エンジンやAIにサイト構造を伝える手段でもあります
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援!
実装方法①:HTMLでパンくずリストを手書きする


HTML手書きでは、nav要素の中にol要素とli要素を配置し、各項目にリンクを設定するのが基本構造です。区切り文字はHTMLに直接書くよりCSSの擬似要素で表示する方がコードがすっきりします(出典)。
nav・ol・liを使った基本のHTML構造
基本構造としては、ナビゲーションの役割を明示するためにnav要素を使い、その中にリストであることを示すol要素、各階層をli要素で並べるのが一般的です。それぞれのli要素の中にa要素でリンク先を設定し、リンクテキストにはページ内容が分かるキーワードを含めることが推奨されます。
- nav要素にaria-labelでナビゲーションの種類を示す
- ol要素で階層の順序があることを明示する
- 各li要素の中にa要素でリンクを設置する
- 最後のli要素だけはリンクなしのテキストにする
最下層(現在ページ)はリンクにしない
最下層は現在表示しているページ自体を指すため、リンクを設定する必要はありません(出典)。同じページへのリンクを設置してしまうと、クリックしても何も起こらずユーザーを混乱させる可能性があるため、a要素ではなくspan要素などのテキストのみで表示するのが適切です。
区切り文字はCSS擬似要素で表示するとすっきりする
「>」や「/」といった区切り文字は、HTMLの本文にテキストとして書き込むのではなく、CSSのafter擬似要素でcontentプロパティとして表示させる方法が推奨されています。区切り文字をCSS側に持たせることで、HTML側の記述がシンプルになり、読み上げソフトが不要な記号まで読み上げてしまう問題も避けやすくなります。アクセシビリティを重視する場合は、区切り文字をcontentではなく背景画像(background-image)で表示する方法がより望ましいとされています。
デザインとレスポンシブ対応のポイント
設置位置はページ上部やメインコンテンツの直前が効果的とされ、フォントサイズやカラー、区切り記号を見やすく整えることが望ましいです(出典)。スマートフォンでは表示スペースが限られるため、階層が多い場合は折り返しや省略表示などの配慮を検討するとよいでしょう。
HTML実装時は次の点を確認しておくと、後のトラブルを防ぎやすくなります。
- nav要素とol要素を使い階層構造を明示したか
- 最後の項目からリンクを外したか
- 区切り文字をCSSに任せたか
- モバイル表示時の折り返しを確認したか
TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作の仕組みを「バクヤスAI記事代行」事業で培っており、その制作エンジンとナレッジをサイト構造やHTMLマークアップの設計にも応用し、検索意図に沿った階層設計を支援しています。



HTMLはシンプルに、区切り文字はCSSに任せるのがコードをすっきり保つコツです
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援!
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
実装方法②:CMS・プラグインで自動生成する


WordPressではテーマ標準機能やプラグインでパンくずリストを自動生成できます。実装手段はテーマ標準機能、プラグイン、HTML手書きの3つがあり、JavaScriptのみでの実装は推奨されていません(出典)。
WordPress:テーマ標準機能とプラグイン
多くのWordPressテーマにはパンくずリストの表示機能が標準搭載されており、設定画面から有効化するだけで導入できる場合があります。標準機能がない、または構造化データまで含めて自動化したい場合は、Yoast SEOやBreadcrumb NavXTといったプラグインの導入が定番の選択肢です。Yoast SEOはmicrodataではなくJSON-LD形式で構造化データを出力しますが、得られる効果は同じとされています(出典)。
| 手段 | 構造化データ対応 | カスタマイズ性 | 向いている人 |
|---|---|---|---|
| テーマ標準機能 | テーマによる | 低い | とにかく早く導入したい人 |
| Yoast SEO | 対応(JSON-LD) | 中程度 | SEO対策全般も一緒に行いたい人 |
| Breadcrumb NavXT | 対応 | 高い(表示形式を細かく調整可) | デザインを細かく調整したい人 |
Shopify・STUDIOなどノーコード系での導入
ShopifyやSTUDIOなどのノーコード系サービスでも、テーマやテンプレートの設定からパンくずリストを表示できる場合があります。コーディング不要で導入できる分、デザインの自由度はテーマの仕様に依存するため、事前にテンプレートの対応状況を確認しておくと安心です。
JavaScriptのみでの実装が非推奨な理由
JavaScriptのみでパンくずリストを描画する実装は非推奨とされています(出典)。検索エンジンやAIのクローラーがJavaScriptの実行タイミングによって内容を正しく読み取れない可能性があり、パンくずリストとしての効果が十分に発揮されないおそれがあります。React/Next.jsなど動的にレンダリングするサイトでは、サーバー側やビルド時にHTMLとして出力する、あるいは構造化データをページのソースに直接埋め込む形での実装が望ましいとされています。
TechSuite株式会社の「AI検索パートナーズ」は、技術実装を担う人材とコンテンツ制作人材が一つのチームで連携し、CMSの選定からプラグインの設定、構造化データの実装、効果測定までを一気通貫で支援しています。



CMSを使っているなら、まずはプラグインでの自動生成を検討するのが効率的です
実装方法③:構造化データ(BreadcrumbList)でリッチリザルトを狙う


構造化データでリッチリザルトを狙うには、Google推奨のJSON-LD形式でBreadcrumbListをマークアップします。BreadcrumbListは最低でも2つのListItemを含めて定義する必要があり、コンテンツと共に表示させるにはitemListElement・item・name・positionという必須プロパティを含める必要があります(出典)。
JSON-LDでの書き方(コピペで使える構成)
JSON-LDはページのhead内などにスクリプトとして埋め込む形式で、Googleが推奨する記述方法です。基本構成は次のような項目を持つオブジェクトになります。
- 「@context」に「https://schema.org」を指定する
- 「@type」に「BreadcrumbList」を指定する
- 「itemListElement」の中にListItemの配列を並べる
- 各ListItemに「position」(1から始まる整数)、「name」(表示名)、「item」(リンク先URL)を設定する
positionはパンくず内の位置を示す整数で、position=1がリスト内の最初のパンくずを表します(出典)。1ページ内で目的のページへ到達する経路が複数存在する場合は、1ページに複数のBreadcrumbListを指定することも可能です(出典)。
microdata・RDFaでの書き方と違い
Googleは構造化データの記述形式としてJSON-LD・RDFa・microdataをサポートしています(出典)。microdataでは、ol要素にitemscopeとitemtypeでBreadcrumbListを指定し、各li要素にitemtypeでListItem、itempropでitemListElementを指定、a要素やspan要素にitemprop「item」「name」、meta要素にitemprop「position」とcontentを設定する形で表現します(出典)。既存のHTML要素に属性を追加していく形式のため、既にできあがったパンくずリストへ後付けしやすい一方、JSON-LDに比べて記述量が多くなりやすい傾向があります。
必須プロパティと最低2アイテムのルール
BreadcrumbListを正しく機能させるには、必須プロパティと構成ルールを守る必要があります。以下の表で主なプロパティの役割を整理します。
| プロパティ | 役割 | 必須かどうか |
|---|---|---|
| itemListElement | ListItemの配列全体を表す | 必須 |
| position | パンくず内の位置を示す整数 | 必須 |
| name | 各階層の表示名 | 必須 |
| item | 各階層のリンク先URL | 最後の項目以外は必須 |
パンくずが最後のアイテムの場合、itemは必須ではなく、含まれていない場合はGoogleがそのページ自身のURLを使用します(出典)。また、パンくずリストにはURL構造をそのまま反映させるのではなく、ユーザーが特定ページに辿り着くまでの一般的な経路を示すことが推奨されており、最上位パスやページ自体をListItemに含める必要はありません(出典)。
data-vocabulary.orgは廃止・古い実装に注意
かつて使われていたdata-vocabulary.orgのマークアップは、Googleのリッチリザルト機能でサポートされなくなっています(出典)。古い記事やテンプレートを流用している場合は、schema.org形式へ移行できているか改めて確認することが必要です。また、構造化データに対しガイドライン違反の手法が検出されると、サイトに手動による対策が講じられることがあるため(出典)、実際のページ内容と一致しない誇張的なマークアップは避けるべきです。
構造化データを実装する前に、以下を満たしているか確認しておきましょう。
- ListItemを2つ以上用意したか
- position・name・itemの必須プロパティを設定したか
- 最上位パスやページ自身をリストに含めていないか
- data-vocabulary.orgなど古い形式を使っていないか
TechSuite株式会社の「AI検索パートナーズ」は、生成AIが引用・推薦する仕組みを構造化データやエンティティ認識、知識の一貫性といった観点から技術的に捉え、BreadcrumbListを含む一次情報設計までLLMO・GEO・AEO対策に落とし込んでいます。



構造化データは必須プロパティと経路の考え方を守ることが、リッチリザルト表示への近道です
実装後の検証方法とよくある失敗・トラブル対処


実装後はリッチリザルト テストでコードを検証し重大なエラーを修正、URL検査ツールでページ表示を確認、Search Consoleのリッチリザルト ステータスレポートで監視するという手順が推奨されています(出典)。
リッチリザルトテストとSearch Consoleでの検証手順
まずはGoogleのリッチリザルト テストにページのURLまたはコードを入力し、BreadcrumbListが正しく認識されているか、重大なエラーが出ていないかを確認します。次にURL検査ツールで実際のインデックス状況を確認し、最後にSearch Consoleのリッチリザルト ステータスレポートで、サイト全体としてどのページが有効・無効になっているかを継続的に監視するという流れが基本です。
リッチリザルトが出ない・減ったときの原因切り分け
リッチリザルトが表示されない、あるいは以前は出ていたのに減った場合は、原因を切り分けて確認する必要があります。以下の表を目安に、当てはまる項目から優先的に確認するとよいでしょう。
| 症状 | 考えられる原因 | 確認すべき箇所 |
|---|---|---|
| そもそも表示されない | 必須プロパティの不足・記述ミス | リッチリザルト テストのエラー内容 |
| 一部のページだけ表示されない | ページごとのマークアップ漏れ | 該当ページのソースコード |
| 以前は出ていたが減った | テーマ更新やプラグイン変更による出力崩れ | Search Consoleのステータスレポート |
| Googleの表示仕様自体の変化 | アルゴリズムやUI仕様の変更 | Google公式のガイドライン更新情報 |
よくある失敗(表示崩れ・カテゴリ重複・リンク切れ)と対処法
典型的な失敗は、カテゴリ名が分かりづらい・重複していること、そしてリンク切れや誤ったURL設定です(出典)。階層を深くしすぎない・スマホでの見やすさを意識する・目立ちすぎるデザインは避けるという3点を守るだけで、多くの表示トラブルを未然に防ぎやすくなります(出典)。JSON-LDが認識されない場合は、JSONの記法ミス(カンマ抜けや引用符の不一致)が原因になっているケースが多いため、まずは記述内容そのものを見直すことが有効です。
AI検索(LLMO)の観点でパンくずが持つ意味
パンくずリストと構造化データを整備することは、生成AIがサイトの階層構造やページ同士の関係性を機械的に理解する助けにもなります。こうしたサイト構造の最適化は、LLMOとは何かを理解し、LLMO対策の具体的なやり方を検討するうえでも土台となる取り組みです。あわせてGEO(生成エンジン最適化)の観点でも、サイト内の情報が整理されていることは評価につながりやすいと考えられます。
TechSuite株式会社の「AI検索パートナーズ」は、露出や順位だけでなく受注という成果を重視しており、AI検索経由での受注率は従来のSEO経由の約3倍という実績があります。パンくずリストのような基礎的な構造化対策も、こうした成果につながる施策の一部として位置づけています。
実装後は次の順番で確認すると、問題の切り分けがスムーズです。
- リッチリザルト テストでエラーが出ていないか確認したか
- URL検査ツールで対象ページのインデックス状況を見たか
- Search Consoleのステータスレポートを定期的に見ているか
- カテゴリ名の重複やリンク切れがないか見直したか



表示トラブルは記述ミスとカテゴリ設計の見直しでほとんど解決できます
よくある質問
- トップページにもパンくずリストは必要ですか
トップページはそれ自体が最上位の階層であるため、パンくずリストを表示しないサイトが多く見られます。一方でBreadcrumbListの構造化データは、下層ページから見た経路として設定するものであり、トップページ自体に無理にListItemを追加する必要はないとされています。
- JSON-LDとmicrodataはどちらを使うべきですか
Googleは両方の形式をサポートしていますが、既存のHTMLと分離して管理できる点や記述のシンプルさから、多くの実装例ではJSON-LDが選ばれる傾向があります。既にmicrodataでマークアップ済みのサイトを大きく作り変える必要はなく、正しく必須プロパティが設定されていればどちらの形式でも問題ありません。
- React・Next.jsなど動的サイトでの実装はどうすればよいですか
ルーティング情報からパンくずのデータを生成し、サーバーサイドレンダリングやビルド時にHTMLと構造化データを出力する方法が現実的です。クライアント側のJavaScriptのみで描画すると、クローラーが内容を正しく認識できない可能性があるため注意が必要です。
- パンくずリストの階層はどこまで深くしてよいですか
階層を深くしすぎないことが望ましいとされています。目安としては3〜4階層程度に収め、ユーザーが自分の位置を一目で把握できるシンプルな構成にすることが推奨されます。
まとめ
パンくずリストの実装方法には、HTML手書き、CMS・プラグインによる自動生成、構造化データ(BreadcrumbList)によるマークアップの3つがあり、実際には見た目とJSON-LDを併用するのが基本です。構造化データを実装する際はitemListElement・item・name・positionといった必須プロパティと、最低2アイテムというルールを守ることが重要です。
実装後はリッチリザルト テストとSearch Consoleで継続的に検証し、カテゴリ名の重複やリンク切れといった典型的な失敗を避けることで、リッチリザルト表示とユーザビリティ向上の両方につなげやすくなります。自サイトの技術レベルやCMS環境に合わせて、無理のない方法から着手することをおすすめします。
参考にした情報源



