ECサイトのProduct構造化データとは？実装と検証の基本
目次
Product構造化データは、商品名、価格、在庫、評価などの意味を機械が理解しやすい形式で示すマークアップです。要件を満たす商品ページは、Google検索で価格や在庫などを含む表示の対象になる可能性があります。
構造化データを入れれば必ずリッチリザルトが表示されるわけではなく、順位向上を保証する施策でもありません。画面に表示している正確な商品情報を、同じデータから一貫して出力することが基本です。
Product構造化データの役割
構造化データは、ページの内容を分類し、各情報の関係を明示します。ECサイトの商品ページでは、ProductにOfferやAggregateRatingなどを組み合わせて商品情報を表現します。
Google検索での対応は、schema.orgに存在する語彙すべてではありません。実装時はGoogle Search Centralの対象機能、必須プロパティ、コンテンツガイドラインを確認します。
商品スニペットと販売者向けリスティング
直接購入できる商品ページでは、販売者向けリスティングに必要な情報を検討します。編集記事など購入できない商品紹介ページは、商品スニペットの要件が対象になります。
同じProductでもページの役割で必要情報が異なります。商品詳細テンプレートへ一律に貼る前に、購入可能ページ、レビュー記事、カテゴリ一覧を区別します。
画面上の情報と一致させる
構造化データの価格、通貨、在庫、商品名、画像、評価は、利用者がページで確認できる内容と一致させます。検索向けだけに別価格や高い評価を記載してはいけません。
セール開始・終了、在庫更新、会員価格、送料条件など、変化する値の更新経路を確認します。表示とマークアップを別システムで管理するとずれやすくなります。
商品識別子を管理する
sku、gtin、mpn、brandなど、実際に保有する商品識別情報を正確に出します。値がない場合に架空のコードを作ってはいけません。
商品マスタのどの項目を使うかを決め、重複や表記ゆれを確認します。構造化データ、商品フィード、画面表示で同じ商品を同じ識別子として扱えるようにします。
価格と在庫の更新
Offerでは価格、通貨、在庫状況、URLなどを扱います。ページがキャッシュされる場合、画面だけ新価格に変わりJSON-LDが古いままにならないようにします。
在庫が頻繁に変わる商品は、更新遅延を監視します。JavaScriptで構造化データを生成する場合も、レンダリング負荷や取得失敗を考慮し、可能なら初期HTMLへ正確な情報を出します。
レビューと評価
実際の顧客レビューや評価がある場合に、ReviewやAggregateRatingを使います。レビュー件数や評価値を作ったり、別商品の評価を流用したりしてはいけません。
画面で確認できるレビューとマークアップの集計が一致するようにします。削除や非公開レビューが評価計算へどう反映されるかも運用ルールに含めます。
商品バリエーション
色やサイズなどのバリエーションは、ProductGroupとProductを使って関係を示せます。各バリエーションには一意のskuやgtinなどを持たせ、直接選択できる固有URLを用意します。
一ページで切り替える方式と、バリエーションごとにページを持つ方式で実装が異なります。canonical、URL、選択状態、構造化データが同じ商品を指すようにします。
カテゴリページへ商品を大量にマークアップしない
Product構造化データの中心は個別商品ページです。カテゴリ一覧へ見えていない詳細情報を大量に埋め込むのではなく、ページの主目的と表示内容に合うマークアップを選びます。
パンくずリストなど、カテゴリページに適した構造化データは別にあります。種類を増やすことより、ページの内容を正しく表すことを優先します。
実装方法
JSON-LDはHTMLのscript要素で記述でき、テンプレートから生成しやすい方法です。MicrodataやRDFaを使う場合も、ページ表示と同じ情報を正確にマークアップします。
商品マスタから必須項目が欠けている場合は、空文字や仮値で埋めず、公開条件やエラー通知を設計します。テンプレート改修では複数の商品状態をテストします。
検証と監視
リッチリザルトテストでコードと対象機能のエラーを確認し、URL検査でGoogleが取得したページを見ます。数ページで検証してから、全商品へ段階的に展開します。
公開後はSearch Consoleの拡張レポートでエラーや警告の増減を確認します。仕様変更や商品マスタ変更で一斉に不整合が起きるため、定期監視が必要です。
よくある間違い
- 画面にない価格や評価を記載する
- 架空の商品識別子やレビューを作る
- 在庫更新が構造化データへ反映されない
- リッチリザルト表示を保証する
- テストせず全商品へ一括展開する
確認項目
- ページの役割に合うProductマークアップか
- 必須プロパティが正確に入っているか
- 画面、商品フィード、構造化データが一致するか
- 価格と在庫を同時に更新できるか
- バリエーションIDとURLが一意か
- テストとSearch Consoleで継続確認したか
商品マスタの項目を対応付ける
Productのname、image、description、sku、brand、Offerのprice、priceCurrency、availabilityなどを、商品マスタのどの項目から出すか決めます。表示用文字列と構造化データ用の値が異なる場合は変換ルールを明文化します。
在庫状態の名称が「販売中」「残りわずか」「取り寄せ」のように社内独自の場合、schema.orgのどの値へ対応させるかを決めます。判断できない状態を在庫ありへ寄せず、データ不備として検知します。
セール価格と会員価格の扱い
誰でも購入できる表示価格と、ログイン後だけの会員価格を区別します。構造化データへ記載する価格は、ページの利用者が確認でき、条件が正しく説明されている必要があります。
セール期間の開始・終了で、画面、Offer、商品フィードが同時に切り替わるかをテストします。終了後も古い価格やpriceValidUntilが残らないようにします。
テンプレート全体への展開手順
通常商品、セール、在庫切れ、予約、バリエーション、レビューなしの商品をサンプルにします。必須項目の欠落、値の型、URL、画像、価格の一致を確認します。
最初は限定した商品群へ公開し、リッチリザルトテストとSearch Consoleのレポートを確認します。エラーがなければ対象を広げ、商品マスタ変更時の回帰テストへ追加します。
警告とエラーを分ける
必須プロパティの欠落は対象機能への適格性に影響するエラーです。推奨プロパティの不足は警告として示される場合があります。警告をすべて機械的に埋めるのではなく、実際に保有し画面へ表示できる情報かを確認します。
架空のレビュー、未確認のGTIN、存在しない返品条件で警告を消してはいけません。正確なデータがない項目は、収集・表示の業務を整えてから追加します。
ECサイトでの実装例
通常価格5,000円、セール価格4,000円の商品では、画面に適用条件と現在価格を表示し、Offerにも同じ通貨と価格を出します。ログインした会員だけ4,000円になるなら、誰に見える価格かを整理し、検索向けだけに会員価格を出しません。
色バリエーションごとにURLを持つ商品では、アクセスした色のsku、画像、在庫、価格をProductとして出します。基本URLへcanonicalをまとめる単一ページ方式なら、ProductGroupとの関係と代表URLを一貫させます。
レビューが0件の商品では、AggregateRatingを空値や0点で生成しません。レビューが存在する商品だけ正確な件数と評価を出し、削除・非公開時に集計が再計算されることを確認します。
まとめ
Product構造化データは、商品情報の意味を検索エンジンへ明示する仕組みです。正しい実装により検索結果で豊かな表示の対象になり得ますが、表示は保証されません。
商品マスタを基準に、画面、構造化データ、商品フィードの値を一致させてください。少数ページで検証し、価格・在庫・バリエーションの更新まで含めて運用することが大切です。
