商品ページSEO

TL;DR — 商品ページ（PDP、商品詳細ページ）とは、誰かが購入を決断できるように1つの商品を説明するページです。検索で上位表示させるには、メーカーの説明文をコピーするのではなく、_自分自身の_説明文を書き、構造化データを追加してGoogleが検索結果に価格・在庫・星評価を表示できるようにし、適切なaltテキスト付きの実際の商品写真を使用し、実際の顧客レビューをページに掲載し続けます。構造化データは、リッチな表示結果を_獲得_するのに役立ちますが、それ自体で検索順位を上げるわけではありません。

商品ページが果たすべき役割

商品ページは、ストアの中で最も重要なページです。最も購買意欲の高い検索者がたどり着く場所であり、「nike pegasus 41 size 10」と入力する人は、ブログ記事を読んでいる人よりもはるかに購入に近い状態です。したがって、このページには同時に2つの役割があります。特定の高意図検索で上位表示されることと、訪問者が到着したら購入を決断させることです。

良いニュースとしては、商品ページはロングテール検索（特定の商品名、型番、「〜向け」といったクエリ）をターゲットにすることが多く、これらは通常、広範なキーワードよりも競争が激しくありません。適切に構築された商品ページは、その文字数からは考えられないほどの効果を発揮できます。

最も重要なこと

• 独自の説明文を書く。 最大の失敗は、メーカーの説明文を貼り付けることです。他の小売業者も同じテキストを使用しています。Googleはこれらすべての同一ページの中から1つの「勝者」を選ばなければならず、それがあなたのページになるとは限りません。この商品が誰向けで、他とどう違うのかについて、たとえ数文のオリジナルな文章でも効果があります。
• 構造化データを追加する。 これはコード（ページ上では表示されません）であり、価格、在庫状況、ブランド、平均レビュー評価をGoogleに伝えます。これにより、Googleは検索結果に星、価格、「在庫あり」を直接表示できるようになります。 Evidence for this claim Product structured data can make eligible pages available for enhanced product search appearances. Scope: Valid markup creates eligibility but does not guarantee a rich result. Confidence: high · Verified: 2026-07-14 Google: Product structured data ほとんどのECプラットフォーム（Shopify、WooCommerce）で自動的に追加できます。
• 適切な商品画像を使用する。 実際の写真を自社サイトでホストし、説明的なaltテキスト（「青いランニングシューズ、横から見た図」— 「IMG_4821」ではない）を付けます。
• 顧客レビューをページに掲載し続ける。 レビューは信頼を構築し、買い物客が実際に使う自然な言葉を追加し、検索結果に星評価として表示されることがあります。
• 在庫切れ商品には慎重に対応する。 一時的に売り切れた商品のページを削除しないでください。ページを公開したまま、在庫切れとマークするだけにします。商品が完全に販売終了になった場合のみ、リダイレクトまたは削除します。

多くの人が誤解していること

構造化データは検索順位を上げません。 追加する価値はあります。検索結果で価格・在庫・星評価の表示を獲得し、無料の商品リスティングの対象になるためです。しかし、スキーマがある_というだけ_でページの順位が上がるわけではありません。 Evidence for this claim Structured data enables eligibility for search features rather than guaranteeing ranking improvements. Scope: Google does not guarantee display even when markup is valid. Confidence: high · Verified: 2026-07-14 Google: Structured data guidelines ページは依然として、優れた有用なページである必要があります。スキーマはページを説明するものであり、努力の代わりにはなりません。

完全版（必須のスキーマフィールド、バリアントの正規化パターン、メーカー重複問題、レビューとE-E-A-T、在庫切れルール）が必要ですか？上級者向けタブに切り替えてください。

TL;DR — 商品ページは、ストアの中で最も意図が高く、技術的に最も負荷がかかるページです。構造化データには2つの種類があります。商品スニペット（購入できないページ）とマーチャントリスティング（購入できるページ）です。マーチャントリスティングの最小限のマークアップはProduct.name + Product.image + Offer.price + Offer.priceCurrencyであり、マーチャントリスティングには0より大きい価格が必要です。スキーマはリッチリザルトと無料の商品リスティングを獲得しますが、ランキングシグナルではありません。バリアントはベースURLに正規化し（クエリパラメータのバリアント→パラメータなしのURL、パスベースのバリアント→親商品のURL）、ProductGroupを使用して関係を示します。メーカーの定型文ではなく独自の説明文を書き、在庫切れページはavailabilityをOutOfStockに設定して公開し続け、実際の顧客レビューにE-E-A-Tの経験・信頼シグナルを担わせます。

商品ページが最もROIの高いターゲットである理由

商品ページはファネルの最下部に位置します。そこに流入するクエリは、サイト全体で最も高い商業的意図を持ち、また、具体的（モデル名、サイズ、SKU、「〜用」など）であるため、通常ロングテールで競争が低いものです。Ahrefsのeコマースガイドが述べるように、「最適化された商品ページはユーザー体験を向上させ、通常競争が低く商業的意図が高いロングテール検索語でより良い順位を獲得します。」

また、これらはあなたが扱う中で最も技術的に要求されるページでもあります。リッチリザルト用の構造化データを保持し、バリアントの正規化を処理し、他のすべての小売業者に広がる同一のメーカーコピーと競合し、eコマースサイトのファセットナビゲーションURLの肥大化の大部分を生み出します。構造化データ、正規タグ、コピーを正しく設定すれば、ページの長さに不釣り合いなほどの報酬が得られます。

生のHTMLとレンダリング後のeコマースSEO

