ECサイトのSEO対策15選｜商品ページとカテゴリページの改善方法【2026年版】

ECサイトのSEO対策では、検索エンジンが商品情報へたどれる構造を整えます。そのうえで、カテゴリでは商品を比較しやすくし、商品ページでは購入条件を確認できるようにします。商品説明の文字数を増やすだけでは、絞り込みURLの増殖や価格・在庫の食い違いは解決できません。

重要商品が検索から見つからないなら、リンクとインデックスの確認が先です。すでに見つかっているなら、カテゴリの選択軸と商品の購入条件から改善できます。この記事では自社ECを対象に、15の施策と、既存売上への影響を抑えながら変更する確認手順を紹介します。

この記事でわかること

• カテゴリと商品ページで検索意図を分担する方法
• 商品属性・在庫・送料・返品の記載例
• 絞り込み・ページ分割・バリエーションURLの扱い
• ページ・構造化データ・商品フィードを照合する方法
• 変更後に続行・再調査・切り戻しを判断する基準

症状	最初の確認	この記事の施策
重要商品が検索に出ない	URL検査・カテゴリからのリンク	4・14
カテゴリは表示されるが選ばれない	検索意図・title・比較情報	1〜3
商品を見ても購入されにくい	適合条件・送料・納期・返品	5〜8
不要なURLが大量に取得される	絞り込みの生成規則・クロール状況	9・10
一覧の後半商品が見つからない	2ページ目のURL・商品リンク	11
色違い・欠品・終売の扱いが混乱する	選択状態・在庫・URLの継続方針	12・13
検索側の価格・在庫が古い	表示・構造化データ・フィードの更新元	15

※症状だけで原因は確定しません。対象URLを確認してから変更します。

着手先が決まったら、該当する施策と検証方法を確認してください。

最初に重要URLと商品データの状態を確認する

最初に調べるのは、売上や粗利を担う商品、これから販売を伸ばしたい商品、その商品が並ぶカテゴリです。すべてのURLを同じ優先度で直すと、重要ページの問題が埋もれてしまいます。

Search ConsoleのURL検査で、対象URLのインデックス状態、Googleが選んだ正規URL、取得の問題を確認しましょう。正規URLとは、同じ内容のURLが複数あるときに代表として扱うURLです。canonicalで指定したURLと、Googleの選択が一致するとは限りません。

重要URLで先に確認すること

• 意図しないnoindexやrobots.txtの遮断がない
• カテゴリから商品へ、hrefを持つリンクでたどれる
• サイト内検索へ商品名を入力しなくても商品へ到達できる
• 商品名・価格・在庫が、表示と商品データで一致している
• サイトマップに検索へ出したい正規URLが含まれている

GoogleはECサイトの構造を、URLの見た目だけでなくページ間のリンクから理解します。通常のナビゲーションで全商品へリンクしきれない場合、サイトマップや商品フィードも発見を補えます。ただし、送信すれば必ずインデックスされるわけではありません。

商品が速やかに見つかり、不要URLの増殖もない小規模ECなら、高度なクロール調整より商品情報の改善を先に進めてよいでしょう。反対に、新商品が発見されにくく、絞り込みURLばかり取得されているなら、URL設計の調査が必要です。

出典：Google 検索セントラル『e コマースサイトの構造を Google が把握できるようにする』（2026年10月15日確認）

変更前の状態を保存する

URL、canonical、noindex、robots.txtを変える前に、対象URLと設定を保存してください。検索流入があるページを誤って除外したとき、元の状態を追えるようにするためです。

改善前に残す基準値と設定

• ページ別の検索表示回数・クリック・主なクエリ
• 自然検索を入口とした商品閲覧・カート追加・購入・売上
• 重要URLのインデックス状態とGoogleが選んだ正規URL
• canonical・noindex・robots.txt・リダイレクトの現状
• 商品数、検索対象URL数、サイトマップURL数
• 商品マスタ・価格・在庫の更新元と反映先

商品ページとカテゴリページは検索意図で役割を分ける

