コマーススキーマ

TL;DR — 「コマーススキーマ」は、検索して行動できる対象、つまり購入する商品や応募する求人を記述するためのschema.org型を指す私の略称です。3つの型があります。Product（販売する1商品）、ProductGroup（複数サイズ・色などのバリエーションをまとめる親）、JobPosting（公開中の1件の求人）です。適切な型を追加すると、ページはショッピング風の商品結果やGoogle for Jobsカードという、より目立つ検索表示の対象になれます。ただし順位が上がるわけでも、実際に表示されることやクリック増を保証するわけでも、AIに引用される手段でもありません。このハブは適切な型へ案内し、完全なプロパティ表は各型の記事に置いています。

「コマーススキーマ」とは何か

「コマーススキーマ」は、単一のSchema.org型やGoogleの機能ではなく、実務上の分類です。 Evidence for this claim Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Scope: This article's taxonomy; Schema.org and Google document individual types and search experiences. Confidence: high · Verified: 2026-07-14 Schema.org: Product Googleは商品、merchant listing、Organizationのマークアップ要件と適格性を別々に文書化しています。 Evidence for this claim Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Scope: Google Product structured data and merchant-listing experiences. Confidence: high · Verified: 2026-07-14 Google: Product structured data

ジャケットを販売するページを見れば、価格、色の選択肢、「在庫あり」という表示を人間は読み取れます。検索エンジンは通常のテキストからそれを推測しなければなりません。スキーママークアップは、「これは価格」「これは在庫状況」「これは職種名」と明示するコードです。共通語彙として schema.org を使います。

「コマーススキーマ」は公式用語ではありません。人が検索し、絞り込み、何らかの行動を取れる商用または取引型のリスティングを記述するschema.org型を、私がまとめて呼ぶための名称です。

• Product — 販売する単一の商品。
• ProductGroup — 1つの商品に属するバリエーション（サイズ、色など）を親として結び付け、別の商品ではなく同じ商品の選択肢だと検索エンジンに伝える型。
• JobPosting — 採用ページに載せる1件の公開求人。

この3つをまとめるのは、SEO上の役割が共通しているからです。追加すると、Googleがリスティングを専門的な検索結果として扱えるようになります。ただし、Googleとschema.orgがこの3つを同じ分類に入れているわけではありません。なぜこの区分を正直に説明する必要があるのかは、Advancedタブで扱います。

このハブの役割もそこから決まります。ここは実装ガイドではなくルーターです。まずページに該当する3つの型を選び、次にその型の詳細記事を読んでください。レビュー、返品、配送が関係する場合は、Review、MerchantReturnPolicy、OfferShippingDetailsの関連レコードにあるプロパティ表も確認します。

なぜ使うのか：リッチリザルト

得られるものは、検索結果で目立つ拡張リスティング、つまりリッチリザルトです。

• 🛍️ 価格、「在庫あり」の表示、レビュー星を備えた商品
• 👕 サイズと色の選択肢を表示する商品
• 💼 会社、勤務地、給与とともにGoogleの求人枠に表示される求人

必要な詳細をすべて含む対応スキーマを追加すれば、ページはその表示の対象になれます。ただし対象になることは保証ではありません。実際に表示するかどうかは、Googleが別途判断します。

多くの人が間違える点

コマーススキーマを追加しても順位は上がりません。 Googleはこの点を明確に繰り返し説明しています。スキーマがするのは、より豊かなリスティングの対象にし、検索エンジンがページを理解しやすくすることです。これは順位改善とは別であり、対象になったことも実際の表示を保証しません。有効なマークアップは表示、クリック増、AI回答での引用を約束しません。これらは別々の成果として扱ってください。

初心者が陥りやすいもう1つの罠は、これらの型を相互に置き換えられると思うことです。単一商品にはProduct、バリエーションがある商品にはProductGroup、求人にはJobPostingを使います。複数求人を一覧するページにJobPostingを使ってはいけません。この最後の規則は、想像以上に厳格です。

schema.orgの階層での位置、Merchant CenterやGoogle for Jobsとの接続、次に読む記事まで知りたいですか？ Advancedタブへ進んでください。

