商品ページの構造化データで外してはいけない設計 2026年版の基準

商品ページの構造化データが失敗する現場には、共通した崩れ方があります。公開直後は `Product` や `Offer` が正しく見えていても、二週間後にはセール価格だけ古いまま残る。色違いURLが大量に残り、`canonical` は親ページを指しているのに、構造化データでは子SKUの価格を返している。返品条件は共通ポリシーの改定後に追従せず、レビューはブランド全体の平均点を個別商品へ流し込んでしまう。こうした事故は、JSON-LD の書き方そのものより、検索に残すURLと残さないURLの判断が先に固まっていないことから起こります。

先に結論を示します。商品ページの構造化データは、記法より先にページ設計を決めるべき施策です。 Google: e コマースの SEO と Google: URL 構造のガイドライン を見ると、ECではURL、商品情報、内部リンク、クロール設計が一体であることがよく分かります。構造化データは、その最後に載せる整理済みの信号です。JSON-LD の基本を先に確認したい場合は、JSON-LDの書き方を実務で整理 ツールを使って安全に実装する基本手順 を読んでから戻るほうが理解しやすくなります。

商品URLの残し方を先に決める理由と基準

商品ページで最初に決めるべきなのは、検索意図と販売条件が独立しているURLだけを残す設計です。理由は明快で、構造化データはURL単位で解釈されるからです。同じ商品の色違い、サイズ違い、販促用パラメータ付きURL、在庫切れの派生URLを無秩序に残したままでは、どれだけ丁寧に `Product` を書いても信号が分散します。特に中小規模ECで起こりやすいのが、「ひな型で付与できるから、すべてのURLに入れる」という判断です。これは避けてください。

残すURLと寄せるURLを三分類で決める

Google: 重複 URL の統合 と Google: 重複した URL の正規化 に沿って考えるなら、商品URLは次の三分類で管理するとぶれにくくなります。

• 残すURL: 型番、容量、セット数、用途違いなどで検索意図が分かれ、価格や在庫も独立している商品。こうしたURLは個別に残します。
• 寄せるURL: 色違い、軽微なサイズ違い、同一内容のキャンペーン違いなど、代表ページの選択肢として説明できる商品。代表URLへ寄せます。
• 終了するURL: 廃番、旧キャンペーン、再販予定のない販売終了ページ。惰性で残さず、Google: 301 リダイレクトの使い方 や Google: HTTP ステータス コード に沿って整理します。

ここで大切なのは、`canonical` を設計の代用品にしないことです。代表URLへ寄せるなら、価格、在庫、画像、レビューも代表ページに集約されていなければ意味がありません。`canonical` だけ親URLへ向け、本文や構造化データは子SKUのまま残す運用では、検索エンジンにもユーザーにも説明がつきません。

月間PVと検索需要で線を引く基準

「状況による」で終わらせると、担当者ごとに判断が割れます。実務では、次の数字で線を引くと迷いにくくなります。

• 90日間でSearch Consoleの表示回数が50未満、クリックが10未満の派生URLは、原則として代表URLへ寄せる。
• 価格差が5%未満で、説明文も画像もほぼ同じなら、色違いURLは個別に残さない。
• 型番や容量違いで検索需要が分かれ、月20クリック以上見込める商品群は個別URLを残す。
• 月間PV10万未満のECで、色違いURLが300本超になったら、目視運用だけで整合性を保つのは難しいと考える。

この基準なら、アパレルや雑貨の色違いをむやみに残さずに済みます。一方で、家電、工具、業務用品のように型番検索が強い商材では、個別URLを残すべき商品を切り分けやすくなります。中小規模ECが最初に選ぶべきなのは、全部残す設計でも全部畳む設計でもなく、検索意図が分かれる軸だけを残す設計です。

移行時はURL以外も同時に直す手順

URL整理で抜けやすいのが移行作業です。派生URLを代表URLへ寄せると決めても、旧URLの内部リンク、パンくず、サイトマップ、関連商品リンク、構造化データの `url` が古いままでは、整理したことになりません。Google: URL 変更を伴うサイト移行 でも、URL変更は周辺信号を同時に揃える前提で説明されています。

実務では、次の順番を崩さないほうが安全です。

1. 残すURL、寄せるURL、終了URLを一覧化する。
2. 旧URLの内部リンクとサイトマップを新方針に揃える。
3. リダイレクト、`canonical`、構造化データの `url` を同時に切り替える。
4. 公開後に主要商品20URLでクロールと表示を確認する。

構造化データだけ先に更新し、URL移行はあとで行う順番は避けるべきです。運用現場では、この順番の乱れがもっとも長引く障害になります。商品ページSEOの土台から見直したいなら、ECサイト商品ページSEOの実務基準 商品情報と構造設計で評価を積み上げる も合わせて読むと、URL設計と商品情報のつながりが見えやすくなります。