Google検索はJavaScriptをレンダリングできますが、それによってレンダリングされたDOMだけが監査に値する唯一のバージョンになるわけではありません。他のクローラー、ショッピングシステム、ユーザーがトリガーするフェッチャー、抽出エージェントは、異なるレンダリング機能と時間予算を持っています。コアとなる商品提案を最初のサーバーレスポンスに含め、JavaScriptでそれを拡張します。

生のHTMLは以下を公開する必要があります：

• 商品名、正規URL、安定した商品またはグループID；
• 選択された、またはデフォルトのSKUとその定義属性；
• 選択されたオファーの価格、通貨、在庫状況；
• URL戦略で必要な場合、アドレス可能なバリアントへのクロール可能なリンク；
• 一致するProduct / ProductGroup および Offer JSON-LD。

レンダリングされたコンテンツは、ギャラリー、レコメンデーション、パーソナライゼーション、ファイナンスウィジェット、店舗検索、郵便番号別の配送予定、よりリッチな選択コントロールを追加できます。ただし、商品IDの唯一の表明を置き換えたり、選択されたオファーを静かに変更したりしてはなりません。同じURLについて、生のレスポンス、レンダリングされたDOM、表示されている選択、構造化データ、カートリクエストを比較してください。それらが異なる商品やオファーを識別する場合、レンダリングは技術的には成功しましたが、eコマース契約は依然として失敗しています。 Evidence for this claim Google Merchant Center recommends including product structured data and key product information, particularly price and availability, in the initial HTML response because JavaScript-generated markup can make Shopping crawls less frequent and less reliable. Scope: Google Merchant Center landing-page guidance; other crawlers and agents have provider-specific rendering behavior. Confidence: high · Verified: 2026-07-29 Google Merchant Center: Landing page requirements 完全な選択オファー契約とURL戦略の選択については、商品バリアントSEOを参照してください。

商品構造化データ：2つの異なるクラス

Googleは商品構造化データを2つの機能に分けており、その区別がどのフィールドが必要かを決定します： Evidence for this claim Google documents product snippets and merchant listings as distinct Product structured data experiences. Scope: The experiences overlap but have different requirements and page-intent constraints. Confidence: high · Verified: 2026-07-14 Google: Product structured data

• 商品スニペット — 「人々が直接商品を購入できない商品ページ向け。」比較ページや編集ページを考えてください。
• マーチャントリスティング — 「顧客があなたから商品を購入できるページ向け。」これがトランザクション型のPDPです。

重複があります：「2つの商品機能の間にはいくつかの重複があります」、そして「追加できるプロパティが多いほど、ページが対象となる拡張機能が多くなります。」重要な範囲の制限：「現在、商品リッチリザルトは単一の商品（または同じ商品の複数のバリアント）に焦点を当てたページのみをサポートしています」— したがって、カテゴリページや複数商品の一覧ページは商品リッチリザルトの対象外です。

最小限のマーチャントリスティングマークアップ

購入可能なPDPの場合、必須のProductフィールドは3つだけです：

• name — 商品の名前。
• image — 商品の写真。Google：「商品を明確に示す写真（例えば、白い背景に対して）が好まれます。」
• offers — 商品を販売するためのネストされたOffer。

そして、そのOffer内には2つの必須フィールドがあります：

• price（またはpriceSpecification.price）
• priceCurrency — 3文字のISO 4217。

人々を悩ませる重要なルール：「商品スニペットとは異なり、マーチャントリスティングエクスペリエンスでは、価格がゼロより大きいことが必要です。」0 USDのプレースホルダーは対象になりません。また、実際に購入可能なページのみが対象です——「ショッパーが商品を購入できるページのみがマーチャントリスティングエクスペリエンスの対象となり、商品を販売する他のサイトへのリンクがあるページは対象外です。」 Evidence for this claim Merchant listing experiences require a positive price and a page where shoppers can purchase the product. Scope: Other eligibility and policy requirements also apply. Confidence: high · Verified: 2026-07-14 Google: Merchant listing properties

（商品スニペットはより緩やかです：name に加えて review、aggregateRating、または offers のいずれかが必要です。）

より多くのサーフェスを解放する推奨フィールド

これらは必須ではありませんが、追加するたびに対象範囲が広がります：

• Product の場合：aggregateRating、brand.name、color、description、gtin/mpn、material、review、sku、size。
• Offer の場合：availability（InStock、OutOfStock、BackOrder など）、itemCondition、hasMerchantReturnPolicy、shippingDetails、url。

description、sku、brand、または review/aggregateRating を必須として扱わないでください——これらは推奨です。多くのガイドがこれを間違えて、これらがないとページが「壊れている」と伝えます。実際はそうではありません。ただ、利用できる拡張機能が少ないだけです。

Merchant Center アカウントなしでの無料商品リスティング

2022年9月以降、構造化データだけでマーチャントリスティングエクスペリエンスの対象になる可能性があります——Google は従来の Merchant Center フィードの要件を撤廃しました。無料リスティングは「Search、Images、Lens、YouTube、Gemini、Shopping タブ、Business Profile の products モジュールなど、Google のさまざまな場所に表示される可能性があります」が、入札ではなく商品データによってマッチングされます。Google の注意点：「商品が Google 全体に表示されることは保証されません。」構造化データと Merchant Center フィードの両方を提供することで、対象範囲を最大化し、Google がデータを検証するのに役立ちます——ただし、フィードはもはや必須の前提条件ではありません。

商品バリアントの処理

バリアント（色、サイズ）は正規化の判断が行われる場所であり、Google は2つのパターンをサポートしています——単一の必須アプローチはありません：

• クエリパラメータのバリアント（/shirt?color=blue）：「オプションのクエリパラメータを使用してバリアントを識別する場合は、クエリパラメータを省略した URL を正規 URL として使用します。」つまり、すべてがクリーンな /shirt に正規化されます。
• パスベースのバリアント（各バリアントが独自の URL を持つ）：「バリアントごとに一意の URL を持つ商品の場合、すべてのバリアントページに canonical タグを使用して正規の商品 URL を含めます。」各バリアントは親商品ページを指します。