TL;DR — 「コマーススキーマ」はGoogleやschema.orgのカテゴリではなく、取引型のリッチリザルトを得るリスティング型をまとめた、私の実務上の分類です。対象はProduct、ProductGroup、JobPostingです。GoogleではProduct／Variantsが**「Shopping」に、Job postingが一般のfeature guides一覧に分かれています。schema.orgでも統合されていません。Product → ProductGroupは実際の親子関係（Thing > Product > ProductGroup）ですが、JobPostingはProductとは無関係なIntangible分岐（Thing > Intangible > JobPosting）にあります。3つを結び付けるのはSEO上の用途だけで、Googleが構造化リスティングを専門的な検索表示（商品リスティング、Google for Jobs）に変える点です。順位要因ではなく、得られるのは適格性です。表示、CTR向上、AI引用はそれぞれ保証されません。Review／AggregateRatingの適格性は別プロファイルで判定され、返品・配送データもOrganizationレベルのポリシーとOfferレベルの例外に分かれます。このハブはその2つの契約へ案内するだけです。ライフサイクルの危険性も異なり、古いProductは主に適格性を失いますが、期限切れにしないJobPostingは手動対策**につながることがあります。

まず正直に：これはGoogleの分類ではなく私の分類

この記事の分類は、関連する複数の語彙と検索機能を利便性のために組み合わせています。 Evidence for this claim Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Scope: This article's taxonomy; Schema.org and Google document individual types and search experiences. Confidence: high · Verified: 2026-07-14 Schema.org: Product Googleの各検索体験には独自の必須・推奨プロパティがあり、有効なマークアップでも表示は保証されません。 Evidence for this claim Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Scope: Google Product structured data and merchant-listing experiences. Confidence: high · Verified: 2026-07-14 Google: Product structured data

最初に透明性を持たせたいと思います。「commerce」や「ecommerce」スキーマを扱う記事の多くは、これらの型が公式のファミリーであるかのように、暗黙に示します。しかし、そうではありません。

• Google自身の文書は分けています。 構造化データの ギャラリーでは、「Job posting」はArticle、Local business、Organizationなどと並ぶ平坦な一般のFeature guides一覧にあります。一方、「Product snippet」「Merchant listing」「Variants」は別のShopping見出しの下です。異なる2つの文書ファミリーです。
• schema.orgも統合していません。 型の 階層には「Product, Offer, and AggregateOffer」という専用のまとまりがありますが、JobPostingはその隣に置かれたトップレベルのまとまりには登場しません。

それなのに、なぜ1つの記事に入れるのでしょうか。実務では、SEO担当者が扱う問題の形が同じだからです。専門的な検索体験を得るために、構造化されたリスティング型コンテンツへマークアップを追加します。その用途の共通性は現実的で役に立ちますが、共通の分類は存在しません。Googleがこの箱を描いたかのように装うより、私はその点を明言したいのです。

3つの型を一望する

• Product（schema.org/Product）— 販売可能な単一商品です。Googleは有効なProductマークアップを2つの体験に変えます。購入ページ以外でレビュー星や価格を示すproduct snippetsと、購入できるページでより詳しいショッピング型表示を示す商品リスティングです。リッチリザルトの最低条件はnameとoffers、review、aggregateRatingのいずれか1つです。ただしreview／aggregateRatingの経路は、自己評価レビューの制限などを含む、Googleの別のReview snippet規則に従います。「どの商品ページでも星を出せる」という一律の資格ではありません。すべてのProductやmerchant pageが自動的にレビュー星の対象になるわけではないため、そのプロファイルはReviewスキーマ詳細記事で確認してください。
• ProductGroup（schema.org/ProductGroup）— 1つの概念上の商品（複数サイズ・色のTシャツなど）のバリエーションをまとめる親です。Googleが別々のリスティングではなく同じ商品の選択肢だと理解できるようにします。hasVariant、variesBy、productGroupIDでバリエーションを結びます。重要なのはProductの代わりではない点です。各バリエーションは完全なProductであり、ProductGroupはその上位に置かれます。
• JobPosting（schema.org/JobPosting）— Google for Jobs体験（検索に出る求人カード／カルーセル）の対象になる、1件の公開求人です。基本的な必須プロパティはtitle、description、datePosted、hiringOrganization、jobLocationです。完全リモートならapplicantLocationRequirementsでも構いません。

このハブでは各型のプロパティ表を意図的に浅く扱っています。詳しい内容は末尾から案内する3つの子記事にあります。

schema.orgの階層での位置

ここは、ほとんど誰も正しく引用しない部分です。推測と事実を分けるポイントでもあります。

• Product — Thing > Product。
• ProductGroup — Thing > Product > ProductGroup。これは本当のProductのサブタイプで、Productの全プロパティを継承し、hasVariant、productGroupID、variesByを追加します。したがって「ProductかProductGroupか」は完全な二者択一ではありません。ProductGroupはバリエーションのために特化したProductです。
• JobPosting — Thing > Intangible > JobPosting。完全に別の分岐です。JobPostingの定義はProduct、Offer、その他のコマース型を参照しません。