価格と在庫の正本を一つに絞るべき理由と判断軸

URLの次に決めるべきなのは、どのデータを正本として画面表示と構造化データへ流すかです。ここが曖昧なまま項目を増やすと、ほぼ確実に事故が起きます。価格は販売システム、在庫は在庫API、説明文はCMS、返品条件は別の管理表、レビュー件数は外部タグ。こうした分散自体は珍しくありません。問題は、最終的にページへ出す直前に、一つの「公開用データ」として束ねていないことです。

画面表示とJSON-LDを別更新にしない

強く勧めたいのは、価格と在庫を一度正規化し、その同じデータからHTMLとJSON-LDを同時に出力する方式です。HTMLは即時更新、構造化データは夜間バッチ、レビュー件数だけ朝に更新するといった分離運用は避けてください。販促期は、一日に2回以上価格が変わる商品も珍しくありません。更新経路が複数あるだけで、数時間の不整合は簡単に起きます。

Google: e コマースの SEO と Google: モバイル ファースト インデックスのベスト プラクティス を商品ページの視点で読むと、検索エンジンが見たいのは、ユーザーがその場で確認できる正しい価格と在庫です。本文にない価格や、カートに入れた瞬間だけ変わる条件を、構造化データへ先回りして書くべきではありません。

実務では、次の更新順序を固定してください。

1. 販売システムまたはCMSで正本データを更新する。
2. 正規化レイヤーで公開可否を判定する。
3. HTMLと構造化データを同じタイミングで再生成する。
4. キャッシュ反映後に代表URLを再検証する。

この流れを守れないなら、セール価格や配送条件のように更新頻度が高い項目は、最初から出さないほうが安全です。

正本管理で決める責任範囲と承認者

もう一つ重要なのは、責任の置き方です。価格は販売部門、在庫は基幹システム、返品条件はCS、配送条件は物流、レビューはレビュー基盤。この分担は自然ですが、構造化データ全体の整合性責任者を空席にしてはいけません。誰も最後に確認しない設計では、最終的にSEO担当へ障害が集まり、修正は他部門待ちで止まります。

責任分界は、次の形で仕様に残す必要があります。

• 正本データの所在
• 更新頻度
• 異常時の停止条件
• 公開可否の最終承認者

この整理ができていないなら、Schema.org の型を細かく増やす前に、データ契約を固めるほうが先です。型の選び方そのものを整理したい場合は、Schema.orgマークアップの最新トレンド Google対応と実務設計のずれを埋める が参考になります。JPSM SEOの支援価値も、実装代行より、こうした判断基準をチーム内で固定できる点にあります。

バリエーションを残す条件は数字で決めるべき

バリエーション設計では、代表URLへ集約し、残す派生URLだけを数字で選別する方式を勧めます。全SKUを一律でインデックス対象にする設計は、監視と検証の仕組みがかなり強くない限り勧めません。理由は三つあります。価格と在庫の監視点が増えること、`canonical` と内部リンクの整合確認が難しくなること、検索意図が同じURLが増えて商品群全体の評価が薄まりやすいことです。

比較表で見る代表URLと個別URLの違い

次の比較表を最初にチームで共有すると、議論がかなり整理しやすくなります。

現場で一番危ないのは、代表URLと個別URLを混在させているのに、残す基準が担当者の感覚に依存している状態です。これでは半年後に誰もルールを説明できなくなります。

個別URLを残す商品の見極め方と実例

実務では、次の基準で判断するとぶれにくくなります。

• 90日間で表示50未満、クリック10未満の派生URLは原則として代表URLへ寄せる。
• 価格差が10%以上あり、容量やセット内容も異なるなら個別URLを残す価値がある。
• バリエーション軸が3つ以上ある商品群では、全組み合わせURLを残さない。売上上位10〜20%だけを候補にする。
• 月間PVが30万超のサイトで、ブラウザ側の操作に応じて価格と在庫を書き換える設計は、再現性が低いので避ける。

ここでも例外はあります。家電、工具、産業資材のように型番検索が強い商材は、SKUごとの差分を本文でも明確に出せるなら個別URLを残すべきです。逆に、アパレルや雑貨で色違いしか差がないのに個別URLを乱立させるのは避けてください。検索意図が分かれない商品をSKU単位で量産しても、運用コストばかり増えます。

代表URLへ集約する場合は、初期表示の状態も固定してください。初期表示の商品名、価格、画像、在庫が3秒以内に理解できないページは、構造化データ側でもぶれます。ユーザー操作後の状態まで即時反映しようとしてブラウザ側で値を差し替えると、HTML、キャッシュ、構造化データ、購入導線の四か所で整合性を取る必要が出てきます。ここは割り切ったほうが安全です。