商品ページは「この商品を買えるか」、カテゴリページは「どの商品を選ぶか」に答えます。同じキーワードが両方に入るだけで、競合するページだと判断する必要はありません。

検索の型	受けるページ	確認したい内容
商品名・型番	商品ページ	仕様・価格・在庫・購入条件
商品群・カテゴリ	カテゴリページ	品揃え・比較軸・選び方
ブランド×商品群	ブランド内の一覧	ブランド内の違い
用途・条件×商品群	条件別の一覧	条件に合う商品の比較
商品名×送料・在庫	商品ページ	その商品の配送・購入可否

※自社の取扱商品、実際の検索結果、Search Consoleのクエリで調整します。

「オフィスチェア」「敏感肌 化粧水」「1万円以下 バッグ」のように候補を比べる検索には、一覧と選択軸が必要です。一方、型番を指定して探す人には、別の商品群を長く説明するより、該当商品の適合条件や在庫を伝えます。

一つの検索語について、検索結果が主に商品詳細なのか商品一覧なのかを見て、候補ページを選びましょう。そのうえで、同じ意図のページが複数ないかを確認します。検索語の表記違いだけで新しい一覧を量産せず、実際に異なる商品集合と選ぶ理由があるかを基準にします。

検索意図と事業価値を合わせて考える手順は、SEOキーワード選定のやり方で解説しています。

カテゴリページで比較しやすくする4施策

カテゴリには、商品のリンクだけでなく、その一覧から選ぶための情報を置きます。長い説明文で商品を押し下げる必要はありません。用途や寸法など、比較に使う情報を商品一覧の近くで確認できる形にします。

施策1：検索に出したいカテゴリを選ぶ

検索対象にするのは、継続して扱う商品群があり、他の一覧と役割が違い、購入者がその条件で選びたいカテゴリです。一時的なキャンペーン条件や、別カテゴリと商品も説明もほぼ同じ一覧まで、すべて検索対象にする必要はありません。

商品が1点だから一律に除外するのではなく、その1点で検索意図を満たせるかを見ます。反対に、商品が多くても分類名だけでは選びにくいなら、用途や比較軸を整理します。欠品中の定番カテゴリと、存在しない絞り込み条件も分けて判断してください。

施策2：title・H1・導入文でカテゴリの役割を伝える

titleは検索結果でページの内容を伝え、H1はページ内で一覧の対象を示します。同じ語を無理に繰り返すより、何の商品を、どんな条件で探せるかを揃えましょう。

場所	記載例
title	収納棚・ラック｜幅・奥行き・用途から選ぶ
H1	収納棚・ラック
導入文の要点	置き場所と収納物から選ぶ
条件別一覧	幅60cm以下／本・書類用／工具なしで組み立てられる商品

※説明用の例です。実在する品揃えや販売実績を示すものではありません。

導入文は「置き場所の幅と奥行き、収納する物の重さから選べます。各商品の寸法・耐荷重・組立条件を比較してください。」のように書けます。この例では、カテゴリは収納棚全体の比較を受け持ちます。

「幅60cm以下」を独立ページにするかは、検索需要と該当商品の継続性で判断します。商品が条件に合わないのに、検索語だけをtitleへ追加しないでください。

施策3：比較軸を商品一覧の近くに置く

収納棚なら幅・奥行き・耐荷重、オフィスチェアなら本体幅・座面高・調整機能が比較軸になります。商品カードにも主な寸法と価格を表示できれば、詳細ページを往復する負担を減らせます。

化粧品では内容量、使用方法、メーカーが確認している対象や注意事項を比較材料にします。制作側が効能や適合を創作しないことが前提です。価格だけで並べると選びにくい商材は、用途や対応条件から絞れるようにします。

施策4：商品へクロール可能なリンクを置く

商品名や画像から詳細へ移動するリンクは、基本的にhrefを持つa要素にします。クリックイベントだけで移動するボタンは、商品を発見する経路として頼らないようにしてください。JavaScriptで生成しても、取得されたHTMLに商品URLを持つリンクがあるかが確認点です。