結論として、ProductとProductGroupは分類上の親子関係にあり、検証可能で引用できます。一方、JobPostingは分類上無関係です。3つをつなぐのは型の継承ではなくSEO上の用途です。ここを正確に言えば、確かな説明になります。

ProductとProductGroup：どちらを使うか

単純なルールは次のとおりです。

• 購入可能な構成が1つ → 通常のProduct。単一SKU、1つの価格、ページ上で購入できる1つの商品です。
• 概念上は1つの商品で、購入可能なバリエーションが複数 → Productメンバーを包むProductGroup。5色のシャツのようなケースです。ProductGroup自体が販売されるのではなく、hasVariantの各メンバーがそれぞれsku／gtin、価格、在庫状況を持って販売されます。

GoogleはProductGroupを別の形でも文書化しています。独立したトップレベルの機能ガイドではなくVariantsページに置いており、Productとは完全に別のリッチリザルト型ではなく、Productの拡張として扱っていることが分かります。完全なプロパティ表、variesByの完全URLに関する注意点、Merchant Centerのitem_group_idとの照合は、ProductGroup詳細記事で扱います。

JobPosting：例外的な型

JobPostingは分類上Productと何も共有しません。しかし問題の形が同じなので、このハブに含めています。運用面では、次の2点が異なります。

1. 1ページにつき1求人です。常にそうしてください。 Googleの規則は次のとおりです。“The JobPosting markup must only be used on pages that contain a single job posting.” (翻訳)「JobPostingマークアップは、1件の求人を含むページでのみ使用してください。」一覧や検索結果ページでは決して使いません。Product／ProductGroupにはこの単一項目制限がありません。ProductGroupは、まさに1ページに複数のバリエーションを扱うために存在します。
2. 期限切れ求人は、放置できないコンプライアンス上の義務です。 Productとの違いが最も大きく出るリスクについては、以下で詳しく説明します。

3つすべてに共通する基本ルール

型の分類は共通していなくても、Googleの一般的な構造化データのガイドラインは共通します。ここでまとめて確認しましょう。

• 必須プロパティが適格性のゲートです。 必須プロパティが欠けると、そのリッチリザルトの対象になりません。推奨プロパティは品質を高めます。Googleは求人給与を例に、給与が明記された求人の方をユーザーが好むと説明しています。同じ「より完全な方がよい」という考え方はProductにも当てはまります。
• 適格性と表示は同じではありません。 有効なマークアップで候補には入りますが、拡張表示を出すかどうかはGoogleのシステムが別に判断します。
• 見えていて正確な内容だけをマークアップします。 非表示のマークアップ、偽のレビュー、誤解を招くデータは不可です。Googleのスパム・コンテンツ品質ポリシーは3つすべてに適用され、各型にはJobPostingのコンテンツポリシーのような固有の方針もあります。
• JSON-LDが3つすべてに推奨される形式です。 インラインMicrodata／RDFaより、大規模サイトで保守しやすい形式です。

ページ上のマークアップ以外での接続先

本当の共通価値は分類ではありません。Googleがリスティング型コンテンツに独自の商品ライン向け表示を与える点です。

• Product／ProductGroup ↔ Google Merchant Center。 商品データはページ上の構造化データ、Merchant Centerフィード、または両方で提供できます。Googleは適格性を高めるため両方を推奨し、別々に検証される2つのシステムを照合します。Rich Results Testに合格してもフィードが有効とは限らず、その逆も同じです。ページ上のマークアップ、フィード、チェックアウトで価格と在庫状況を一致させる必要があります。
• JobPosting ↔ Google for Jobs。 有効なJobPostingマークアップで、単一求人ページがJobs体験の対象になります。Shoppingとは別の縦型検索です。
• 返品と配送も、さらに細かく分かれます。 MerchantReturnPolicyは通常Organizationレベルで、サイト全体の標準的な返品期間と条件を持ちます。OfferShippingDetailsはOfferレベルで動作し、重い商品や料金の異なる地域など、1つの商品の例外として組織レベルの既定値を上書きします。1回設定して終わる1つの塊ではなく、組織レベルのポリシーとOfferレベルの例外を別々のレコードとして保守してください。詳しい優先順位は各詳細記事にあります。
• ページ上の構造化データ、Merchant Centerフィード、Googleの検索機能やAI回答に実際に表示される内容は、3つの別々の契約です。最初の契約で有効性を得ても、2つ目が自動で埋まるわけではなく、3つ目の表示も保証しません。

