2026.05.18 公開 2026.05.23 更新読了約18分（10,302字）

構造化データとパンくず・URL階層の正しい設定｜失敗例も図解

結論：パンくず・URL階層・構造化データは「3つで1セット」として整える

あなたが自社サイトの評価を底上げしたいなら、パンくずリスト・URLの階層・構造化データの3つをバラバラにではなく、ひとつの整合した設計として整えるのが正解です。理由はシンプルで、この3つは「サイトのどこに、何が、どんな関係で置かれているか」を人と検索エンジンに伝える、同じ目的を持った仕組みだからです。どれか一つだけ整えても、他がちぐはぐだと効果は半減します。逆に3つの階層がぴたりとそろうと、1ページの改善がサイト全体の理解しやすさにつながり、施策の効果が積み上がっていきます。

このページでは、(1)パンくずが正しい階層構造になっていないとどれくらいまずいのか、(2)URLスラッグの階層をなぜ崩してはいけないのか・中間階層が「歯抜け」だと何が起きるのか、(3)構造化データの仕組みと検証方法、そして(4)実際に設定する手間とメリット・デメリット・ミス時の症状までを、図解を交えて網羅的に解説します。情報の根拠として、Google検索セントラル(Google公式ドキュメント)、Ahrefs、Screaming Frog、schema.orgといった一次情報・主要ツールの公開情報を参照し、検証した内容を盛り込みました。前提知識は不要です。専門用語には初出時に簡単な説明を添えています。

この記事は、京都でホームページ制作・WEBサイト制作・WordPress構築・SEO対策を手がける株式会社ドラマが、創業26年・4800件超の制作実績にもとづく実務の視点でまとめた保存版リファレンスです。「どこを間違えると、どんな症状が出るか」を現場で検証してきたからこそ書ける内容を意識しました。

前提：3つの階層がそろうとはどういう状態か（全体像）

まず全体像をつかみましょう。理想は、URLの階層・画面に出るパンくず・構造化データの3つが、同じ親子関係を指している状態です。次の図で、3つが一致しているイメージを確認してください。

【URLの階層】 example.com / service / web-seisaku / kyoto-plan
【パンくず(画面表示)】ホーム > サービス > ホームページ制作 > 京都プラン
【構造化データ(裏側のコード)】
BreadcrumbList
├── position1: ホーム
├── position2: サービス
├── position3: ホームページ制作
└── position4: 京都プラン(現在地)

このように3つが同じ階層・同じ順序・同じ名前を指していれば、人も検索エンジンも迷いません。逆に、URLは深いのにパンくずは2段しかない、構造化データの順番がURLとずれている、といった「ずれ」が、これから説明する問題の正体です。なお用語として、パンくずはページ上部に出る「ホーム > …」の現在地表示、構造化データは検索エンジンに内容の意味を伝える裏側のコード、スラッグはURLの末尾にあるページ固有の文字列(例:kyoto-plan)を指します。

パンくずが正しい階層構造になっていないとどれくらいまずいか

結論から言えば、パンくずの階層が崩れていてもサイトが即座に圏外へ飛ぶような致命傷にはなりにくい一方で、「得られるはずだったメリットを取りこぼし続ける」じわじわとした損失が発生します。深刻度を段階に分けて見ていきましょう。

パンくずの2つの顔：見た目と構造化データ

パンくずには2つの側面があります。1つは利用者が画面で見る視覚的なパンくず(ナビゲーション)、もう1つは検索エンジンが読む構造化データ(BreadcrumbList)です。Google検索セントラルの解説によると、BreadcrumbListはページがサイト階層のどこに位置するかを示すもので、利用者が末尾のパンくずから1段ずつ上の階層へたどれるようにする役割を持つとされています。つまりパンくずは、見た目と裏側コードの両輪で機能します。

Google公式の重要な考え方：URLの丸写しではなく「利用者の経路」

ここは誤解が多いポイントです。Google検索セントラルは、パンくずについてURL構造をそのまま反映するのではなく、利用者がそのページへたどり着く典型的な経路を表すことを推奨しています。つまり「URLが深いから機械的に同じ段数を並べる」のではなく、「人が実際にどう移動して来るか」を基準に組むのが本筋です。多くの場合この2つは一致しますが、目的は階層の意味を正しく伝えることにある、と理解してください。

崩れていると起きること:深刻度の段階

パンくずの階層が崩れている状態を、影響の小さい順に整理します。