合格の目安は、カテゴリの取得内容に商品リンクがあり、そのURLを直接開くと該当商品が表示されることです。一覧の後半商品は、施策11のページ分割と合わせて調べます。

商品ページで購入条件を伝える4施策

商品ページでは、商品を特定できる情報、使える条件、購入にかかる費用と時間を確認できるようにします。説明文を増やしても、置ける寸法や送料が不明なままでは購入の判断が止まります。

情報	読者が判断できること
商品名・型番・ブランド	探していた商品と同じか
寸法・材質・重量・容量	使う場所や用途に合うか
対応機種・使用条件・対象外	自分の環境で使えるか
税込価格・追加費用	支払う総額はいくらか
在庫・発送・配送地域	購入でき、必要な時期に届くか
返品・交換条件	購入後に困った場合どうなるか
写真・動画・実際のレビュー	大きさや使い方、評価を確認できるか

施策5：商品名・型番・ブランドを揃える

商品マスタ、ページのtitle・H1、パンくず、構造化データで、同じ商品を特定できる名称を使います。titleとH1を一字一句同じにする決まりではありません。色や容量の違いで商品を取り違えないことが大切です。

メーカーの型番と自社SKUは分けて管理してください。SKUは自社で商品やバリエーションを管理する識別子です。型番が共通でも、販売する色・サイズや在庫単位が違う場合があります。

施策6：仕様・用途・対応しない条件を具体化する

家電では電源・接続端子・対応機器、家具では設置寸法・搬入経路・組立条件を示します。「どんな場所にも合う」と広く書くより、適合しない条件まで確認できる方が選びやすくなります。

項目	記載例
商品の識別	収納棚SR-60・ホワイト
寸法	幅60×奥行30×高さ90cm
耐荷重	棚板1枚あたり10kg。均等に載せた場合
用途	本・書類・小物の収納
組立条件	購入者による組立が必要。プラスドライバーを使用
対象外	屋外・水がかかる場所では使用できません
設置前の確認	設置幅に加え、組立作業と搬入のスペースを確認

※数値と条件は説明用の仮定です。実商品ではメーカー資料と実際の販売条件で置き換えます。

数値には単位と条件を付けます。耐荷重の測定条件、家電の対応機種、化粧品の使用上の注意は、メーカーが確認していない内容を推測で埋めないでください。

施策7：価格・在庫・配送・返品を購入ボタンの近くに置く

価格は税込か、送料や設置費が別かを明確にします。配送は「発送日」と「到着日」を区別し、地域・受付時刻・在庫状況によって変わる条件を示しましょう。購入ボタンを押す前に、確認先が分かる配置にします。

たとえば「税込8,800円／送料は配送先により計算／在庫あり／入金確認後2営業日以内に発送／到着目安は配送先を選んで確認」のように、価格・費用・在庫・時間の条件を並べます。これは説明用の表示例であり、実際の価格や納期を約束するものではありません。

返品は、購入者都合と不良品対応で条件が異なるなら分けて案内し、詳細な受付条件へリンクします。ページとカートで費用や条件が食い違っていないかも確認してください。実際の販売条件や法令・利用規約への適合は、SEOの表示改善とは別に確認が必要です。

施策8：画像・動画・レビューを商品選びに使う

主画像に加え、色の違い、使用時の大きさ、設置状態、付属品が分かる写真を用意します。操作や組立が重要な商品には、動画が判断材料になります。画像の代替テキストは内容を説明し、検索語を羅列しません。

レビューを掲載する場合は、実際の投稿に基づく内容と件数を使ってください。見えている評価と構造化データが違う、架空の評価を追加する、といった処理は避けます。

絞り込み・ページ分割・在庫のURLを整理する5施策

URLを整理するときは、「検索結果へ出したいか」と「クロールさせる必要があるか」を分けます。検索対象から外したい既存URLと、今後増やしたくない不要URLでは、確認する状態も手段も違います。