Bingとの非対称性も明言しておきます。Bingは3つすべてをschema.orgの形に照らして一般的に検証しますが、どの型についても専用の必須・推奨プロパティ表やコンテンツポリシーを公開していません。また商品リスティングやGoogle for Jobsに相当する機能もありません。ProductGroupについては、BingのFabrice Canelが2024年9月に、買い物用キャプションではまだProductGroupマークアップを利用していないが「注目している」と述べています。つまり基礎語彙は同じでも、専用で文書化されたリッチリザルト体験を上に構築しているのはGoogleだけです。

リスクとライフサイクルの違い

ここは特に覚えてほしい対比です。他の記事ではあまりこのように整理されていません。古いリスティングには3つすべてでライフサイクル管理が必要ですが、重大さは大きく異なります。

• 古い、または在庫切れのProductは、主にリッチリザルトの適格性を失うか、「売り切れ」「在庫なし」と表示されます。困りますが、致命的ではありません。
• 削除されない古いJobPostingは別のリスクです。Googleは “We don’t allow expired job postings,” (翻訳)「期限切れの求人は許可していません」とし、求人の期限切れや削除を怠ると “may result in a manual action.” (翻訳)「手動対策につながることがあります」と説明しています。通常の不適格化よりはるかに重大です。求人を期限切れにする方法は、validThroughを過去の日付にする、404/410を返す、マークアップを削除する、の3つです。

教訓は同じです。構造化リスティングにはライフサイクルの手順が必要です。ただしクリーンアップパイプラインを1つだけ作るなら、求人向けに作るべきです。

コマーススキーマはSEOに役立つか？

順位には役立ちません。John Muellerは、構造化データでサイトの順位が上がることはないと明確に述べています。スキーマがもたらすのは、リッチリザルトや専門的な体験への適格性と、Googleがページを理解する助けです。「スキーマを追加した」ことと「順位が上がる」ことを同一視するのは、3つの型に共通する最大の誤解です。

順位だけではありません。適格性、実際に表示されるリッチリザルト、CTR向上、収益は4つの別の主張です。これらを1つにまとめないでください。有効なマークアップでもShoppingやJobs体験への表示は保証されず、クリック増も保証されません。また、このハブのスキーマ型はいずれもAI可視性のシグナルとして文書化されていないため、AI OverviewsやAI Modeに表示・引用されるための手段でもありません。それぞれの成果を個別に測定し、検索機能の対象を得るために実装してください。

私の見方もMuellerと同じです。開発時間を使う前に、スキーマが何のためにあるのかを理解しましょう。Googleがスキーマを廃止するわけではないともMuellerは述べていますが、実装の目的は検索機能を得ることであり、順位を上げたりクリックやAI回答を保証したりすることではありません。

次に読む記事

このハブは地図です。以下はそれぞれ、このハブの下にある独立した詳細記事です。

• Productスキーマ — 2つのGoogle体験（product snippetsと商品リスティング）、必須・推奨プロパティの違い、availability列挙値、フィードとマークアップの混同を整理します。1商品を販売するページならここから。
• ProductGroupスキーマ — hasVariant／variesBy／productGroupIDによるバリエーションのグループ化、単一ページと複数ページのパターン、完全なschema.org URLの注意点、Merchant Centerのitem_group_idとの照合を扱います。サイズ・色・素材があるならここから。
• JobPostingスキーマ — 必須・推奨プロパティ、リモート／ハイブリッドの扱い、1ページ1求人の規則、期限切れ対策、求人サイト向け2024〜2025年のIndexing APIアクセス変更を説明します。採用ページや求人サイトならここから。
• MerchantReturnPolicyスキーマ — 返品ポリシーのプロパティレベルの型です。マークアップとMerchant Center設定の優先順位、applicableCountryとreturnPolicyCountryの混同を扱います。
• OfferShippingDetailsスキーマ — 配送料、配送先、配送時間を補うプロパティと、無料リスティングでGoogleが実際に要求する場合を説明します。
• Reviewスキーマ — Productリッチリザルトでreview／aggregateRatingを使う別の適格性プロファイルです。単一レビューと集計、自己評価レビューの制限、すべての商品ページが自動的に星の対象になるわけではない理由を扱います。

