SEO担当としてQiitaの自社メディア記事の作成を行なっています。
サイト運用中、「URLを変えずに、パンくずリストだけを階層化してGoogleに親子関係を伝えたい」というケースが発生しました。
その際、エンジニアとすり合わせた要件をもとに、今後同じような実装依頼が発生した時に、迷わず進められるような内容にまとめました。
なお、本記事は2026年6月時点での勉強中の内容をもとにまとめています。専門的な部分はまだ学習中のため、誤りがある可能性があります。
今後も随時アップデートしていく予定ですので、参考としてお読みください。
はじめに：こんなことがありました
「すべての記事が TOP > 記事タイトル になっており、Googleに親子関係が伝わっていない。しかし、今からURL構造を変えるとSEO評価がリセットされるリスクがある」という課題がありました。
(参考：パンくずリスト（BreadcrumbList）の構造化データ|
Google Search Central｜)
そこで、「URLのパスは変更せず、CMSの設定とフロントエンドの条件分岐だけで、パンくず（画面表示と構造化データ）のみを階層化する」というアプローチをとりました。
実際にエンジニアとすり合わせた「3つのポイント」
上記の依頼を投げた後、実務においてエンジニアとすり合わせが発生したポイントを共有します。依頼後のコミュニケーションの参考にしてください。
① 「孫ページ」など複数階層になった時のルール
「将来的に TOP > 記事A > 記事B > 記事C のように3階層になったらどうするか？」という確認が発生しました。
ここでは、「中間階層はすべて breadcrumbName を遡って表示し、一番最後（現在地）だけ title を出す」というロジックで合意しました。
② CMSの「API取得制限（深さの限界）」
エンジニアから「利用しているCMS（今回はmicroCMS）のAPI仕様上、遡って取得できる階層の深さは最大3階層までになる」という技術的な制約の共有がありました。
「運用上、3階層まで対応できれば十分か？」を話し合い、パフォーマンスへの悪影響もないことを確認した上で「最大3階層まで」という要件に着地させています。
③ 運用時の罠：記事の設定順序
機能リリース後、コンテンツ担当者がCMSに入力する「順序」についてのすり合わせです。
「親の短い名前（breadcrumbName）」を設定する前に、「子記事」から親の紐付けを先に行ってしまうと、本番環境のパンくずに「親の長いタイトル」がそのまま露出してしまうことが分かりました。
必ず「親記事の設定を済ませてから、子記事を紐付ける」という運用フローをチーム内で徹底することにしました。
（参考サイト：microCMSで親子関係をもつページを実装してみよう | microCMSブログ）
📋 【コピペ用】エンジニア依頼用テンプレート
以下は、その際にエンジニアへ依頼するためのテンプレです。Markdownでそのままコピーして使えます。
### 目的・背景（Why）
SEO（トピッククラスター強化）およびUX向上のため、記事間の親子関係を明確にし、内部リンクを最適化したいです。
※URL構造を変更するとGoogleの評価がリセットされるリスクがあるため、**URLは一切変更せず、パンくずリストと内部リンクの構造のみ**で論理的な階層化（例：`TOP > カテゴリ > 記事`）を実現したいと考えています。
また、親記事へ戻るパンくずが「長い記事タイトル」だと視認性が悪いため、短い「カテゴリ名」を表示させるのが狙いです。
### 実現したい挙動（What）
記事A（親）と 記事B（子）がある場合…
* **子記事（B）閲覧時：** `TOP > 記事Aの短い名称 > 記事Bのタイトル`
* **親記事（A）閲覧時：** `TOP > 記事Aのタイトル`（※自分自身の時はタイトルをそのまま表示）
### 具体的な依頼・調査事項
上記を実現するため、CMS（microCMS等）の仕様とフロントエンドの実装調査をお願いします。
#### 1. CMS側の改修要望
コンテンツ担当者が自由に親子関係と名称を設定できるよう、以下2つのフィールドを追加可能でしょうか。
* **親子関係の紐付け：** 親記事を選択するフィールド（例：`parent`）
* **パンくず用の短縮名：** 中間階層として表示する際の短い名称を入力するフィールド（例：`breadcrumbName`）
#### 2. フロントエンド側の改修要望
CMSの設定をもとに、以下の条件分岐でパンくずのテキストを出し分け可能でしょうか。
* **自分が「親（中間階層）」として表示される時：** `breadcrumbName` を使用
* **自分が「現在地（一番右端）」として表示される時：** 通常の `title` を使用
#### 3. 構造化データ（JSON-LD）の同期【重要】
Googleのガイドライン違反（隠しテキスト等）を防ぐため、**「フロントで出し分けた画面上のテキスト」と「裏側で出力する構造化データ（JSON-LD）のテキスト」を完全に一致させる**必要があります。こちらの同期出力もセットでお願いいたします。
※Googleの仕様上、URLのディレクトリ構造とパンくずの階層が不一致でも問題ありません。
おわりに
今回の実装を通じて、「URLを変えないパンくず階層化」は、SEOの都合とシステムの制約が密接に絡む施策だと実感しました。
だからこそ、単に依頼を投げて終わるのではなく、「なぜこのデータ形式が必要か（SEO視点）」と「どんな技術的制約があるか（エンジニア視点）」を、事前にお互いが理解し合うことが何より大切だとわかりました。