出す項目より止める条件を先に書くべき設計

商品ページの構造化データでよくある誤解は、「項目を多く埋めるほど強い」という考え方です。2026年に優先すべきなのは量ではなく信頼性です。最初に安定させるべき核は、商品名、画像、説明、SKU、価格、在庫、販売URLです。レビュー、返品条件、配送条件はその後で十分です。欠けたときに止められない項目は、最初から出さないほうが成果につながります。

先に止める四項目の判断基準を決める

特に先に停止条件を決めるべきなのは、次の四項目です。

• レビュー: ページ上で確認できる同一SKUのレビューでないなら出さない。ブランド全体の平均評価を個別商品へ流し込むのは避けるべきです。
• 返品条件: 商品ごとの例外が多いなら一律で出さない。例外率が20%超の商材は、まず本文整備を優先するべきです。
• 配送条件: 地域差や会員条件が頻繁に変わるなら、更新責任者が固定されるまで出さない。
• セール価格: 開始時刻と終了時刻を同じ系統で管理できず、反映遅延が15分超になるなら出さない。

この判断は厳しく見えるかもしれませんが、現場ではこちらのほうが長く持ちます。セール価格だけ旧値が残る、レビュー件数が0なのに評価点だけ残る、返品条件が本文と合わない。こうした事故は、追加した項目が多いサイトほど起きやすいからです。

停止条件は本体情報と補助情報で分ける

停止条件を曖昧にすると、障害時に担当者ごとの判断が割れます。ここで勧めたいのは、商品本体の情報が欠けたら全体を止め、補助情報だけが欠けたらその項目だけ止める方式です。

• 商品名、価格、在庫、販売URLのどれかが欠けたら、商品構造化データ全体を止める。
• レビュー、返品条件、配送条件のどれかが欠けても、本体情報が正しければその項目だけ省略する。
• 価格と在庫の同期遅延が30分超になったら、自動監視で公開継続の可否を判定する。

この線引きがあると、障害時の対応が速くなります。逆に、すべての項目を同じ重さで扱う設計は避けるべきです。補助情報まで全停止対象にすると、軽微な障害で商品本体まで消えてしまいます。商品本体と補助情報の扱いを分けておくことが、運用の安定につながります。

公開後一か月で差がつく監視の進め方と基準

商品ページの構造化データは、公開直後よりも公開一か月後に差が出ます。文法確認より、公開後の例外監視に工数を多めに割くべきです。Rich Results Test を通過したことは出発点にすぎません。壊れやすいのは、価格改定、在庫変動、レビュー連携、返品条件改定が重なる公開後です。

よくある崩れ方と直し方を先に共有する

実務で多い崩れ方は、次の五つです。

• 親URLへ `canonical` を向けたまま、子URLには子SKUの価格を出している

対処: 代表URLへ寄せるなら、価格も在庫も代表側へ統一する。残す子URLだけ個別値を持たせる。

• セール終了後に通常価格へ戻る前に、構造化データだけ旧価格が残る

対処: 価格更新と再生成を同時に走らせ、反映遅延が15分を超える構成を見直す。

• 在庫切れ商品を `200` のまま長期間放置し、代替導線も出していない

対処: 再入荷予定の有無で「維持」「代替へ誘導」「終了」の三択を明文化する。

• レビュー基盤の障害で件数が0になったのに、平均点だけ残る

対処: 件数と評価値を同時検証し、片方だけ欠けたらレビュー出力を止める。

• モバイル初期表示では重要情報が見えず、選択後にしか価格や在庫が分からない

対処: 初期表示で主情報が確認できる構成へ戻す。モバイルで見えない情報は、構造化データでも出しすぎない。

この五つは、技術的に書けるかどうかではなく、運用変化に耐えられるかどうかで決まります。SKUが500件を超えたら、担当者の注意力だけで防ぐのは無理があります。監視の仕組みが必要です。

監視対象の選び方にも順番があります。売上上位URLだけを見ると、障害の種類が偏ります。売上上位、流入上位、値引き頻度が高い商品、在庫切れになりやすい商品、レビュー連携のある商品を混ぜて20〜30URLを選ぶほうが、異常を早く拾えます。毎日全商品を再検証するより、崩れやすい条件を含んだ固定サンプルを回すほうが、少ない工数で再現性の高い監視になります。

公開前後に確認する七つの実務項目

監視は大がかりでなくても構いません。まずは主要カテゴリから20〜30URLを固定監視対象にし、次の項目だけでも毎週確認してください。

• 代表URL、派生URL、終了URLの三分類が文書化されているか。
• HTMLと構造化データが同じ正規化データを参照しているか。
• 値引き商品、在庫切れ商品、画像欠損商品、レビュー未取得商品の四つを公開環境で確認したか。
• 90日無クリックの派生URL本数を把握しているか。
• 価格不一致、在庫欠損、レビュー欠損の件数が前週比で増えていないか。
• セール開始時と終了時の反映時間を同じ手順で再確認できるか。
• 返品条件と配送条件の更新責任者が明文化されているか。