より広い全体像については、構造化データのサブクラスターにある記事群を見てください。同じ場所にあるスキーママークアップ記事では、語彙、形式、廃止サイクルを説明しています。すべてはオンページクラスターに属し、構造化データは他のオンページ技術SEOと並びます。

AI要約

Advanced版の要点を短くまとめます。

• 概要： 「コマーススキーマ」はPatrickの実務上の分類であり、Googleやschema.orgのカテゴリではありません。取引型リッチリザルトの対象になるschema.orgのリスティング型、Product、ProductGroup、JobPostingをまとめています。
• 公式ファミリーではない： GoogleのギャラリーではProduct／商品リスティング／Variantsが**「Shopping」、Job postingが一般のfeature guides**に置かれます。schema.orgは「Product, Offer, AggregateOffer」をまとめ、JobPostingをそれらと同じトップレベルの分類には入れていません。
• 階層： ProductはThing > Product、ProductGroupはThing > Product > ProductGroup（バリエーション用のProductのサブタイプ）、JobPostingはThing > Intangible > JobPosting（無関係な分岐）です。Product／ProductGroupは親子で、JobPostingは分類上別です。
• 使い分け： 購入可能な構成が1つならProduct、バリエーションがある1商品ならProductGroupでProductメンバーを包みます（ProductGroup自体は販売しません）。公開中の1求人ならJobPostingです（1ページ1求人で、一覧ページには使いません）。
• リッチリザルト： Productはproduct snippetsと商品リスティング、ProductGroupはバリエーション対応の商品リスティング、JobPostingはGoogle for Jobsです。
• 共通ルール： 必須プロパティが適格性のゲートで、適格性は表示を保証せず、見えていて正確な内容だけをマークアップし、形式はJSON-LDが推奨です。
• マークアップ以外： Product／ProductGroupとGoogle Merchant Centerは別だが照合されるシステムです。両方を提供し、マークアップ、フィード、チェックアウトで価格と在庫状況を一致させます。JobPostingはGoogle for Jobsに接続します。返品・配送も同じように細かく分かれ、MerchantReturnPolicyは通常Organizationレベル、OfferShippingDetailsは例外のためOffer単位で上書きします。2つのレコード、2つの保守スケジュールです。
• レビュー星は別プロファイル： Productのreview／aggregateRating経路はGoogleのReview snippet適格性規則に従い、どの商品ページでも対象になるわけではありません。Reviewスキーマ記事を参照してください。
• Bing： 3つを一般的に検証しますが、専用仕様・ポリシー、商品リスティング、Jobs相当機能はありません。Fabrice Canelによれば、2024年9月時点では買い物用キャプションでProductGroupマークアップをまだ利用していません。
• リスク： 古いProductは主に適格性を失いますが、期限切れにしないJobPostingは手動対策につながる可能性があります。過去のvalidThrough、404/410、またはマークアップ削除で期限切れにします。
• SEO効果： 順位要因ではありません（Muellerは構造化データでサイトの順位が上がらないと説明しています）。適格性と理解を助けますが、実際の表示、CTR向上、AI回答での引用とは別で、このハブの型はAI可視性シグナルとして文書化されていません。
• このハブは案内役： 実装用の完全なプロパティ表はここではなく、Product、ProductGroup、JobPosting、Review、MerchantReturnPolicy、OfferShippingDetailsの詳細記事にあります。

公式ドキュメント

3つのコマーススキーマ型と、それらに共通する規則を確認できる一次資料です。

Google — 共通ルール

• 一般的な構造化データのガイドライン — 3つすべてに適用される適格性の原則、コンテンツ品質、スパムポリシー。
• 構造化データ検索ギャラリー — 現在リッチリザルトを生むものの基準資料。「Shopping」と「Feature guides」の分割も確認できます。

Google — ProductとProductGroup（「Shopping」）

• Product構造化データの概要 — product snippetとmerchant listingの違い、構造化データとフィードの関係。
• Product snippet構造化データ — 軽量なスニペット体験の必須・推奨プロパティ。
• Merchant listing構造化データ — 「ここで購入できる」ことに関する厳しい要件。
• Product variant（ProductGroup）構造化データ — Productの拡張としてProductGroupを説明するページ。
• Merchant Center — 商品データ仕様 — ページ上のマークアップと照合されるフィード側の仕様。

Google — JobPosting（「Feature guides」）

• 求人の構造化データ — 必須・推奨プロパティ、1ページ1求人の規則、コンテンツポリシー、期限切れの処理。

Schema.org（分類）

• schema.org/Product · schema.org/ProductGroup · schema.org/JobPosting · 型階層の概要

