ECサイトのSEO対策｜商品ページ・カテゴリ設計・重複対策を解説

この記事でわかること

ECサイトのSEOが他の種別と違う3つの前提

施策の話に入る前に、ECサイト特有の前提を3つ確認します。この3つを踏まえずに一般的なSEOのチェックリストを上から潰していくと、労力の割に成果が出ません。

URLは「作る」のではなく「勝手に増える」

コーポレートサイトやBtoBサイトのURLは、担当者が1枚ずつ作ります。ECサイトのURLはそうではありません。カートシステムが、カテゴリ・絞り込み条件・並び替え・表示件数・ページ送り・セッション管理などの組み合わせで自動的に生成します。管理画面上の商品数が3,000点でも、クロール可能なURLが数十万に達していることは珍しくありません。

したがってECのSEOでは、「どのページを作るか」と同じかそれ以上に、「どのURLを検索エンジンに読ませないか」が設計項目になります。この線引きを先にやらないまま商品ページの文章を磨いても、評価は分散したままです。

ページの中身が毎日変わる

価格は変わり、在庫は切れ、セールは終わり、商品は廃番になります。記事コンテンツのように「一度書けばしばらく有効」という前提が通用しません。ページの内容が変わること自体は問題ではなく、問題になるのは変わったことがページと構造化データに反映されていない状態です。表示価格と構造化データの価格が食い違えば、リッチリザルトの表示が止まるだけでは済まない場合があります。

商品ページは1枚では完結しない

1つの商品について、商品ページ・カテゴリページ・絞り込み結果ページ・レビュー一覧・サイト内検索結果と、複数のURLが同じ商品を扱います。これらが互いに競合しないよう役割を決めるのが、EC特有の情報設計です。Google検索セントラルのeコマース向けガイドも、URL構造の設計、サイト構造の伝え方、ページ分けと段階的ページ読み込みを個別のトピックとして立てています。

カテゴリ階層とファセットナビゲーションの設計

カテゴリは組織図ではなく検索語から作る

カテゴリ階層は、社内の商品部門やメーカーの分類をそのまま持ち込みがちです。しかし検索で使われるのは「レディース アウター」ではなく「ロングコート 大きいサイズ」のような、素材・用途・シーン・サイズを含む語であることが多い。カテゴリページで受けるべきなのは後者です。

実際にどの絞り込み条件が検索されているかは、サイト内検索のログ、検索候補、Search Consoleのクエリで確認できます。手順はキーワード選定の完全マニュアルとサジェストをSEO・企画に活かす方法にまとめています。既存のカテゴリ構造に合う語を探すのではなく、検索されている語に合わせてカテゴリを増やす方向で考えてください。

ファセットがURLを爆発させる仕組み

ファセットナビゲーション（絞り込みナビゲーション）は、ユーザーには便利な機能ですが、URLの観点では組み合わせ爆発の発生源です。次のようなURLがすべて別々に生成されます。

/category/shoes/                                     カテゴリ本体
/category/shoes/?color=black                         色で絞り込み
/category/shoes/?size=260                            サイズで絞り込み
/category/shoes/?color=black&size=260               色 × サイズ
/category/shoes/?size=260&color=black               パラメータの順序が違うだけの別URL
/category/shoes/?color=black&sort=price_asc         絞り込み × 並び替え
/category/shoes/?color=black&per_page=100           絞り込み × 表示件数
/category/shoes/page/2/?color=black                  絞り込み × ページ送り

色を10種類、サイズを8種類、並び替えを4種類用意しただけで、単純な掛け合わせは320通りになります。ここにページ送りと表示件数が掛かり、さらにパラメータの順序違いが加わると、1カテゴリだけで数千のURLが生まれます。カテゴリが100あれば規模は推して知るべしです。

この状態を放置すると、同じような内容のページに評価が分散し、クロールの予算が価値の低いURLに使われます。Googleは大規模サイト向けのクロールバジェット最適化ドキュメントに「304 Not Modified」への対応推奨と、クロール上限は全クローラーで共有されるという記述を追加しており（クロールバジェット文書への2点の追記）、大規模ECでは無視できない論点です。

