AI時代のECサイトSEO設計 — 3つの読み手と、判断が割れる4つの場面

結論、ECのSEOは3つの読み手に同時に最適化する設計になった

これまでのECサイトのSEOは、人とGooglebotの2つを相手にしていました。ここに3つ目の読み手が加わっています。AIクローラーです。

3つは同じページを見ていますが、読み方が違います。設計の判断が難しくなったのは、この3つの要求が一致しない場面があるからです。表示速度のために遅延描画したレビューは、人には速く見え、Googlebotには読め、AIクローラーには存在しません。

人・Googlebot・AIクローラーは、同じページを違うふうに読む

まず違いを整理します。

最も差が大きいのはJavaScriptの扱いです。Googlebotはレンダリングを行うので、JavaScriptで描画された価格も読めます。一方、GPTBot、OAI-SearchBot、ClaudeBot、PerplexityBotといった主要なAIクローラーはJavaScriptを実行せず、返ってきたHTMLしか読みません。Google系のAI機能だけが例外で、Google検索のインデックスを土台にしているためレンダリング済みの情報を使えます。

この非対称が、Googleで上位表示されているページがChatGPTからは空に見えるという状況を生みます。実測を含む詳細はECサイトのLLMO対策で扱いました。

変わらないSEOの土台

先に不安を消しておきます。全部作り直す必要はありません。Googleも公式ガイドで、既存のSEOのベストプラクティスは引き続き有効だと明言しています。

インデックス設計は変わりません。何をインデックスさせ、何をさせないか。この判断がサイト全体の評価を決める構造は同じです。重複コンテンツの扱いも同じで、色違い・サイズ違い・並び替えのURLをcanonicalでまとめる定石は有効です。

カテゴリ構造と内部リンクも土台のままです。トピックの近い商品をまとめ、ハブとなるページから辿れるようにする設計は、AIから見ても情報の関係が読み取りやすくなります。表示速度とモバイル対応は、人の体験に直結する要素として、これまでどおり重要です。

これらは前提条件になったと考えてください。土台が無いところに新しい施策を積んでも効きません。対策全体の見取り図はLLMO対策とは何かにまとめています。

AI時代に足す4つの要件

土台の上に足すのは4つです。それぞれに「なぜ土台だけでは足りないか」を添えます。

2つ目の実装はECの構造化データ実装ガイドに、3つ目はMerchant Centerと商品フィードにまとめました。

SEOとAIで判断が割れる場面

ここが実務でいちばん困る部分です。4つ取り上げます。

絞り込み・ファセットのURLをどうするか

SEOの定石は制御です。絞り込み条件の組み合わせでURLが無限に増えると、クロールバジェットが浪費され、薄いページが大量に生成されます。noindex、canonical、パラメータ制御で抑えるのが基本でした。

一方でAIは「防水で5万円以下の掃除機」のような条件付きの質問に答えます。条件に合う商品群がまとまったページは、AIにとって有用な情報源です。全部潰すと、この経路を自ら閉じることになります。

裁き方は、需要のある組み合わせだけを静的な一覧として持ち、それ以外は制御することです。検索需要のある2軸までの組み合わせを選び、それを独立したページとして作る。3軸以上や需要のない組み合わせは従来どおり制御します。閾値を決めておけば、判断が属人化しません。

JavaScriptでの遅延描画をどこまで許すか

表示速度のためにレビューやスペック表を遅延描画する設計は一般的です。しかしAIから見ると、遅延描画された部分は存在しません。

裁き方は、初期HTMLに含める要素の優先順位を決めることです。価格、在庫、主要スペック、レビューの要約は初期HTML。レビューの全件表示、関連商品、閲覧履歴は遅延で構いません。「AIが答えに使う情報かどうか」で線を引いてください。顧客が質問しそうな内容が初期HTMLにあれば足ります。

カテゴリページを増やすか、絞るか

薄いページの量産は、クロールの抑制を招きます。当社自身が経験しました。2026年6月に、当社サイトのインデックス数が約1,000から787へ減少しています。技術的な不具合ではなく、薄い日次記事を量産したことによるクロール抑制が原因でした。

