ECの構造化データ実装ガイド2026｜Product・Offerで検索結果を強くする

結論から書きます。ECの構造化データで最初に決めるのは「そのページで商品を買えるかどうか」です。Googleの公式ドキュメントは、商品の構造化データが生む見え方を「プロダクト スニペット」（購入できないページ向け）と「マーチャント リスティング」（自社で購入できるページ向け）の2つに分けています。自社ECの商品ページは後者です。だから狙うのはマーチャント リスティングの必須項目で、プロダクト スニペットの要件は結果としてほぼ満たします。

本記事の要点を先に並べます。

1. 必須は5つだけ。Productのname・image・offers、Offerのprice・priceCurrency。これが揃えば「表示される資格」を得ます（第3章）
2. 推奨プロパティで差がつく。availability（在庫）・itemCondition（状態）・sku／gtin（識別子）・送料・返品ポリシーまで入れると、検索結果に出せる情報が増えます（第4〜5章）
3. 色・サイズ違いはProductGroupで束ねる。親にvariesBy、子にskuとisVariantOf（またはhasVariant）。URLの持たせ方は1ページ型と複数ページ型で違います（第6〜7章）
4. パンくずはBreadcrumbListで別に入れる。最後の項目はitemを省略できます（第8章）
5. 価格・在庫・有効期限を手で入れない。カートの商品データからテンプレートで自動生成し、リッチリザルト テストとSearch Consoleで検証します（第9章）

先に注意を一つ。Googleは、正しくマークアップしてもリッチリザルトの表示を保証していません。構造化データを入れても順位が上がるわけでもありません。本記事で言えるのは「表示される資格を得る」「検索結果に価格や在庫が出れば、クリック率に影響し得る」までです。順位そのものの話は検索順位が上がらない15の原因で扱っています。

Googleの公式ドキュメント「Product 構造化データ」（2026年11月時点）は、商品の構造化データの用途を2つに分けて説明しています。自社ECの担当者が混乱しやすいのはここなので、最初に整理します。

両者は重なっています。公式ドキュメントでは、マーチャント リスティングの必須項目を入れたページは、プロダクト スニペットの対象にもなり得るとされています。つまり自社ECの商品ページは、マーチャント リスティングの要件を満たしておけば両方の資格を得られます。

マーチャント リスティングの前提条件（公式ドキュメントより）

• 購入できるページだけが対象。カテゴリ一覧や「販売終了」ページは対象外です
• 価格は0円より大きいこと。無料サンプルや価格未定の商品は対象になりません
• 通貨ごとにURLを分けること。1つのURLで円とドルを切り替える構成は推奨されていません
• 画像はクロール・インデックスできること。robots.txtで画像フォルダを止めていると表示されません。推奨の縦横比は16:9・4:3・1:1です
• 対象外の商材がある。銃器、娯楽目的の薬物、タバコ・電子タバコ、ギャンブル関連は対象外と明記されています

Merchant Centerのフィードと「併用」が推奨されている

もう一つ重要な点があります。公式ドキュメントは、ページ上の構造化データとMerchant Center（Googleに商品データを登録する無料の管理画面）のフィードを併用することを推奨しています。Merchant Centerに登録しているから構造化データは不要、という理解は逆です。Merchant Centerの商品データとページ上の構造化データが一致していると、Google側が商品ページを確認しやすくなります。

私の経験則として、Merchant Centerを使っていないEC（小規模な自社ECの多くがそうです）ほど、ページ上の構造化データが商品情報をGoogleに渡す唯一の手段になります。ここを整えないまま広告やSNSに予算を回しても、検索結果の商品表示には乗りません。

マーチャント リスティングの必須プロパティは、公式ドキュメント（2026年11月時点）ではProductに3つ、Offerに2つです。まずこの5つだけで動く最小構成を作り、動いたことを確認してから推奨プロパティを足します。最初から全部入れようとすると、どこでエラーになったか分からなくなります。

最小構成のJSON-LD（必須のみ）