施策9：検索需要がある絞り込みは恒久ページとして検討する

「幅60cm以下の収納棚」のように、購入者がその条件で比較し、該当商品を継続して揃えられるなら、条件別一覧を検索対象にする余地があります。通常カテゴリと違う商品集合や選ぶための情報があることが前提です。

URLの例	役割	判断の出発点
/storage/	基本カテゴリ	検索に出したい正規URL
/storage/width-60/	幅60cm以下の恒久一覧	需要・品揃え・固有情報があれば検索候補
/storage/?order=price	同じ商品群の並べ替え	独立した検索価値があるか確認
/storage/?page=2	一覧の続きにある別の商品群	固有URLと商品リンクを維持
無効な条件の組み合わせ	成立しない絞り込み	そのURLで404を返す

※URLは説明用です。既存の正常なURLを、この形へ改名する指示ではありません。

条件を掛け合わせるたびに新しいURLができる設計では、実際の商品数に対してURLが膨らみます。ただし、URL数が多いというだけで売上低下の原因とは断定できません。不要な条件URLが実際に取得され、重要商品の発見が遅れているかを調べます。

施策10：不要ファセットのクロール抑制と検索除外を分ける

ファセットとは、色・サイズ・価格帯などの条件で商品を絞り込む仕組みです。Googleのガイドは、検索に出す必要がないファセットURLのクロールを抑える方法を案内しています。canonicalやnofollowだけでは、長期的なクロール抑制として十分でない場合があります。

無効な組み合わせ、結果が存在しない絞り込み、存在しないページ番号は、そのURLで404を返します。共通のエラーページへリダイレクトする処理は避けてください。一時欠品の商品や、再び品揃えが戻る定番カテゴリを、無効な条件と一括で扱うことはできません。

出典：Google『ファセット ナビゲーション URL のクロール管理』（2026年10月15日確認）

URLの状態と目的	進め方	変更前に守るもの
新規の不要条件URLを増やしたくない	生成・リンク設計やクロール抑制を検討	必要商品・ページ2・検索用条件ページに遮断が及ばないこと
既に登録されたURLを検索から外したい	クロール可能な状態でnoindexを認識させ、状態を確認	既存流入・内部リンク・選択された正規URL
ほぼ同じ内容の代表URLを知らせたい	canonicalと内部リンク先を揃える	内容が異なる一覧の続きを誤って集約しないこと
条件ページに継続した検索価値がある	検索対象として維持・改善	不要URL用のrobotsルールと衝突しないこと

除外後にクロール抑制も必要かを改めて判断します。全URLへ「noindexの後にrobots.txt」という固定工程を当てはめないでください。

robots.txtの広いパターンを本番へ足す前に、残す商品、ページ2、条件別一覧のサンプルURLが一致しないかを検証します。設定方法はEC基盤によって違うため、この判断表を開発担当と共有してから実装します。

出典：Google 検索セントラル『noindex を使用してコンテンツをインデックスから除外する』（2026年10月15日確認）

施策11：一覧の続きに固有URLと商品リンクを用意する

「もっと見る」や無限スクロールを使っていても、Googlebotはユーザーのようにボタンをクリックしません。各範囲の商品を直接開けるURLと、次の範囲へたどるリンクを用意します。

たとえば/storage/?page=2を直接開くと2ページ目の商品が表示され、そのページのcanonicalもページ2を指す状態です。ページ1とは商品集合が違うため、ページ2以降をまとめてページ1へcanonical指定しません。#page=2のように、ページ番号をURLのフラグメントだけへ持たせる方法も避けます。

ページ分割の受け入れ確認

• 2ページ目のURLを直接開いても、該当の商品群が表示される
• 次のページへ移動するリンクにhrefがある
• ページ2のcanonicalがページ2を指している
• 取得されたHTMLから、後半の商品URLを見つけられる
• ページ数の範囲外では、適切に404が返る

出典：Google 検索セントラル『ページ分け、段階的ページ読み込み、それらの Google 検索に対する影響』（2026年10月15日確認）

