W2が検索に出ないとき、まず見る5つ
Category
- Search OS
- W2
W2が検索に出ないとき、まず見る5つ
- Tips
- 12分で読める 日本ECプラットフォーム別 検索・AI検索ガイド
W2のショップが検索やAI検索に出ないときに見る順番を5つに整理します。WAF・ボット対策によるクローラーのブロックをSearch Consoleとサーバーログで確認する手順、正規クローラーの見分け方、AIクローラーの許...
- URL
- searchos.io/ja/blog
- Brand
- Search OS
- Copyright
- © 2026 Search OS
W2で運営しているサイトの索引数が、ある週から急に減った。サイト側は何も変えていないが、その時期にセキュリティ強化でWAFの設定を変えていた。W2で3ブランドを運営し、ブランドごとに別ドメインにしたものの、どのブランドも検索で弱く、1つにまとめるべきだったのかが分からない。自社基盤で運用するショップから届く相談は、この2つに集中しています。
どちらも、HTMLを触っていないのに検索エンジンから見たサイトが変わる、という点が共通しています。WAFの設定変更は「サイトの変更」であり、ドメインは「検索エンジンにとっての会社の単位」です。この記事では、個別の記事で整理してきた内容を「まず見る5つ」の順番にまとめ直します。数値と手順は各記事のものをそのまま使い、詳しい作業は記事末尾のリンク先に譲ります。
1. 索引数が急に減ったら、WAFを変えた日を書き出し、Search Consoleのクロール統計と照らす
まず疑うのは、WAFやボット対策です。検索エンジンやAIクローラーを「攻撃的なボット」と判定していることがあり、判定されたクローラーはそのままブロックされます。クローラーは短時間に多くのリクエストを送るため、レート制限や振る舞い検知に引っかかりやすい存在です。ブロックされると、Googlebotにはエラー(403、429、5xx)が返り、索引が減り、順位が落ちます。サイトのHTMLは何も変わっていないので、原因に気づきにくい状態が続きます。
確認 | 見る場所 | ブロックの兆候 |
|---|---|---|
クロールの応答 | Search Console 設定 → クロールの統計情報 | 403・429・5xxの割合が増えている |
取得の可否 | Search Console URL検査 → ライブテスト | 「取得できませんでした」 |
サーバーログ | WAF・Webサーバーのログ | Googlebot・GPTBot等のUser-Agentに対する403・429 |
WAFのブロックログ | WAFの管理画面 | 正規クローラーのIPがブロック対象に含まれる |
Search Consoleでは、設定からクロールの統計情報を開き、「ホストのステータス」に問題が出ていないか、「レスポンス別」の内訳で403・429・5xxが増えた時期はいつかを見て、主力ページのライブテストで取得できるかを確かめます。ライブテストで取得できないなら、その時点でGooglebotはブロックされています。数日のブロックなら解除すれば回復しますが、数週間続くと索引から外れるページが出て、回復に時間がかかります。CDNにもボット対策があり、WAFと二重にブロックしていることもあるため、CDNのログもあわせて見ます。
2. サーバーログで正規クローラーへの403・429を探し、IPで検証して許可リストに入れる
WAFまたはWebサーバーのアクセスログを、User-AgentにGooglebot、bingbot、GPTBot、ClaudeBot、PerplexityBot等を含み、応答コードが403、429、5xxという条件で絞り込みます。該当があれば、どのルールでブロックされたかをWAFのログで突き止めます。User-Agentは偽装できるため、許可リストにはIPの検証を組み合わせます。
クローラー | 検証方法 |
|---|---|
Googlebot | Googleが公開するIPアドレス範囲(JSON)と照合、または逆引きDNSでgooglebot.comを確認 |
bingbot | Bingが公開するIP範囲と照合 |
GPTBot・OAI-SearchBot | OpenAIが公開するIP範囲と照合 |
ClaudeBot | Anthropicが公開する情報と照合 |
PerplexityBot | Perplexityが公開するIP範囲と照合 |
各社の公開IPは更新されるため、許可リストも定期的に見直します。レート制限の閾値は、クロール統計で確認できるGooglebotの通常のクロール頻度を下回らない値にします。以前はSearch ConsoleでGooglebotのクロール頻度を下げる設定がありましたが、今は自動調整だけで、サイトが遅かったりエラーが多かったりすると自動的に減ります。レート制限で拒否するより、サイト側の応答を安定させるほうが確実です。
3. AIクローラーの許可・拒否は方針として決め、拒否はWAFではなくrobots.txtで行う
AIクローラーを許可するか拒否するかは、技術ではなく方針の問題です。設定を触る前に、3つのうちどれかを決めます。
方針 | 意味 | 設定 |
|---|---|---|
検索エンジンもAIも許可 | AI検索での引用を狙う | 全正規クローラーを許可リストに |
検索エンジンは許可、AIの学習用は拒否、AI検索用は許可 | 引用は欲しいが学習には使わせない | GPTBot(学習)は拒否、OAI-SearchBot(検索)は許可、等 |
検索エンジンのみ許可 | AI検索に出なくてよい | AIクローラーをrobots.txtで拒否 |
拒否するなら、WAFではなくrobots.txtで行うのが基本です。WAFでブロックすると、クローラーはエラーとして記録し、サイトの健全性の評価に響くことがあります。robots.txtでの拒否は「意図的な拒否」として扱われます。設定を変えるときは、WAF・ボット対策・レート制限の変更を日付と内容で記録し、変更後1週間はクロール統計で応答コードを確認し、許可リストを更新する前に各社の最新のIP範囲を取得します。WAFの設定はセキュリティ担当が変え、SEO担当は知らない、というのがよくある状況です。1回確かめて問題がなくても次の設定変更でまた起きるため、WAFを変えたらSEO担当に伝える決まりを先に作ります。
4. マルチブランドのドメイン構成は、ブランドの独立性と評価の集約のトレードオフで決める
別ドメインにすれば各ブランドは独立しますが、評価は3つに分散します。1つのドメインのサブディレクトリにまとめれば評価は集まりますが、ブランドは「1社の商品ライン」として見えます。正解は、ブランドが本当に独立した存在として知られるべきかどうかで決まります。ドメインは検索エンジンにとっての会社の単位で、分ければ別会社、まとめれば1社です。ブランド戦略で決めたことを、ドメインで裏切らないようにします。
構成 | 評価の蓄積 | ブランドの独立性 | 運用負荷 | 向いている場合 |
|---|---|---|---|---|
別ドメイン | 分散 | 高 | 高(Search Console・サイトマップ・robots が各々) | ブランドが個別に認知され、相互に関連づけたくない |
サブドメイン | ほぼ分散(近年は同一サイト扱いの傾向) | 中 | 中 | ブランドの独立性を保ちつつ、企業としてのつながりも見せたい |
サブディレクトリ | 集約 | 低 | 低 | 1社の商品ラインとして扱われて構わない。評価の集約を優先 |
判断は5つの質問で行います。ブランド名で検索されているか、ブランド間で顧客層が異なるか、各ブランドに専任の運用担当がいるか、共通商品が多いか、企業名での認知を高めたいか。「はい」が多いほど分ける側、「いいえ」が多いほどまとめる側で、迷ったらサブドメインです。Googleは近年、サブドメインとサブディレクトリを大きく区別しないとしていますが、はっきり約束された保証ではなく、確実に集約したいならサブディレクトリを選びます。7.5万ブランドを分析したAhrefsの研究では、AI Overviewsへの露出と最も強い相関を示した信号は被リンク数(0.218)ではなくブランドのウェブ上の言及(0.664)でした。別ドメインからサブディレクトリへの統合は可能ですが、旧ドメインの全URLのリダイレクト、Search Consoleでのアドレス変更、構造化データの作り直しを伴う、サイト移転と同じ規模の作業になります。
5. 共通商品のcanonicalとOrganizationを、構成に合わせて設計する
複数のストアで同じ商品を扱うと、同じ商品ページがストアの数だけできます。重複の扱いと、ブランドと企業の関係を伝えるOrganizationの置き方は、構成によって変わります。
構成 | 共通商品の重複の扱い | Organizationの置き方 |
|---|---|---|
別ドメイン | 各ドメインが独立したページとして索引される。内容が同じなら、どちらかが重複として除外される可能性 | 各ドメインのトップに、それぞれのブランドをOrganizationとして。親会社との関係はparentOrganizationで |
サブドメイン | 同一サイト内の重複。canonicalで1つに寄せる | 各サブドメインのトップにブランドのOrganization。メインドメインのトップに企業のOrganization |
サブディレクトリ | 同一サイト内の重複。canonicalで1つに寄せる | メインドメインのトップに企業のOrganization。各ブランドはBrandとして商品に紐づける |
重複への対処は、主となるストアを決めて他のストアの共通商品ページはcanonicalで主ストアに寄せるか、ストアごとに商品説明を書き分けて重複でなくするか(運用負荷は高い)のどちらかで、共通商品が大半ならそもそもストアを分ける意味を再検討します。W2のマルチストア機能で共通商品のcanonicalがどう出力されるかは、仕様で確かめます。ブランドと企業の関係を構造化データで明示しておくと、AI検索が「このブランドはこの企業のもの」と理解し、企業への質問でブランドが、ブランドへの質問で企業が参照されやすくなります。ストアを追加するときは、構成を既存のストアと揃え、Search Consoleのプロパティを追加し(ドメインプロパティならサブドメイン・サブディレクトリは追加不要)、サイトマップを登録し、robots.txtを確認し(別ドメイン・サブドメインは独立、サブディレクトリは共通)、共通商品のcanonicalとOrganization・Brandの構造化データを設定し、企業トップと各ブランドの間に内部リンクを置きます。
Search OSは、設定の結果としてクローラーに何が起きているかを見続ける層です
WAFの設定は次の変更でまた崩れ、AIクローラーも新しいものが出続けるため、許可リストの前提は変わっていきます。複数ストアでは、テンプレート更新、商品追加、canonicalの設定など、1つのストアでの変更が他のストアと食い違うことが日常的に起き、ストアが増えるほど「全ストアで同じ方針が守られているか」を確かめる手間が増えます。Search OSは、W2などの自社運用の基盤とマルチストア構成を支える層です。ボットログから検索エンジンとAIクローラーの応答コードを継続して監視し、ブロックの発生、新しいクローラーの出現、許可リストと実態のずれを見つけます。ストア横断でcanonical・構造化データ・サイトマップ・メタデータの整合を確認し、共通商品の重複、Organizationの矛盾、ストアごとのボットの取得状況の差を修正対象として整理します。WAFの設定を行う層でも、構成を決める作業でもありません。
担当者が先に見る質問
索引数が減った週の前後に、WAF・ボット対策・レート制限の設定を変えていないか。変えた日付は記録してあるか
Search Consoleのクロールの統計情報で、403・429・5xxの割合が増えた時期はあるか
主力ページのURL検査のライブテストで、取得できているか
許可リストは、User-Agentだけでなく各社の公開IP範囲で検証しているか
AIクローラーを拒否するなら、WAFではなくrobots.txtに書いてあるか
指名検索の有無、顧客層の違い、共通商品の多さで、別ドメイン・サブドメイン・サブディレクトリの構成を決めているか
共通商品のcanonicalは主となるストアを指し、企業トップのOrganizationに各ブランドが紐づいているか
結論
W2のショップが検索に出ないときは、まずWAF・ボット対策の設定変更日とSearch Consoleのクロール統計を照らし、サーバーログで正規クローラーへの403・429を探します。正規クローラーはIPで検証して許可リストに入れ、AIクローラーの扱いは方針として決めて、拒否はrobots.txtで行います。マルチブランドなら、ブランドの独立性と評価の集約のどちらを優先するかでドメイン構成を決め、共通商品のcanonicalとOrganizationを構成に合わせて設計します。ここまでが設定の話で、その先はWAFの変更やストアの追加のたびに同じ状態を保ち続ける運用の話です。