JSON-LD（HTMLの中にscriptタグで埋め込む構造化データの書き方。Googleが推奨している形式）で書くと、必須のみの最小構成は次の通りです。商品名・価格・画像URLをご自身のものに置き換えてください。

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "本革ビジネスシューズ ストレートチップ ブラック",
  "image": [
    "https://example.com/photos/1x1/shoes-black.jpg",
    "https://example.com/photos/4x3/shoes-black.jpg",
    "https://example.com/photos/16x9/shoes-black.jpg"
  ],
  "offers": {
    "@type": "Offer",
    "price": 19800,
    "priceCurrency": "JPY"
  }
}
</script>

必須項目で止まりやすい3つのミス

• offersをAggregateOfferにしてしまう。「最安〜最高」の価格帯を書きたくなりますが、マーチャント リスティングでは対象外です。商品ページでは単一のOfferにします
• priceに「19,800円」と書く。数値（19800）だけにします。通貨はpriceCurrencyで別に渡します
• imageがカートの管理画面URLやCDNの一時URLになっている。公開されていてクロールできる固定URLにします

カートによっては、この最小構成を商品テンプレートが自動で出力します。ただし「どこまで自動で出るか」はカートとテーマごとに違い、今回Shopify・BASEの公式ヘルプで出力範囲を確認できませんでした。確実なのは、ご自身の商品ページのソースを開いて「application/ld+json」を検索することです。出ていれば中身を本章の表と照らし、出ていなければテーマに追加します。カート選びの段階で確認したい方はShopify・BASE・STORES徹底比較も合わせてご覧ください。

必須の5つで資格は得られますが、検索結果に出せる情報は限られます。推奨プロパティを足すと、在庫の有無や商品の識別子など、Googleが商品を正しく理解するための材料が増えます。公式ドキュメント（2026年11月時点）の推奨プロパティを、Offer側とProduct側に分けて示します。

Offer側の推奨プロパティ

Product側の推奨プロパティ

全部入れない。入れる順番を決める

ここが実務で一番大事な判断です。商品数が数百〜数千あるサイトで「全商品に推奨プロパティを全部」は現実的ではありません。私の経験則として、順番は次の通りです。

1. availability・sku・brand・description・urlを全商品に。これらはカートの商品データに標準で入っているので、テンプレートで自動出力できます
2. gtinはJANコードを持つ商品だけに。持たない商品に空欄やダミーを入れない
3. priceValidUntilは、カートが価格変更に連動して自動で更新できる場合だけ入れる。手で入れると過去日のまま残り、表示が止まります
4. 送料・返品ポリシーは全商品共通なら1回の設定で済むので、第5章の方法で入れる

前職のECでは、priceValidUntilを手で入れていた時期があり、価格改定のたびに古い有効期限が残って検索結果の価格表示が消える、という事故を起こしました。この経験から、値が変わるプロパティは、カートの商品データから自動で生成できるものだけ入れると線引きしています。売上上位の型番から順に入れ、効果を確認してから対象を広げる進め方が、運用として続きました。

送料と返品ポリシーは、Offerの推奨プロパティの中でも中身が深いので章を分けます。この2つはお客様が購入を決める直前に見る情報で、検索結果に出せれば「送料がいくらか分からないからクリックしない」という離脱を減らせる可能性があります。公式ドキュメント「マーチャント リスティングの構造化データ」（2026年11月時点）の必須・推奨は次の通りです。

shippingDetails（OfferShippingDetails）の必須・推奨

hasMerchantReturnPolicy（MerchantReturnPolicy）の必須・推奨

Offerに入れ子にした書き方（日本国内・送料660円・14日返品の例）

"offers": {
  "@type": "Offer",
  "price": 19800,
  "priceCurrency": "JPY",
  "availability": "https://schema.org/InStock",
  "itemCondition": "https://schema.org/NewCondition",
  "url": "https://example.com/products/shoes-black",
  "shippingDetails": {
    "@type": "OfferShippingDetails",
    "shippingRate": { "@type": "MonetaryAmount", "value": 660, "currency": "JPY" },
    "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "JP" },
    "deliveryTime": {
      "@type": "ShippingDeliveryTime",
      "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
      "transitTime": { "@type": "QuantitativeValue", "minValue": 1, "maxValue": 3, "unitCode": "DAY" }
    }
  },
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "applicableCountry": "JP",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 14,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn"
  }
}