インデックスさせる組み合わせの決め方

すべてを閉じる必要はありません。次の3条件をすべて満たす組み合わせだけを公開対象にする、という基準が実務的です。

• その条件で実際に検索されている（検索需要がある）
• 該当商品が十分な件数ある（数点しかない絞り込み結果は薄いページになる）
• そのページにしかない情報を載せられる（説明文・選び方の解説など）

この3条件を満たす組み合わせは、多くのサイトで「1軸の絞り込み」と「よく検索される2軸の掛け合わせ」に収まります。並び替え・表示件数・在庫の有無といった、商品の並び順が変わるだけのパラメータは原則として公開対象外です。公開すると決めた組み合わせは、パラメータ付きURLのままにせず、静的なパスを持つカテゴリページとして用意するほうが管理しやすくなります。

制御の3手段と使い分け

手段	何が起きるか	向いている場面	注意点
リンクをたどらせない	そもそも発見されにくくなる	並び替え・表示件数など機能的なリンク	外部リンクやサイトマップ経由で発見されることはある
canonicalで正規化	評価を代表URLに集約する	内容が実質同じになる絞り込み結果	あくまでヒントであり、必ず従われるとは限らない
robots.txtでクロールを禁止	クロール自体が発生しなくなる	大量に生成されるパラメータURL	クロールされないためnoindexなどの指示も読まれない

最後の注意点は重要です。Googleのドキュメントは、robotsメタタグとX-Robots-Tag HTTPヘッダーは「URLがクロールされたときに発見される」と明記し、robots.txtでクロールがブロックされている場合には「インデックス登録や配信のルールに関する情報は発見されず、したがって無視される」としています。robots.txtでブロックしたURLにnoindexを書いても意味がありません。この2つは併用するものではなく、どちらかを選ぶものです。

絞り込み結果を代表URLに集約する場合の記述は次のとおりです。

<!-- /category/shoes/?color=black&sort=price_asc の <head> 内 -->
<link rel="canonical" href="https://example.com/category/shoes/">

並び替えや表示件数のように、そもそもクロールさせる必要のないパラメータはrobots.txt側で止めます。