施策12：バリエーションの選択状態と商品データを揃える

色やサイズの違いは、1ページで切り替える設計と、バリエーションごとにページを持つ設計があります。GoogleのProductGroupは商品グループを表し、その中のProductで個々のバリエーションを説明できます。

方式	URLと正規化	商品データの確認
1ページ内で切り替える	選択URLで対象色を開く。代表URLはグループ単位	各色・サイズの価格・在庫・画像
バリエーション別ページを持つ	各URLで商品情報が完結。単一ページ方式と区別	共通グループIDと各商品のProduct・Offer

単一ページ方式なら、たとえば/products/sr-60?color=whiteを開くとホワイトが選ばれます。グループの代表canonicalは/products/sr-60とする設計です。これは説明用のURLです。独立した販売ページを持つ方式へ、この正規化を一律に転用しません。

URLはホワイトを指すのに画面はブラック、画像だけ変わり価格・在庫は元のまま、という状態がないかを調べましょう。選択用URLを別のタブで開き、画面、構造化データ、カートへ入るSKUを照合します。

出典：Google 検索セントラル『バリエーション商品用構造化データ（ProductGroup、Product）』（2026年10月15日確認）

施策13：一時欠品と販売終了を分けて処理する

一時欠品なら、商品ページを残し、在庫切れ、分かっている再入荷予定、通知や代替商品を案内できます。予定が未定なのに「近日入荷」と書かず、ページ・構造化データ・商品フィードの在庫も更新してください。

出典：Google 検索セントラル『ウェブサイトを一時停止または無効化する』（2026年10月15日確認）

状態	主な処理	残す・確認する情報
一時欠品で再入荷を見込む	200で商品ページを維持	仕様・欠品表示・判明している予定・在庫データ
終売後も型番や仕様の確認需要がある	有用な情報ページとして残すことを検討	販売終了の明示・旧仕様・関連する代替の案内
ページが移動した、または明確な代替先がある	関連性を確認して301を検討	旧商品を探す人が移動先で目的を満たせるか
ページを削除し、明確な代替もない	404または410	内部リンクとサイトマップの更新

※情報ページとして残す判断は、検索需要と読者の用途に基づく運用案です。一律のGoogle要件ではありません。

終売後に情報ページとして残す場合も、購入受付を止め、販売中と誤認させる構造化データや商品フィードを見直します。被リンクや流入があるという理由だけで、無関係な商品やトップページへ一括転送しないでください。

「販売終了」の一文しかないページを200で返し続けると、実体のないページとしてsoft 404と判断される場合があります。残すなら旧商品の仕様など、読者が使える情報を残します。

出典：Google 検索セントラル『Google 検索のクロールエラーのトラブルシューティング』（2026年10月15日確認）

内部リンクとサイトマップで商品を見つけてもらう

施策14：カテゴリ・パンくず・関連商品を役割でつなぐ

トップから主要カテゴリ、カテゴリから商品へたどれる構造を基本にします。パンくずでは上位カテゴリへ戻り、関連商品では一緒に使う商品、代替商品では欠品時の候補へ進めるようにします。全ページから全商品へリンクを置く必要はありません。

図の「リンクなし＝発見されない」は、サイト内リンクをたどる経路に限った説明です。サイトマップや商品フィードから発見される場合もあります。ただ、検索窓でしか見つからない商品を減らし、購入者にもカテゴリから探せる構造を用意しましょう。

内部リンクの設計と点検は、内部リンクとは？SEOに効果的な貼り方で解説しています。

サイトマップには検索に出したい正規URLを載せる

サイトマップのURLは、内部リンクとcanonicalで使う正規URLに揃えます。検索へ出したい、正常に開けるURLを選び、削除済み、リダイレクト先が変わったURL、noindex対象が混ざっていないかを確認してください。

例として、商品カテゴリと商品詳細を別のサイトマップに分ければ、更新やエラーを調べる単位を分けられます。分割そのものが順位を上げるわけではありません。Search Consoleで送信後の読み取り状況を確認し、新商品を代表URLとして含められているかを点検します。

