パンくずリストの設計とWordPress実装｜表示・構造化データ・公開確認の手順

パンくずリストは、今いるページの位置と、上の分類へ戻る道を伝える案内です。追加する前に、記事からカテゴリへ戻り、そのカテゴリで関連情報を探せるかを確認してください。検索順位を上げる約束ではなく、利用者が目的の情報へ移動できることを出発点にします。

この記事は、会社のサイトを点検する更新担当者と、WordPressの実装を担当する制作会社に向けたものです。画面の案内、検索エンジンに渡す構造化データ、検索結果での表示を分け、必要な修正と公開後の確認を整理します。

1．画面の案内と検索結果の表示を分ける

サイト内で役立つかを先に確かめる

たとえば「ホーム ＞ ブログ ＞ ホームページ制作 ＞ 現在の記事」という案内なら、読者は上の分類へ移動できます。これは説明用の例です。実際にはサイトの分類とリンク先に合わせます。閲覧履歴をそのまま並べるのではなく、そのページをどこに位置付けると理解しやすいかを考えます。

パンくずがないだけでサイト全体の構造をGoogleに伝えられなくなるわけではありません。主なメニュー、カテゴリ一覧、本文の関連リンクも案内の役割を持ちます。独立した一ページの案内などでは、意味のある上位分類があるかから判断してください。

構造化データを追加しても表示や順位は保証されない

BreadcrumbListは、パンくずの情報を機械が読み取れる形式で伝えるものです。画面に表示するリンクと、HTML内のデータは別に確認します。Googleのパンくず構造化データの公式仕様では、この検索機能はパソコン版が対象です。

スマートフォンのGoogle検索でパンくずが見えないことだけを、実装失敗と判断しないでください。Googleはモバイル検索のURL表示の簡素化を案内しています。検索結果の表示と、自社サイトをスマートフォンで開いたときの案内は別です。サイト内の使いやすさは引き続き点検します。

実装だけでクリック率や流入が何％増える、何日で効果が出るとは言えません。検証ツールの合格も、検索掲載や受注の保証にはなりません。

2．利用者が戻れる分類と名前を決める

戻った先で何が見つかるかを確認する

代表的な記事とサービスページを開き、上位リンクを一つずつたどります。リンク先の一覧に対象の記事があるか、表示名と一覧の内容が合うか、行き止まりにならないかを確認してください。名前だけ整えても、リンク先が別の分類なら案内として役立ちません。

URLの文字列を機械的に切り分けて表示する必要はありません。Googleの公式仕様も、URLの構造をそのまま再現することより、利用者がページへ到達する典型的な経路を考えるよう説明しています。既存URLを変更せずに、表示する分類を整えられる場合があります。

記事が複数カテゴリに属する場合は、表示する経路を編集方針として決めます。一方でGoogleの仕様には複数経路の記述例もあります。「必ず一経路しか認められない」とは考えず、利用者に見せる案内と出力データを整理してください。

長い名前でも読めて操作できるようにする

スマートフォンでは長い記事名、折り返し、拡大表示を試します。中間の分類を省略するなら、その分類へ移動する手段が残るかを確かめます。見えない部分へ横スクロールが必要な場合も、利用者が気付いて操作できるかが確認点です。

W3Cのパンくずパターンは、案内の領域に名前を付け、現在ページを識別する方法を示しています。制作担当は、適切なnav要素とラベル、現在位置、キーボードのフォーカスを確認します。現在ページを文字だけで示す場合とリンクにする場合では扱いが異なり、「現在ページへのリンクはすべて誤り」とは言い切れません。

3．WordPressでは既存の出力元を調べてから実装する

まず、テーマ、子テーマ、SEOプラグイン、独自実装のどれが画面とデータを出しているかを調べます。画面の案内が一つでも、HTML内には別の仕組みからデータが重複して出ていることがあります。複数出力の存在だけで違反と決めず、意図しない別経路や古い情報の競合がないかを調べます。

設定名や対応機能はテーマとバージョンで異なります。一般的な説明を見て、新しいSEOプラグインを追加したり、既存のものを無差別に停止したりしないでください。

Yoast SEOを利用している場合は、公式の実装手順で、設定と表示場所の追加方法を確認できます。ブロックやテーマ側の対応によって手順が変わります。親テーマのPHPへ直接追記する前に、更新で失われない方法と戻し方を担当者へ確認してください。

手動実装を選ぶ制作担当は、名称、URL、順序を実際の分類から生成し、文字列の安全な出力と存在しない分類の処理も確認します。公式仕様にある最小の例を、そのまま全記事へ固定出力することは避けます。最後の項目のURLは省略可能ですが、「省略しなければ不正」という意味ではありません。

4．表示・データ・公開状態を順番に検収する

設定を変える前に、対象URL、現在の表示、出力元、変更予定、復元方法を保存します。検証環境を使う場合は、そこで合格したことと本番で合格したことを別に記録してください。共有テンプレートに触れるときは、一記事だけでなく影響するページ種別も対象にします。

画面では、記事、カテゴリ、固定ページ、複数カテゴリの記事、長いタイトルなどを確認します。PCとスマートフォンで全項目を読み、リンクを開き、キーボードでも操作します。省略表示や折り返しで重要なリンクが隠れないか、目次や見出しと重ならないかも見ます。

データはGoogleの公式仕様とリッチリザルトテストで確認します。検出件数だけでなく、名前、URL、順序、意図した経路かを読みます。テストで取得できないURLについて、未確認の状態を合格と記録してはいけません。

本番反映後は、管理画面の保存値だけでなく公開ページとHTMLを取り直します。キャッシュが残る場合は対象と配信元を確認し、関係のない設定まで一括変更しないようにします。担当者が認証済みSearch Consoleを使える場合は、URL検査や利用可能な拡張レポートも補助にできます。レポートがすぐ出ないことだけで失敗とせず、公開表示とテスト結果を先に照合します。

変更日、対象、修正内容、確認結果と残課題を残します。検索の表示・クリックを比較するときは期間と対象を揃え、他の更新や検索需要の違いも考慮します。パンくず修正だけが変化の原因だったと断定しないでください。

5．自社で直す範囲と制作会社へ任せる範囲を分ける

表示名の誤りで、既存の設定と影響範囲が分かる場合は、自社で直して公開リンクを確認できることがあります。一方、PHPの編集、複数プラグインの出力競合、分類の変更が広い範囲へ及ぶ場合は、変更前の調査と検証を担当者へ依頼する方が適切です。実装時間は現状と対象範囲で変わります。

依頼するときは、対象URL、現在の経路、希望する経路、困る操作、対象のページ種別をまとめてください。認証情報を最初の問い合わせへ貼る必要はありません。次は依頼メモの記入項目です。

• 対象：問題が見られる記事と一覧のURL
• 現状：表示名・リンク先・PCとスマートフォンで困る点
• 希望：どの分類へ戻り、何を探せるようにしたいか
• 作業範囲：設定の修正か、テーマの実装やデータ調査を含むか
• 完了条件：公開の表示・操作・出力データと更新時の確認方法

Acquaへ相談する場合、企業の担当者は企業向けのWeb支援から、制作会社はWordPress等の実装支援から対応内容を確認できます。既存出力の調査、必要な表示・実装の修正、公開確認と引き継ぎについて、対象と担当範囲を相談してください。費用や対応可否は状況を確認して決めます。

相談窓口には、上のメモと分かる範囲の情報を送れます。支援後に目指すのは、利用者が迷わず上の分類へ戻れ、担当者が出力元・修正内容・再確認方法を引き継げる状態です。公開確認、検索の変化、実際の相談・受注は別々に記録します。