どちらの場合も：「内部リンク、sitemap ファイル、canonical タグで同じ URL を使用します。」これら3つのシグナル間の一貫性が、選択した正規 URL に対する Google の信頼を高める方法です——rel=canonical は_ヒント_であり、保証ではありません。

関係を明示するには、ProductGroup を使用します：「Google がどの商品が同じ親商品のバリエーションであるかをよりよく理解できるように、ProductGroup クラスを関連プロパティ variesBy、hasVariant、productGroupID とともに使用します。」「各バリアントは、対応する構造化データマークアップ内で一意の ID を持つ必要があります（たとえば、sku または gtin プロパティを使用）」、また複数ページの実装では、各バリアントページは「そのページで定義されたエンティティの完全で自己完結型のマークアップを含める必要があります。」

メーカー説明の問題

これは商品ページで最も一般的で、最も損害の大きい間違いです。メーカーの説明をそのまま貼り付けると、メーカー自身のサイトとその商品を扱うすべての小売業者の間でほぼ同一のコンテンツが作成されます。重複コンテンツのペナルティはありません——ただし、Google は重複を統合して表示する URL を1つ選択し、ドメインオーソリティ、年齢、ユーザーシグナルがすべてその選択に影響します。選択されるページはあなたのページではないかもしれません。

Googleの有用なコンテンツに関するガイダンスでは、コンテンツが「他の情報源を参考にしている」かどうかを直接問いかけていますが、それは「単にそれらの情報源をコピーしたり書き換えたりする」のではなく、「実質的な付加価値」を提供するものであり、「あまり価値を加えずに他人の意見を要約すること」を警告しています。製品にとってこれは、誰向けなのか、代替品とどう比較するのか、実際に使ってみてどう感じるのか、ということです。少なくとも売れ筋のSKUについてはオリジナルのコピーを書くことが、EコマースカタログにおけるROIの高いコンテンツ施策の一つです。

ここでAIには注意したいところです。構造化データはGoogleがページを理解するのに役立ちます。Gary Illyes氏は、構造化データは「ページをより良く理解するのに役立ち、間接的にはある意味でランキング向上につながる」と述べています（Sam Underwood氏のAhrefsガイド経由の引用であり、Googleの公式見解としてではなく伝聞として扱ってください）。しかし、AIで製品_説明文_を生成すると、仕様、寸法、互換性に関する誤った情報（幻覚）が生じるリスクがあります。自動生成する場合は、Google Merchant Centerが現在、AI生成のタイトルと説明をstructured_title / structured_descriptionフィード属性で開示することを求めている点に注意してください。

ファセットナビゲーションと製品ページのURL肥大化

製品ページやカテゴリページに重ねるフィルタや並べ替えは、膨大な数のクロール可能なURLを生成します。Googleは次のように述べています。「ファセットURLのクロールは、そのページをレンダリングするために必要なURLと操作の量が膨大であるため、サイトに多大なコンピューティングリソースのコストがかかる傾向があります。」これは_クロールとインデックス効率_の問題であり、ペナルティではありません。一般的なパターンは、フィルタリングされたURLをフィルタリングされていないベースURLに正規化すること（これにより、非正規のファセットURLの「クロール量が時間の経過とともに減少する可能性があります」）、パラメータパターンを対象としたrobots.txtの不許可ルール、そして「フィルタの組み合わせが結果を返さない場合はHTTP 404ステータスコードを返す」ことです。完全な解説はファセットナビゲーションにあります。

カスタマーレビューとE-E-A-T

レビューは複数の軸で実際にSEOに効果があります。

• 検索での星表示はAggregateRating構造化データに由来します。自社の製品ページのレビューは「自己中心的」で星の対象外であるという根強い誤解があります。その制限は実際に存在します。「レビュー対象のエンティティが自身に関するレビューを管理している場合、LocalBusinessまたはその他のOrganization構造化データを使用するページは、星レビュー機能の対象外です」— ただし、これはLocalBusiness/Organizationマークアップに適用されます。_その製品_の顧客AggregateRatingを持つProductページは対象です。条件は次のとおりです。「評価はユーザーから直接取得する必要があります」および「他のウェブサイトからのレビューや評価を集約しないでください」。
• E-E-A-T。 ユーザー生成レビューは実際のランキング要素です。それらは直接的な_経験_と_信頼_のシグナルであり、単に星への道ではありません。また、買い物客が実際に使うロングテールの言葉を表面化し、キーワードカバレッジを無料で広げます。

一つ明確にしておくべき区別があります。Googleのレビューシステムは、顧客のレビューを評価_しません_。それは「記事、ブログ投稿、ページ、または類似のファーストパーティのスタンドアロンコンテンツを評価するように設計されており」、「製品やサービスのページのレビューセクションにユーザーが投稿したようなサードパーティのレビューは評価しません」。したがって、編集者の「最高のランニングシューズ」まとめ記事はレビューシステムの対象ですが、PDPの顧客の星評価は対象外です。

避けるべきインデックスの罠： クロール可能な<a href>ページネーションなしでAJAX経由で読み込まれるレビューは、Googlebotから見えません。そのUGCキーワード価値をすべて失います。レビューは実際のリンクと自己参照の正規URLでページネーションしてください。

製品画像のSEO