lastmodを使う場合は、主要な本文・構造化データなどを実際に更新した日時を反映します。毎日すべてのURLの日付だけを更新する運用は避けます。サイトマップの送信は発見を助ける手段であり、クロールや登録を保証しません。

出典：Google 検索セントラル『サイトマップの作成と送信』（2026年10月15日確認）

ページ・構造化データ・商品フィードを揃える

施策15：Product・Offerをページ表示と一致させる

構造化データのProductは商品、Offerは価格や在庫などの販売情報を表します。商品を購入できるページでは、販売者リスティング向けの要件を確認して実装します。構造化データを入れただけで順位が上がる、リッチリザルトが必ず出る、という意味ではありません。

販売者リスティングの基本要件には、Productのname・image・offers、Offerの価格情報とpriceCurrencyがあります。送料、返品ポリシー、在庫などは、対象となる表示機能の要件・推奨項目を確認してください。「項目を多く埋める」より、実際の販売条件と一致していることを優先します。

レビューや商品比較のページを、そこで購入できる商品の販売ページと同じ扱いにしないようにします。実装後はリッチリザルトテストで必須項目のエラーを調べ、表示内容と照合してください。

出典：Google 検索セントラル『販売者リスティング（Product、Offer）の構造化データ』（2026年10月15日確認）

Merchant Centerは商品データを渡す経路として使う

Merchant Centerへの登録は、通常のGoogle検索へ出るための必須条件ではありません。一方、Googleのショッピング関連の表示先によっては、Merchant Centerへの参加が必要です。構造化データと商品フィードは、商品情報を伝える経路として併用できます。

フィードを送信していても、ページの価格が更新されていなければ不一致になります。更新元と担当を決め、更新失敗を確認できる状態にしましょう。自動取得や自動更新を利用する場合も、元の価格・在庫情報を継続して管理する運用が必要です。

出典：Google 検索セントラル『商品データを Google と共有する』（2026年10月15日確認）

一つのSKUで更新から反映まで照合する

まず一つのSKUを選び、同じ時点の商品マスタ、画面、構造化データ、フィードを並べます。たとえば価格を8,800円から7,900円へ更新した場合、税込価格・通貨・選択中のバリエーションが各経路で揃うかを確認します。この金額は説明用の仮定です。

照合する項目	確認する場所	不一致時に調べるもの
商品と選択状態	商品マスタ・ページ・構造化データ・フィード	SKUとURL、色・サイズの対応
価格と通貨	ページ・カート・Offer・フィード	税込表示、セール期間、更新元
在庫	ページ・購入操作・Offer・フィード	在庫連携、更新時刻、注文受付
画像	選択商品・Product・フィード	色違いの商品画像、画像URL
配送と返品	ページ・適用するデータ・各サービスの設定	配送地域、費用、条件差、反映先

※同じSKU・配送先・確認時点を揃えて比較します。文字列の表記が同じかではなく、販売条件が一致するかを見ます。

ページだけ古ければキャッシュや表示側、フィードだけ古ければ生成・送信処理、すべて古ければ更新元を調べる、という順で切り分けられます。ただし反映には経路ごとの時間差があります。更新時刻と期待する反映期限も記録し、検索結果の表示だけで即座に連携不良と決めつけないでください。

JSON-LDの基本的な実装手順は、構造化データの実装方法で解説しています。

モバイルとJavaScriptは取得内容と購入操作を確認する

PageSpeed Insightsの点数だけで改善を終えず、スマートフォンで商品名、主画像、価格、在庫、購入条件を確認できるかを見ます。重い画像やスクリプトを調べる場合も、購入ボタンや商品情報を削って点数だけを上げる変更は避けてください。

主要情報を、操作しないと取得できない形にしない

モバイル版だけ仕様や返品情報を省いていないかを確認します。タブやアコーディオンに入っていても、内容が取得されるHTMLに存在するなら、折り畳まれているだけで削除対象にはなりません。問題は、クリックやスワイプをして初めて主要情報が読み込まれる設計です。