段階1(軽度):リッチリザルトを取りこぼす — 構造化データのBreadcrumbListに不備があると、検索結果でパスが表示される機会(リッチリザルト)を失います。Google検索セントラルは、BreadcrumbListに最低2つのListItemと、各項目の位置(position)・名前(name)・URL(item、最後の項目は省略可)が必要としています。必須項目が欠けると表示対象から外れます
段階2(中度):サイト構造の理解が弱まる — パンくずは検索エンジンが階層を理解する手がかりの一つです。崩れていると、ページ同士の関係が伝わりにくくなり、トピックのまとまり(専門性の評価)で不利になりえます
段階3(中度):利用者が現在地を見失う — 視覚的なパンくずが正しくないと、訪問者は「今どこにいるか」「上の階層に何があるか」がわからず、回遊せずに離脱しやすくなります。これは滞在時間や再訪に響きます
段階4(要注意):手動対策のリスク — Google検索セントラルは、構造化データのガイドラインから外れた手法(実際と異なる偽の階層を記述するなど)を検出した場合、手動による対策の対象になりうると警告しています。実態と食い違うパンくずは作らないことが鉄則です

2025年の変更:モバイル検索でのパンくず表示

近年の動きとして、モバイルの検索結果ではパンくずのパス表示が簡素化され、ドメイン中心の表示に変わったと複数の業界情報が報じています。ただしこれは「検索結果での見え方」の話であり、サイト内のパンくずナビゲーションと構造化データが不要になったわけではありません。デスクトップ検索での表示や、サイト内の回遊性、検索エンジンの構造理解には引き続き価値があります。表示が変わっても土台の整備は続ける、と覚えておきましょう。

URLスラッグの階層を崩してはいけない理由と「歯抜け」問題

次にURLの階層です。あなたが「スラッシュを1つ消したらどうなるのか」「中間のアーカイブ(一覧ページ)が歯抜けだと何が起きるのか」と疑問に思ったなら、その感覚はとても正しい着眼点です。順に検証します。

そもそもURLの階層は何を表すか

URLのスラッシュ区切りは、サイトの親子関係を表す住所のようなものです。Ahrefsやスクリーミングフロッグ(Screaming Frog。サイトを解析するクローラーツール)の解説でも、サブフォルダ(/service/ のような区切り)は階層とグルーピングを示し、利用者にも検索エンジンにも構造を伝えると説明されています。URLを見ただけで、そのページがどのカテゴリの下にあるかがわかるのが理想です。

スラッシュを1つ消すとどうなるか(中間階層の歯抜け)

例えば example.com/service/web-seisaku/kyoto-plan というURLがあるとします。ここから web-seisaku を消して example.com/service/kyoto-plan のように飛ばすと、中間階層が抜けます。さらに、中間の example.com/service/web-seisaku/ にアクセスしたとき、そこに一覧ページ(アーカイブ)が存在せずエラー(404 Not Found)が返る状態を、ここでは「歯抜け」と呼びます。図にすると次のようになります。

【良い例:歯抜けなし】
/service/ … サービス一覧(存在する)
└ /service/web-seisaku/ … 制作の一覧(存在する)
└ /service/web-seisaku/kyoto-plan … 個別(存在する)
【悪い例:歯抜けあり】
/service/ … 存在する
└ /service/web-seisaku/ … 404(中間が抜けている)
└ /service/web-seisaku/kyoto-plan … 存在する

スクリーミングフロッグの解説では、利用者がURLからフォルダを削って一つ上のカテゴリへ戻れるようにすることが望ましいとされています。つまり中間階層を消したり、消した先が404になったりするのは、この「上に戻れる」前提を壊す行為です。

歯抜けだと実際にどれくらいまずいか(諸説の検証)

ここは正直に整理します。「Googleが必ずURLのパスをさかのぼって中間階層を確認する」という公式の断定はありません。実際、海外のSEOフォーラムでは、現在のGoogleが20年前のように物理フォルダをたどって中間を検証することは考えにくい、という見解も見られます。一方で、次の理由から歯抜けは避けたほうが良いというのが実務の結論です。

利用者の体験が落ちる:URLを削って戻ろうとした人が404に当たると、離脱の原因になります
内部リンクが404を指していると実害が出る:複数の情報源が共通して指摘するのは「404そのものより、404へ向かう内部リンクが残っていることが問題」という点です。歯抜けの中間階層に向けたリンクが残ると、評価の流れ(リンクの力)が行き止まりになります
パンくず・構造化データと食い違う:パンくずでは中間階層を見せているのに、その中間URLが404では整合性が崩れ、リッチリザルトの条件(各項目に有効なURL)も満たせなくなります
クロールの効率が落ちる:行き止まりが多いと、検索エンジンがサイトを巡回する効率が下がります