Bing／Microsoft

• Bing Webmaster Tools — 構造化データでサイトをマークアップする — 一般的なschema.orgサポートであり、型別の適格性仕様はありません。

出典からの引用

記録に残る発言を掲載します。ページ上で引用文が公開されている場合、リンクは引用箇所へ移動するディープリンクです。

Googleのドキュメント — 共通の適格性原則

• “Specify all required properties listed in the documentation for your specific rich result type. Items that are missing required properties are not eligible for rich results. The more recommended properties that you provide, the higher quality the result is to users. For example: users prefer job postings with explicitly stated salaries than those without…” (翻訳)「対象のリッチリザルト型について文書に記載された必須プロパティをすべて指定してください。必須プロパティがない項目はリッチリザルトの対象になりません。推奨プロパティを多く指定するほど、ユーザーにとって結果の品質が高くなります。たとえば、ユーザーは給与が明記された求人を、明記されていない求人より好みます……」 引用へ移動
• “Content in structured data must also follow the additional content guidelines or policies, as documented in the specific feature guide. For example, content in JobPosting structured data must follow the job posting content policies.” (翻訳)「構造化データ内のコンテンツも、個別の機能ガイドに記載された追加のコンテンツガイドラインやポリシーに従う必要があります。たとえば、JobPosting構造化データのコンテンツは求人のコンテンツポリシーに従わなければなりません。」 引用へ移動

Googleのドキュメント — ProductとMerchant Centerの関係

• “Two markup types exist: Product snippets for non-purchase pages, emphasizing reviews, and Merchant listings for purchase pages, highlighting product details like sizing and shipping.” (翻訳)「2種類のマークアップがあります。購入ページ以外でレビューを重視するProduct snippetsと、購入ページでサイズや配送などの商品詳細を強調するMerchant listingsです。」 引用へ移動
• “To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both.” (翻訳)「Google検索に豊富な商品データを提供するには、ページにProduct構造化データを追加するか、Google Merchant Centerでデータフィードをアップロードして無料リスティングに参加するか、またはその両方を行えます。」 引用へ移動

Googleのドキュメント — JobPostingの固有ルール

• “The JobPosting markup must only be used on pages that contain a single job posting. We don’t allow the use of JobPosting markup in any other page, including pages that do not list any job.” (翻訳)「JobPostingマークアップは、1件の求人を含むページでのみ使用してください。求人を掲載していないページを含め、その他のページでJobPostingマークアップを使うことは許可していません。」 引用へ移動
• “We don’t allow expired job postings. Ideally you should remove expired job postings from your website. If you prefer to not remove them, then you need to ensure the validThrough property is populated and in the past.” (翻訳)「期限切れの求人は許可していません。理想的には、期限切れの求人をサイトから削除してください。削除しない場合は、validThroughプロパティを設定し、過去の日付にする必要があります。」 引用へ移動
• “Jobs that are no longer open for applications must be expired in one of the following ways. Failure to take timely action on expired jobs may result in a manual action.” (翻訳)「応募を受け付けなくなった求人は、次のいずれかの方法で期限切れにしなければなりません。期限切れ求人に適時対応しないと、手動対策につながることがあります。」 引用へ移動

John Mueller（Google）— スキーマは順位要因ではない

• “Structured data won’t make your site rank better.” (翻訳)「構造化データを使っても、サイトの順位は上がりません。」続けて、“It’s fine to use it for other things in schema.org, that won’t cause problems, but you’re unlikely to see any visible change from it in Google Search.” (翻訳)「schema.orgの別の用途に使うのは問題ありませんが、Google検索で目に見える変化が出る可能性は低いでしょう」とも述べています。 報道へ移動 Search Engine Roundtableによる、Muellerの2025年4月のBluesky投稿の報道を経由した引用です。二次報道の転記として扱ってください。
• “In order to be eligible to be shown as a rich result, you need to make sure that the page uses the right structured data and that it complies with the appropriate policies on our side.” (翻訳)「リッチリザルトの表示対象になるには、ページが正しい構造化データを使い、Google側の適切なポリシーに従っていることを確認する必要があります。」 報道へ移動
• “Exactly. Understand that markup types come and go, but a precious few you should hold on to (like title, and meta robots).” (翻訳)「そのとおりです。マークアップ型は現れては消えますが、titleやmeta robotsのように、保持すべき貴重なものはごく少数です。」 報道へ移動 Search Engine Roundtableによる、2025年11月のReddit返信の報道を経由した引用です。

