商品ページの構造化データ入門｜Product・Offerで伝えられる情報
目次
商品ページの構造化データは、商品名、価格、在庫、評価などの意味を検索エンジンへ明示するための記述です。画面上の商品情報を置き換えるものではなく、利用者に見える内容と同じ事実を、定められた形式でも伝える仕組みだと考えてください。
正しく実装された商品ページは、Google検索の商品スニペットや販売者向けの表示対象になり得ます。ただし、構造化データを追加すれば必ずリッチリザルトが表示されるわけではなく、検索順位や売上も保証されません。
構造化データとは
構造化データは、ページに書かれた情報の種類と関係を機械が理解しやすい形で示すデータです。商品ページではSchema.orgのProduct、Offer、AggregateRatingなどが使われます。Googleが対応するプロパティや表示要件は、公式ドキュメントで確認します。
実装形式にはJSON-LDなどがあります。どの形式でも、ページの主題と一致し、利用者が画面上で確認できる内容を記述することが重要です。コードが文法的に正しいだけでは、内容の品質まで保証されません。
Productで商品そのものを表す
Productは、ページが扱う商品を示します。商品名、画像、説明、ブランド、SKUやGTINなど、商品を識別する情報を関連付けます。すべての項目を無理に埋めるのではなく、実在し確認できるデータを使います。
SKUは店舗内の商品識別に使われ、GTINは国際的な商品識別番号です。両者を混同したり、存在しない番号を作ったりしないでください。商品マスタにある値が、画面表示や外部フィードと一致しているかも確認します。
Offerで販売条件を表す
Offerは、価格、通貨、在庫状況、販売URLなどの条件を示します。同じ商品でも、販売者や条件が違えばOfferの内容が変わります。価格や在庫は変動が大きいため、ページ表示と同じデータ源から更新できる設計が望まれます。
在庫切れなのにInStockが残る、セール終了後も旧価格が残る、といった不一致は避けなければなりません。キャッシュ、JavaScript、商品フィードなど複数経路で更新している場合は、反映時刻の差も確認します。
レビューと評価を扱う
実際の購入者や利用者によるレビューがあり、ページ上で内容を確認できる場合は、ReviewやAggregateRatingを検討できます。評価件数や平均値は、表示されているデータと一致させます。
存在しないレビューを作る、他サイトの評価を自社商品の評価として見せる、利用者に見えない評価だけをマークアップすることは避けます。構造化データは、見せたい数字を入力する欄ではありません。
商品スニペットと販売者向け表示の違い
Googleの商品構造化データには、商品スニペットと販売者向けの掲載に関係する要件があります。ページの目的や購入可否によって必要なプロパティが異なるため、単にProductを付ければよいとは限りません。
一般に、商品スニペットは個別の商品または同一商品のバリエーションに焦点を当てたページが対象です。複数の商品を一覧するカテゴリページへ、代表商品一つのProductを付けるような実装は、ページの主題と合いません。
画面上の情報と一致させる
構造化データに書いた商品名、価格、在庫、画像、評価は、利用者がページ上で確認できる内容と一致させます。コードにだけ「送料無料」と書き、画面では条件が分からない状態にしないでください。
バリエーションを選ぶと価格や在庫が変わる場合は、選択中のバリエーションと構造化データの関係を設計します。初期HTML、JavaScriptによる更新、URLごとの表示がどのように動くかを開発担当者と確認します。
バリエーション商品ではProductGroupを検討する
色、サイズ、素材などの違いを持つ商品では、ProductGroupとProductを使い、親商品と各バリエーションの関係を示す方法があります。Googleの対応プロパティにはvariesBy、hasVariant、productGroupIDなどがあります。
単一ページで選択する設計と、バリエーションごとに別URLを持つ設計では実装が異なります。各バリエーションへ直接アクセスしたときに、正しい画像、価格、在庫、選択状態を表示できるかも重要です。
実装前に商品データを確認する
構造化データの不具合は、コードより商品マスタの欠損から起きることがあります。ブランド名、SKU、価格、在庫、画像URLがどのシステムから来るのかを整理し、空欄や異常値を確認します。
- 価格に税の扱いが混在していないか
- 通貨コードが販売地域と一致しているか
- 在庫ステータスの変換ルールが正しいか
- 商品画像がクロール可能なURLか
- 販売終了商品が在庫ありとして残っていないか
テストしてから段階的に公開する
実装後はリッチリザルトテストで文法と対象機能を確認します。重大なエラーだけでなく、推奨項目の警告も商品データの不足を見つける材料になります。ただし、警告があるだけで必ず表示対象外になるとは限りません。
いきなり全商品へ展開せず、商品タイプの異なるページを選んで検証します。通常商品、セール商品、在庫切れ、バリエーション、予約商品など、更新条件の違うケースを含めると事故を見つけやすくなります。
Search Consoleで公開後を確認する
公開後はSearch Consoleの拡張レポートやURL検査を利用し、Googleが取得したページと検出された構造化データを確認します。修正を依頼しても、再クロールや再処理には時間がかかる場合があります。
エラー件数が減ったことだけを成果にせず、商品情報が最新か、対象URLが正しいかも確認してください。検索結果の表示はGoogleが判断するため、テストに合格しても常に同じ見え方になるわけではありません。
よくある間違い
- ページに表示していない情報を構造化データへ入れる
- 価格や在庫を手入力し、更新されない
- カテゴリ一覧へ個別商品のProductを付ける
- SKUとGTINを同じ値として扱う
- 架空のレビューや評価をマークアップする
- 全商品へ一括展開し、例外商品をテストしない
- 実装すれば必ずリッチリザルトが出ると考える
実務での導入手順
- 対象ページと表示したい商品情報を決める
- 商品マスタの項目と更新元を整理する
- Google公式の必須・推奨プロパティを確認する
- 代表ページへ実装してテストする
- 画面表示、構造化データ、商品フィードを照合する
- 例外条件を確認して段階的に展開する
- Search Consoleでエラーと検出状況を監視する
チェック項目
- ページの主題に合うタイプを選んでいるか
- 商品名、価格、在庫が画面と一致しているか
- 識別番号が正しい種類と値になっているか
- バリエーションの関係を説明できているか
- 更新時に構造化データも変わるか
- 代表的な商品状態をテストしたか
- 表示や順位を保証する説明をしていないか
更新責任と監視方法を決める
構造化データは、公開時に正しくても、価格改定、在庫切れ、レビュー削除、URL変更で古くなります。商品マスタのどの項目から生成し、どの頻度で更新されるかを明文化します。
エラー通知を受け取る担当者と、商品データを直す担当者が異なる場合は、連絡経路を決めます。コードの修正が必要なのか、商品マスタの値が誤っているのかを切り分けます。
商品フィードとの役割を整理する
構造化データとMerchant Centerなどの商品フィードは、どちらか一方だけを用意すれば常に十分という関係ではありません。更新経路、対象機能、扱う商品範囲を確認します。
両方を使う場合は、価格、在庫、URL、商品識別子の不一致を監視します。構造化データのテスト結果だけでなく、販売面で参照される各データ源を横断して確認してください。
まとめ
商品ページの構造化データは、ページにある商品情報の意味を検索エンジンへ伝える仕組みです。ProductやOfferを使う前に、商品マスタと画面表示を整え、価格や在庫が同じデータから更新される状態を作ります。
最初は代表商品へ実装し、テスト結果だけでなく画面との一致を確認してください。正しいデータを継続して保てる運用まで含めて設計することが、構造化データを活用するうえで重要です。
