Search Consoleでサイトマップが403になる原因｜CloudflareがGooglebotをブロックした実例

独自ドメインへ移行した直後、Google Search ConsoleのURL検査で「アクセス禁止（403）が原因でブロックされました」と表示されました。

ただし、ブラウザでは普通に開けており、Cloudflare Pagesも正常稼働していました。そこでSearch Consoleの「公開URLをテスト」を実行したところ、現在のURLは正常に取得できることが確認できました。

先に結論

URL検査に表示される403が、必ずしも「今もGooglebotが403を受けている」という意味とは限りません。まず過去のインデックス情報と現在の公開URLを分けて確認します。

今回のケースでは、さらにCloudflareのSecurity Eventsを確認したところ、Googlebotによる/sitemap.xmlへのアクセスが実際にブロックされていたことも判明しました。

今回の状況

旧pages.devから独自ドメインへ移行し、301リダイレクト、canonical、新しいsitemap、Search Consoleの新プロパティ登録まで完了した後に確認しました。

通常のURL検査では、新ドメインのトップページに対して「403でブロックされた」という過去のクロール結果が残っていました。

URL検査の表示は「今この瞬間」とは限らない

Search ConsoleのURL検査画面には、Googleが過去にクロールした時点の情報が表示されます。

そのため、DNSやCloudflare設定を修正した直後は、画面上の結果が古い状態のまま残ることがあります。

まず「公開URLをテスト」する

今回の切り分けで一番有効だったのが、URL検査画面右上の「公開URLをテスト」です。

テスト後、画面は「URLはGoogleに登録できます」へ変わりました。

つまり、通常のURL検査に残っていた403は古い状態で、現在のGooglebot相当の取得では問題ないと判断できました。

ライブテストが成功した場合

「URLはGoogleに登録できます」と表示された場合、現在のページはインデックス対象として取得可能です。

今回はこちらから「インデックス登録をリクエスト」を実行しました。

リクエストは即時インデックスを保証するものではありませんが、Googleの優先クロールキューへ追加されます。

ライブテストでも403の場合

公開URLテストでも403になる場合は、実際にGooglebotがCloudflareやサーバー側で拒否されている可能性があります。

その場合は、次を確認します。

Cloudflareのセキュリティイベント
WAFルール
Bot Fight ModeやBot関連設定
IP・国・User-Agentによるブロック
Accessや認証設定
robots.txtではなくHTTPステータスとして403が返っていないか

Cloudflare利用時に見る場所

Cloudflareを使っている場合、403が出た時刻付近のセキュリティイベントを見ると、どのルールがブロックしたか特定できることがあります。

闇雲にWAFやBot対策を無効にするのではなく、まずライブテストとイベントログで原因を絞る方が安全です。

今回の直接原因：CloudflareがGooglebotをブロックしていた

Search Consoleのサイトマップ画面で、「サイトマップを読み込めませんでした」「HTTPエラー: 403」が続いたため、CloudflareのSecurity Eventsを確認しました。

すると、実際に次の条件のリクエストがブロックされていました。

ホスト：aipcdouka.com
パス：/sitemap.xml
User-Agent：Googlebot/2.1
ASN：Google LLC
実行された操作：ブロック
ルールセット：Cloudflare Bot Management rules for all plans
ルール：Block AI training crawlers - BOBA-199

つまり今回の403は、Search Console側の問題ではなく、Cloudflare側のBot ManagementルールがGooglebotのサイトマップ取得を止めていたことが直接原因でした。

Cloudflare側のブロック設定を見直して再送信

該当するAIクローラー関連のブロック設定を見直したあと、Search Consoleからサイトマップを再送信しました。

その結果、サイトマップのステータスは「成功しました」に変わりました。

さらにトップページのURL検査も後から「URLはGoogleに登録されています」となり、インデックス登録済みであることを確認できました。

今回の切り分け順

Search Consoleで403を確認
公開URLテストで現在の取得可否を確認
サイトマップだけ403が続くことを確認
CloudflareのSecurity Eventsで/sitemap.xmlを検索
GooglebotがBot Managementルールでブロックされていることを特定
該当設定を見直す
Search Consoleへサイトマップを再送信
「成功しました」になったことを確認

独自ドメイン移行直後は特に混乱しやすい

今回のように、DNS、Cloudflare Pages、301、canonical、Search Consoleを短時間で切り替えた直後は、Google側に古い結果が残っていても不思議ではありません。

実際のブラウザ表示だけでなく、Search Consoleのライブテストを使うことで「現在も403なのか」「過去のクロール結果だけなのか」を分けられました。

まとめ

URL検査の403は過去のクロール結果の場合がある
まず「公開URLをテスト」で現在の取得可否を見る
ライブテストが成功すれば、現在のページは取得可能
ライブテストでも403ならCloudflareやサーバー側のブロックを調べる
Cloudflare利用時はSecurity EventsでGooglebotの/sitemap.xmlアクセスを確認する
今回の実例では「Block AI training crawlers」ルールがGooglebotをブロックしていた
独自ドメイン移行直後は反映差を考慮する

Cloudflare Pagesへ独自ドメインを設定した実例はこちら

GA4をChatGPTから確認できるようにした手順はこちら