月次棚卸しだけに頼る運用では遅すぎます。少なくとも週次で異常件数を見る必要があります。価格不一致は販売部門、在庫欠損は在庫基盤、返品条件はCSや法務、レビュー欠損はレビュー基盤といった返し先まで先に決めておけば、修正の初動が速くなります。

サイト規模別に優先順位を変える設計判断の基準

すべてのECに同じ設計を当てはめるべきではありません。ただし、規模に応じた優先順位はかなり明確です。ここは「状況による」で逃げず、最初の一手を決めたほうがよいです。

月間PV10万未満・SKU500未満

最初にやるべきことは、代表URLの整理と最小構成の安定化です。推奨するのは、商品名、価格、在庫、主要画像、SKUだけを確実に保つ設計です。色違いURLを大量に残すより、売れ筋上位20〜30商品の代表ページを先に固めるべきです。

例外はあります。型番検索が強く、月20クリック以上見込める商品群だけは個別URLを残して構いません。ただし、その場合でも価格と在庫の正本を一本化できないなら見送るべきです。返品条件、配送条件、レビュー集計まで一気に自動化しようとするのは避けてください。開発工数の割に事故点が増えます。

月間PV10万〜100万の中規模帯

この帯域で最初に入れるべきなのは、URL分類の自動ルールと監視です。検索需要がある派生URLだけを残し、90日無クリックの派生URLを定期点検する運用へ切り替えるべきです。カテゴリ特性が違うなら、家電は個別URL中心、アパレルは代表URL中心のように分けたほうが成果が出ます。

例外として、返品条件や配送条件がカテゴリごとに大きく違うなら、商品構造化データの拡張より本文と案内導線の見直しを先に行うべきです。売上の7割を占める主要カテゴリが2〜3個に絞れるなら、そのカテゴリだけ基準を厳しくするほうが現実的です。

月間PV100万以上・SKU2万超

ここまで来たら、手作業前提の確認をやめ、ひな型単位で監視するべきです。価格不一致率、在庫欠損率、レビュー欠損率を日次で見る仕組みを先に作るほうが、個別商品の場当たり対応よりはるかに効きます。

例外は、法規制や商材特性で返品・配送条件が大きく分かれるカテゴリです。その場合は全体共通ルールではなく、カテゴリ別の正本設計を採ったほうが安全です。ただし、大規模サイトでも全SKUを個別URLで持つ必要はありません。検索需要と売上寄与の高いディレクトリから順に整備するべきです。

海外向けと地域別配送がある場合

この場合、最初に決めるべきなのは商品情報よりURL体系と地域の切り分けです。Google: 多言語サイトの管理 と Google: 複数地域向けサイトの管理 に沿って、言語違いと地域違いをURLで整理してから構造化データへ入るべきです。

送料や返品条件が国ごとに違うのに、一つの代表URLへ全部載せる設計は避けてください。海外売上が全体の10%未満で、翻訳ページも少数なら、地域分岐より国内商品情報の整合性を先に固めるほうがよいです。逆に、特定一国の売上が全体の30%を超え、現地運用チームもあるなら、地域別の独立運用を前提に設計したほうが安全です。

最後に今週着手する順番を実務向けに固める

ここまで読んで判断軸が見えたなら、今週やるべきことは多くありません。大事なのは、構造化データのコードを書く前に、残すURLと止める項目を決めることです。次の順番で進めると、二週間から四週間で基準線を作れます。

1. 主要カテゴリから20〜30URLを抜き出し、残すURL、寄せるURL、終了URLに分類する。
2. 価格、在庫、レビュー、返品条件、配送条件の正本がどこにあるかを一枚で整理する。
3. 90日無クリックの派生URL本数と、在庫切れのまま残っている商品本数を把握する。
4. 値引き商品、在庫切れ商品、レビュー未取得商品を代表ケースとして公開環境で再検証する。
5. 監視対象を「価格不一致」「在庫欠損」「レビュー欠損」の三つに絞り、週次で回し始める。
6. 項目追加はそのあとに行い、止められない項目は出さないという原則を仕様に書く。

この順番を飛ばして、型の追加や細かなプロパティ実装から始めると、あとでURL設計とデータ契約をやり直すことになります。商品ページの構造化データで成果を出したいなら、最初の一歩は派手な拡張ではありません。今週中に主要商品20URLを三分類し、価格と在庫の正本を一枚で整理することです。そこまで終われば、次に何を追加し、何を止めるべきかがぶれなくなります。レビューや返品条件を広げる判断も、そのあとなら無理なく進められます。