ECサイトのSEOとは、商品を探している人の検索に対して、自社のカテゴリページや商品ページを Google に正しく認識させ、検索結果に表示されるようにする取り組みのことです。記事型コンテンツを中心に考える一般的なサイトの SEO と違い、ECサイトでは「商品を買える URL をクロール・インデックスさせ、そのページで購入まで完結させる」ことが目的になります。
この記事では、2026年10月26日時点の Google 検索セントラルのドキュメントを根拠に、ECサイトの SEO 対策を「ステップ1｜インデックスの土台づくり」「ステップ2｜カテゴリページと商品ページの最適化」「ステップ3｜コンテンツSEOと外部対策」の順に整理し、最後に AI 検索（AI による概要（AI Overviews）・AIモード・ChatGPT）への備え、チェックリスト、よくある質問をまとめます。担当者が上から順に進められる構成にしています。
ECサイトのSEOが一般サイトと違う3つの理由
Google は ECサイト向けのガイドを公開しており、商品データやサイト構造を Google に伝えることで、Google 検索・画像検索・Google レンズ・ショッピングタブなど複数の面で商品が見つかりやすくなると説明しています（出典：Google 検索で e コマースサイトを見つけやすくするためのおすすめの方法）。そのガイドが前提にしている ECサイトならではの性質は 3 つあります。
理由1：自動生成ページが多く、クロールが分散しやすい
色・サイズ・価格帯・ブランドといった絞り込み（ファセットナビゲーション）を組み合わせると、ほぼ同じ商品一覧を表示する URL が大量に生まれます。Google は、こうした URL は役に立たないと判断できるまで大量にクロールする必要があり、「新しく有用な URL の検出が遅れる」こと、サーバー負荷が増えることを問題として挙げています（出典：ファセット ナビゲーション URL のクロール管理）。
理由2：商品の入れ替えと在庫変動で URL が不安定になる
季節商品の入れ替え、販売終了、在庫切れ、再入荷が日常的に起こるため、「昨日まであった URL が今日は 404 になる」「同じ商品が新しい URL で再登場する」といった状態になりがちです。Google は、セッション ID のような一時的なパラメータを内部リンクに使わず、長期的に変わらない URL を使うことで検索結果が安定すると説明しています（出典：e コマース サイトの URL 構造ベスト プラクティス）。
理由3：カテゴリページと商品ページで役割が分かれている
Google はサイト構造の理解にリンクを使うため、メニューからカテゴリ、サブカテゴリ、商品ページへと辿れる経路を用意し、「カテゴリページには、そのカテゴリの商品への直接リンクをすべて含める」ことを推奨しています。検索ボックスからしか辿り着けない商品は、Googlebot が通常は検索語を送信しないため見つけられない可能性があります（出典：Google が理解しやすい e コマース サイトの構造）。カテゴリページは「比較の場」、商品ページは「購入の場」として最適化の観点が異なります。
なお、複数の国・言語向けに展開する越境 EC では、上記に加えて hreflang による言語・地域の指定が必要です。詳しくは hreflang と地域ターゲット指定 をご覧ください。
ステップ1｜インデックスの土台づくり
ステップ1の要点は、「売りたい商品ページとカテゴリページが Google にクロール・インデックスされ、不要なページはクロールされない状態を作る」ことです。インデックスされていなければ検索結果には出ず、不要な URL が大量にクロールされると重要なページの検出や更新が遅れます。
Google がクロール・インデックスできるようにする
まず、検索結果に出したいページが Search Console で「インデックス登録済み」になっているかを確認します。Google は ECサイトのリリース手順として、Search Console で所有権を確認し、URL が少なければ URL 検査ツール、多ければサイトマップの送信でインデックス登録をリクエストし、「ページのインデックス登録レポート」で進捗を追跡するよう案内しています。Merchant Center は Google 検索のインデックスと照合して検証することがあるため、商品を購入できる状態でインデックス登録されていることを確認するよう述べています（出典：新しい e コマース サイトのリリースと Google への登録）。
「検出 − インデックス未登録」と「クロール済み − インデックス未登録」の見分け方
Search Console の「ページ」レポートには、エラーではないものの検索結果に出ていない URL が「インデックス未登録」として一覧されます。ECサイトで特に多いのが次の 2 つで、原因と対処が異なります。
| 項目 | 検出 − インデックス未登録 | クロール済み − インデックス未登録 |
|---|---|---|
| Google の説明 | 検出されたが、まだクロールされていない | クロールされたが、インデックスには登録されていない |
| URL の発見 | 完了 | 完了 |
| クロール | 完了していない | 完了 |
| インデックス | 完了していない | 完了していない |
| Google の案内 | 過負荷が予想されクロールが再スケジュールされた状態（対応方法の記載なし） | 再クロールのリクエストを再送信する必要はない |
（出典：ページ インデックス登録レポート – Search Console ヘルプ）
実務では、前者が大量に出ているときはクロールの到達性（サーバー応答、内部リンク、無駄な URL の多さ）を、後者が多いときはページの中身（薄い商品説明、重複、価値の低い絞り込み結果）を疑うのが基本です。切り分け手順は 検出 – インデックス未登録の原因調査・ツールで簡単解決 で解説しています。
不要ページの制御：robots.txt / noindex / canonical の使い分け
ECサイトのインデックス管理で最も重要なのが、絞り込みと並べ替えの URL です。Google は、検索結果に表示する必要のない絞り込み URL はクロールを許可してもサーバーリソースを消費するわりに得られるものが少ないとし、絞り込みなしの一覧ページと個々の商品ページのクロールを許可する方針を示しています。方法ごとの位置づけは次のとおりです（出典：ファセット ナビゲーション URL のクロール管理）。
- robots.txt で Disallow：クロールをブロックする最も強力な方法。
color=やsize=を含む URL を Disallow し、全件一覧は Allow する例が示されています。 - rel=”canonical”：絞り込み URL から絞り込みなしページを指定。非正規版のクロールが減ることがありますが、長期的には robots.txt より効果が低いとされています。
- rel=”nofollow”：該当 URL へのすべてのリンクに付ける必要があり、同じく長期的には効果が低いとされています。
- 該当商品 0 件の絞り込みや存在しないページ番号：HTTP 404 を返し、汎用エラーページへリダイレクトせずその URL 上で「見つかりません」と表示します。
並べ替え（価格順・人気順）のような「同じ一覧の別バリエーション」は、noindex の robots メタタグで除外するか、robots.txt で URL パターンをブロックするよう案内されています（出典：ページ分け、段階的ページ読み込み、それらの Google 検索に対する影響）。
最も間違えやすいのが noindex と robots.txt の併用 です。Google は「noindex ディレクティブを有効にするためには、robots.txt ファイルでページやリソースをブロックせず、クローラがページにアクセスできるようにする必要があります」と明記しています（出典：noindex を使用してコンテンツをインデックスから除外する）。既にインデックスされた絞り込み URL を消したいときは、まず noindex を付けてクロールさせ、消えたあとで robots.txt のブロックに切り替える順序になります。実装方法は noindex/nofollow の使い方とX-Robots-Tag、サイト内検索結果ページの扱いは サイト内検索結果ページのインデックスをブロックすべき理由とGoogleガイドライン改定後の最新方針 を参照してください。
チェック方法： Search Console ＞ 設定 ＞ クロールの統計情報、ページレポートの「robots.txt によりブロックされました」「代替ページ（適切な canonical タグあり）」の件数推移
ページネーション
Google は rel="next" / rel="prev" をページの順序把握に使わなくなっています。現在の推奨は、ページごとに ?page=n のような固有の URL を持たせ、<a href> で順番にリンクし、1 ページ目を一連のページ全体の正規 URL にしないことです。「もっと見る」や無限スクロールを JavaScript で実装する場合も、Google は <a href> の URL をたどって次のページを見つけるため、ボタンのクリックやスクロールを前提にせず、クロール可能なリンクを用意する必要があります（出典：ページ分け、段階的ページ読み込み、それらの Google 検索に対する影響）。
URL 構造と URL の維持
Google の URL 構造ベストプラクティスのうち、ECサイトで影響が大きい項目を抜粋します（出典：e コマース サイトの URL 構造ベスト プラクティス）。
- フラグメント（#）で内容を切り替えない：
/product/t-shirt#blackと#whiteは Google には同じページとして扱われます。 - セッション ID や時刻をパラメータに含めない：
/t-shirt?session=123123123のような URL は、クローラに無数のページがあると判断されるおそれがあります。 - URL パスに内容を表す語を入れる：
/product/black-t-shirt-with-a-white-collarは推奨、/product/3243は非推奨です。 - インデックスさせるページには自己参照の canonical を付け、サイトマップにもその URL を含める。
もう一つ、実務上効くのが「URL を変えない」ことです。季節キャンペーンや定期的に更新されるページは、毎回新しい URL を作らず既存 URL の内容を更新します。新しい URL は評価をゼロから積み直すことになる一方、既存 URL は蓄積された評価を引き継げます。過去の情報は履歴ページに分けて既存ページからリンクします。サイトマップの運用は XMLサイトマップの作り方・更新・分割運用までを押さえる実践ガイド をご覧ください。
表示速度とモバイル（Core Web Vitals）
Google は Core Web Vitals を含むページエクスペリエンスのシグナルを、コアランキングシステムが順位決定の際に考慮していると説明しています。目安は、LCP（Largest Contentful Paint：読み込み）が 2.5 秒以内、INP（Interaction to Next Paint：応答性）が 200 ミリ秒未満、CLS（Cumulative Layout Shift：視覚的安定性）が 0.1 未満です（出典：Core Web Vitals と Google 検索の検索結果について）。ECサイトは商品画像が多く LCP が悪化しやすいため、メイン画像の圧縮と優先読み込み、画像サイズ指定による CLS 対策が効果的です。
チェック方法： Search Console ＞ エクスペリエンス ＞ ウェブに関する主な指標
ステップ2｜カテゴリページと商品ページの最適化
ステップ2の要点は、「カテゴリページでは比較しやすさ、商品ページでは独自情報と正確な商品データ」です。購入意図のあるクエリはカテゴリ名や商品種別（「レディース スニーカー 白」など）であることが多く、商品ページよりカテゴリページに着地することが珍しくありません。
ECサイトのキーワード選定
商品名やブランド名にまで検索キーワードを入れない
サイト名や商品名そのものに「激安」「人気」「おすすめ」のような汎用的な検索語を入れると、逆効果になりやすい方法です。独自のブランド名は購入意欲が高い指名検索の受け皿ですが、汎用語をブランド名にすると指名検索そのものが競争の激しい一般クエリになり、収益性の高いブランドクエリの集客を失います。さらに、既存顧客が自社名で検索したときに同じ汎用語で上位表示されているライバルが並び、ブランドスイッチの機会を与えてしまいます。独自のブランド名を育て、クチコミやファンからの指名検索を増やすことが、長期的に最も確実な集客基盤です。
トランザクショナルクエリに記事コンテンツを当てない
購入目的（トランザクショナル）のクエリに対して、ハウツー型の長文記事で上位を狙うのは非効率です。購入目的のクエリには、比較に十分な商品数、分かりやすいカテゴリ分類、返品ポリシーや特定商取引法の表記、購入者のクチコミといった「安心して買える材料」を備えた購入ページを当てます。Search Console の検索パフォーマンスで「○○ 評判」「○○ サイズ感」のようなクエリが一定数あれば、そのクエリに答える情報を商品ページやガイド記事に追加します。
カテゴリページで考慮すべきポイント
カテゴリページは「比較の場」です。ユーザー視点のカテゴリ名、比較できる情報（価格・主要スペック・在庫）、有益な絞り込み条件を用意し、キーワードの詰め込みは避けます。Google は、商品のないカテゴリには noindex を設定するか、サイト内検索やブラウジングから外れる場合は 404 を返すことを推奨しています（出典：e コマース サイトの URL 構造ベスト プラクティス）。掲載商品が 0〜1 件しかない細分化されすぎたカテゴリは、比較の場として機能しないため上位カテゴリへ統合するのが基本です。カテゴリ名を H1 に置き、補足説明を H2・H3 で整理する見出し設計は H1タグ・H2タグとは？ で解説しています。
商品ページで考慮すべきポイント
商品ページは「購入の場」です。自社オリジナル商品でない限り同じ商品を扱うサイトは多数あり、メーカー提供の説明文をそのまま掲載しただけのページは他サイトと区別がつきません。Google はコンテンツの自己評価項目として、他のソースを参考にする場合は「単なるコピーや書き換えではなく」付加価値と独自性を示しているか、実際に製品を使った実体験が示されているかを挙げています（出典：有用で信頼性の高い、ユーザー第一のコンテンツの作成）。商品ページに載せる情報を優先度順に整理したのが次の表です。
| 優先度 | 情報 | 内容の例と目的 |
|---|---|---|
| 必須 | 商品名・ブランド名・型番 | 「ブランド名＋商品種別＋色・サイズ」を含むタイトルと H1。検索語との一致、バリエーションの区別 |
| 必須 | 価格・在庫状況・配送/返品条件 | 税込価格、在庫の有無、送料、返品期限。構造化データ・Merchant Center と整合させる |
| 必須 | 高解像度の商品画像（複数） | メイン画像、バリエーション画像、使用シーン。画像検索・Google レンズ・AI 検索での表示 |
| 推奨 | 仕様・サイズ・素材の詳細 | 実寸、重量、素材構成、対応機種。メーカー文の流用を避け、比較を助ける |
| 推奨 | スタッフレビュー・使用感 | 実際に使った感想、サイズ感、向き不向き。実体験に基づく独自情報 |
| 推奨 | 購入者レビュー | 評価と本文（良い点・悪い点の両方）。信頼性、レビュー評価の表示 |
| 推奨 | Q&A | 「○○と併用できますか」などの質問と回答。会話型の検索・AI 検索への対応 |
| 推奨 | 関連商品・上位カテゴリへのリンク | 同シリーズ、代替品、パンくずリスト。サイト構造の伝達と回遊 |
文字数稼ぎのテキストを足す必要はありません。「この商品を買う人が知りたいこと」を他サイトにない形で載せることが商品ページの SEO です。タイトルには「ブランド名・商品種別・色・サイズ」を含めると、検索エンジンにもユーザーにも区別しやすくなります。
在庫状況と販売終了ページの扱い
在庫切れそのものが順位に与える影響について、Google の公式ドキュメントに明確な記述はありません。一方で Google は、売り切れた商品がサイトでは購入不可でもフィードには反映されていない、といったタイムラグが価格・在庫の不一致を生むと説明しており（出典：商品データを Google と共有する）、欠品はショッピング面での表示に直接影響します。重要なクエリで上位表示している商品ほど欠品を避けることをおすすめします。
販売終了ページの扱いは、次の 3 択で判断します。
| 状況 | 推奨する対応 | 根拠 |
|---|---|---|
| 後継商品・同等品がある | 後継商品ページへ 301（永続的）リダイレクト | 永続的リダイレクトは「リダイレクト先が正規版であることを示すシグナル」として扱われ、検索結果にはリダイレクト先が表示される（出典：リダイレクトと Google 検索） |
| 再入荷の見込みがある | URL と内容を維持し「在庫なし」「入荷待ち」と表示。構造化データの availability も更新 | 永続的リダイレクトは「元に戻す予定がない場合」に使うものとされている（出典：同上） |
| 後継品がなく完全に終了 | 404 または 410 を返す（汎用エラーページへのリダイレクトはしない） | 4xx を返す URL はインデックスから削除され、クロール頻度は徐々に下がる。410 は 404 と同じ扱い（出典：HTTP ステータス コードが Google のクローラーに及ぼす影響） |
避けたいのは、販売終了ページを一律でトップページやカテゴリページへリダイレクトすることです。ユーザーは探していた商品にたどり着けず、Google にとっても無関係なページの代替名になるだけです。
構造化データ（Product / Offer / Review）とバリエーション商品
商品ページに Product 構造化データを追加すると、価格・在庫状況・レビュー評価・配送情報などが検索結果に表示される可能性があります。Google のドキュメントでは、購入できないレビュー中心のページ向けの「商品スニペット」と、購入できるページ向けの「販売者リスティング」の 2 種類があり、ECサイトの商品ページは後者が中心です。返品ポリシーとポイントプログラムは商品ごとではなく Organization にネストして指定することが推奨されています（出典：Google における商品の構造化データの概要）。ページ種別で見ると、カテゴリ・商品ページ共通の BreadcrumbList、商品ページの Product / ProductGroup、レビューのある商品ページの Review、会社情報ページの Organization、実店舗情報ページの LocalBusiness が ECサイトに関係します（出典：EC サイトで実装すべき構造化データ）。
実装で守るべきポイントは次のとおりです（出典：販売者リスティングの構造化データを追加する方法）。
- 単一商品のページにだけ付ける：「商品のリッチリザルトは単一の商品（または同じ商品の複数のバリエーション）に焦点を当てたページのみをサポートしています」とされ、複数商品を並べるカテゴリページではなく個別の商品ページにマークアップします。対象は買い物客が購入できるページのみで、マークアップする側が販売者である必要があります。
- 画像は高解像度で 16:9、4:3、1:1 の 3 比率を用意すると、表示先に合った画像が選ばれやすくなります。
- セール価格は現在の販売価格に
priceTypeを設定せず、期間をvalidFromとpriceValidUntilで指定します。
バリエーション商品（色・サイズ）のマークアップ
色やサイズのバリエーションがある場合は、ProductGroup で親商品を定義し、variesBy で何が異なるか（例：https://schema.org/color）を示し、hasVariant に各バリエーションの Product をネストします。各バリエーションには sku や gtin などの一意の ID と、クエリパラメータなどで直接選択できる URL が必要です。URL の持ち方は、1 ページで ?color=green のように事前選択する 単一ページ型（正規 URL はバリエーション未選択のベース URL 1 つだけ）と、バリエーションごとに別ページを持つ 複数ページ型 の 2 通りです。同じドキュメントは、動的に生成されるマークアップが「Google ショッピングのクロールの頻度と信頼性を下げる可能性がある」と注意しており、在庫や価格のように頻繁に変わる情報では特に影響が大きいとしています（出典：バリエーション商品の構造化データ（ProductGroup、Product））。価格や在庫を含む構造化データは、JavaScript 実行後に挿入するのではなく、サーバーサイドで HTML に含めて出力することをおすすめします。
URL 構造の観点では、Google はバリエーションに /t-shirt/green または /t-shirt?color=green の形式を推奨し、オプションのクエリパラメータを使う場合は「そのパラメータを除いた URL を正規 URL」とするよう案内しています（出典：e コマース サイトの URL 構造ベスト プラクティス）。
チェック方法： Search Console ＞ ショッピング ＞ 販売者のリスティング、リッチリザルト テスト
Google Merchant Center フィードと構造化データの整合
Google は、商品ページへの構造化データの追加と Merchant Center へのデータ提出の 両方 を推奨しています。構造化データは検索結果の商品リッチリザルトに主に使われ、Merchant Center は Google ショッピングタブへの掲載に必須です。両方を使うと Google がデータを検証しやすくなります。提出方法は、小規模サイト向けの 自動フィード、大規模サイト向けの フィードファイルのアップロード、在庫など即時の更新が必要な場合の Content API の 3 つです（出典：商品データを Google と共有する）。
価格・在庫の矛盾に注意
Merchant Center には、ランディングページの構造化データ（price、availability、itemCondition など）を読み取り、フィードの価格・在庫・状態をページに合わせて自動更新する機能があります。ただし、不一致が検出された場合は「商品が更新されずに不承認となることがあります」とされ、取り消し線付きの旧価格があるページでは価格を誤認する可能性があるため価格の自動更新を有効にしないよう注意も書かれています（出典：Merchant Center による商品情報の自動更新を許可する）。実務上のルールは、ページの表示価格・構造化データの価格・フィードの価格を常に一致させることです。税込/税抜の表記揺れ、セール終了後の構造化データの更新漏れ、JavaScript で後から書き換えられる価格表示が、不一致の典型的な原因です。
Google ビジネスプロフィールと「SEO と MEO のどちらが大事か」
実店舗がある場合は、Google ビジネスプロフィールに登録し Merchant Center と連携することで、店舗在庫付きの商品を Google マップ上に表示できるようになります（出典：Google で e コマース コンテンツが表示される場所）。
「SEO と MEO（マップ検索対策）のどちらが大事か」は、販売チャネルによります。オンラインのみで販売するなら来店導線である MEO の優先度は下がり、本記事の 3 ステップに集中すべきです。実店舗があり「近くで買いたい」「今日欲しい」というニーズに応えるなら MEO は SEO と同じくらい重要で、両者は Merchant Center とビジネスプロフィールの連携でつながっています。商品データ（フィード・構造化データ）を共通の土台として両方に展開するのが現実的です。
ステップ3｜コンテンツSEOと外部対策
ステップ3の要点は、「商品ページだけでは取れない検索（選び方・比較・使い方）をガイド記事で受けて商品ページへ送客すること」と、「ECサイトならではの被リンクとレビューで信頼性を積み上げること」です。ステップ1・2 が整っていない状態で記事を量産しても効果は限定的です。順番を守ってください。
「選び方」「使い方」記事で潜在層を集め、商品ページへ送客する
購入前のユーザーは「○○ 選び方」「○○ 比較」「○○ サイズ 目安」のような情報収集型のクエリで検索します。こうしたクエリはカテゴリページや商品ページでは応えにくいため、ガイド記事で受け、記事内から該当カテゴリ・商品ページへリンクします。Google も、ベストセラー商品はホームページやブログ記事など他のコンテンツからもリンクすると重要性が伝わりやすくなると述べています（出典：Google が理解しやすい e コマース サイトの構造）。
記事のテーマは、Search Console に既に表示されている細かなクエリから選ぶのが確実です。検索数は少なくても購入に近いクエリを集める考え方は ロングテールSEOとは? で解説しています。記事と商品ページの役割を分けることで、「トランザクショナルクエリに記事を当てない」原則とも両立します。
専門家・購入者レビューの獲得
商品・ブランド・カテゴリのクエリで上位表示を狙う際に、その分野の専門家や影響力のある人にレビューを依頼する方法があります。自社サイトでも外部サイトでも、Google が「質の高いレビューを書く」として挙げる要素、すなわち専門性を示す、画像などで信頼性の裏付けを提供する、測定結果など定量的なデータを示す、競合との違いを説明する、メリットとデメリットの両方を独自の調査に基づいて述べる、などを満たすことが重要です（出典：レビューの書き方）。購入者レビューも、良い評価だけでなく悪い点も含めて正直に表示することが信頼につながります。Google は E-E-A-T（経験・専門性・権威性・信頼性）のうち「信頼性は最も重要なもの」と説明しています（出典：有用で信頼性の高い、ユーザー第一のコンテンツの作成）。
EC 特有の被リンク獲得
ECサイトは記事メディアと違い自然に紹介されにくい面がありますが、ECサイトならではの機会があります。
- 取引先・メーカーの「取扱店一覧」「正規販売店」ページからのリンク。正規取扱店であれば依頼しやすく関連性も高い
- プレスリリース：新商品・限定商品・コラボ商品の発表はニュースサイトや業界メディアに取り上げられる機会になる
- イベント協賛・地域活動：実店舗がある場合、地域のイベントや団体のサイトからの紹介
- 専門家レビューの外部掲載：レビューと被リンクを同時に得る
購入したリンクや相互リンク集のような手法は Google のスパムポリシーに抵触するおそれがあるため避けてください。「紹介される理由」を商品・ブランド側に作ることが先です。
SEO に強い EC 会社・プラットフォームの選び方
「SEO に強い ECサイト構築会社はどこか」には、特定の社名ではなく選定基準でお答えします。ステップ1・2 の要件を標準機能または設定で満たせるかが判断軸です。
| 確認項目 | 確認する内容 |
|---|---|
| URL 制御 | 絞り込み・並べ替え URL を robots.txt / noindex / canonical で制御でき、ページネーションが固有 URL と <a href> で実装されているか |
| 構造化データ | Product / ProductGroup / BreadcrumbList をサーバーサイドで出力できるか |
| 販売終了時の挙動 | 商品ごとに 301 / 404 / 在庫なし表示を選べるか |
| Merchant Center 連携 | フィード生成に対応し、価格・在庫がページと同期されるか |
| 実績の示し方 | Search Console のデータなど検証可能な形で説明し、提案の根拠を Google 公式ドキュメントで示せるか |
AI 検索時代の EC SEO
2026年10月26日時点で、「ec サイト seo」のような情報収集型のクエリでは検索結果の最上部に AI による概要が表示され、商品そのものの検索でも AIモードや ChatGPT などの会話型 AI で商品を探す行動が広がっています。
Google の AI による概要・AIモードで引用される条件
Google は「AI による概要や AI モードにコンテンツが表示されるための追加の要件はなく、別途特別な最適化を行う必要もありません」とし、「新たにコンピュータが解読可能なファイルや AI テキスト ファイル、マークアップを作成する必要はありません」とも明言しています。同じドキュメントが挙げる確認事項のうち ECサイトに関係するのは、ページがインデックス登録されスニペットが表示されていること（ステップ1）、重要なコンテンツをテキストで提示し画像・動画で補うこと（ステップ2）、構造化データをページに表示されているテキストと一致させること、Merchant Center とビジネスプロフィールを最新に保つことです。AI による概要・AIモードからのトラフィックは、Search Console の検索パフォーマンスで検索タイプ「ウェブ」に含めて計測されます（出典：AI 機能とウェブサイト）。
つまり、AI 検索向けに特別なことをするのではなく、本記事の 3 ステップを確実に実行することがそのまま AI 検索対策になります。記事型コンテンツが引用されやすくなる書き方は AIによる概要を最適化する方法：実践すべき7つのベストプラクティス で解説しています。
ChatGPT ショッピングへの備え
OpenAI は ChatGPT 上で商品を会話形式で探し、画像・価格・レビュー・店舗リンクを表示する商品検索機能を提供しています。「2 万円以下の白いスニーカーで、通気性の良いもの」のように自然言語で条件を伝えるだけで候補が提示される体験です（本節は OpenAI の発表に基づく記述で、Google 公式の見解ではありません）。準備すべきことは Google 向けの対応とほぼ重なります。
| 項目 | 対策内容 |
|---|---|
| 商品ページの構造化 | schema.org/Product のマークアップを実装し、AI が読み取れる情報を強化する |
| 商品画像の整備 | 高解像度のメイン画像・バリエーション画像を用意する |
| 商品レビューの拡充 | オーガニックなレビューを獲得し、AI が信頼情報として参照できるようにする |
| 商品情報フィードの提供 | 商品データ連携の窓口が広がる可能性に備え、フィードを整備しておく |
| FAQ・Q&A の整備 | 会話ベースの質問に答えられるよう、商品ページに Q&A を掲載する |
Google 検索でも ChatGPT でも、どちらの入口でも読み取られるのは「商品ページの構造化データ」「画像」「レビュー」「フィード」です。商品データの品質を一本化して高めることが AI 時代の EC SEO の本質です。
ECサイト SEO チェックリスト
3 ステップと AI 検索の項目を「確認場所・担当・頻度」で一覧にしました。そのまま社内の運用表として使えます。
| ステップ | 項目 | 確認場所 | 担当 | 頻度 |
|---|---|---|---|---|
| 1 | 重要ページがインデックス登録済みか | Search Console ＞ URL 検査／ページ | SEO 担当 | 週次 |
| 1 | 「検出 − インデックス未登録」「クロール済み − インデックス未登録」の件数推移 | Search Console ＞ ページ | SEO 担当 | 週次 |
| 1 | 絞り込み・並べ替え URL が robots.txt / noindex / canonical で制御され、noindex ページが robots.txt でブロックされていないか | robots.txt、ページソース | 開発 | 改修時 |
| 1 | 0 件の絞り込み・存在しないページ番号が 404 を返すか | 実機確認 | 開発 | 改修時 |
| 1 | ページネーションが固有 URL と <a href> で実装されているか | ページソース | 開発 | 改修時 |
| 1 | Core Web Vitals（LCP 2.5 秒以内 / INP 200 ミリ秒未満 / CLS 0.1 未満） | Search Console ＞ ウェブに関する主な指標 | 開発 | 月次 |
| 2 | 商品名・サイト名に汎用的な検索語を入れていないか | 商品登録ルール | 商品企画 | 新商品登録時 |
| 2 | カテゴリページに全商品への直接リンクがあり、商品 0 件のカテゴリが noindex または 404 か | カテゴリ一覧、Search Console | EC 運用 | 月次 |
| 2 | 商品ページにメーカー文以外の独自情報（サイズ感・使用感・Q&A）があるか | 商品ページ | EC 運用 | 新商品登録時 |
| 2 | 販売終了商品が 301 / 404 / 在庫なし表示のいずれかで処理されているか | 販売終了フロー | EC 運用 | 販売終了時 |
| 2 | Product / ProductGroup 構造化データがサーバーサイドで出力され、エラーが無いか | Search Console ＞ 販売者のリスティング | 開発 | 月次 |
| 2 | ページ価格・構造化データ・Merchant Center フィードの価格と在庫が一致しているか | Merchant Center ＞ 診断 | EC 運用 | 週次 |
| 3 | 「選び方」「使い方」記事から該当カテゴリ・商品ページへリンクしているか | 記事一覧 | コンテンツ担当 | 記事公開時 |
| 3 | レビューが良い点・悪い点の両方を含む形で掲載されているか | 商品ページ | EC 運用 | 月次 |
| 3 | 取引先・メーカーの取扱店ページからリンクされているか | 被リンク一覧 | マーケ担当 | 四半期 |
| AI | 構造化データの内容がページ表示と一致し、AI 経由の流入を検索パフォーマンスで把握しているか | リッチリザルト テスト、Search Console | SEO 担当 | 月次 |
よくある質問
ECサイトでSEOとは何ですか？
商品を探している人の検索に対して、自社のカテゴリページや商品ページを Google に正しくクロール・インデックスさせ、通常の検索結果・画像検索・ショッピングタブ・AI による概要などに表示されるようにする取り組みです。記事を書くことよりも「売れるページが検索結果に出る状態を作る」ことが中心で、①インデックスの土台づくり ②カテゴリ・商品ページの最適化 ③コンテンツSEOと外部対策 の 3 ステップで進めます。
ECサイトでSEOに効果的な対策は何ですか？
順番を守ることです。まず絞り込み・並べ替え URL の制御と販売終了ページの処理でインデックスを整理し、次に商品ページの独自情報・Product 構造化データ・Merchant Center フィードの整合を整え、そのうえで「選び方」記事やレビュー、取引先からのリンクで補強します。ステップ1・2 が整っていない状態で記事やリンクを増やしても効果は限定的です。
ECサイトのSEOに強い会社はどこですか？
特定の社名ではなく選定基準で判断することをおすすめします。絞り込み URL の制御、サーバーサイドの構造化データ出力、販売終了時の 301 / 404 の選択、Merchant Center との価格・在庫同期を標準機能や設定で満たせるか、提案の根拠を Google 公式ドキュメントで示せるかを確認してください。
SEOとMEO、どちらが大事ですか？
販売チャネルによります。オンラインのみで販売するなら SEO が優先です。実店舗があり「近くで買いたい」「今日欲しい」というニーズに応えるなら MEO（Google ビジネスプロフィールとマップ検索の対策）も同じくらい重要です。両者は Merchant Center とビジネスプロフィールの連携でつながっており、商品データを共通の土台にして両方へ展開するのが現実的です。
まとめ
ECサイトの SEO 対策は、①インデックスの土台づくり（不要 URL の制御・販売終了ページの処理・URL の安定）、②カテゴリページと商品ページの最適化（比較情報・独自情報・Product 構造化データ・Merchant Center との整合）、③コンテンツSEOと外部対策（選び方記事・レビュー・EC 特有の被リンク）の順に進めます。AI による概要・AIモード・ChatGPT といった新しい入口に対しても、Google は「追加の要件はない」と明言しており、この 3 ステップで整えた商品データがそのまま読み取られます。
まずは Search Console の「ページ」レポートでインデックス未登録の内訳を確認し、絞り込み URL と販売終了ページの処理から着手してください。本記事のチェックリストを運用表として使い、週次・月次で状態を確認していくことが、順位の安定と売上につながる最短ルートです。