Fabrice Canel（Microsoft Bing）— ProductGroupについて

• “ProductGroup markup isn’t used in our captions yet, but it’s on our radar. Our team is closely monitoring its adoption. Stay tuned!” (翻訳)「ProductGroupマークアップはまだ当社のキャプションでは使っていませんが、注目しています。チームはその採用状況を継続的に監視しています。続報をお待ちください！」 報道へ移動 Search Engine Roundtableによる、2024年9月のX上の発言の報道を経由した引用です。時点付きの情報なので、依存する前にBingの現在のProductGroup対応を再確認してください。

コマーススキーマ早見表

3つの型の比較

要点

• 「コマーススキーマ」は実務上の分類であり、Googleやschema.orgのカテゴリではありません。3つの型はSEO上の用途を共有しますが、分類を共有していません。
• ProductとProductGroupは親子で、JobPostingは無関係な分岐です。
• 適格性 ≠ 表示。 有効なマークアップで候補には入りますが、拡張表示を出すかはGoogleが決めます。
• 順位要因ではなく、CTR・表示・AI引用も保証しません。 スキーマはリッチリザルトの適格性と理解を助けます。実際に表示されるか、クリックが増えるか、AI回答に出るかは別々で、いずれも保証されません。
• Review／AggregateRatingの適格性は別プロファイルです。 すべての商品・merchant pageが星の対象になるわけではなく、Googleの別のReview snippet規則に従います。Reviewスキーマ詳細記事を参照してください。
• 返品と配送も細かく分かれます。 MerchantReturnPolicyは通常Organizationレベル（既定の返品ポリシー）、OfferShippingDetailsは例外のためOffer単位で上書きします。2つのレコード、2つの保守スケジュールです。
• JSON-LDは3つすべてにGoogleが推奨する形式です。
• Merchant Centerフィードとページ上のProductマークアップは別システムで、Googleが照合します。両方を提供し、マークアップ、フィード、チェックアウトの価格と在庫状況を一致させます。
• 求人の衛生管理が最重要です。 終了した求人は過去のvalidThrough、404/410、またはマークアップ削除で期限切れにし、手動対策を避けます。

必要なコマーススキーマ型はどれか？

マークアップするページについて答えれば、正しい型と次に読む詳細記事へ進めます。

コマーススキーマで実際に見る間違い

これはProduct、ProductGroup、JobPostingのマークアップで実際に起こる具体的なミスです。仮の例ではありません。どれにも修正方法があります。

複数求人を一覧するページにJobPostingマークアップを置く

Googleの規則は明確です。JobPostingマークアップは「“must only be used on pages that contain a single job posting”」 (翻訳)「1件の求人を含むページでのみ使わなければならず」、求人をまったく載せていないページを含むその他のページでは許可されません。採用一覧や検索結果ページに追加しても、複数のJobs掲載を獲得できません。マークアップが不適合になり、対象外になるだけです。

代わりに： 公開中の各求人に単独のURLを与え、そのページだけをマークアップします。一覧・インデックスページはナビゲーションに使い、JobPostingスキーマは置きません。

終了した求人を期限切れにせず公開したままにする

古いProductは主に適格性を失うか「在庫なし」と表示されるだけです。少し不便な程度です。古いJobPostingはリスクの種類が違います。Googleは “We don’t allow expired job postings,” (翻訳)「期限切れの求人は許可していません」とし、終了した求人を期限切れにしたり削除したりしないと “may result in a manual action.” (翻訳)「手動対策につながることがあります」と説明しています。これはリッチリザルトのスニペットを失うだけの問題ではなく、サイト全体に及ぶペナルティです。

代わりに： 求人が終了した瞬間に、Googleが認める3つの方法のいずれかを実行します。validThroughを過去の日付にする、URLで404/410を返す、またはJobPostingマークアップを完全に削除することです。手作業の後回しにせず、採用システムのオフボーディング手順に組み込みます。

ProductGroupを使えば各バリエーションのマークアップは不要だと考える

ProductGroupはhasVariant、variesBy、productGroupIDでバリエーションを結ぶ親ですが、Productの代わりにはなりません。各バリエーション（サイズ、色、素材の組み合わせ）には、独自のsku／gtin、価格、在庫状況を持つ完全なProductマークアップが必要です。ProductGroupだけを公開して個々のProductエントリを省くと、Googleが販売に必要とするデータがバリエーションから欠落します。

代わりに： 購入可能な各バリエーションをそれぞれProductとしてマークアップし、その集合を参照するProductGroupで包みます。

