SiteOps
トップメディアダッシュボード更新履歴
記事一覧

CloudflareのWAFでGooglebotが弾かれるとき、最初の30分でやること

CloudflareのWAF/Bot対策が原因でGooglebotが403/Challengeされる疑いがあるとき、最初の30分で「本物判定 → 止めたルール特定 → 最小差分で止血」を進める手順です。

著者: 川原更新: 2026-05-15障害対応RSS
Xで共有FacebookLinkedIn
料金相談

Cloudflare の WAF / Bot 対策を触った直後に、Search Console のクロールエラー（403/5xx）が増えた・インデックスが急に減ったとき、最初の30分でやるべきことは「設定を当てずっぽうで戻す」ではなく「本当に Googlebot か」「Cloudflare のどのルールが止めたか」をログで確定して、最小差分で止血することです。

この手順のゴールは、次のどれかを30分で確定することです。

  • 本物の Googlebot を Cloudflare 側で誤って止めていた（止めたルールが特定できる）
  • 偽装クローラ（Googlebot を名乗る攻撃者）を止めていた（Googlebot 偽装の判定がつく）
  • Googlebot ではなく、別の原因（デプロイ事故/オリジン障害/認証/ルーティング）だった

0. まずやらないこと

  • 「たぶんこれが原因」で WAF / Bot 設定を大きく戻す（再発防止の学びが消える）
  • User-Agent だけで allowlist を作る（偽装に弱くなる）
  • サイト全体を無防備にする（セキュリティ事故に直行する）

最初の30分は、“止めたルールと対象URL”の確定に集中します。

1. 症状を 1 行で固定（3分）

次のどれかを 1 行で書けるようにします（混ざると迷走します）。

  • Search Console の **「クロール統計情報」**が落ちた（全体/特定のホストだけ）
  • Search Console の URL 検査で 403/5xx が出る
  • Cloudflare の Security Events で Block / Challenge が増えた
  • /sitemap.xml など特定パスだけが取れない

2. “本当に Googlebot か”を確定（10分）

Search Console の表示だけでは「本物の Googlebot」と「偽装クローラ」が混ざります。最短で確定します。

  1. サーバーログ（または Cloudflare Logs / Security Events のリクエスト詳細）から アクセス元 IP を拾う
  2. Google 推奨の手順で、逆引き → 正引きで Google のドメインに紐づくか検証する

ここが曖昧だと、「止めて良いもの」と「止めると SEO が落ちるもの」を混同します。

3. Cloudflare 側で “誰が止めたか” を特定（10分）

Cloudflare の Security Events（セキュリティイベント）で、対象リクエストを 1 件掘ります。

  • Action: Block / Managed Challenge / JS Challenge / Log のどれか
  • Service/Source: WAF Managed Rules / Custom Rules / Rate Limiting / Bot (Bot Fight Mode 等) のどれか
  • Rule: 具体的なルール名（“Rule unavailable” の場合は、直近の変更で消えた可能性）
  • Path / Host / Method: どの URL が止まっているか

この 10 分の目的は「止めたルールを 1 つに絞る」ことです。

4. 最小差分で止血（5分）

止血の原則は 2 つです。

  • “本物の Googlebot” だけを通す（偽装は通さない）
  • 必要なパスだけを通す（サイト全体をゆるめない）

代表的な止血パターンは次のいずれかです（環境により名称が異なります）。

  • Verified bots（Cloudflare が検証した “good bots”）を Skip/Allow するルールを追加する
  • 特定の Managed Rules を対象パスだけ Skip/Log にする
  • Rate Limiting を “検索クローラ” が通るように 除外する（必要な場合のみ）

「まず通す」ではなく、“止めていた 1 ルールだけ” を、対象パスに限って緩めるのが最短です。

5. 30 分で出す結論の型

最初の30分で、次のどれかに分類して次の1時間の作業を固定します。

  1. 本物の Googlebot を誤ブロック: ルール特定 → 対象パス限定の Skip/Allow → 再クロール待ち
  2. 偽装クローラをブロックしていた: そのまま維持（ただし Search Console 側の誤認を切り分ける）
  3. 別要因: オリジン 5xx / 認証 / ルーティング / robots / sitemap を優先して切り分け

SiteOpsで“クロール障害”を早期検知する（再発防止）

WAF / Bot 対策の変更は「意図せず検索クローラを止める」事故が起きやすい領域です。次からは、毎朝の確認で“異常が出た瞬間に気づく”状態にしておくと、初動が速くなります。

  • Search Console のクロール/インデックス異常を、ドメイン別に優先順位で確認できるようにする
  • 403/5xx などの変化が出たら「どのドメインの、どのパスか」をすぐ切り出せるようにする

状況が再現できない/原因が複合している場合は、相談だけ先に進めるのも有効です。

  • 料金・導入の概要を見る
  • 相談する

関連

  • /media/robots-txt-crawl-stop-first-30-minutes
  • /media/search-console-sitemap-fetch-error-first-30-minutes
  • /media/search-console-indexing-drop-first-30-minutes

参考にした一次情報

  • Cloudflare WAF: Concepts
  • Cloudflare WAF: Security Events
  • Google Search Central: Verifying Googlebot

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事Search Consoleに「手動による対策」が出たとき、最初の30分でやること次の記事Cloudflareへデプロイしたのに反映されないとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