• 標準的なHTML <img>要素を使用してください — 「標準的なHTML画像要素を使用すると、クローラーが画像を検出して処理しやすくなります。」商品写真にはCSS背景画像を避けてください。
• 代替テキストは「画像により多くのメタデータを提供する際に最も重要な属性」ですが、「alt属性にキーワードを詰め込むのは避けてください…それはネガティブなユーザー体験をもたらし、サイトがスパムと見なされる可能性があります。」
• Googleは<img src>でBMP、GIF、JPEG、PNG、WebP、SVG、AVIFをサポートしています。WebP/AVIFはファイルサイズが最小になります。
• Google画像のリッチリザルトでは、「画像属性はバッジやリッチリザルトの対象となるために必須のフィールドです」— これは、imageがマーチャントリスティングスキーマで必須である理由に戻ります。
• 画像は自社ドメインでホストしてください。品質と形式が単なる量に勝ります。

在庫切れおよび製造中止製品

これは「状況による」領域であり、答えは製品が戻ってくるかどうかにかかっています。私の一般的なルールは次のとおりです。自分が快適に思えるルールを設定し、一貫して適用してください。 強く反対する点が2つあります。まず、noindexは通常、_一時的に_在庫切れのページには間違ったツールです。noindexされたページは内部PageRankの受け渡しを停止し、蓄積されたランキングシグナルを失う可能性があるためです。次に、「内部リンクの削除はランキングに悪影響を与える可能性があります」ので、売り切れた製品をナビゲーションから反射的に削除しないでください。

• 一時的に在庫切れ： ページを公開したままにし、availabilityをOutOfStock（またはBackOrder）に設定し、再入荷/ウェイトリストオプションを追加してください。noindexにしないでください。
• 恒久的に製造中止： リンクエクイティを保持するために、最も近い同等品に301リダイレクトするか、関連する代替品がない場合は410/404を返してください。
• 鮮度： 正確なsitemap <lastmod>とIndexNowは、エンジンが価格と在庫の変更をより迅速に取得するのに役立ちます（詳細は後述）。

完全な決定ツリーは 在庫切れ製品にあります。

返品ポリシー、配送、パンくずスキーマ

PDPでSERPの信頼シグナルを獲得するスキーマタイプがさらにいくつかあります：

• MerchantReturnPolicy — 「Google検索はこの情報を使用して、製品と一緒に返品ポリシーを表示できます。」サイト全体でOrganization.hasMerchantReturnPolicyを介して設定し、製品ごとにOffer.hasMerchantReturnPolicyを介して上書きするか、Search Consoleで設定します（Search Consoleの設定はページ上のマークアップよりも優先されます）。
• OfferShippingDetails — 買い物客が「自分の場所に基づいて送料と推定配達時間を確認できる」ようにし、Offer.shippingDetailsの下にネストします。
• BreadcrumbList — すべてのPDPに含める必要があります。各ListItemにはposition、name、item（URL）が必要ですが、「パンくずリストの最後の項目がパンくずトレイルの最後の項目である場合、itemは必須ではありません」、ホームページと現在のページのListItemは省略できます。

鮮度：価格と在庫の変更のためのIndexNow

Bing（および他のIndexNowコンシューマー — Google以外）の場合、再クロールを待つ代わりに変更をプッシュしてください。Bingは明確に述べています：「IndexNowは検索エンジンに_何かが_変更されたことを伝え、構造化データは_何が_変更されたかを伝えます。」「価格、在庫状況、プロモーションが変更された場合、その更新が顧客にどれだけ早く届くかによって成功が決まります」— 価格下落や再入荷はIndexNow pingをトリガーする必要があります。ShopifyはIndexNowサポートを統合しています。他のスタックでは、schema.org/Productデータを追加して自分で有効にします。

製品ページからの内部リンク

PDPは行き止まりであってはなりません。関連製品や補完製品（「よく一緒に購入される」）にリンクし、親カテゴリに戻り、グローバルに重要な製品にリンクしてください。これにより、ページ内外にPageRankが分散され、製品間のトピック関係が強化されます。

クラスター内での位置

商品ページは、ECストアの サイト構造の一部です。その直上にあるページは カテゴリページ（クローラーとリンクエクイティを商品に誘導する一覧/PLPページ）です。両方のフィルターUIは ファセットナビゲーションです。ライフサイクル処理は 在庫切れ商品にあり、全体のまとめは ECサイト構造にあります。 全体像については、Ecommerce SEOを参照してください。

AIまとめ

Advancedバージョンの簡潔な見解:

• 商品ページ（PDP）は、ストアの中で最も意図が高く、最も技術的なページです — ロングテール、商業的、そして構造化データ、正規化、重複コンテンツの判断が満載です。
• 2つのスキーマクラス: 商品スニペット（購入できないページ）と マーチャントリスティング（購入できるページ）。最小限のマーチャントリスティング = Product.name + Product.image + Offer.price + Offer.priceCurrency、ただし価格はゼロより大きい必要があります。description、sku、brand、review/aggregateRating は_推奨_であり、必須ではありません。
• 構造化データはランキングシグナルではありません。 リッチリザルト（価格、在庫、星）と無料商品リスティングを獲得し、Googleがページを理解するのに役立ちます — ただし、ページ自体が優れている必要があります。
• 無料リスティングにはMerchant Centerアカウントは不要です（2022年9月以降）。構造化データだけで資格を得られます。フィードはリーチと検証を追加します。
• バリアント: クエリパラメータのバリアントはパラメータなしのベースURLに正規化。パスベースのバリアントは親に正規化。ProductGroup（variesBy、hasVariant、productGroupID）をバリアントごとに一意のsku/gtinとともに使用します。
• メーカーの説明を貼り付けないでください — 重複統合が競合他社のURLを選ぶ可能性があります。主要なSKUには独自のコピーを書きましょう。
• レビューは2回重要です: AggregateRatingは星用（Productページで許可。自己奉仕制限はLocalBusiness/Organization用）、そして実際のE-E-A-Tの経験/信頼シグナルとして。Googleの_レビューシステム_は編集レビューを評価し、顧客レビューではありません。レビューはクロール可能な<a href>リンクでページ分割します。
• 在庫切れ: 一時的な在庫切れページはavailability = OutOfStockで公開し続けます（noindexしない）。恒久的に廃止された場合のみ301または410。
• 鮮度: IndexNow（Bing、Googleではない）が価格/在庫の変更をプッシュ。構造化データは_何が_変わったかを示します。

