はじめに：ECの商品ページは「検索に伝わる情報」と「人が買いやすい画面」の両方が必要
ECサイトの商品ページは、単に商品名・写真・価格を並べるだけでは成果につながりにくくなっています。検索エンジンには商品情報を正しく伝え、訪問者には迷わず比較・判断・購入できる画面を用意する必要があります。
特に重要なのが、Product構造化データと商品ページUI/UXの一体設計です。本稿では、ECサイトの商品ページにおけるProduct構造化データ、Google Merchant Center連携、PDPの情報設計、効果測定を横断して整理します。
Googleは、商品ページにProduct構造化データを追加することで、価格、在庫、レビュー評価、配送情報などの商品情報が検索結果でより豊かに表示される可能性があると説明しています。対象は通常検索だけでなく、Google画像検索やGoogle Lensなどにも広がります。
ただし、構造化データを入れれば必ず検索順位や売上が上がるわけではありません。Google自身も、リッチリザルトの表示は各検索体験の裁量によるもので、必ず表示されるものではないとしています。
だからこそ、構造化データは「検索エンジン向けの記述」、UI/UXは「購入者向けの体験」として分けて考えるのではなく、同じ商品情報基盤から整合的に設計することが大切です。
Product構造化データとは何か
Product構造化データとは、商品ページ内の商品名、画像、説明、ブランド、SKU、価格、通貨、在庫状況、レビュー、送料、返品条件などを、検索エンジンが理解しやすい形式で記述する仕組みです。
GoogleのProduct構造化データには、大きく分けて「Product snippets」と「Merchant listings」があります。Product snippetsは、直接購入できない商品紹介・レビュー系ページ向けの要素が中心です。一方、Merchant listingsは、ユーザーがそのページから商品を購入できるECサイト向けで、価格、在庫、配送、返品、サイズ情報などの商取引に近い情報を扱います。
ECサイトの商品詳細ページでは、基本的にMerchant listingsを意識した実装が重要です。検索結果やショッピング関連の表示面で、価格・在庫・配送・返品といった購入判断に関わる情報が扱われるためです。
商品ページに入れるべき基本プロパティ
Product構造化データでは、まず商品を一意に理解させる情報が重要です。商品名、商品画像、説明文、SKU、ブランド、GTINやMPNなどの商品識別子は、検索エンジンが「何の商品か」を判断するための土台になります。
次に重要なのがOffer情報です。Offerには、価格、通貨、在庫状況、販売ページURL、商品の状態などを含めます。GoogleのMerchant listingの例でも、priceCurrency、price、priceValidUntil、availability、itemConditionなどが示されています。
ここで注意したいのは、構造化データの内容と、実際にユーザーへ表示されている商品ページ上の情報を一致させることです。Google Merchant Centerのヘルプでは、構造化データはユーザーに表示される値と一致している必要があり、不正確な情報を提供することはガイドライン違反にあたると説明されています。
たとえば、ページ上では「在庫なし」と表示しているのに、構造化データではInStockになっている。セール終了後も構造化データ上の価格だけが古いまま残っている。このようなズレは、検索面での不整合だけでなく、ユーザーの不信感にもつながります。
Google Merchant Centerとの連携で重要になるデータ整合性
ECサイトでは、商品ページ、構造化データ、Google Merchant Centerの商品フィードを別々に管理しているケースがあります。この場合、価格・在庫・商品状態・送料などの情報がズレやすくなります。
Google Merchant Centerでは、schema.orgの構造化アノテーションを使うことで、GoogleがWebサイトから最新の商品情報を取得しやすくなり、商品データ更新やフィード作成の簡略化に役立つと説明されています。さらに、価格や在庫の不一致による不承認を防ぐため、自動商品アイテム更新にも構造化データが使われます。
ただし、自動更新に頼りきるのは危険です。Merchant Centerの公式説明でも、自動商品アイテム更新は通常の商品データ更新の代替ではないとされています。
実務では、以下のような運用が必要です。
- 商品マスタの価格・在庫を正とする
- 商品ページの表示情報を商品マスタと同期する
- JSON-LDの構造化データも同じ情報源から出力する
- Merchant Centerフィードとページ情報の差分を定期確認する
- セール、欠品、終売、再入荷時の更新フローを決めておく
構造化データは、SEO担当だけで完結する施策ではありません。商品登録、在庫管理、ECシステム、広告運用、制作チームが同じ商品情報を見て動ける状態をつくることが、安定運用の前提になります。
ProductGroupでバリエーション商品を正しく整理する
アパレル、家具、生活雑貨、タオル、化粧品などのECサイトでは、色違い、サイズ違い、素材違い、容量違いの商品が多く存在します。このとき、商品ごとにページを分けるのか、1つの商品ページ内で選択させるのかによって、構造化データの設計も変わります。
Googleは、サイズ、色、素材、パターンなどの違いを持つ商品群について、ProductGroupを使い、variesBy、hasVariant、productGroupIDなどのプロパティでバリエーションをまとめる方法を示しています。これにより、Googleが同じ親商品に属するバリエーションを理解しやすくなります。
たとえば、同じタオルシリーズで「フェイスタオル」「バスタオル」「カラー違い」「ギフトセット」がある場合、すべてを無関係な商品として扱うと、検索エンジンにもユーザーにも関係性が伝わりにくくなります。
実務上は、以下の整理が有効です。
- 親商品：シリーズ名、ブランド、共通説明、共通レビュー
- 子商品：サイズ、色、価格、在庫、SKU、商品画像
- UI上の選択肢：色・サイズ・セット内容を明確に表示
- URL設計：1ページ型か個別URL型かを事前に決める
- canonical設計：重複ページにならないよう管理する
バリエーション管理は、検索エンジン対策であると同時に、ユーザーの比較負担を減らすUI改善でもあります。
送料・返品ポリシーは検索と購入判断の両方に効く
ECサイトの商品ページでは、送料、配送日数、返品条件、交換可否、返送料の負担などが購入直前の不安要素になります。商品そのものに魅力があっても、「いつ届くのか」「返品できるのか」「追加費用はいくらか」が分かりにくいと、購入をためらう可能性があります。
Googleは、MerchantReturnPolicyを使うことで、返品ポリシーのURLや返品条件、返品方法、返品手数料、返金方法などを指定できると説明しています。また、標準的な返品ポリシーはOrganization配下に設定し、商品ごとに異なる場合はOffer配下で個別指定できるとされています。
この考え方はUIにもそのまま応用できます。すべての商品ページに長い返品規約を載せる必要はありませんが、購入ボタン付近には最低限の安心材料を置くべきです。
たとえば、次のような表示が有効です。
- 〇円以上で送料無料
- 最短〇営業日で発送
- 未使用品は到着後〇日以内返品可
- ギフト配送対応
- 返品・交換条件はこちら
検索エンジンに伝える情報と、ユーザーに見せる情報が一致していることが重要です。構造化データだけ整えても、画面上で分かりにくければ購入不安は残ります。
商品ページUI/UXで改善すべきポイント
商品ページのUI/UXでは、ユーザーが「見つける」「理解する」「比較する」「不安を解消する」「購入する」までの流れを妨げない設計が求められます。
Baymard Instituteの2026年版の商品ページUX調査では、主要ECサイトでも商品ページUXに改善余地が多く、デスクトップの52%、モバイルの62%、アプリの64%が「mediocre or worse」とされています。商品ページは購入判断の中心であり、解決可能なUX課題によって適切な商品が離脱されるケースもあると説明されています。
特に見直したいのは、以下の領域です。
ファーストビューで購入判断の核を見せる
商品ページの上部では、商品名、メイン画像、価格、在庫、購入ボタン、主要な特徴、配送・返品の要点をすぐ確認できるようにします。写真だけが大きく、価格や在庫がスクロールしないと見えない構成は、購入検討のスピードを落とします。
商品説明は長くても構いませんが、最初に「この商品は何が良いのか」を短く伝える必要があります。素材、用途、対象者、他商品との違いを、箇条書きや短い見出しで整理すると理解されやすくなります。
バリエーション選択は迷わせない
サイズや色を選ぶUIは、購入直前の重要な接点です。Baymardは、サイズ選択をドロップダウン内に隠すと、在庫の有無が見えにくくなり、ユーザーが無駄な操作をする原因になると指摘しています。
タオルやアパレルのようにサイズ・色・セット違いがある商品では、選択肢をボタンや色チップで見せ、在庫なしのものは最初から分かるようにすることが望ましいです。
商品画像は「質感」「サイズ感」「使用シーン」を補う
ECでは実物を触れません。だからこそ、画像は単なる見た目ではなく、購入前の疑問を減らす情報として設計します。
生活雑貨やタオルなら、単品の白背景画像だけでなく、手に持った時の厚み、洗面所での使用シーン、ギフト包装、カラーバリエーション、吸水・速乾などの特徴を伝えるビジュアルが有効です。
画像と構造化データのimage指定も整合させ、代表画像だけでなく、検索結果に出ても商品内容が伝わる画像を選ぶことが重要です。
レビューは点数だけでなく判断材料にする
レビューは、単に星の数を表示するだけでは不十分です。購入者が知りたいのは、「自分の用途に合うか」です。
たとえば、肌触り、吸水性、洗濯後の状態、ギフト利用、色味、サイズ感など、商品ごとに重要な観点を整理すると、レビューは強い購入支援コンテンツになります。構造化データでレビュー評価を扱う場合も、ページ上に実際に表示されているレビュー情報と一致させる必要があります。
実装時のチェックリスト
Product構造化データとUI/UXを同時に改善する場合、次の順番で進めると実務に落とし込みやすくなります。
- 商品マスタを整理する
商品名、ブランド、SKU、JAN・GTIN、価格、在庫、画像、サイズ、色、素材、送料、返品条件を確認します。 - 商品ページ上の表示を確認する
ユーザーが見る価格、在庫、送料、返品条件、レビュー、バリエーションが最新かどうかを確認します。 - JSON-LDを実装する
Product、Offer、AggregateRating、Review、ProductGroup、MerchantReturnPolicyなど、商品特性に応じて必要な項目を設計します。 - Merchant Centerと突合する
フィード情報と商品ページ、構造化データの差分を確認します。 - Rich Results TestとSearch Consoleで検証する
重大なエラーを優先して修正し、警告は改善余地として管理します。Googleは、構造化データの追加後にRich Results Testで検証し、URL検査ツールでGoogleからの見え方を確認する流れを推奨しています。 - UI上の購入導線を見直す
購入ボタン、バリエーション選択、配送・返品表示、レビュー、関連商品、FAQ、ギフト対応などを確認します。
効果測定はCTRとCVRを分けて見る
Product構造化データと商品ページUI/UXの改善効果は、分けて確認する必要があります。
検索面では、Search Consoleで表示回数、クリック数、CTR、検索クエリ、リッチリザルトの状況を確認します。商品ページ側では、GA4などで商品詳細ページの閲覧数、カート追加率、購入率、離脱率、スクロール、クリックイベントを確認します。
ここで大事なのは、「検索結果でクリックされるようになったか」と「ページに来た人が買いやすくなったか」を混同しないことです。構造化データの改善はCTRや検索露出に影響する可能性があり、UI/UXの改善はカート追加や購入率に影響する可能性があります。両方を分けて観測することで、次に直すべき場所が見えます。
まとめ：商品ページ改善はデータ整備と体験設計の統合で進める
ECサイトの商品ページ改善では、Product構造化データだけを入れても不十分です。検索エンジンに商品情報を正しく伝えることと、ユーザーが安心して購入できる画面をつくることは、同じ商品情報を使った一体の取り組みです。
価格、在庫、送料、返品、レビュー、バリエーション、画像、商品説明が、商品ページ・構造化データ・Merchant Centerで一致していること。さらに、その情報がユーザーに分かりやすく表示されていること。この2つがそろって、検索露出とCV改善の土台になります。
次に取り組むべきは、単なるSchema追加ではなく、商品マスタ、ECシステム、Merchant Center、Search Console、GA4をつないだ運用設計です。商品ページを「売るための画面」から「検索エンジンと購入者の両方に伝わる情報基盤」へ進化させることが、これからのEC改善の中心になります。
コメント