パンくずリストのSEO効果と構造化データの点検手順

パンくずは画面にあるのに、検索結果では何も変わらない

ページの上に「トップ > サービス一覧 > 〇〇」と並べた。見た目は整った。それでも検索結果の見え方は変わらない。

見落としやすいのは、画面のパンくずと、Google 向けのパンくずが別物だという点です。画面に並ぶリンクは人のための表示です。Google 向けには、BreadcrumbList という構造化データ（検索エンジンにページの内容や階層関係を伝えるための専用コード）が用意されています。

つまり、点検するのは2か所です。画面の表示と、ソースの中のコード。片方だけ整えて終わりにしないのが、この記事の手順の前提です。

構造化データで期待できること、期待しすぎないこと

まず、公式が言っている範囲を押さえます。

Google 検索セントラルの「構造化データの仕組みについて」は、構造化データがページの内容についての Google の理解を高めると説明しています。JSON-LD・Microdata・RDFa といった形式で実装すると、リッチリザルト（通常の青いリンクより情報が多い検索結果の表示）につながることがある、とも書かれています。さらに、構造化データを入れたページでクリック率や訪問、ユーザーの関わりが増えた事例があることにも触れています。

一方で、「構造化データを入れると順位が上がる」とは書かれていません。ここは分けて考えるのが安全です。期待してよいのは、ページの理解を助けることと、表示の候補に入ることまで。順位が上がった・下がったを構造化データだけのせいにすると、ほかの原因を見落とすことがあります。

もう一つ、表示の候補に入ることと、実際に表示されることも別です。コードが正しくても、検索の状況によって表示されない場合があります。だから、テストに通った翌日に検索結果を見て「出ていない」と慌てる必要はありません。

パンくずがサイトにもたらす、もう一つの効果

検索結果での見え方だけが目的なら、構造化データだけ書けば済みそうです。ところが、パンくずの役目はそれだけではありません。

画面上のパンくずは、それ自体が上の階層へのリンクの束です。サービス詳細ページから「サービス一覧」「トップ」へ毎回リンクが出るので、人も巡回ロボットも、サイトの階層をたどりやすくなります。

ここからは独自の整理ですが、パンくずを設計し直すとカテゴリ構造の乱れが表に出ることがよくあります。「この記事はどのカテゴリの下か」に答えられないページは、パンくずを書こうとした瞬間に手が止まるからです。手が止まったページは、内部リンクの設計を見直す候補だと考えてよいでしょう。

BreadcrumbList のコードは何でできているか

公式のパンくずリストのページには、書籍サイトを例にしたコードが載っています。骨格はこうです。

{
  "@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"
  }]
}

見るべき部品は3つだけです。

公式の例では、最後の3番目の段に item がありません。自社のコードで最後の段に item が無くても、公式の例と同じ形なので、それだけで慌てる必要はないでしょう。

公式の例にはもう一つ、同じページに2本のパンくずを書く例も載っています。「Books > Science Fiction > Award Winners」と「Literature > …」のように、1つのページが2つの経路から到達できる場合の書き方です。商品が複数のカテゴリに属するサイトでは、この例が参考になります。ただし、経路を増やすほど点検の手間も増えます。迷ったら、まず主な経路を1本に決めて正しく書くほうが運用は楽になる場合が多いです。

ガイドラインで外せない1点:画面と一致させる

「構造化データの一般的なガイドライン」は、リッチリザルトの対象になるには、構造化データが Google のコンテンツポリシーとスパムポリシーに沿っている必要があるとしています。そのうえで、データがページの内容を正確に表していること、内容が完全で最新であることを求めています。

パンくずに当てはめると、こうなります。画面に出ていない階層をコードにだけ書かない。画面のラベルを変えたら、コードの name も変える。

表示とコードがずれる典型は、デザインの改修です。見た目のパンくずだけ作り直し、構造化データは古いテンプレートのまま残る。こうしたずれは、次の手順で見つけられます。

点検の5ステップ

公式のパンくずリストのページは、必要なプロパティを入れ、ガイドラインに沿い、リッチリザルト テストで検証し、公開後は Search Console でエラーを監視する、という流れを示しています。これを自社サイトの点検に置き換えると次の5ステップになります。

1. 対象ページを1つ選ぶ。最も深い階層のページ（例: サービス詳細）を選ぶと、全段の点検が一度で済みます。
2. 画面のパンくずを書き写す。表示されている順に、ラベルとリンク先URLをメモします。これが正解表になります。
3. リッチリザルト テストにURLを入れる。公開されているページをテストできる Google の公式ツールです。パンくずとして認識された項目が出てくるかを確かめます。
4. 3つの部品を正解表と突き合わせる。上の表の観点で、position の順番、name の文言、item のURLを1段ずつ見比べます。
5. 直したら、公開後も Search Console で見張る。公式は、公開や更新のあとにエラーを確認し、無効な項目を直して検証をリクエストする流れを示しています。テンプレートを1か所直すと全ページが変わるので、1ページの確認で終わらせないことが大切です。

通し例:架空のBtoBサイトで5ステップを回す

架空のBtoBサービスサイトで、5ステップを実際に通してみます。対象は「トップ > サービス一覧 > クラウドセキュリティ」のページです。

ステップ2で書き写した正解表はこうでした。

• 1段目:「トップ」→ https://example.com/
• 2段目:「サービス一覧」→ https://example.com/services/
• 3段目:「クラウドセキュリティ」→ 現在のページ

ステップ3でリッチリザルト テストに通すと、パンくずは認識されました。テストは通った。ここで終わりにしたくなります。

ところがステップ4で突き合わせると、2段目の item が https://example.com/service/ になっていました。末尾の「s」がありません。サイト移行の前に使っていた古いURLが、テンプレートに残っていたのです。テストはコードの形が正しいかを見るので、指している先が古いURLかどうかまでは教えてくれないことがあります。

さらに name の2段目は「Services」で、画面の「サービス一覧」と食い違っていました。デザイン改修で画面だけ日本語に直した名残です。

先ほどの表の「つまずきやすい所」のうち、2つが同時に出たことになります。item の古いURLと、name の片方だけ修正です。どちらも、正解表を先に作っていなければ見落としやすいずれでした。

直すのはテンプレートの1か所です。直したらステップ5に進み、Search Console 側でもエラーが出ていないかを数日おきに見ます。

自社サイトの自己点検表

最後に、その場で当てはめられる点検表を置きます。1つでも「いいえ」があれば、そのページから5ステップを回してください。

最後の2行は、構造化データだけでは片づかない項目です。パンくずは、サイトの階層そのものを映す鏡でもあります。

構造化データ全体の直す順番は「構造化データのエラーと警告｜直す順番の決め方」に、階層をたどりやすくするリンク設計は「内部リンクの貼り方と設計」にまとめています。