公式ドキュメント

商品ページの一次ソースドキュメント。

Google — 商品構造化データ

• 商品構造化データの紹介 — 商品スニペットとマーチャントリスティング、およびそれらの重複について。
• 商品スニペット構造化データ — 購入不可の商品ページの必須/推奨フィールド。
• マーチャントリスティング構造化データ — 購入可能なPDPの必須/推奨フィールド。
• 商品バリアント構造化データ（ProductGroup） — variesBy、hasVariant、productGroupID。
• レビュースニペット構造化データ — AggregateRating/Reviewと自己奉仕制限。
• マーチャント返品ポリシー構造化データ。
• 配送ポリシー構造化データ。
• パンくずリスト構造化データ。

Google — Eコマースとコンテンツ

• eコマースサイト向け構造化データ — eコマースに重要なスキーマタイプ。
• eコマースサイト向けURL構造の設計 — バリアントの正規化に関するガイダンス。
• ファセットナビゲーションURLのクロール管理。
• 高品質なレビューの作成。
• Googleのレビューシステム — 編集レビューを対象としており、顧客レビューは対象外であることに注意。
• 役立つ、信頼できる、ユーザー第一のコンテンツの作成 — メーカー重複／付加価値に関するガイダンス。
• 画像SEOのベストプラクティス。
• Merchant Centerを使わないマーチャントリスティング（2022年9月ブログ）。

Google Merchant Center

• 商品の無料リスティング。

Bing / Microsoft

• ショッピングと広告向けIndexNow（2025年5月）。
• サイトへの構造化データのマークアップ。

ソースからの引用

GoogleとBingからの公式声明。各リンクは、ソースページの引用箇所にジャンプするディープリンクです。

Google — スキーマクラスと必須フィールド

• “Product snippets require either review or aggregateRating or offers.” (翻訳) 「商品スニペットには、review、aggregateRating、offersのいずれかが必要です。」 — Google Search Central。 引用にジャンプ
• “Unlike product snippets, merchant listing experiences require a price greater than zero.” (翻訳) 「商品スニペットとは異なり、マーチャントリスティング体験では0より大きい価格が必要です。」 — Google Search Central。 引用にジャンプ

Google — バリアントと正規化

• “To help Google better understand which products are variations of the same parent product, use the ProductGroup class with associated properties variesBy, hasVariant, and productGroupID.” (翻訳) 「Googleが同じ親商品のバリエーションである商品をよりよく理解できるようにするには、関連プロパティvariesBy、hasVariant、productGroupIDを持つProductGroupクラスを使用します。」 — Google Search Central。 引用にジャンプ
• “If you use optional query parameters to identify variants, use the URL with the query parameter omitted as the canonical URL.” (翻訳) 「バリアントを識別するためにオプションのクエリパラメータを使用する場合は、クエリパラメータを省略したURLを正規URLとして使用します。」 — Google Search Central。 引用にジャンプ

Google — レビュー

• “It does not evaluate third-party reviews, such as those posted by users in the reviews section of a product or services page.” (翻訳) 「商品やサービスのページのレビューセクションにユーザーが投稿したものなど、第三者によるレビューは評価されません。」 — Googleのレビューシステム。 引用にジャンプ

Google — ファセットナビゲーション

• “Crawling faceted URLs tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages.” (翻訳) 「ファセットURLのクロールは、それらのページをレンダリングするために必要なURLと操作の量が膨大であるため、サイトに多大なコンピューティングリソースを費やす傾向があります。」 — Googleクロールドキュメント。 引用にジャンプ

Google — 画像

• “The most important attribute when it comes to providing more metadata for an image is the alt text (text that describes an image).” (翻訳) 「画像により多くのメタデータを提供する際に最も重要な属性は、altテキスト（画像を説明するテキスト）です。」 — Google Search Central. 引用にジャンプ

Bing — 鮮度

• “IndexNow tells search engines that something has changed, while structured data tells them what has changed.” (翻訳) 「IndexNowは検索エンジンに何かが変更されたことを伝え、構造化データは何が変更されたかを伝えます。」 — Microsoft Bing Webmaster Blog. 引用にジャンプ

中継された情報であり、一次情報ではない

• Gary Illyes（Google）の構造化データに関する発言: “It will help us understand your pages better, and indirectly, it leads to better ranks in some sense.” (翻訳) 「これにより、私たちはあなたのページをよりよく理解できるようになり、間接的には、ある意味でランキングの向上につながります。」

  Sam UnderwoodのAhrefs eコマース商品ページ ガイド経由で引用； 中継された情報として扱い、Google自身の発言として引用する前に原本を確認してください。

商品ページSEOチェックリスト

PDP（またはテンプレートを構築する前）に対して実行するチェック項目：

クロールとインデックス

• ページがクロール可能である — robots.txtでブロックされておらず、不要なnoindexがない。
• 自己参照の正規化が設定され、内部リンクと サイトマップで同じURLが使用されている。
• バリエーションが正しく正規化されている（クエリパラメータ → パラメータなしのベースURL；パスベース → 親商品のURL）。

構造化データ