要するに、歯抜けは「即・大ペナルティ」ではないものの、UX・内部リンク・整合性・クロール効率の4方向でじわじわ損をする状態です。中間階層には、その配下をまとめた一覧(アーカイブ)ページをきちんと用意し、リンクを通しておくのが鉄則です。

あわせて押さえたいスラッグ設計のルール

Ahrefsやスクリーミングフロッグなどの公開情報から、実務で効くポイントをまとめます。あなたがスラッグを決めるときの判断材料にしてください。

階層は浅く:重要ページはトップから3〜4クリック以内に収めるのが目安とされています
サブフォルダを使う:サブドメイン(blog.example.com)は別サイト扱いになりやすく、評価が分散します。サブフォルダ(example.com/blog/)が一般に有利とされています
長すぎない:Ahrefsの大規模調査では、約115文字を超える長いURLで平均順位が下がる傾向が報告されています。これはURL自体への罰というより、長いURLに余計な語が混ざりやすいためと説明されています
区切りはハイフン:Googleはハイフンを語の区切りとして扱い、アンダースコアは語の連結として扱うため、単語区切りにはハイフンを使います
英小文字で意味が伝わる語に:日本語や記号をそのまま入れず、内容を表す英小文字とハイフンで構成すると安定します

構造化データの深掘り:仕組み・検証・よくあるミス

ここからが本題の一つ、構造化データの深掘りです。構造化データとは、ページの内容が「会社情報なのか」「商品なのか」「パンくずなのか」といった意味を、機械が理解できる形式で記述する仕組みです。共通ルールにはschema.org(スキーマ・ドット・オルグ。構造化データの語彙を定める共通規格)があり、記述形式はJSON-LD(ジェイソン・エルディー。HTMLとは分離して書ける、Googleが推奨する記法)が主流です。

BreadcrumbListの中身を分解する

パンくずの構造化データであるBreadcrumbListを例に、中身を分解します。schema.orgの定義では、BreadcrumbListは連なったページの鎖であり、各項目の順序はposition(位置)で再構成されます。慣習として、小さい数字ほど上位(ホーム側)から並べます。各項目(ListItem)に必要なのは、次の要素です。

position:並び順。1から始める整数で表します
name:その階層の名前(例:サービス)
item:その階層のURL。ただし最後の項目(現在地)はURLを省略でき、省略時はそのページのURLが使われます

Google検索セントラルは、有効な表示のためにBreadcrumbListへ最低2つのListItemを含めることを求めています。なお、かつて使われたdata-vocabulary.orgの記法は、現在のリッチリザルトの対象外となっている点も押さえておきましょう。

検証の三段構え:3つのツールを使い分ける

構造化データは「書いて終わり」ではなく、検証してから公開するのが鉄則です。複数の情報源が共通して挙げる、3つのツールの役割分担を整理します。

schema.orgのバリデータ:規格そのものに沿っているか(標準準拠)を確認します
リッチリザルトテスト(Rich Results Test):Googleの表示資格があるかを、1ページ単位・公開前に確認します。開発・公開前のチェック向きです
サーチコンソールの拡張(Enhancements)レポート:公開後にサイト全体を継続的に監視します。テンプレートの変更で200ページのスキーマが一斉に壊れた、といったサイト規模の異常はここで初めて見えるため、1ページ単位のテストとは役割が異なります

順序としては、(1)標準準拠を確認 → (2)Googleの表示資格を確認 → (3)公開後はサーチコンソールで監視、という流れが王道です。

「エラー」と「警告」は意味が違う

サーチコンソールやリッチリザルトテストの結果は、大きく3つの状態に分かれます。ここを取り違えると、対応の優先順位を誤ります。

有効(valid):問題なく、リッチリザルトの対象になりえます
警告(warning):必須ではない項目が欠けている状態です。マークアップ自体は有効で、表示の資格は残ります。改善すればより良くなる、という位置づけです
エラー(error):マークアップが壊れている状態です。修正するまでGoogleはその構造化データをリッチリザルトに使いません。最優先で直すべき対象です

対応の鉄則は「エラーを先に潰し、警告は改善の指針として後から拾う」こと。修正後はサーチコンソールの「修正を検証(Validate Fix)」で再チェックを依頼できます。

よくあるミスと、その症状