コマーススキーマで順位が上がると期待する

これは3つすべてに共通する最も大きな誤解です。Googleは、構造化データでサイトの順位が上がることはないと明確に繰り返し説明しています。スキーマ導入を順位施策として扱うと、関係者の期待を誤らせ、もともと順位を動かさないマークアップ作業を優先して他の改善を削ることにもつながります。

代わりに： コマーススキーマは、merchant listingやJobsカードという特定の検索機能の適格性を得るために実装します。クリックや表示に価値がある正当な目的として、その目的に対して測定し、順位だけで評価しないでください。

ページ上のマークアップ、Merchant Centerフィード、チェックアウトの内容をずれたままにする

商品データはページ上の構造化データ、Merchant Centerフィード、または両方から来ます。Googleは一方を他方のコピーとは扱わず、別システムとして照合します。Rich Results Testに合格してもフィードが有効とは限らず、その逆も同じです。マークアップ、フィード、チェックアウトの実際の請求で価格や在庫状況が異なると、適格性とユーザーの信頼の両方を損ないます。

代わりに： 3つすべての面で価格と在庫状況を同一にし、ページ上のマークアップとフィードを別々に検証します。一方が他方を自動的にカバーすると考えないでください。

コマーススキーマを作成・確認するツール

3つの型のいずれかでJSON-LDを書いたら、まず私のSchema Markup Validatorを使います。Product、ProductGroup、JobPostingのブロック（またはページ全体）を貼り付けると、schema.orgの語彙とGoogleのリッチリザルト要件に対して重要度別のチェックを実行します。3つの型のどれを扱っている場合でも、出荷前に必須プロパティの欠落を見つけるのに役立ちます。

私のRich-Result Eligibility Checkerは、このハブが繰り返し扱う、より具体的な問いに答えます。つまり「これは有効なJSON-LDか」ではなく「このページは本当にリッチリザルトの対象か」です。JSON-LD、HTMLページ、または公開URLを入力すると、Product（offers／review／aggregateRating）やJobPosting（title、description、datePosted、hiringOrganization、jobLocation）について、必須フィールドの有無を示します。この記事が説明する適格性ゲートそのものです。

私のPDP SEO Checkerは、このハブの商品詳細ページ向けに作られています。スキーマだけでなく、Product／ProductGroupマークアップと並ぶオンページシグナルも含めて、単一SKUページまたはバリエーションをまとめたページが正しく構成されているかを確認します。

マークアップがこれらのチェックを通ったら、Google独自のRich Results Testでページを確認します。3つの型のいずれでも、Googleが適格性を判断する際に実際に使うツールなので、公開前の最終確認になります。

自分で確認：コマーススキーマ

3つのコマーススキーマ型、それらの関係、できることとできないことについての短い5問です。それぞれ答えを選んでから確認してください。

時間を使う価値のある資料

私のスキーママークアップ記事

• スキーママークアップ — 語彙、形式、エンティティ理解、廃止サイクルについての広い説明です。コマーススキーマはその一部です。
• テクニカルSEO初心者ガイド — スキーマを、検索エンジンのコンテンツ理解を助け、リスティングを目立たせる機能を支えるコードとして説明しています。
• エンタープライズSEO — ここにも当てはまる実務的な原則、「検索機能を得られるならスキーママークアップを支持する」を扱います。

私の講演

• How Search Works（SlideShare）— クロール、レンダリング、インデックス、ランキングを説明する講演です。構造化データがどこに入るかを理解する背景になります。（私の常設の注意書き：「これはシステムについての私の理解であり……100%完全または正確ではありません。」）

業界の資料

• Google、構造化データはサイトの順位を上げないと改めて説明（Search Engine Roundtable）— 2025年4月のMuellerの発言で、このハブ全体の誤解を正す根拠です。
• Googleはスキーマを廃止しない — マークアップは変わり得る（Search Engine Roundtable）— マークアップ型は現れては消えるが、保持すべき貴重なものは少数という説明です。
• Bingは将来ProductGroupマークアップを使う可能性（Search Engine Roundtable）— BingがProductGroupを使っていないことに関する、Fabrice Canelの2024年9月の発言です。
• リッチリザルトが必要なら構造化データのガイドラインを守る（Search Engine Land）— 正しいマークアップとポリシー順守がリッチリザルトの適格性に必要だというMuellerの説明です。
• schema.orgの型階層 — 語彙そのものです。「Product, Offer, and AggregateOffer」のまとまりと、JobPostingがどこにあり、どこにないかを確認できます。

変更履歴