• Productスキーマが少なくともname + image + offersとともに存在する。
• Offerにprice + priceCurrencyがある；マーチャントリスティングでは価格がゼロより大きいこと。
• availabilityが実際の在庫状況を反映している。
• 利用可能な場合は推奨フィールドを追加：brand、sku/gtin/mpn、 description、aggregateRating、shippingDetails、hasMerchantReturnPolicy。
• 複数バリエーションの商品にはProductGroupを使用し、バリエーションごとに一意のsku/gtinを設定。
• BreadcrumbListが存在し、リッチリザルトテストで検証されている。

コンテンツ

• 説明が一意である — メーカーの定型文ではない（少なくとも 売れ筋商品では）。
• タイトルとH1が、人々が実際に検索する方法と一致している（商品名 + 主要な修飾語）。
• 仕様がセマンティックHTML（リスト / <dl>）で記述され、<div>の羅列に埋もれていない。
• FAQが実際の顧客の質問から作成されている。

画像

• 標準の<img>要素（CSS背景ではない）を使用し、自社ドメインでホストしている。
• 説明的で、キーワードを詰め込んでいないaltテキストとファイル名。
• 可能な場合はWebP/AVIFを使用；圧縮され、レスポンシブ対応。

レビュー

• ページに実際の顧客レビューがあり、AggregateRatingがユーザーから取得されている （他のサイトからスクレイピングしたものではない）。
• レビューのページネーションがクロール可能な<a href>リンクを使用 — AJAXのみではない。

ライフサイクル

• 一時的に在庫切れのページは、availability = OutOfStockのまま公開し続ける （noindexにしない）。
• 販売終了商品は同等の商品に301リダイレクトするか、同等品がない場合は410を返す。
• サイトマップの<lastmod>が正確；IndexNowが価格/在庫の変更を通知している（Bing向け）。

商品スキーマ — 早見表

必須 vs. 推奨（マーチャントリスティング）

スニペット vs. マーチャントリスティング

バリアントの正規化ルール

• クエリパラメータのバリアント（?color=）→ パラメータなしのURLに正規化。
• パスベースのバリアント（/blue/）→ 親商品のURLに正規化。
• 内部リンク + サイトマップ + 正規化で同じURLを使用。ProductGroup がそれらを結び付けます。

在庫切れの判断

• 再入荷予定 → 公開を維持し、availability = OutOfStock に設定し、noindex にしない。
• 完全に廃止 → 同等のページに301、または該当なしの場合は410/404。

否定すべき誤解

• スキーマ ≠ ランキングシグナル（リッチリザルト / 無料リスティングのみを獲得）。
• 重複コンテンツの_ペナルティ_はない — ただし、重複は1つのURLに統合される。
• 商品ページのカスタマーレビュー_は_星評価の対象となる（自己参照ルールは LocalBusiness/Organization 用）。
• マーチャントリスティングにマーチャントセンターアカウントは不要。

メンタルモデル

1. 1ページで2つの役割。 PDPは_ランキング_（ロングテール、高意図のクエリ）と コンバージョン（価格、画像、レビュー、CTA）の両方を担う必要があります。一方を最適化することは通常、もう一方にも役立ちます — 独自のコピーはランキングに効き_かつ_説得力を高めます。レビューはランキングに効き_かつ_安心感を与えます。

2. スキーマは説明するものであり、ランキングには影響しません。 構造化データは資格を獲得します — リッチリザルト（価格/在庫/星評価）、無料の商品リスティング、そして機械の理解の向上。それは_ランキングのレバーではありません_。したがって、作業の順序を決めましょう: まずページを良くしてから、マークアップします。

3. 必須と推奨を明確に区別する。 マーチャントリスティングの必須項目は name + image + offers（price+priceCurrency、価格は0より大きい）。それ以外 （description、sku、brand、評価、配送、返品）は_推奨_であり、 適合範囲を広げます。ツールに脅かされて、推奨項目が必須だと誤解しないようにしましょう。

4. 重複コンテンツの現実。 ペナルティはありませんが、統合はあります。N社の小売業者にわたって同一の メーカーコピーがあると、Googleは1つの勝者を選びます。独自のコピーと一貫したcanonical/sitemap/内部リンクのシグナル（canonicalはヒントであり、保証ではありません）で、勝つ可能性を高めましょう。

5. 在庫切れの判断ツリー。 1つの質問をしましょう：それは戻ってきますか？ はい → 公開を維持し、OutOfStockをマークし、決してnoindexにしない（PageRankとシグナルを失うことになります）。いいえ → 最も近い同等品に301リダイレクトするか、同等品がない場合は410を返します。ルールを一度設定し、一貫して適用しましょう。

6. URL構造によるバリアントのcanonical。 クエリパラメータのバリアントは パラメータなしのベースに集約され、パスベースのバリアントは親を指します。ProductGroupは どちらの場合も親子関係を明示します。

商品ページSEOのためのツール

• リッチリザルトテスト（Google） — Product、Offer、BreadcrumbList、 およびレビューのマークアップを検証し、ページがどの拡張機能の対象かを確認します。
• スキーママークアップバリデータ（schema.org） — Googleのサポート機能を超えた一般的な構造化データの検証。
• Google Search Console — マーチャントリスティングと商品スニペットのレポート — どの商品ページが対象/有効で、どのページにエラーがあるかを大規模に確認します。
• Google Merchant Center — オンページの構造化データに加えて、リーチとデータ検証を追加するオプションのフィード。
• Bing Webmaster Tools + IndexNow — マークアップバリデータに加え、価格/在庫変更のプッシュ通知。
• サイトクローラー（Ahrefs Site Audit、Screaming Frog） — カタログ全体で、欠落/重複したcanonical、薄いまたは重複した説明、欠落したaltテキスト、孤立した商品ページを見つけます。
• URL Inspection（GSC） — 単一の商品URLがどのようにクロールされ、レンダリングされ、Googleがどのcanonicalを選択したかを確認します。

