W2のWAF・ボット対策がクローラーをブロックしていないか確認する方法

W2で運営しているサイトの索引数が、ある週から急に減った。サイト側は何も変えていないが、その時期にセキュリティ強化でWAFの設定を変えていた。自社基盤で運用するショップから、この相談が届きます。

まず疑うのは、WAFやボット対策です。クローラーは、ページを読み取っていくプログラムです。検索エンジンやAIクローラーを「攻撃的なボット」と判定していることがあります。判定されたクローラーは、そのままブロックされます。クローラーは短時間に多くのリクエストを送るため、レート制限や振る舞い検知に引っかかりやすい存在です。ブロックされると、Googlebotにはエラー(403、429、5xx)が返ります。索引が減り、順位が落ちます。サイトのHTMLは何も変わっていないので、原因に気づきにくい状態が続きます。

この記事では、ブロックの確認手順と、正規クローラーの見分け方を整理します。AIクローラーの許可・拒否の方針と、設定を変えるときの運用ルールもまとめます。

結論: Search Consoleのクロール統計とサーバーログの応答コードで確認し、正規クローラーは許可リストに入れる

確認	見る場所	ブロックの兆候
クロールの応答	Search Console 設定 → クロールの統計情報	403・429・5xxの割合が増えている
取得の可否	Search Console URL検査 → ライブテスト	「取得できませんでした」
サーバーログ	WAF・Webサーバーのログ	Googlebot・GPTBot等のUser-Agentに対する403・429
WAFのブロックログ	WAFの管理画面	正規クローラーのIPがブロック対象に含まれる

重要な考え方: WAFの設定変更は「サイトの変更」です。HTMLを触っていなくても、検索エンジンから見たサイトは変わります。設定を変えた日付を記録して、索引の変化と照らし合わせられるようにしておきます。最近WAFを変えた日を、まず書き出してください。

手順1: Search Consoleで確認する

設定 → クロールの統計情報を開く
「ホストのステータス」に問題が出ていないか確認する
「レスポンス別」の内訳で、403・429・5xxが増えた時期を特定する
URL検査で主力ページのライブテストを行い、取得できるか確認する

ライブテストで取得できないなら、その時点でGooglebotはブロックされています。主力ページをライブテストにかけてください。

手順2: サーバーログで確認する

WAFまたはWebサーバーのアクセスログを、次の条件で絞り込みます。

User-Agentに Googlebot、bingbot、GPTBot、ClaudeBot、PerplexityBot 等を含む
応答コードが403、429、5xx

該当があれば、どのルールでブロックされたかをWAFのログで突き止めます。まず、Googlebot宛ての応答コードをログで確認してください。

手順3: 正規クローラーを見分ける

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の公開IP範囲と、許可リストを照らし合わせてください。

AIクローラーを許可するか、拒否するか

これは技術ではなく、方針の問題です。

方針	意味	設定
検索エンジンもAIも許可	AI検索での引用を狙う	全正規クローラーを許可リストに
検索エンジンは許可、AIの学習用は拒否、AI検索用は許可	引用は欲しいが学習には使わせない	GPTBot(学習)は拒否、OAI-SearchBot(検索)は許可、等
検索エンジンのみ許可	AI検索に出なくてよい	AIクローラーをrobots.txtで拒否

拒否するなら、WAFではなくrobots.txtで行うのが基本です。WAFでブロックすると、クローラーはエラーとして記録します。サイトの健全性の評価に響くことがあります。robots.txtでの拒否は「意図的な拒否」として扱われます。拒否したいボットがrobots.txtに書かれているかを、確かめてください。

設定変更時の運用ルール

WAF・ボット対策・レート制限の設定変更は、日付と内容を記録する
変更後1週間、Search Consoleのクロール統計で応答コードを確認する
許可リストを更新する前に、各社の最新のIP範囲を取得する
レート制限の閾値は、Googlebotの通常のクロール頻度(クロール統計で確認)を下回らない値にする

確認したあとの運用

WAFの設定はセキュリティ担当が変え、SEO担当は知らない。よくある状況です。1回確かめて問題がなくても、次の設定変更でまた起きます。AIクローラーも新しいものが出続けるため、許可リストの前提は変わっていきます。

Search OSは、W2などの自社運用の基盤を支える層です。ボットログから、検索エンジンとAIクローラーの応答コードを継続して監視します。ブロックの発生、新しいクローラーの出現、許可リストと実態のずれを見つけて、修正対象として整理します。WAFの設定を行う層ではありません。設定の結果としてクローラーに何が起きているかを、見続ける層です。WAFを変えたらSEO担当に伝える、という決まりを先に作ってください。

よくある質問

一時的なブロックでも索引に影響しますか

数日のブロックなら、解除すれば回復します。数週間続くと、索引から外れるページが出てきます。そうなると、回復に時間がかかります。

CDN側のボット対策もありますか

CDNにもボット対策があります。WAFと二重にブロックしていることもあります。CDNのログも、あわせて見てください。

レート制限に引っかかるのはGooglebotのクロールが多すぎるからでは

以前はSearch ConsoleでGooglebotのクロール頻度を下げる設定がありました。今は自動調整だけです。サイトが遅かったり、エラーが多かったりすると、自動的に減ります。レート制限で拒否するより、サイト側の応答を安定させるほうが確実です。

参考資料

Google Search Central: Verifying Googlebot and other Google crawlers
Google Search Central: Crawl Stats report
Google Search Central: Overview of Google crawlers and fetchers
OpenAI: Overview of OpenAI Crawlers

W2のWAFがクローラーをブロックしていないか確認する