User-agent: *
# 並び順・表示件数が変わるだけのURLはクロールさせない
Disallow: /*?*sort=
Disallow: /*?*per_page=
Disallow: /*?*view=

Sitemap: https://example.com/sitemap_index.xml

canonicalの考え方と誤用パターンはcanonicalタグによるURL正規化と重複コンテンツ対策、robots.txtの書式と検証方法はrobots.txtの書き方完全ガイドで詳しく扱っています。

ページ送りとパンくず

カテゴリの2ページ目以降を1ページ目にcanonicalでまとめる実装は、2ページ目以降にしか存在しない商品が検索対象から外れる原因になります。Google検索セントラルのeコマース向けガイドも、ページ分けと段階的ページ読み込みを独立したトピックとして扱っています。実装の選択肢と比較はSEOに強いページネーションの実装と無限スクロールの比較にまとめました。

階層構造を検索エンジンに伝える手段としては、パンくずリストの構造化データが有効です。カテゴリが深いECサイトほど効果が分かりやすく、実装方法はパンくずリストのSEO効果と設置方法で扱っています。カテゴリ間・商品間の内部リンク設計はSEO内部リンク戦略の設計と実装が参照先です。

商品バリエーション（色・サイズ）の重複

1URLにまとめるか、バリエーションごとに分けるか

同じ型のシューズに色が10種類、サイズが8種類あるとき、URLを80枚に分けるか1枚にまとめるかという判断が必要になります。分けると、色名やサイズを含む検索語に個別に対応できる一方、内容がほぼ同じページが80枚並び、評価が分散します。まとめると、1枚のページに評価が集約される一方、「ブラック 26cm」のような具体的な検索語で狙いにくくなります。

実務上の基本形は統合です。商品としての実体が同じであれば1つの商品ページに集約し、色・サイズの選択はページ内のUIで切り替える。そのうえで、単独で検索されている型番やカラー名がある場合にだけ、例外的に個別URLを持たせます。判断に使う材料は次の3つです。

• そのバリエーション名で実際に検索されているか（Search Consoleのクエリと検索候補で確認）
• バリエーション固有の情報が十分にあるか（専用の商品画像・仕様・説明文）
• 在庫や価格がバリエーションごとに独立して動くか

Googleが用意しているバリエーション商品の構造化データ

Google検索セントラルは、商品にバリエーションがある場合について、バリエーション商品の構造化データを追加することで「どの商品が同じ親商品のバリエーションであるかをGoogleがより正確に理解できるようになる」と説明しています。後述する商品スニペットと販売者リスティングのいずれも、バリエーション商品をサポートしています。

ここで押さえておきたいのは、バリエーションを個別URLに分ける場合であっても、それらが同じ親商品に属することを明示する手段が公式に用意されているという点です。URLを分けるかどうかの判断とは別に、親子関係の明示は行っておく価値があります。

判断の対応表

状況	URLの持ち方	あわせて行うこと
色・サイズが違うだけで仕様は同一	1つの商品ページに統合	ページ内で選択させる。在庫状況は選択に応じて表示
カラー名が単独で検索されている	カラー別にURLを持つ	バリエーション商品の構造化データで親子関係を明示
型番が異なり仕様も違う	別商品として個別URL	相互に内部リンクを張り、比較できるようにする
並び替え・表示件数だけが違う	URLを増やさない	canonicalまたはrobots.txtで制御

在庫切れ・販売終了商品の扱い

ECサイトで最も判断がぶれるのがこの領域です。「在庫が切れたのでページを削除した」という運用は、そのページが積み上げてきた評価と外部リンクを毎回捨てることになります。まず、一時的な在庫切れと恒久的な販売終了を分けて考えてください。

一時的な在庫切れ：ページは残す

再入荷の予定があるなら、ページを削除せずに残します。Google検索セントラルは、検索結果の機能強化の一つとして「在庫状況データを提供し、商品の在庫状況を購入者が把握できるようにする」ことを挙げています。在庫がないこと自体を隠すのではなく、正しく伝えるのが前提です。あわせて、再入荷通知の受付、代替商品や同カテゴリへの導線を用意しておくと、来訪者を取りこぼしません。

恒久的な販売終了：後継商品があるかで分岐する

販売終了商品の扱いは、後継商品の有無で3通りに分かれます。

• 明確な後継商品がある: 後継商品のページへ301リダイレクトする。評価と外部リンクを引き継げます
• 後継はないが同カテゴリに代替がある: ページを残し、販売終了である旨と代替商品への導線を明記する
• カテゴリごと取り扱いを終了した: ページを削除し、404または410を返す

301リダイレクトの仕様と設定方法は301・302リダイレクトの違いと設定方法で扱っています。注意すべきは、関連性の薄いページ（トップページやカテゴリ最上位）へ一律にリダイレクトする運用です。ユーザーが探していた商品と無関係なページに着地することになり、体験としても検索エンジンの評価としても得るものがありません。

掲載終了日が確定しているページ

期間限定セールの告知など、掲載終了日があらかじめ決まっているページには、robotsメタタグやX-Robots-Tagヘッダーで指定できるunavailable_afterというルールがあります。Googleの公式ドキュメントは、これを「指定した日時以降、このページを検索結果に表示しない」ルールと説明し、指定日時以降はGooglebotがそのURLのクロール頻度を大幅に下げるとしています。

<!-- 掲載終了日が確定しているページの <head> 内 -->
<meta name="robots" content="unavailable_after: 2026-12-31">

ただし、掲載が延長される可能性のあるページでこのタグに依存するのは避けてください。GoogleのGary Illyes氏は、日付を後ろ倒しすること自体は問題ないという直感を示しつつ、「新しい日付を見るためにはそのページを再度クロールする必要がある」と説明し、いったん期限切れになった後に更新されるページでこのタグを信頼してよいかについては回答を保留しています（unavailable_afterの日付を後ろ倒しできるかに関するIllyes氏の回答）。指定日時以降はクロール頻度が大幅に下がる仕様であるため、延長後の日付が読み直される機会も細っていきます。

状況別の対応表

状況	ページ	ステータス	ページ上で伝えること
一時的な在庫切れ（再入荷予定あり）	残す	200	在庫状況、再入荷の見込み、通知の受付
後継商品がある販売終了	統合	301	後継商品ページへ遷移
後継はないが代替がある販売終了	残す	200	販売終了の明記と代替商品・カテゴリへの導線
取り扱い自体を終了	削除	404 / 410	カテゴリ一覧への導線を持つエラーページ
掲載終了日が確定した告知	残す	200	unavailable_afterを指定（延長がない場合に限る）

レビューの活用とリスク

レビューは重複しにくい独自コンテンツ

ECサイトの商品説明文は、メーカー提供のテキストをそのまま使っているケースが多く、他店と同一の内容になりがちです。その中で、購入者レビューは自社にしか存在しない情報です。Google検索セントラルも、検索結果の機能強化の例として「購入者レビューや評価を掲載することで、検索結果の表示をより質の高いものにする」ことを挙げ、商品レビューの説明文で取り上げられている長所と短所を特定して検索結果でハイライトされるようにすることにも触れています。eコマース向けガイドには「質の高いレビューを書く」というトピックも独立して用意されています。

Googleが明確に禁止していること

一方で、レビューは執行の対象にもなっています。Googleはレビュースニペットの構造化データマークアップに関するガイドラインに、やらせのレビューや、謝礼を受けていることを開示していないレビューを、ページ本文にも構造化データマークアップにも含めてはならないという文言を追加しました（やらせ・未開示の謝礼レビューの記載禁止が明記された件）。

さらにGoogleは、手動対策の対象となりうる違反理由に、レビューコンテンツの真正性に関する項目を追加しています（レビュースニペットの手動対策の対象条件が拡大された件）。構造化データの記述形式が正しいかどうかではなく、掲載されているレビューが実際の利用経験にもとづくものか、謝礼がある場合に開示しているかという内容面が問われる点が特徴です。レビュー投稿でポイントを付与するようなキャンペーンを行っている場合は、その事実がページ上で開示されているかを確認してください。

レビュー由来のページを増やしすぎない

レビューが増えると、レビュー一覧のページ送り、評価点でのフィルタ、新着順・高評価順の並び替えなど、また新たなURLが生成されます。前述の絞り込みと同じ問題です。レビューは商品ページ内に主要な数件を表示し、一覧ページはインデックス対象から外す構成が管理しやすくなります。

商品ページの構造化データ

商品スニペットと販売者リスティングの使い分け

Google検索セントラルは、商品の構造化データには主に2つのタイプがあるとしています。

タイプ	使う場面	記述できる項目の特徴
商品スニペット	ユーザーが商品を直接購入できない商品ページ	レビュー情報を指定するオプションが多い（エディターレビューの長所と短所など）
販売者リスティング	ユーザーが商品を購入できるページ	詳細な商品情報を指定するオプションが多い（衣料品のサイズ、配送情報、返品に関するポリシーなど）

この2つには重複する部分があり、Googleは「一般に、販売者リスティングに商品情報の必須プロパティを追加した場合、その商品ページは商品スニペットの対象にもなる」と説明しています。どちらにも独自の拡張機能があるため、実装前に両方の要件を確認することが推奨されています。自社サイトで決済まで完結するECであれば、販売者リスティングが基本形になります。

検索結果で強化される項目

Googleは、商品のリッチリザルトを強化する例として次を挙げています。評価（購入者レビューや評価の掲載）、長所と短所、送料（特に送料無料に関する情報）、在庫状況、値下げ（Googleが価格変動を継続してモニタリングして計算するもので、常に表示されるとは限らない）、返品（返品に関するポリシー、返品に必要な料金、返品可能な日数など）です。

ショッピング体験が検索結果に表示される場所としては、追加の商品情報を含むテキスト検索結果（商品スニペット）、より視覚に訴える形での「人気商品」、販売者のリスト付きのショッピングナレッジパネル、そしてGoogle画像検索での注釈付き画像が挙げられています。どの体験に出るかを気にするより、できるだけ詳細な商品情報を提供することが推奨されています。

事業者単位のポリシーはOrganizationにネストする

個々の商品の構造化データに加えて、Googleはeコマース事業のポリシーを定義する構造化データをOrganizationマークアップにネストすることを推奨しています。対象は、販売者の返品に関するポリシー（1つまたは複数指定）と、ポイントプログラムです。返品条件やポイント付与のルールは商品ごとに変わらないことが多いため、商品単位で繰り返すより事業者単位で一度定義するほうが、運用上も整合を保ちやすくなります。

最小構成の記述例

販売者リスティングとして商品ページに置くJSON-LDの骨格は次のようになります。必須・推奨プロパティは機能ごとに異なるため、実装前にGoogle検索セントラルの該当ページとリッチリザルトテストで確認してください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "ランニングシューズ RS-100 ブラック 26.0cm",
  "image": "https://example.com/img/rs-100-black-260.jpg",
  "sku": "RS100-BK-260",
  "gtin13": "4901234567894",
  "brand": {
    "@type": "Brand",
    "name": "Example Sports"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/rs-100-black-260/",
    "priceCurrency": "JPY",
    "price": "12800",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {
          "@type": "QuantitativeValue",
          "minValue": "0",
          "maxValue": "1",
          "unitCode": "DAY"
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": "1",
          "maxValue": "3",
          "unitCode": "DAY"
        }
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "JP"
      }
    }
  }
}
</script>

JSON-LDの書き方、よく出るエラーの読み方、他のスキーマタイプとの組み合わせは構造化データマークアップ完全ガイドにまとめています。ページ上の表示内容と構造化データの値が一致していることは、実装後に必ず確認してください。

構造化データとMerchant Centerフィードの関係

Googleは、検索に充実した商品データを掲載する方法として、ページにProduct構造化データを追加する、Merchant Centerにデータフィードをアップロードして無料リスティングを有効にする、あるいはその両方を行う、という選択肢を示しています。両方を用意すると各種の体験を最大限に利用でき、Googleがデータを正しく認識して検証できるようにもなるとされています。

両者が組み合わされる例として、ページの構造化データに価格データが存在しない場合、商品スニペットでは販売者フィードの価格データが使用される場合があることが挙げられています。裏を返せば、ページとフィードで値が食い違っていると、どちらが表示されるか読めない状態になるということです。フィード側の属性に関する要件はMerchant Centerのドキュメントを確認してください。

AIエージェント時代に不足しがちなフィールド

近年は、検索順位とは別の軸で商品データの整備状況が問われるようになりました。SALT.agency共同創業者のReza Moaiandin氏の調査では、上位小売29社の商品詳細ページ207件（アクセスエラーなどを除いた分析対象は141件）のうち、priceValidUntilを含んでいたのは18%、shippingDetails.deliveryTimeは13%、hasMerchantReturnPolicy.merchantReturnDaysは11%にとどまり、65%はGTIN（国際的な商品識別コード）も欠いていました。さらに15%にあたる32ブランドはHTTP 403でボットアクセスを完全にブロックしていたと報じられています（上位小売の70%がエージェント型商取引に「見えない」とする調査）。

これらのフィールドはSchema.orgに2020年から2021年にかけて追加されたもので、目新しい技術要件ではありません。テンプレートを更新していないだけ、というのが多くの現場の実態です。自社の商品ページのソースを開いて、価格の有効期限・配送日数・返品可能日数・商品識別コードが入っているかを確認するところから始められます。

あわせて、AI Modeでの商品の見え方は通常の検索結果とは別物である点も押さえておきたいところです。Productriseの調査では、通常検索のPopular productsカルーセルに載っている商品のうち同じ日の同じ検索でAI Modeにも登場したのは1.28%、両方に登場した商品でも1位の売り手が違っていたのは49.6%でした（AI Modeの商品・価格・売り手が通常検索のカルーセルとほぼ一致しないとする調査）。なおGoogleはこの数字について「検証していない」と回答しており、調査は商品掲載の追跡サービスを販売する事業者によるものです。数字の性質を踏まえたうえで、自社の商品がAI経由の回答でどう扱われているかを個別に確認するのが現実的です。

サイト内検索結果ページのインデックス

なぜ原則としてインデックスさせないのか

サイト内検索結果ページは、検索されたキーワードごとにURLが生成されます。ユーザーが打ち込んだ語の数だけURLが増えるため、上限がありません。しかも中身は既存の商品一覧の並べ替えであり、そのページにしかない情報はありません。カテゴリページと内容が重複するうえ、検索エンジンの検索結果から自社サイトの検索結果に着地するという体験にもなります。

放置すると品質の問題になりうる

放置のリスクは重複だけではありません。GoogleのJohn Mueller氏とMartin Splitt氏は、スパマーがサイトの検索機能を悪用して大量のスパム検索ページを生成した場合、Googleがそうしたページをハッキングされたものとして扱い始めると説明しています（サイト内検索ページの放置がハッキング判定につながるという警告）。検索バーからスパムブランド名やURLを含むページを数千枚つくれてしまう、という指摘です。ECサイトは検索窓を必ず持つため、この問題の当事者になります。

実装

基本形は、検索結果ページにnoindexを指定することです。リンクはたどらせて構わないので、通常はfollowと併記します。

<!-- /search/?q=... の <head> 内 -->
<meta name="robots" content="noindex, follow">

ここで前述の注意点が効いてきます。robots.txtで /search/ をブロックしてしまうと、Googleはそのページをクロールしないためnoindexを読めません。noindexを効かせたいURLは、クロール可能なままにしておく必要があります。クロール量そのものを抑えたい場合は、noindexでインデックスを外したうえで、内部リンクから検索結果ページへ導線を張らない（サイトマップにも含めない）という組み合わせが現実的です。

あわせて、検索窓から生成されるURLに不正な文字列が入り込まないよう、入力値の扱いをアプリケーション側で確認してください。技術面の点検項目はテクニカルSEO完全ガイドのチェックリストにまとめています。

大規模ECのクロールとインデックス管理

ここまでの施策を実装したうえで、大規模サイトでは次の2点を継続的に監視します。

1つはインデックスの実態です。サーチコンソールの使い方ガイドのインデックス作成レポートで、「検出 – インデックス未登録」「クロール済み – インデックス未登録」がどのURLパターンで増えているかを見ます。絞り込みURLがここに大量に並んでいれば、制御が効いていないということです。

もう1つはサイトマップです。数万件規模になると1ファイルに収まらないため、商品・カテゴリ・記事といった種類ごとに分割し、サイトマップインデックスでまとめます。種類ごとに分けておくと、Search Console上で「どの種類のURLがインデックスされていないか」を切り分けられます。作成と送信の手順はXMLサイトマップの作り方・SEO効果・送信手順にまとめています。

実店舗を持つ事業者の場合は、オンラインの商品ページとは別に、店舗情報の最適化が必要になります。Googleビジネスプロフィールの運用と地図検索での見え方はローカルSEOとMEO・GBP最適化で扱っています。

実装の優先順位

すべてを同時に進める必要はありません。次の順で着手すると、前の作業の成果が次に活きます。

順番	作業	完了の判定
1	URLの棚卸し（パラメータ・絞り込み・並び替え・ページ送りの全パターン抽出）	生成されうるURLパターンが一覧化されている
2	公開対象の線引き（3条件での判定）	インデックスさせる組み合わせが確定している
3	canonicalとrobots.txtの実装	非公開対象がインデックス作成レポートから減り始める
4	サイト内検索結果ページのnoindex	検索結果URLがインデックスから外れている
5	在庫切れ・販売終了の処理ルール策定	状況別の対応が運用フローに組み込まれている
6	商品ページの構造化データ整備	リッチリザルトテストがエラーなしで通る
7	検索需要のあるカテゴリページの追加	新規カテゴリが流入を獲得し始めている

1から4までが「減らす」作業、5以降が「整える・増やす」作業です。順番を逆にすると、増やしたページが既存の重複に埋もれて評価されません。成果の見方と指標の置き方はSEO効果測定の方法、コンバージョン率の扱いはCVRの計算と改善施策を参照してください。

まとめ

ECサイトのSEOは、ページを増やす作業ではなく、自動生成されるURLのうちどれを検索対象にするかを決める作業から始まります。色10種・サイズ8種・並び替え4種という平凡な構成でも、組み合わせは320通りになり、ページ送りが掛かればさらに増えます。公開する組み合わせの基準を先に決め、canonicalとrobots.txtで線を引いてから、商品データの精度を上げる。この順番が最短です。

商品バリエーションは原則として1つの商品ページに統合し、単独で検索されている型番やカラー名だけ例外にします。個別URLに分ける場合も、Googleが用意しているバリエーション商品の構造化データで親子関係を明示できます。在庫切れではページを消さず在庫状況を正しく伝え、販売終了は後継商品の有無で301・ページ保持・404/410を使い分けます。掲載終了日が確定しているページに限ってunavailable_afterが使えますが、延長があり得るページで依存するのは避けてください。

レビューは他店と重複しない自社固有のコンテンツですが、やらせレビューと未開示の謝礼レビューはページ本文にも構造化データにも含めないようGoogleが明記しており、違反には手動対策がありうるとされています。構造化データは、その場で購入できるページなら販売者リスティングが基本形です。価格の有効期限・配送日数・返品可能日数・商品識別コードといった、数年前から使えるフィールドが空のままになっていないか、まずソースを開いて確認してください。そしてサイト内検索結果ページのnoindexは、後回しにされがちですが品質の問題に直結します。

本記事の構造化データに関する記述は、Google検索セントラルの「Product（商品）の構造化データについて」および「eコマースサイトのSEOベストプラクティス」（いずれも2026年9月5日取得。ページ上の最終更新日は2025-12-18）の記載範囲にもとづいています。必須・推奨プロパティは機能ごとに異なり更新されるため、実装前に公式ドキュメントとリッチリザルトテストで最新の要件をご確認ください。数値を伴う調査結果は、サイト内で報じたニュース記事（エージェント型商取引の可視性調査、AI Modeの商品カルーセル比較）で確認できる範囲のみを引用しており、いずれも出典と調査主体を本文に明記しています。EC市場規模や平均コンバージョン率などの推計値は、出典を確認できないため記載していません。

関連記事｜サイト種別別SEO

他の種別の考え方も見ておくと、自社の優先順位が判断しやすくなります。

• サイト種別で変わるSEO対策— 6タイプ別に打ち手の優先順位を整理した全体像
• BtoBサイトのSEO対策— 検索数が少ない前提での商談への設計
• コーポレートサイトのSEO対策— 指名検索と信頼性の設計
• 採用サイトのSEO対策— 求人の構造化データと応募導線
• メディアサイトのSEO対策— 回遊設計とAI検索時代の記事設計
• ポータル・比較サイトのSEO対策— 大量ページの品質を保つ設計

無料ダウンロード資料

はじめてのSEO 完全ガイド

Web担当になった人が、90日で自走するための実務書

検索エンジンの仕組みから、キーワード選定・記事づくり・技術対応・効果測定、 そしてAI検索時代の打ち手まで。専門用語の知識ゼロの状態から読み始められるよう、用語はすべて本文中で説明しています。

体裁	PDF／A4縦・全109ページ
収録	図解21点、チェックリスト120項目、90日実行プラン、用語集56語

※フォーム送信後、ご入力のメールアドレス宛にダウンロードリンクをお送りいたします。

資料の詳細と目次を見る

こちらのフォームにご記入ください

入力は1分ほどで終わります。

Website

会社名必須

部署名任意

お名前必須

メールアドレス必須

電話番号必須

従業員規模必須 選択してください 1〜9名 10〜49名 50〜99名 100〜299名 300〜999名 1,000名以上

SEOの検討状況必須 選択してください 何から始めるべきか検討中 自社で運用しているが成果が出ていない 外部への委託を検討している 現在の委託先を見直したい 情報収集のみ

プライバシーポリシーに同意する必須

資料をダウンロードする

ご入力いただいた情報は、資料のご送付および当社サービスのご案内のために利用します。