時間をかける価値のあるリソース

関連する私の記事

• 在庫切れ商品の扱い方：状況による — 在庫切れの判断に関する私の見解。
• 技術的SEOの初心者向けガイド — 商品ページの技術的要素が全体像にどう適合するか。

Ahrefsから

• SEOのためのEコマース商品ページ改善の14の方法 — Sam Underwoodの実践者向けウォークスルー。
• 商品ページSEO：最適化されたページの構造 — Chris Hainesの16要素PDPチェックリスト。

その他の情報源

• ユーザー生成コンテンツがSEOに有効な理由 — レビューとUGCに関するSearch Engine Land。
• カスタマーレビューがSEOの取り組みを改善する方法 — Search Engine Land。
• 商品ページSEO：実践ガイド — Search Engine Land（Maria White）— タイトルタグ、説明、構造化データ、画像をカバーする実践者向けウォークスルー。
• rel=canonicalは保証ではない — John Muellerの、canonicalはヒントであり指示ではないという明確化をカバーするSearch Engine Roundtable。
• schema.org/Product — すべてのProductおよびOfferプロパティの権威あるschema.orgリファレンス。型定義と例付き。
• r/TechSEO — canonical/インデックス/スキーマのデバッグのためのコミュニティ。

このサイトについて

• カテゴリページSEO、ファセットナビゲーション、在庫切れ商品、およびECサイトアーキテクチャ — サイト構造クラスターの残りの部分。

引用に値する統計

• レビューが5件ある商品は、レビューがない商品に比べて購入可能性が270%高い — Spiegel Research Center（ノースウェスタン大学メディル校）、How Online Reviews Influence Sales、2017年。同じ研究では、最初の5件以降、追加レビューの効果は急速に薄れることが判明しています。 出典
• 検索結果の星評価はクリック率を最大35%向上させたというアイトラッキングと調査研究が、Search Engine Land（2022年1月の記事）によって報告されています。Search Engine Landの記事は、本文中で元の研究を明示していません。35%という数字は、元の研究を追跡するまで、SEL自身の報告として扱ってください。 出典
• 買い物客の98%がレビューは購入判断に不可欠だと答え、78%は商品が高価になるほど多くのレビューを読む — Search Engine Land（2025年6月の記事）による報告。これはPowerReviewsが近年発表している自社の消費者調査の範囲と一致しますが、SELはPowerReviewsを明示的に引用していないため、さらに追跡するまでSELの記事に帰属させてください。 出典

どの商品ページ修正を最初に行うべきか？

ページを損なう商品ページの慣行

買い物客が検証できないマークアップを公開する

失敗する理由: 表示されている価格、在庫状況、レビューと矛盾する構造化データは信頼性が低く、対象資格を失う可能性があります。代わりに: レンダリングされた商品情報と同じ情報源からマークアップを生成します。

すべてのバリエーション組み合わせに対してインデックス可能なURLを作成する

失敗する理由: 色、サイズ、並べ替え、トラッキングの組み合わせにより、ほぼ重複したURLが増殖し、シグナルが分割される可能性があります。代わりに: 一貫した商品/バリエーションURLモデルを選択し、canonical、内部リンク、サイトマップを整合させます。

メーカーのテキストをコピーし、キーワードブロックを追加する

失敗する理由: 一般的な供給元のコピーでは、検索エンジンがそのページを優先する理由がほとんどなく、隠されたまたは反復的なキーワードの散文は買い物客の役に立ちません。代わりに: 重要な商品について、独自性があり正確な情報を優先します。

ライフサイクルを考慮せずに利用できない商品を削除する

失敗する理由: 一時的な在庫切れ、後継品のある廃止商品、死んだSKUには異なる対応が必要です。代わりに: 戻ってくるかどうか、真の代替品が存在するかどうかに応じて、URLを保持、リダイレクト、アーカイブ、または削除します。

商品ページのSEO問題を診断する

商品リッチ結果が対象資格を満たさない

考えられる原因: 必須のProduct/Offerプロパティが欠落している、不正な形式である、または表示されているコンテンツと矛盾している。修正: 生のHTMLをテストし、共有データソースを修正し、リッチ結果対象資格チェッカーでマークアップを確認します。

Googleが異なるcanonical商品URLを選択する

考えられる原因: バリアント、カテゴリパス、パラメータのURLが、優先URLよりも強い内部リンク、サイトマップ、正規化シグナルを受け取っている。修正方法: 1つのURLポリシーを選択し、正規化、リンク、リダイレクト、サイトマップエントリを一致させる。その後、再クロール後にURL検査を監視する。

検索で価格や在庫が古い

考えられる原因: 表示されるページ、マークアップ、Merchant Centerフィードが異なるスケジュールで更新されるか、重要な値がクライアントレンダリング後にのみ表示される。修正方法: ソースを整合させ、レンダリングされた出力を検証し、新しいフィードデータを送信する。

ページがインデックスされているが、インプレッションがほとんどない

考えられる原因: ページのコピーが不十分、内部リンクが弱い、クエリターゲティングが不明確、または製品固有の価値が少ない。修正方法: ページをクエリセットと比較し、差別化情報を強化し、関連するカテゴリや製品からリンクする。

簡素化された製品ページの改善

好まれる製品コピー

Before: “Premium waterproof hiking jacket. Available in multiple colors.” (翻訳) 「高級防水ハイキングジャケット。複数の色があります。」

After: “Three-layer rain shell with pit zips, a helmet-compatible hood, and a packable design for exposed day hikes. The relaxed cut leaves room for a mid-layer.” (翻訳) 「ピットジップ付き3層レインシェル、ヘルメット対応フード、露出した日帰りハイキング用のパッカブルデザイン。ゆったりとしたカットでミッドレイヤーを重ねられます。」