送料・返品は「構造化データ以外」でも渡せる。優先順位がある

ここを知らずに実装して混乱するケースが多いです。公式ドキュメントは、送料と返品ポリシーの情報源が複数あるときの優先順位を次のように定めています（強い順）。

1. 商品単位のMerchant Centerフィード
2. Content APIの設定
3. Merchant CenterまたはSearch Consoleの設定（送料・返品の設定画面）
4. 商品単位の構造化データ（Offerに入れ子にしたもの）
5. 組織単位の構造化データ（Organizationに入れ子にしたもの）

実務での判断はこうなります。全商品で送料・返品の条件が同じなら、Search Consoleの設定か組織単位の構造化データで1回入れれば済みます。商品ごとに送料が違う（大型商品・冷蔵便など）なら、その商品だけOfferに入れ子で上書きします。両方入れたときは上の順位が勝つので、「設定画面とページの値が食い違って検索結果に古い送料が出る」事故は、この優先順位を知っていれば防げます。送料の設計そのもの（無料ラインの決め方）は、別記事で扱う予定です。

アパレルや雑貨の自社ECで一番詰まるのが、色違い・サイズ違いの扱いです。Googleは2024年2月から商品バリエーションの構造化データに対応しており、公式ドキュメント「商品バリエーションの構造化データ」（2026年11月時点）ではProductGroup（親）とProduct（子＝各バリエーション）の入れ子で表現します。

ProductGroupの必須・推奨プロパティ

各バリエーション（子のProduct）は、skuやgtinで一意に識別できる必要があります。同じskuを2つのバリエーションに使うと、Googleはどれがどれか判別できません。また子のProductには、第3章の必須プロパティ（name・image・offers）がそれぞれ必要です。

ProductGroup＋hasVariantの入れ子イメージ（1ページ型・サイズ違い2点）

{
  "@context": "https://schema.org/",
  "@type": "ProductGroup",
  "name": "コットンクルーネックTシャツ",
  "description": "厚手のコットン生地で、洗濯後も型崩れしにくいベーシックTシャツ",
  "url": "https://example.com/products/tshirt",
  "brand": { "@type": "Brand", "name": "ExampleBrand" },
  "productGroupID": "TS-100",
  "variesBy": ["https://schema.org/size"],
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "TS-100-M",
      "name": "コットンクルーネックTシャツ M",
      "image": "https://example.com/photos/tshirt-white.jpg",
      "size": "M",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/products/tshirt?size=M",
        "price": 3300,
        "priceCurrency": "JPY",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "sku": "TS-100-L",
      "name": "コットンクルーネックTシャツ L",
      "image": "https://example.com/photos/tshirt-white.jpg",
      "size": "L",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/products/tshirt?size=L",
        "price": 3300,
        "priceCurrency": "JPY",
        "availability": "https://schema.org/OutOfStock"
      }
    }
  ]
}

バリエーションで起きやすい3つのミス

• variesByを「color」と文字だけで書く。公式ドキュメントはschema.orgのフルURL（https://schema.org/color）を指定しています
• 色とサイズで変わるのに、variesByに片方しか書かない。変わる軸はすべて配列で列挙します
• 在庫切れのサイズをhasVariantから消す。消すと「そのサイズは存在しない」と解釈されます。availabilityをOutOfStockにして残します

私の経験則として、バリエーションが多い商品（色5×サイズ5＝25通りなど）は、この入れ子を手で書くのは不可能です。カートの商品データ（親商品とバリエーションのテーブル）からテンプレートで自動生成する前提で、まず売れ筋の1商品で出力を確認し、リッチリザルト テストが通ってから全商品に広げます。

バリエーションの構造化データで、カート設計と直結するのがURLの持たせ方です。公式ドキュメントは「1ページ型」と「複数ページ型」の2つの構成を区別し、それぞれで書き方を変えるよう求めています。カートによってはどちらになるかが決まっているので、第6章の実装前に確認します。

1ページ型：正規URLは「何も選んでいない状態」