現場で頻発するミスを、症状とあわせて挙げます。あなたが点検するときのチェック観点として使ってください。

必須項目の欠落:itemやnameが空・未定義だと、Google検索セントラルの定義上、パンくずの鎖が途切れてリッチリザルトの対象から外れます
JSON-LDの構文エラー:カンマの付け過ぎ(末尾の余分なカンマ)が代表例で、構造化データが読み取れなくなります
表示と実態の不一致:画面のパンくずと構造化データの内容がずれていると、整合性の問題になります。両者は一致させます
重複したBreadcrumbList:テーマやプラグインが二重に出力すると、競合が起きます。出力元を一本化します
動的描画での読み取り漏れ:ページ読み込み後に後から差し込む方式だと、検索エンジンが初回巡回時に見落とすことがあります。サーバー側で最初から出力する設計が安全です

実際の設定は面倒:メリット・デメリットを正直に

ここまで読んで「正しくやるほど手間がかかりそう」と感じたなら、その通りです。手間と効果を正直に整理します。判断はあなたの状況に合わせて行ってください。

整える側のメリット

検索結果での視認性が上がる:パンくずや各種リッチリザルトが出ると、検索結果で目立ち、クリックされやすくなる可能性があります
サイト構造が伝わりやすくなる:人と検索エンジンの双方が階層を把握しやすくなり、回遊と評価の土台になります
改善が積み上がる:整合した構造は、後から記事を足すたびに効果が乗りやすくなります
異常を早期発見できる:サーチコンソールで監視していれば、テンプレート変更による一斉破損などにすぐ気づけます

デメリット(手間)とその軽減策

初期設定が手間:JSON-LDを手書きすると、項目の記述や保守に時間がかかります
保守が必要:ページ追加やサイト改修のたびに、整合性の確認が要ります
誤実装のリスク:構文ミスや実態との不一致が起きやすく、検証の手間がかかります

軽減策として有効なのが、CMS(更新の仕組み)やプラグインの活用です。多くのCMSでは、テーマやプラグインの設定を有効化するだけで、画面のパンくずと構造化データを連動して自動生成できます。手書きより保守が楽で、ミスも減らせます。「自動生成 → ツールで検証 → サーチコンソールで監視」という分業に落とし込むと、面倒さは大きく下がります。

ミスしているとどうなるか:症状から逆算する早見表

「何かおかしい」と感じたとき、症状から原因を逆算できると対処が速くなります。代表的な症状と疑うべき箇所をまとめました。

検索結果にパンくずが出ない → 構造化データの必須項目欠落、または構文エラーを疑う
サーチコンソールにエラーが急増した → テンプレート変更で全ページのスキーマが一斉に壊れた可能性を疑う
利用者の離脱が多い・回遊が浅い → 視覚的なパンくずの欠落や、URL階層の歯抜けを疑う
中間URLにアクセスすると404 → アーカイブ(一覧)ページの不在、リダイレクト未設定を疑う
新しいページがなかなか認識されない → 内部リンク不足や、行き止まり(歯抜け)によるクロール効率の低下を疑う
順位がじわじわ伸び悩む → 階層の深さ過多、長すぎるURL、トピックのまとまりの弱さを疑う

図解:正しい設計と崩れた設計を見比べる

最後に、ここまでの内容を図で総ざらいします。後から読み返すとき、この図を見れば全体を思い出せるようにまとめました。

図1:3つの階層が一致した「理想形」

URL: /service/web-seisaku/kyoto-plan
パンくず: ホーム > サービス > ホームページ制作 > 京都プラン
構造化データ:
BreadcrumbList
├── 1 ホーム → /
├── 2 サービス → /service/
├── 3 ホームページ制作 → /service/web-seisaku/
└── 4 京都プラン → (現在地・URL省略可)
※ 各中間URLにアクセス可能(歯抜けなし)

図2:よくある「崩れた形」

URL: /kyoto-plan (階層が浅く、所属が不明)
パンくず: ホーム > 京都プラン (中間が抜けている)
構造化データ: position の順序がURLと不一致、item が空でエラー
中間URL /service/web-seisaku/ → 404(歯抜け)
→ 症状:パンくず非表示、回遊低下、クロール効率ダウン

図3:検証と監視の流れ

(1) schema.org バリデータ → 標準に沿っているか
↓
(2) リッチリザルトテスト → Google表示の資格(1ページ・公開前)
↓
(3) サーチコンソール拡張レポート → サイト全体を継続監視
↓
エラーを最優先で修正 → 「修正を検証」で再チェック