出典：Google 検索セントラル『モバイルサイトとモバイルファースト インデックスに関するおすすめの方法』（2026年10月15日確認）

レンダリング後のHTMLと実際の購入を分けて確認する

GoogleはJavaScriptを処理できますが、必要なURLやリソースが遮断されるなどの問題があると、内容を取得できません。URL検査のライブテストなどで、レンダリング後のHTMLに商品名、価格、商品リンクが存在するかを調べます。

さらに実機で、色・サイズの切り替え、価格と在庫、カートへ入るSKUを照合します。取得内容が正しいことと、購入操作が正しく動くことは別の確認です。商品への到達は施策11、データの照合は施策15の基準を使えます。

出典：Google 検索セントラル『JavaScript SEO の基本を理解する』（2026年10月15日確認）

AI検索でも商品情報とSEOの基本を整える

GoogleのAIによる概要やAIモードでも、従来のSEOの基本は有効です。Googleは、Merchant Centerなどのサービスを利用することで、AIの回答やその他の検索結果で商品情報が表示されやすくなると説明しています。ただし、商品フィードや構造化データを整えれば、特定の商品が必ず推薦・引用されるという保証ではありません。

たとえば「オフィスチェア」を探した後に、「幅60cm以下」「3万円以内」「指定日までに受け取れる」「返品条件を確認したい」と条件が加わることがあります。幅・価格・配送・返品を正確に管理すれば、来訪者も条件を確認しやすくなります。条件の組み合わせごとにAI向けのページを量産する必要はありません。

Google検索のAI機能だけを目的として、特別な構造化データやllms.txtを新たに用意する必要もありません。公開され、クロールでき、インデックスとスニペット表示の要件を満たすページを整えるのが基本です。

出典：Google 検索セントラル『Google 検索の生成 AI 機能向けにウェブサイトを最適化する』（2026年10月15日確認）

AI機能の対象設定と表示状況を確認する

2026年10月15日の公式案内では、Search Consoleに検索の生成AI機能への参加を制御する設定があります。基本は含める設定ですが、親プロパティの設定を継承する場合もあるため、意図せず除外されていないかを確認してください。含める設定にしても、表示や順位が保証されるわけではありません。

公式案内での入口は、Search ConsoleのSettings > Search generative AIです。この制御は、通常検索の順位やMerchant Centerへの参加を切り替えるものではありません。

出典：Search Console ヘルプ『Search generative AI control』（2026年10月15日確認）

表示状況は生成AIパフォーマンスレポートで、ページ別のインプレッションなどを確認できます。レポートが表示されない場合、十分な表示回数がないこともあるため、非表示だけで設定ミスと断定しません。商品別の購入や粗利は、自社のアクセス・注文データで別に評価します。

出典：Search Console ヘルプ『生成 AI パフォーマンス レポート（検索）』（2026年10月15日確認）

機能の仕組みは、AIモードとは？で解説しています。

担当と合否基準を決め、小さく変更する

カテゴリの説明は運用担当で直せても、URL生成や商品データの同期は開発・商品管理との連携が必要です。誰が更新し、誰が照合し、異常時に誰が戻すかを決めてから変更します。

主な担当	変更するもの	確認するもの
運用・SEO	カテゴリの役割、title、説明、関連リンク	検索意図、商品集合、既存流入
商品管理	名称、仕様、価格、在庫、販売条件	元の商品データと更新時刻
開発	URL・正規化・検索除外・商品データの実装	対象外への影響、取得内容、購入操作
商品フィード担当	生成・送信・連携設定	送信エラー、SKUの対応、データ差分

本番へ広げる前に、代表URLで受け入れ確認をする

最初は一つのカテゴリと、その中の代表商品に範囲を絞れます。販売中、一時欠品、色違い、一覧2ページ目、検索流入がある条件ページなど、変更の影響が違うURLを選んでください。商品数だけで選ぶと例外を見落とします。