1ページ型では、ProductGroupのurlに「バリエーションを選んでいない状態のURL」を入れます。これが正規URL（canonical＝同じ内容のページが複数あるとき、代表として扱ってほしいURL）になります。各バリエーションのOfferには、選択済みの個別URLを入れます。ここで多いミスは、ProductGroupのurlに「?size=M」のような選択済みURLを入れてしまうことです。親は常に未選択のURLです。

複数ページ型：各ページが自己完結する

複数ページ型では、各バリエーションのページがそれぞれ完結したマークアップを持ちます。Mサイズのページには、Mサイズの商品のProductと、所属するProductGroupの情報を置きます。公式ドキュメントは、他のバリエーション（LサイズやXLのページ）のURLも列挙するよう推奨しています。Googleが残りのページを見つけやすくなるためです。

カート移行で構造化データごと消える

1ページ型と複数ページ型は、カートを乗り換えると変わることがあります。移行先のカートが構造化データを出さない、またはURL構成が変わって正規URLがずれる、という事故は珍しくありません。リニューアル・カート移行の際は、移行前の商品ページでリッチリザルト テストの結果を保存しておき、移行後に同じ商品で比較します。移行全体の注意点はECサイトリニューアルで検索順位を落とさない方法にまとめています。

商品ページには、Productとは別にパンくず（BreadcrumbList）の構造化データを入れます。検索結果でURLの代わりに「メンズ › ビジネスシューズ › ストレートチップ」のような階層が表示される資格を得るためです。カテゴリ階層の設計そのものはECのカテゴリページSEOで扱っているので、ここでは構造化データの書き方だけに絞ります。

BreadcrumbListの必須・推奨（公式ドキュメント 2026年11月時点）

商品ページのパンくず（3階層の例）

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "メンズ", "item": "https://example.com/mens/" },
    { "@type": "ListItem", "position": 2, "name": "ビジネスシューズ", "item": "https://example.com/mens/business-shoes/" },
    { "@type": "ListItem", "position": 3, "name": "本革ストレートチップ ブラック" }
  ]
}

パンくずで押さえる3つの原則

• URL構造ではなく「お客様がそのページに至る典型的な経路」を表す。公式ドキュメントはこの考え方を明記しています。URLのフォルダをそのまま並べる必要はありません
• トップ（ドメイン）と現在のページ自体はListItemにしなくてよい。上の例では「ホーム」を入れていません。入れても誤りではありませんが、必須ではありません
• 1ページに複数の経路を指定できる。「メンズ › 革靴」と「ブランド › 革靴」の2経路があるなら、BreadcrumbListを2つ入れられます

画面上のパンくずと構造化データのパンくずは一致させます。画面には3階層あるのに構造化データは2階層、という食い違いは、ページに書いていない情報をマークアップしているのと同じ扱いになります。

実装したら検証します。使うのは2つ、Googleの「リッチリザルト テスト」とGSC（Google Search Console＝検索結果での順位や流入を確認できる無料ツール）です。公式ヘルプ（2026年11月時点）に沿って手順を書きます。

手順1：リッチリザルト テストで1ページずつ確認する

1. リッチリザルト テストを開き、商品ページのURLを入力して実行します（コードを直接貼り付けて試すこともできます）
2. URLで試す場合、ページが匿名で見られる状態である必要があります。公開前のパスワード保護ページや、IP制限のあるテスト環境はテストできません。その場合はコード貼り付けで検証します
3. 結果の「エラー」は、リッチリザルトの対象外になる問題です。先に直します
4. 結果の「警告」は、推奨プロパティの不足です。表示は制限される可能性があるので、第4章の優先順位で埋めます
5. ユーザー エージェントはスマートフォンがデフォルトです。パソコン表示だけ構造化データを出している場合は、ここで気づけます

手順2：Search Consoleでサイト全体の状態を見る

Search Consoleには、商品の構造化データに対応するレポートがあります。公式ブログ（2022年9月・2023年の発表）によると、「商品スニペット」と「販売者のリスティング」の2つのレポートに分かれ、検索パフォーマンスの「検索での見え方」でも両者を分けて確認できます。画面上の表記は変わることがあるので、実際の管理画面の名称でご確認ください。見る順番は次の通りです。