公開前チェックリスト

サイトを公開・改修する前に、次の項目を確認すると失敗が大きく減ります。点検表として保存してお使いください。

URLの階層と画面のパンくず、構造化データが同じ親子関係を指しているか
中間階層のURLにアーカイブ(一覧)ページが存在し、404になっていないか
BreadcrumbListに2つ以上のListItemがあり、position・name・item がそろっているか
JSON-LDに余分なカンマなどの構文エラーがないか
重複するパンくず構造化データが出力されていないか
URLは3〜4階層以内・ハイフン区切り・英小文字で、過度に長くないか
404へ向かう内部リンクが残っていないか
公開後にサーチコンソールで監視する準備ができているか

代替案:自社対応が難しいときの選択肢

構造化データの実装やURL設計の見直しは、専門的な判断を伴う場面が多くあります。無理なく続けられる形を選ぶことが、結果的に最短ルートです。

CMSの標準機能・プラグインに任せる:パンくずと構造化データを連動生成し、手書きの手間とミスを減らす方法です
部分的に外部へ依頼する:構造化データの設計だけ、URL階層の再設計だけ、と範囲を絞って始める方法です
制作から運用まで一括で任せる:設計・実装・公開後の監視まで通して依頼し、社内負担を抑える方法です
研修で社内に知識を蓄える:担当者が自走できるよう、体系的に学ぶ方法です

WEB制作の現場での実装と私たちの視点

サイト制作において、URL階層・パンくず・構造化データの整合は、公開後の集客を支える土台です。サイトマップをツリーで描いて全体像を共有し、中間階層に必ずアーカイブを置き、構造化データを実態と一致させる——この基本を丁寧に積み上げることが、遠回りに見えて最も確実な改善につながります。

株式会社ドラマでは、京都を拠点に創業2000年から26年にわたり、4800件を超えるホームページ制作・WEBサイト制作の実績を積み重ねてきました。設計段階で構造を可視化し、SEO対策・MEO対策・AIO対策まで見据えたページ設計と構造化データの実装、公開後のサーチコンソール監視までを一貫して行うのが私たちの基本姿勢です。WordPress構築やECサイト構築、LP制作、オウンドメディア運用にも対応し、技術スタックの選定から保守運用までお任せいただけます。

さらに、補助金申請サポートでは470件を超える支援実績があり、コストを抑えながら構造の見直しやリニューアルに取り組むことも可能です。担当者育成のためのリスキリング研修もご用意しています。「パンくずや構造化データが正しいか不安」「URL階層を整理したい」といったお悩みも、現状の整合性を点検するところから一緒に取り組めます。

まとめ:整合した階層が、すべての施策の効果を底上げする

パンくず・URL階層・構造化データの3点を、図解と一次情報を交えて解説してきました。最後に要点をまとめます。迷ったときは、ここに戻ってきてください。

パンくずの崩れ:即・致命傷ではないが、リッチリザルトの取りこぼし・構造理解の低下・離脱増という損失がじわじわ続く。実態と異なる偽の階層は手動対策のリスクもある
パンくずの基準:URLの丸写しではなく、利用者の典型的な経路を表すのがGoogle推奨。最低2項目・position/name/itemが必須
URLの歯抜け:中間階層が404だと、UX・内部リンク・整合性・クロール効率の4方向で損をする。中間にはアーカイブを置き、上に戻れる構造にする
スラッグ:3〜4階層以内・サブフォルダ・ハイフン区切り・英小文字・長すぎない、が安定の条件
構造化データ:JSON-LDで記述し、schema.orgバリデータ→リッチリザルトテスト→サーチコンソール監視の三段構えで検証。エラーは最優先で修正、警告は改善の指針
手間の軽減:CMS・プラグインで自動生成し、検証と監視に分業すると現実的

3つの階層がぴたりとそろうと、1ページの改善がサイト全体に効いてきます。この記事をブックマークしておけば、次にサイトを点検するとき、必要な情報をすぐに引き出せます。

パンくずや構造化データの実装、URL階層の再設計を含めたWEB制作のご相談は、株式会社ドラマへお気軽にどうぞ。お問い合わせフォームの送信、LINE相談、お電話(075-585-5352)、お見積り依頼のいずれでも承っています。創業26年・4800件超の実績と補助金活用のノウハウで、設計から公開後の運用まで一貫してサポートします。詳しくは https://drama.co.jp/ をご覧ください。

お知らせ NEWS