図は既存売上への影響を抑えるための手順です。売上維持を保証するものではなく、設定を戻しても検索側の反映には時間差があります。

確認結果	判断	次の行動
予定どおりの情報が取得され、購入できる	実装確認は合格	限定範囲で監視を続ける
検索の表示やクリックが変わったが、技術不具合は未確認	再調査	季節、在庫、変更前の傾向、未変更ページと比較
残すべき商品がrobotsやnoindexで除外された	展開を停止	旧設定へ戻し、対象外URLへの影響を修正
色違いの商品がカートに入る、価格が誤る	購入不具合として停止	開発・商品管理で修正し、購入操作を再確認

検索評価の変化は、実装確認の合否と分けます。直後の数日だけでSEOの成否を決めず、同じ曜日構成、季節、販促、在庫条件を揃えて比較しましょう。アクセスが少ない商品では、購入件数だけで判断できるまで時間がかかる場合もあります。

成果を次の改善へつなげる

確認した状態	次の確認先
重要商品が発見・登録されない	リンク、取得エラー、noindex、正規URL、サイトマップ
表示はあるがクリックされにくい	クエリとページの一致、title、検索結果での競合
商品閲覧は増えたがカート追加が増えない	適合情報、価格、在庫、送料、配送条件
カート追加は増えたが購入されない	決済、追加費用、入力負担、購入不具合
売上は増えたが粗利が減る・返品が増える	集客商品の構成、値引き、送料負担、適合情報

※複数要因があるため、各行は原因の断定ではなく切り分けの入口です。

自然検索を入口とした売上・粗利を同じ集計条件で追います。ページ別クリックとサイト全体の売上を並べるだけでは、変更した商品への効果を判断できません。商品群、流入経路、注文の対象期間を揃え、前年同時期や未変更の商品群も比較材料にします。

内製・部分外注・保留を技術リスクで選ぶ

商品データの更新元とURLルールを説明でき、戻す担当がいるなら、運用と開発で小規模に進められます。説明文や画像だけを先に直す進め方もあります。

URLがSKU数より大きく増えている、正規URLのルールを説明できない、移行を予定している、戻す方法が分からない場合は、調査や設計だけを外部へ依頼する選択があります。仕組みが不明な段階では、広いURL変更を保留してください。

体制と費用を含む判断は、SEO対策を外注する判断基準で整理しています。

ECサイトのSEO対策に関するよくある質問

Q. 商品説明は何文字にすればよいですか？

A. 一律の文字数を目標にせず、商品を特定でき、適合条件・価格・在庫・配送・返品を確認できるかを見ます。同じ説明を長く繰り返すより、購入判断に不足する情報を足してください。

Q. 商品とカテゴリで同じキーワードを使うと問題になりますか？

Q. 絞り込みURLはすべてnoindexにすればよいですか？

Q. robots.txtで止めたURLのnoindexは有効ですか？

Q. 在庫切れの商品ページは削除すべきですか？

Q. Product構造化データで検索順位は上がりますか？

Q. Merchant Centerは必須ですか？

Q. AI検索用に商品ページを大量に作るべきですか？

最初の改善対象と確認項目を一枚にまとめる

15施策を一度に実施する必要はありません。最初は、重要な一つのカテゴリと代表商品を選び、症状、変更、合格条件を一枚にまとめましょう。URLを変えずに情報を改善できるものと、開発検証が必要なものを分けて着手できます。

記入するもの	書く内容
対象	カテゴリURL、代表商品URL、SKU、残したい例外URL
症状と基準値	発見不足・クリック不足・購入不足のどれか、変更前の指標
変更内容	不足情報、リンク、URL設定、商品データの具体的な変更
合格と停止条件	取得内容、応答、価格・在庫、購入操作で確認する結果
担当と復旧	更新担当、照合担当、旧設定、戻す方法
評価条件	比較する期間・商品群・経路、在庫・販促・季節の違い

このメモで対象と戻し方を説明できれば、小さく検証できます。説明できない設定が残る場合は、そこを調査してから範囲を広げてください。