改善されたバージョンは、サプライヤーの文を並べ替えるだけでなく、検証可能な属性と使用コンテキストを追加しています。

一貫性のあるOffer

Before: ページに「$79 — sold out」と表示されている一方、JSON-LDには price: "99" と availability: "https://schema.org/InStock" と記載されている。

After: 表示価格、チェックアウト状態、Offerマークアップが同じカタログレコードから取得されるため、ページと構造化データが1つの状態を報告する。

バリアントの統合

Before: トラッキング、色、サイズのパラメータがすべて自己正規化され、サイトマップに表示される。

After: ストアは製品/バリアントのURLモデルを意図的に選択し、サポートされているURLのみにリンクし、正規化とサイトマップのシグナルをそのモデルと一貫させる。

製品ページ分析プロンプト

サポートされていない、または矛盾する製品クレームを見つける

このプロンプトの後に、表示されている製品コピー、仕様、Offerマークアップ、フィード行を貼り付けます。顧客データや注文データは事前に削除してください。

Act as a product-data QA reviewer. Compare the visible copy, specification table,
Product/Offer structured data, and merchant-feed row below. Return a table with:
field, value in each source, conflict, missing evidence, shopper impact, and the
single source of truth that the team must confirm. Do not infer a price, stock state,
rating, measurement, or compatibility detail that is not present.

[PASTE THE FOUR INPUTS]

製品コンテンツの改善を優先する

製品URL、クエリ/クリックデータ、収益優先度、現在の説明、確認済み仕様を含む小さなエクスポートを貼り付けます。

Prioritize these product pages for content improvement. Score opportunity only from
the supplied search demand, business priority, and content gaps. For each selected
URL, list the missing shopper questions, verified specifications to surface, and a
brief outline. Do not write claims beyond the supplied product data. Flag rows where
the evidence is too thin to draft safely.

[PASTE EXPORT]

製品ページの変更が効果を発揮したことを証明する

製品マークアップリリーステスト

実行するテスト: リリースされた生のHTMLをPDP SEO CheckerとSchema Validatorに送信します。期待される結果: 意図したProduct/Offerフィールドが解析され、表示価格と在庫状況が一致する。失敗の解釈: デプロイ出力またはカタログマッピングが計画されたマークアップと異なる。監視期間: 生のHTMLは即時、検索の強化は再クロール後に更新される。ロールバックのトリガー: リリースが実質的に誤った価格、在庫状況、レビュー、または製品IDを公開する場合。

正規化とバリアントのテスト

実行するテスト: 基本製品と代表的なバリアントURLをクロールし、ステータス、正規化、内部リンク、サイトマップのシグナルを検査します。期待される結果: 各サポートURLが文書化されたURLモデルに従い、ループや競合する正規化がない。失敗の解釈: テンプレート、ルーター、またはサイトマップジェネレーターが異なるバリアントポリシーに従っている。監視期間: 技術的な出力は即時、選択された正規化の変更は再クロール後に遅延する。ロールバックのトリガー: 重要なバリアントがアクセス不能になるか、優先製品URLが意図せず変更される場合。

コンテンツレンダリングテスト

実行するテスト: タイトル、価格、在庫状況、説明、レビュー、画像、関連リンクについて、生のHTMLとレンダリング後のHTMLを比較します。 期待される結果: 検索に重要なコンテンツがクロール可能な表現で存在し、レンダリング後も一貫していること。 失敗の解釈: クライアント側のJavaScriptが重要なフィールドを隠す、遅延させる、または上書きする。 監視期間: テストでは即時、デプロイ後は代表的なテンプレートを確認。 ロールバックのトリガー: 重要な製品フィールドまたはクロール可能なリンクが消える。

製品ページのSEOをシステムとして測定する

対象となる製品ページのカバレッジ

指標: 有効で可視データと整合するProductマークアップを持つ、インデックス可能で正規のPDPの割合。 それが示すもの: リッチリザルトの基盤が意図したカタログをカバーしているかどうか。 取得方法: クロール/スキーマのエクスポートを正規の製品インベントリと結合する。 ベンチマーク/現実的な範囲: まず対象カタログを定義し、その初期監査割合をベースラインとして使用する。除外または未対応の製品は分母を膨らませるべきではない。 頻度: テンプレート作業後は毎週、その後は毎月。

オーガニックな製品ページの需要

指標: カテゴリと在庫状態でセグメント化した、正規PDPへのブランド以外のクリックとインプレッション。 それが示すもの: 製品ページが既知の製品ナビゲーションだけでなく、発見需要を捉えているかどうか。 取得方法: Search Consoleのページクエリエクスポートをカタログメタデータで分類する。 ベンチマーク/現実的な範囲: カテゴリと各コホートの季節ベースラインを比較する。すべてのクエリミックスに適合する普遍的なCTRや成長目標はない。 頻度: 毎月、可能であれば前年比のコンテキストを加えて。

製品ページのインデックス整合性

指標: 意図した正規PDPがインデックスされているか、重複/代替、クロール済みだが未インデックス、またはブロック状態と比較して。 それが示すもの: URL、正規、コンテンツのポリシーが意図した検索可能なカタログを生み出しているかどうか。 取得方法: 製品サイトマップ、クロール、Search Consoleのページインデックスエクスポートを調整する。 ベンチマーク/現実的な範囲: すべての除外バリアントをエラーとして扱うのではなく、理由とテンプレートごとにストアのベースラインからの変化を調査する。 頻度: 毎月、およびURL/テンプレートのリリース後。

自分でテスト: 製品ページSEO

製品詳細ページの技術的およびコンテンツの基盤に関する5つの質問。

変更履歴