• 「無効」の件数と理由。「必須フィールドがありません」「値が無効です」などの理由ごとに、該当URLの一覧が出ます。1件直せば同じテンプレートの全ページが直ることが多いので、理由単位で潰します
• 「有効（警告あり）」の内訳。推奨プロパティの不足です。送料・返品ポリシーの不足はここに出ます
• 検索パフォーマンスの「検索での見え方」。商品表示の表示回数とクリック数が、通常の検索結果と分けて見られます。実装の前後で比較します

「マークアップは正しいのに出ない」ときの切り分け

私が相談を受ける中で、マークアップ自体は正しいのに商品表示が出ないケースの原因は、構造化データの外にあることがほとんどでした。実際にあった原因は次の通りです（具体の社名は伏せます）。

運用で破綻しないための線引き

第4章でも触れましたが、構造化データの運用が止まる原因は、ほぼ「手で入れた値が古くなる」ことです。私が前職で続けられた線引きは次の3つでした。

• 価格・在庫・有効期限は、カートの商品データからテンプレートで自動生成する。手入力の欄を作らない
• 送料・返品ポリシーは、全商品共通なら1か所（Search Consoleの設定か組織単位のマークアップ）で持つ。商品ごとに持つのは例外だけ
• 月に1回、Search Consoleの「無効」件数を見る。増えていればテンプレートの変更が原因なので、直近の変更を戻す

Q. 構造化データを入れれば検索順位は上がりますか？

上がりません。Googleは構造化データを順位の要素とは説明しておらず、リッチリザルトの表示も保証していません。得られるのは「検索結果に価格や在庫を出す資格」で、出れば検索結果での目立ち方とクリック率に影響し得る、というところまでです。順位が上がらない原因の切り分けは検索順位が上がらない15の原因と対策チェックリストをご覧ください。

Q. JSON-LDとMicrodata、どちらで書くべきですか？

これから入れるならJSON-LDです。Googleが推奨している形式で、HTMLの表示部分と分離して書けるため、テンプレートからの自動生成と検証がしやすいです。既にMicrodataで動いているサイトを無理に書き換える必要はありませんが、バリエーション（ProductGroup）のような入れ子はJSON-LDの方が管理しやすいです。

Q. レビューがまだない商品にaggregateRatingは入れられますか？

入れられません。aggregateRatingとreviewは、ページに表示している実際の顧客評価がある場合だけ使えます。評価を自作して入れる、社内で付けた星を入れる、といった方法はガイドライン違反で、手動対策の対象になり得ます。レビューを集める仕組みと、集まってからのマークアップは別記事で扱う予定です。

Q. 売り切れの商品ページは構造化データを消すべきですか？

消さず、availabilityをOutOfStock（再入荷予定ならBackOrder等）にします。消すと商品の情報がなくなり、在庫が戻ったときに再評価されるまで時間がかかります。バリエーションの一部が売り切れの場合も、hasVariantから消さずにOutOfStockで残します。ページ自体を残すかどうかの判断は別記事で扱う予定です。

Q. 制作会社に依頼するとき、何を伝えればいいですか？

次の5点をそのまま渡してください。①マーチャント リスティングの必須5項目（第3章の表）を全商品に出す、②価格・在庫・有効期限は商品データから自動生成し手入力欄を作らない、③色・サイズ違いはProductGroupで束ね、variesByはschema.orgのフルURLで指定する、④パンくずはBreadcrumbListで別に出す、⑤納品前にリッチリザルト テストで売れ筋3商品の結果（エラー0件）を提出する。この5点が要件になっていれば、後から直す場面はかなり減ります。

本記事で書いたことを、実装の順番に並べ直します。

構造化データは、ページに書いてある事実を機械に翻訳する作業です。ページにない価格、ない在庫、ない評価を書く場所ではありません。だから本文がきちんと書けている商品ページほど、構造化データは短時間で入ります。本文の作り方はECの商品ページSEO、EC全体の設計はECサイトのSEO対策 完全ガイドに戻ってご確認ください。

最後に一つ。公式ドキュメントの仕様は年に数回変わります。本記事の内容は2026年11月時点の確認値なので、実装の直前にはGoogle検索セントラルの該当ページで最新の必須・推奨を見てから進めてください。