裁き方は、ページを作る基準を「独自の情報があるか」に統一することです。商品を並べ替えただけのページには独自の情報がありません。そのカテゴリ特有の選び方、比較の軸、注意点が書けるなら作る。書けないなら作らない。この基準なら、担当者が変わっても判断がぶれません。

レビューを自社に集めるか、外部に置くか

AI引用では第三者面の評価が効きます。一方、自社サイトの情報充実にもレビューは必要です。どちらを優先するか。

裁き方は両方です。ただし性質が違うので管理を分けます。自社レビューは構造化して機械可読にし、商品ページの情報として使う。外部レビューは獲得施策として、掲載先の選定と依頼の運用を別に持つ。同じ「レビュー施策」として1人に任せると、片方しか進みません。

主要カートでの実務

Shopifyを例に挙げます。テーマによってJavaScript描画の範囲がかなり違うため、まずJavaScriptを無効にして商品ページを開いてください。価格が消えるテーマは実際にあります。

標準テーマの多くはProductとOfferのJSON-LDを出力しますが、GTINやbrand、priceValidUntilが空のまま出ていることがよくあります。リッチリザルトテストで実際に何が出力されているかを確認し、不足があればテーマのテンプレートで補ってください。

URL構造は /products/ と /collections/ に固定されており、変更できません。この制約は受け入れたうえで、コレクションの設計で情報の関係を作ります。フィード連携はアプリ経由が基本です。

他のカートでも確認する観点は同じです。JavaScript依存の範囲、標準のschema出力、フィード連携の方法、URL構造の自由度。設定名や画面はバージョンで変わるので、着手時に実機で確認してください。

商品数が多いサイトの優先順位

10万点ある商品すべてに同じ手をかけることはできません。優先順位を決めます。

候補にすら入っていない店が、実は多い

順位の話に入る前に、その手前の段階を見ておきます。

当社が箱根の宿泊施設についてAIの推薦を調べた調査では、推薦に登場した施設は114施設でした。町内には454施設あるので、名前が挙がったのは約25.1%にとどまります。4分の3の施設は、そもそも候補として名前が出ていません。

沖縄の調査では、上位5施設が全推薦の44.2%を占めました。少数の施設に推薦が集中する構造です。

ECでも同じことが起きていると考えられます。上位を争う以前に、候補リストに載るという段階があります。そして候補に入るための要件は、順位を上げる要件よりずっと基礎的です。初期HTMLで情報が読めること、情報が矛盾していないこと、第三者面に名前があること。この記事で扱ってきた内容がそのまま効きます。

効果測定の設計

従来のSEO指標に、AI指標を足します。

従来側は表示回数、順位、流入、CV。ここは変わりません。足すのは言及率（想定プロンプトで自社が挙がる割合）、推薦順位（挙がったときの位置）、AI経由流入の3つです。

道具は2つあります。Search Consoleの生成AIパフォーマンスレポートは、AI OverviewsとAIモードでの表示回数を通常のオーガニックと分離して見られます。現時点で見えるのは表示回数のみです。GA4はチャネルの分離設定が必要で、これをしないとAI経由の流入がdirectに吸収されます。

工程として順に進めたい場合はAI検索対策の10ステップ、点検項目として確認したい場合はチェックリスト22項目を使ってください。

よくある質問

まとめ

ECのSEOは、3つの読み手を前提にした設計になりました。土台は変わらず、足すのは4つです。主要情報のサーバーサイド出力、商品データの機械可読化、フィード、第三者面での言及。

判断が割れる場面には基準を決めてください。ファセットは需要のある2軸まで、遅延描画は「AIが答えに使う情報かどうか」で線を引く、カテゴリページは独自の情報があるときだけ作る。基準があれば、担当者が変わっても設計がぶれません。

そして、順位を争う前の段階があります。実測では、候補として名前が挙がった施設は全体の約4分の1でした。まず候補に入ること。そのための要件は、この記事で扱った基礎的なものばかりです。当社では小売・EC事業者向けに無料のAI可視性診断を提供しています。