アクセス禁止(403)によるブロック
Google Search Console の「アクセス禁止(403)によるブロック」の意味、ブラウザーでは開けるのに Googlebot が 403 になる理由、401 との差、診断・修正・検証の方法を説明します。
言語
このページには証拠シグナルが 2 件あります
- リンクされたソースデータgooglebot.json
- 関連するライブツールHTTP Status & Redirect Checker
*"Blocked due to access forbidden (403)"* _(翻訳)_「アクセス禁止によるブロック(403)」は、Google Search Console のページのインデックス登録レポートで、Googlebot が URL をクロールした際にサーバーから HTTP 403 を受け取ったことを意味します。Google はページをインデックス登録せず、以前登録されていた URL は削除します。Google のヘルプは 403 を「認証情報が提供されたが拒否された」と説明しますが、これはレポート上の表現であり、RFC 9110 の定義は認証情報とは無関係な拒否まで含みます。公開して登録する URL なら 403 を修正し、意図的に非公開の URL なら発見経路を整理します。Google はインデックス登録で 401 と 403 を同じように扱い、クロール速度の制限には 401/403 ではなく 429 または 503 を使います。許可リストに追加する前に reverse DNS/公開 IP 範囲で実際の Googlebot を確認し、例外を狭く設定します。ライブ URL テストで 200 を確認し、修正を検証します。
TL;DR — “Blocked due to access forbidden (403)” (翻訳)「アクセス禁止によるブロック(403)」は、Google Search Console で Googlebot がページを読もうとし、サーバーが「いいえ、許可されていません」と HTTP 403 を返したことを意味します。ページはインデックス登録されません。ページが公開されるべきなら、これは修正すべき不具合です。ファイアウォール、CDN、セキュリティプラグインが Google を誤ってブロックしていることが多く、そのためあなたのブラウザーでは正常に表示されるのに Google ではブロックされます。ページを非公開のままにするなら、403 は本来の役割を果たしている可能性があり、修正方法は異なります。
このステータスの意味
このレポートのラベルは、Google が URL を要求した際に HTTP 403 レスポンスを受け取ったことを意味します。 Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report Google は 429 以外の継続的な 4xx レスポンスを、インデックス登録できないコンテンツとして扱います。 Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: HTTP status codes
Search Console の ページのインデックス登録 レポートで「Blocked due to access forbidden (403)」と表示されるのは、Googlebot がサーバーにページを要求し、サーバーが 403 Forbidden エラーで拒否したという単純な意味です。
Google が 403 を受け取るとページのコンテンツを読めないため、インデックス登録しません。すでに Google に登録されていたページなら、検索結果から削除されます。
本当に修正すべきか
ルールを追いかける前に、その URL がどうあるべきかを決めます。
- 公開してインデックス登録する URL — 403 は不具合です。この先の診断と修正を進めます。
- 公開するがインデックス登録しない URL — robots.txt に頼ってはいけません。robots.txt の disallow は独立したゲートで、専用のレポート理由があり、それだけで HTTP 403 を発生させることはありません。通常の
200を返し、代わりにnoindexディレクティブを使います。 - 非公開のままにする URL — 403 は正しく機能するアクセス制御かもしれません。修正すべきなのはファイアウォールルールではなく、Google が繰り返し見つけるサイトマップや内部リンクにその URL が残っていないことです。
あなたには開けるのに Google には開けない理由
これは「公開されるべき URL」の場合に特に混乱しやすい部分です。ブラウザーで URL をクリックすると問題なく表示されるのに、なぜ Google だけがブロックされるのでしょうか。
ブラウザーは、クローラーにはない信号を送ります。Cookie、通常のブラウザー user-agent、そして(JS チャレンジや CAPTCHA ゲートなら)チャレンジを通過する能力です。Googlebot のリクエストは通常、その多くが異なります。Cookie がなく、クローラー user-agent を使うため、スクレーパーを対象にしたボットルールが クローラーにだけ 発動し、実際の訪問者はそのまま通過することがあります。ページ自体が壊れているのではなく、ルールが誤った訪問者をブロックしていることが多いのです。(推測ではなく正確な差分を確認する方法は Advanced タブにあります。)
ファイアウォールまたは CDN は頻繁に報告される原因
ファイアウォール、CDN、セキュリティツール(Cloudflare、WAF、WordPress のセキュリティプラグインなど)が Googlebot を誤ってブロックすることは、公開されるべき URL で頻繁に報告される原因の 1 つです。ただし、発生頻度を独立に検証した数字はありません。ほかにも user-agent や国によるブロック、ホットリンク保護、本来公開すべきコンテンツをログインの背後に置いていることなどが原因になります。
修正を始める方法
- Search Console で影響を受けた URL を URL 検査し、ライブ URL をテストをクリックして、Google が実際に 403 を受け取っていることを確認します。
- CDN、ファイアウォール、セキュリティプラグインの設定とログを調べ、Googlebot またはその IP 範囲をブロックしているものがないか確認します。
- 許可する前に本当に Googlebot かを確認し、例外を狭く保ちます。対象は特定のルートとルールであり、包括的な許可ではありません。Googlebot の名前を偽装するボットは多数あります。(確認方法は Advanced タブと Scripts タブにあります。)
- ルールを修正すると、ページは通常の
200を返すはずです。その後レポートで 修正を検証します。Google が200を再クロールすれば再登録は自動的に進みますが、所要時間の保証はありません。
知っておきたい兄弟ステータスに 「Blocked due to unauthorized request (401)」 があります。ログインウォールの背後にあるページについての表示です。仕組みは異なりますが、結果と修正方法の多くは同じです。
診断と修正の完全なループ、WAF の詳細、Googlebot を検証するコマンドを確認するには、Advanced タブへ切り替えてください。
TL;DR — Page Indexing レポートの 403 は、Googlebot が URL で HTTP 403 を受け取ったことを意味するため、Google はインデックス登録せず、すでに登録されていれば削除します。Google の Page Indexing ヘルプは 403 を「認証情報が提供されたが拒否された」と説明していますが、これは Google のレポート上の表現であり、HTTP の完全な定義ではありません。RFC 9110 は 403 を、認証情報の有無を問わず「理解したが拒否した」より広い状態と定義しています。したがって Google の説明は設定ミスの証明ではなく、手がかりとして扱います。まず URL がそもそも公開・インデックス登録されるべきかを決めます。公開されるべき URL では、ファイアウォール/CDN/WAF が Googlebot を意図せずブロックすることが頻繁に報告されており、そのためページがあなたには表示されても Google には 403 になることがあります。一方、非公開にする URL の 403 は意図どおりに機能している可能性があります。Google はインデックス登録で 401 と 403 を同じように扱い、クロール速度の制限に 401/403 を 使わない よう明示しています。代わりに 429(または 503)を使います。許可リストに追加する前に、reverse DNS、公開 IP 範囲、正しいクライアントカテゴリで 実際の Googlebot を確認し、例外を特定のルートとルールに限定します。その後、URL 検査 → ライブ URL をテストで 200 を確認し、修正を検証します。
Google が 403 について実際に述べていることと、HTTP の実際の定義
このラベルが示すのは観測されたレスポンスであり、それを発生させた WAF、CDN、アクセスルールまで特定するものではありません。 Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report インデックス登録への影響は、Google が一般的な 4xx の扱いとして説明している内容に従います。 Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: HTTP status codes
Google の Page Indexing レポートの文書は、HTTP 403 を user agent が “provided credentials but was not granted access” (翻訳)「認証情報を提供したがアクセスを許可されなかった」状態と説明しています。しかし Googlebot は never provides credentials (翻訳)「認証情報を決して提供しない」ため、Google の説明ではサーバーがこのエラーを誤って返していることになります。ページはインデックス登録されません。登録したい場合の Google の修正方法は、未ログインユーザーを受け入れるか、認証なしで Googlebot のリクエストを明示的に許可することです。
ただし、これは Google のヘルプ文書による説明であり、HTTP の完全な定義ではありません。RFC 9110(現在の HTTP セマンティクス仕様)は 403 をより広く定義しています。“the server understood the request but refuses to fulfill it,” (翻訳)「サーバーがリクエストを理解したが、履行を拒否する」状態です。認証情報が関係することもありますが、RFC は、ポリシー、アクセス制御ルール、エッジのセキュリティ判断など、認証情報とは完全に無関係な理由でもリクエストを禁止できると明記しています。重要なのは「Googlebot への 403 は定義上必ず壊れたルールだ」と考えることではなく、「この URL は本来到達可能かを確認し、403 を返した正確なルールを見つける」ことです。公開してインデックス登録すべきページなら、Googlebot への 403 はほぼ確実に修正対象です。意図的に非公開または禁止しているページなら、403 は有効なアクセス判断かもしれません。その場合の問題はファイアウォールが間違っていることではなく、通常は Google がそもそも URL を発見すべきではなかったことです(下の意図確認を参照)。
どちらの場合でも、Google の HTTP ステータスコード文書が示すインデックス登録への影響は明確です。4xx を返す URL のコンテンツは利用せず、429 を除くすべての 4xx エラーを同じように扱います。クローラーは次の処理システムに、コンテンツが存在しないと伝えます。以前インデックス登録されていた URL は、インデックスから 削除されます。 Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: HTTP status codes
修正する前に URL の役割を決める
このレポートのすべての行に同じ修正が必要なわけではありません。まず URL を次の 4 つの区分に分類します。
- 公開してインデックス登録する URL。 403 は意図しない状態です。以下の診断 → 修正 → 検証ループを進めます。
- 公開するがインデックス登録しない URL。 robots.txt で解決しようとしないでください。robots.txt の disallow は独立したクロールゲートで、専用のページのインデックス登録理由(「robots.txt によりブロック」)があります。このステータスが報告する HTTP 403 自体を発生させるものではありません。通常の
200を返し、noindexディレクティブ(または適切なリダイレクト/削除)を使います。 - 意図的に非公開または禁止する URL。 リクエスト元が到達すべきでないリソースなら、403 は正しい意図的な結果かもしれません。このレポートに出ている場合の対応は、アクセスルールを誤りと決めつけることではなく、サイトマップや内部リンクなどで URL が発見可能になっていないかを直すことです。ドアを開けるのではなく、発見シグナルを整理します。
- 存在させるべきでない URL、または存在を確認したくない URL。 SEO の都合ではなく、アプリケーションのセキュリティポリシーに従ってレスポンスを選びます。URL の存在を確認させたくない場合は、403 も 404 も正当な選択肢です。
ここから先は、実際にクロールおよびインデックス登録したい URL(ケース 1)を前提にします。
403 と 401 を見分ける方法
この 2 つはレポート上の兄弟で、多くの解説が「403 は認証情報を求めない、401 はログインウォール」という経験則で混同します。しかし、それだけでは信頼できません。認証層の設定ミスでも 403 が返り、この行に入ることがあります。真の手がかりはレスポンスそのものです。
- 401(未認証)。 RFC 9110 では、有効な認証資格情報がなく、レスポンスに
WWW-Authenticateチャレンジヘッダーを含める必要があります(HTTP 認証やログインウォール)。Google は認証が必要だと伝えられましたが、通過できませんでした。 - 403(アクセス禁止)。 より広い拒否です。RFC 9110 は「サーバーがリクエストを理解したが、履行を拒否した」状態と定義しており、認証情報があってもなくても起こります。実務上、この行ではファイアウォール/CDN/WAF やセキュリティルールによるブロックが頻繁に見られますが、認証チェックの不具合、レートリミッター、意図的なアクセス制御でもアプリケーションは 403 を返します。
特定の URL で見分けるには、レポートのラベルから仕組みを推測せず、返されたステータスとヘッダーを確認します。レスポンスに WWW-Authenticate ヘッダーがあるでしょうか。どちらも結果は同じ(インデックス登録されない)で、修正方法も(検証済み Googlebot を通す、または匿名ユーザーにコンテンツを開く)重なることが多いため、判別できたら同じ診断ループをどちらの行にも適用できます。
403 がインデックス登録に与える影響
Googlebot が 403 を受け取ると、次の 3 つが起きます。
- コンテンツが無視されます。 Google は
4xxURL のコンテンツを利用しないため、ページ上の内容は何もインデックス登録されません。 - 登録済みなら URL が削除されます。 403 は、以前ランキングしていたページもインデックスから外します。これは「追加登録されない」だけでなく、「検索結果から落ちる」問題です。
- クロール頻度が低下します。 Google は
4xxURL を時間の経過とともに少ない頻度でクロールするため、長期間の 403 は修正後の再訪と回復も遅くなります。
ブラウザーでは開くのに Googlebot が 403 になる理由
この問題は多くの人を迷わせます。ブラウザーではページが表示されるのでコンテンツは問題ないように見えるのに、Google は 403 を報告します。考えられる説明は、ブラウザーと Googlebot が大きく異なるリクエストを送るため、スクレーパーを止めるボット管理ルールがクローラーにだけ発動し、人間には通常どおり応答するというものです。ただし、これは 確認すべき仮説であり、決めつけではありません。実際に重要な属性はサイトごとに異なります。
- ブラウザーは Cookie、実際のブラウザー user-agent を送り、JS または CAPTCHA チャレンジを解決できます。Googlebot のリクエストには通常そのどれもありません。Cookie がなく、クローラー user-agent を使い、対話型チャレンジを解けません(ただし Google-InspectionTool は JavaScript をレンダリングして結果を報告するため、“Googlebot has no JavaScript” (翻訳)「Googlebot には JavaScript がない」という説明がすべての部分に正確とは限りません)。
- クライアント側の違い以外にも、2 つのリクエストでは 送信元 IP/カテゴリ、地域、メソッド、リファラー、キャッシュ状態、実際に発動したルールが異なることがあります。どれも真のトリガーになり得ます。
どの属性が原因かを推測しないでください。実際にブロックされたリクエストと通常のブラウザーアクセスについて、エッジとオリジンの正確なログを比較します。ルール ID、レスポンスヘッダー、メソッド、UA、検証済みカテゴリ付きの送信元 IP、地域、Cookie、リファラー、キャッシュ状態、チャレンジ結果を揃え、1 度に 1 つの属性だけを変えて、レスポンスが切り替わる条件を見つけます。そうすれば、選択的な 403 であることを推測ではなく確認できます。
よくある原因
- CDN/WAF のボット管理。 Cloudflare(Bot Fight Mode/Super Bot Fight Mode、Browser Integrity Check、Managed Challenge)、Akamai、Imperva/Incapsula、Sucuri、AWS WAF は、Googlebot を含むブラウザー以外のクライアントにチャレンジを出したり 403 を返したりすることがあります。公開すべき URL では頻繁に報告される原因の 1 つで、ほぼ常に意図しないものですが、この原因が占める割合を独立に検証した数字はありません。
- サーバーのファイアウォール/セキュリティルール。 mod_security/OWASP CRS、fail2ban、ホスト側ファイアウォールが Googlebot のパターンを不正なアクセスとして検出する場合です。
- user-agent/リファラー/ホットリンクルール。 ブラウザーらしい user-agent やリファラーがないリクエストを 403 にするルールです。
- 地域/IP ブロック。 Googlebot が主に米国 IP からクロールするため、その IP 範囲を除外する国別ブロックが静かに該当することがあります。
- ログイン/認証情報の壁。 本来公開すべきコンテンツを見るために Cookie やログインを要求する設定で、401 のケースと重なります。
- N 回のリクエスト後に 403 を返すレート制限。 これは行わないでください。詳細は下で説明します。
Googlebot のスロットリングに 403 を使わない
これは名前を挙げて指摘する価値のあるアンチパターンです。サーバー負荷を下げるために、Googlebot を 遅くする目的で 403 や 404 を返す人(および一部の CDN)がいます。Google は、これは機能せず、行うべきではないと明言しています。クロール速度の制限に 401 と 403 のステータスコードを使わないでください。 これらはクロール速度に影響せず、ページをインデックスから外すだけです。本当に Googlebot に引いてもらう必要があるなら、429(または 503 のような 5xx)を返します。Google が「速度を落とす」と解釈するコードであり、効果は永続的ではなく一時的です。
診断方法
- URL 検査 → ライブ URL をテスト。 Search Console で影響を受けた URL をテストし、古いレポートではなく、現在 Google が 403 を受け取っていることを確認します。このテストは特定の Google クライアントである Google-InspectionTool のアクセスを確認するものです。ライブテストに成功しても、通常の Googlebot が次回クロールで同じ WAF、地域、キャッシュ、レート制限の経路を通るとは限りません。
- Googlebot として再現。 通常のブラウザーからテストせず、Googlebot の user-agent で、できれば自分のネットワーク外かつ複数地域から URL を取得します(Google は主に米国からクロールしますが、米国からのリクエストがブロックされると他国へ移ることがあるため、1 地域の成功だけでは世界全体のアクセスを証明できません)。同じルールを発動させるためです。(コマンドは Scripts タブにあります。)
- CDN/WAF/ファイアウォールのログを読む。 Googlebot のリクエストで発動した正確なルールを見つけます。レスポンスヘッダー、ルール ID、トリガー(user-agent、IP、チャレンジ、レート制限)を通常のブラウザーアクセスのログと比較し、原因を決めつけません。
- 本物の Googlebot とそのカテゴリを検証。 許可リストに入れる前に、reverse DNS と forward DNS、または Google の公開 IP 範囲でリクエストが本物の Googlebot であることを確認します。どの Google クライアントがリクエストしたかも確認してください。通常の Googlebot、特別用途のクローラー、ユーザー起点のフェッチャー(Google-InspectionTool など)は異なるホストマスクと IP リストを使うため、間違ったリストで検証すると本物のリクエストが偽装に見えることがあります。
修正方法
- 検証済み Googlebot の例外を WAF/ファイアウォールに狭く設定します。 user-agent 文字列だけを信頼せず、検証済みの身元(reverse + forward DNS で正しいクライアントカテゴリと照合)または Google の現在の公開クローラー IP 範囲を使います。例外は、必要な特定のルートとブロックしている特定のルールに限定し、Google 全体を許可する包括的な例外にはしません。ほかのセキュリティ制御、レート制限、ログ記録は残し、古い許可リストが理由なく存続しないよう期限/レビュー日を設定します。CDN/ファイアウォールのベンダーにも Googlebot が許可されることを確認してもらい、Google の current (翻訳)「現在の」公開 IP サブネットに対してブロックルールを自動検査し、将来の IP 範囲更新で再び静かにブロックされないようにします。
- 公開コンテンツを匿名ユーザーに開きます。 公開すべきコンテンツでログイン/Cookie 要件が原因なら、その要件を削除します(401 の兄弟ステータスとも共通する修正です)。
- 403 のレート制限を 429 に置き換えます。 リクエスト数のしきい値を超えるとルールが 403 を返すなら、429(または 503)を返すよう変更します。Googlebot に「立ち去れ」ではなく「速度を落とせ」と伝えるためです。
修正を検証して再登録する
ルールを直したら、URL は 200 を返すはずです。次の手順を行います。
- URL 検査 → ライブ URL をテストで、現在のライブレスポンスが
200であることを確認します。 - 優先度の高い URL では インデックス登録をリクエストし、またはページのインデックス登録レポートの「アクセス禁止(403)によるブロック」行で 修正を検証をクリックします。
- Google が
200を再クロールすると、再登録は 自動的に進みます。正確な速度について公式の保証はなく、URL は通常のクロールも通過してから再表示されます。ブロックを削除し、正常なレスポンスを確認したら、あとは Google が再クロールする時間を待てばよく、手動で追加の操作をする必要はありません。
ここで扱った未登録理由とレポート上の分類の全体像は、ページのインデックス登録レポートの概要を参照してください。兄弟ステータスの「Blocked due to unauthorized request (401)」は、この問題における 401 版です。
AI サマリー
Advanced 版の要点をまとめます。
- 何が起きているか。 GSC のページのインデックス登録レポートで「Blocked due to access forbidden (403)」と表示されるのは、Googlebot が URL をクロールし、サーバーが HTTP 403 を返したという意味です。Google はインデックス登録せず、以前登録されていた場合は削除します。
- Google の説明と HTTP の定義。 Google のヘルプは 403 を「認証情報が提供されたが拒否された」と説明します。これはレポート上の表現であり、HTTP の完全な定義ではありません。RFC 9110 では、認証情報の有無を問わず、サーバーが発行できるより広い拒否として 403 を定義しています。
- まず URL の意図を決める。 公開して登録する URL なら 403 を修正します。公開するが登録しない URL なら robots.txt(独立したゲートで、403 自体を発生させない)ではなく
noindexを使います。意図的に非公開なら 403 は正しい可能性があり、代わりに Google が URL を発見する経路を整理します。 - 公開 URL で頻繁に報告される原因。 ファイアウォール/CDN/WAF(Cloudflare、Akamai、Imperva/Incapsula、Sucuri、AWS WAF)やセキュリティプラグインが Googlebot をブロックすることです。ほぼ常に意図しないものですが、この原因の頻度を示す検証済みの数字はありません。
- あなたには開けても Google に開けない理由。 ブラウザーには Cookie、実際の user-agent、チャレンジ解決能力があり、Googlebot のリクエストには通常ありません。ただし推測せず、ログを比較して実際のトリガーを確認します。
- 401 と 403。 レスポンスを確認します。401 には
WWW-Authenticateチャレンジが必要ですが、403 は認証情報の有無にかかわらず起きるより広い拒否です。Google は登録上どちらも同じように扱い、修正も重なることが多くあります。 - スロットリングに 403 を使わない。 401/403 でクロール速度を制限しないでください。ページを登録から外すだけです。「速度を落とす」には 429(または 503)を使います。
- 診断。 URL 検査 → ライブ URL をテスト(その時点の Google-InspectionTool のアクセスを確認するもので、予定された Googlebot の経路そのものではありません)、複数地域から Googlebot として再現、WAF/ファイアウォールログの行単位比較、本物の Googlebot とクライアントカテゴリの確認を、許可リスト追加前に行います。
- 修正と検証。 検証済み Googlebot に対する狭い例外を設定するか、コンテンツを公開します。403 のレート制限は 429 に置き換え、ライブ URL テストで
200を確認し、修正を検証します。Google が200を再クロールすれば再登録は自動的に進みますが、所要時間の保証はありません。
公式ドキュメント
検索エンジンの一次資料です。
- ページのインデックス登録レポート — 「アクセス禁止(403)によるブロック」と「未認証リクエストによるブロック(401)」の項目と、それぞれの意味を掲載しています。
- HTTP ステータスコード、ネットワークエラー、DNS エラーが Google 検索に与える影響 — Google が
4xx(コンテンツを無視し、URL をインデックスから削除)を扱う方法と、クロール速度の制限に 401/403 を使わないルールです。 - Googlebot とその他の Google クローラーの検証 — 本物の Googlebot を許可リストに入れ、偽装者を入れないための reverse + forward DNS と公開クローラー IP 範囲です。
- Google クローラーとフェッチャーの概要 — Google の user-agent と照合すべき IP 範囲 JSON ファイルを網羅しています。
- Don’t 404 my yum(Search Central Blog、2023) — Google がサイト所有者と CDN に Googlebot のスロットリングで 403/404 を使わないよう求め、代わりに使うコードを説明しています。 “Blocked due to access forbidden (403)” (翻訳)「アクセス禁止(403)によるブロック」および “Blocked due to unauthorized request (401)” (翻訳)「未認証リクエストによるブロック(401)」の項目を参照してください。
Bing / Microsoft
- Bing Webmaster Tools — クロール制御 — Bingbot も Googlebot と同様に、403 を受け取ったページをインデックス登録できません。ファイアウォール/CDN が Bingbot をブロックしていないか確認し、速度の管理にはブロックではなく Crawl Control を使います(ホスト名は
*.search.msn.comに解決されます)。
HTTP 標準
- RFC 9110 — HTTP Semantics、§15.5.2(401)および §15.5.4(403) — Google のより狭い認証情報ベースのヘルプ文言を補正するために使うプロトコル定義です。401 には
WWW-Authenticateチャレンジが必要で、403 は認証情報の有無を問わず発生し得る、より広い拒否です。
出典からの引用
Google による記録に残る発言です。各リンクは、出典ページの引用箇所へ直接移動します。
Google — インデックス登録における 403 の意味(ページのインデックス登録レポート)
- “HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” (翻訳)「HTTP 403 は user agent が認証情報を提供したもののアクセスを許可されなかったことを意味します。しかし Googlebot は認証情報を決して提供しないため、サーバーはこのエラーを誤って返しています。ページはインデックス登録されません。」 — Google Search Console ヘルプ「ページのインデックス登録レポート」 引用箇所へ移動
Google — 4xx(403 を含む)の扱い
- “Google doesn’t use the content from URLs that return
4xxstatus codes.” (翻訳)「Google は4xxステータスコードを返す URL のコンテンツを利用しません。」 — Google Search Central ドキュメント 引用箇所へ移動 - “All
4xxerrors, except429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (翻訳)「429を除くすべての4xxエラーは同じように扱われます。Google クローラーは次の処理システムにコンテンツが存在しないと伝えます。」 引用箇所へ移動
Google — クロール速度の制限に 401/403 を使わない
- “Don’t use
401and403status codes for limiting the crawl rate.” (翻訳)「クロール速度の制限に401と403のステータスコードを使わないでください。」 — Google Search Central ドキュメント 引用箇所へ移動
403 の診断 → 修正 → 検証チェックリスト
「Blocked due to access forbidden (403)」と表示されるすべての URL に対して実行します。
- URL の意図を決める — 公開/インデックス登録、公開/インデックス未登録、意図的な非公開、または発見自体を避ける URL のどれかに分類します。残りのチェックリストが必要なのは、公開してインデックス登録するケースだけです。
- ライブであり古くないことを確認する — URL 検査 → ライブ URL をテストで現在の
403を確認します(これは Google-InspectionTool のアクセスを確認するもので、予定された Googlebot の経路と必ずしも同じではありません)。 - Googlebot として再現する — 通常のブラウザーではなく、Googlebot の user-agent で(自分のネットワーク外、できれば複数地域から)URL を取得します。
- ルールを見つける — ブロックされたリクエストと通常のブラウザーアクセスについて CDN/WAF/ファイアウォール/プラグインのログを比較します。原因を推測せず、ルール ID とトリガー(user-agent、IP、チャレンジ、レート制限)を確認します。
- 本物の Googlebot とクライアントカテゴリを検証する — reverse + forward DNS(ホスト名が
googlebot.com、google.com、googleusercontent.comのいずれかで終わる)または正しいカテゴリの IP 範囲リストとの照合を、許可リスト追加の前に行います。 - 検証済み Googlebot の例外を狭く設定する — 身元/IP 範囲で、ログ記録と期限/レビュー日を付け、特定のルートとルールだけを対象にします。包括的な許可や user-agent 文字列だけの信頼はしません。
- 公開コンテンツを開く — 公開すべきコンテンツに対するログイン/Cookie 要件が 403 の原因なら、要件を削除します。
- 403 のレート制限を
429(または503)に置き換える — クロールを遅くするために 401/403 を使いません。 -
200を確認する — URL 検査 → ライブ URL をテストが200を返すことを確認します。 - 検証する — 403 の行で 修正を検証をクリックし、優先 URL では インデックス登録をリクエストします。再クロール時に再登録は自動的に進みます。
- 将来に備える — Google の公開 IP サブネットに対してブロックルールを自動検査し、IP 範囲の更新で再び静かにブロックされないようにします。
メンタルモデル
1.「誰の設定が間違っているか」より先に「公開すべきか」を問う。 Google のヘルプは 403 を認証情報が送られて拒否された状態として説明しますが、RFC 9110 は、認証情報の有無を問わず、サーバーが理解して拒否したリクエストとしてより広く定義します。公開してインデックス登録するページなら、Googlebot への 403 はほぼ常に誤った訪問者にルールが発動している状態です。「ページを評価する」のではなく「ルールを見つける」と考えます。意図的に非公開のページなら、403 は役割を果たしている可能性があり、修正はファイアウォールを開くことではなく、Google の発見経路から URL を外すことです。
2. 同じルールに別の見た目の訪問者 — どの差が重要かを確認する。 あなたにはページが開くのに Google には 403 になるのは、ブラウザーに Cookie、実際の user-agent、チャレンジを解く能力があるのに、Googlebot のリクエストには通常それがないためです。ただし、どの属性がルールを発動させたかは決めつけず、ログを比較し、一度に 1 つの属性を変えます。自分のリクエストではなく Googlebot のリクエストを作ってデバッグし、推測ではなくログに理由を語らせます。
3. 身元を検証してから、例外を狭く設定する。 Googlebot の user-agent は誰でも偽装できます。順序は常に、身元とクライアントカテゴリを確認(reverse DNS/一致する IP 範囲リスト)→ その後で許可です。さらに、例外はログ記録と期限/レビュー日を伴う特定のルートとルールに限定し、Google 全体への包括的な許可リストにはしません。user-agent だけで、または広すぎる範囲で許可すると、Google を装うスクレーパーに穴を開けることになります。
4. 403 は不適切なスロットルです。
Googlebot を遅くしたい場合、401/403 では目的を達成できず、ページをインデックスから外すだけです。「速度を落とす」コードは 429 と 5xx/503 です。意図に合うコードを選びます。「永久に来させない」(インデックスから外す)のか、「後で戻らせる」(スロットリング)のかを区別します。
5. 403 と 401 は近い兄弟だが、レスポンスで見分ける。
401 には WWW-Authenticate チャレンジが必要で、実際の認証ウォールです。403 は認証情報の有無を問わず起こるより広い拒否なので、ラベルだけから仕組みを推測せず、実際のレスポンスを確認します。どちらか分かったら、結果(登録されない)と修正(検証済み Googlebot を通す/コンテンツを開く)が重なることが多いため、同じループで診断できます。
403 チートシート
ページのインデックス登録における兄弟ステータス
| ステータス | Google が受け取ったもの | 通常の意味 |
|---|---|---|
| アクセス禁止(403)によるブロック | HTTP 403(拒否。認証情報が関係する場合もしない場合もあります) | ファイアウォール/CDN/WAF/セキュリティルールが Googlebot をブロックしていることが多い。意図的に禁止したページや、認証チェックの設定ミスの場合もある |
| 未認証リクエスト(401)によるブロック | HTTP 401(WWW-Authenticate チャレンジが必要) | ログイン/HTTP 認証ウォールの背後にあるページ |
| その他の 4xx による URL のブロック | その他の 4xx | URL 検査で診断する |
ステータスコードとクロール — 正しいものを選ぶ
| 目的 | 返すコード | 影響 |
|---|---|---|
| 悪質/不要なボットをブロックする | 403 | ページは登録されず、登録済みならインデックスから外れる |
| Googlebot に 速度を落とすよう求める | 429(または 503) | 一時的なスロットル。サポートされる「速度を落とす」シグナル |
| ページが本当に消えた | 404/410 | 時間の経過とともにインデックスから外れる |
| ページをインデックス登録する | 200 | クロール可能で登録可能 |
インデックス登録すべきページに対する 403 の影響
- コンテンツは無視されます(Google は
4xxのコンテンツを利用しません)。 - 以前登録されていた URL はインデックスから削除されます。
- 403 が続く間、クロール頻度は低下します。
Googlebot 検証クイックリファレンス
- IP を reverse DNS で引き、ホスト名が
googlebot.com、google.com、googleusercontent.comのいずれかで終わることを確認します。 - そのホスト名を forward DNS で引き、同じ IP に戻ることを確認します。
- または、正しいクライアントカテゴリの Google の現在の公開クローラー IP 範囲 JSON と照合します。通常の Googlebot、特別用途のクローラー、ユーザー起点のフェッチャー(Google-InspectionTool など)は別々のリストを公開しています。
Googlebot として 403 を再現する
通常のブラウザーからテストしないでください。ボットルールが発動しないためです。Googlebot の user-agent で URL を取得し、Google に見えている状態を確認します。
macOS / Linux
# Fetch headers only, as Googlebot's user-agent — look at the status line
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
-I https://www.example.com/page/
# A "HTTP/1.1 403 Forbidden" here reproduces what Googlebot is getting.Windows (PowerShell)
# -SkipHttpErrorCheck so PowerShell shows the 403 instead of throwing
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Head `
-UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescriptionこれで 403 が返り、通常のブラウザーリクエストが 200 を返すなら、ボット固有のブロックを確認できています。ただし、高度な WAF は IP も条件にすることがあるため、完全な再現テストは自分のネットワーク外からも行います。
許可リストに追加する前に、本当に Googlebot かを検証する
Googlebot の user-agent を偽装するトラフィックは多数あります。ファイアウォールで IP を許可する前に、reverse + forward DNS で身元を確認してください。
macOS / Linux
# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com
# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1Windows
nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.comreverse lookup の結果が Google ドメインで終わらない、または forward lookup が元の IP と一致しないなら、それは Googlebot ではありません。許可リストに追加しないでください。Google の公開範囲(googlebot.json)と IP を照合する方法もあります。ただし googlebot.json は通常の Googlebot だけを対象にします。特別用途のクローラーやユーザー起点のフェッチャー(Google-InspectionTool など)は別の IP 範囲ファイルを公開しているため、検証対象の実際のクライアントに対応するリストを使います。身元を確認してから、特定のルートとルールに例外を限定します。user-agent 文字列だけで許可したり、包括的な例外を開いたりしてはいけません。
403 を診断する: WAF ブロック、ログインウォール、それともレート制限の誤用?
最初の分岐ではレスポンスそのものを確認します。WWW-Authenticate ヘッダーやログインプロンプトのない 403 は、401 の兄弟ステータスよりもセキュリティルールやアクセス制御による拒否を示します。そこから先は Advanced タブの「診断してから修正する」ループに沿います。各結果は確定事項ではなく、ログで確認すべき仮説として扱います。クリックして進んでください。
Why is Googlebot getting a 403, and what fixes it?
403 の区分を追跡する(存在だけを見ない)
注目すべき 1 つの数字は、ページのインデックス登録レポートで「アクセス禁止(403)によるブロック」の行に入っている URL の数です。行が存在するかどうかだけではありません。単一のスナップショットでは、修正が本当に効いたのか、新しい 403 が蓄積しているのか分かりません。
403 区分の件数の推移
- 指標 — GSC のページのインデックス登録レポートで「アクセス禁止(403)によるブロック」の下にある URL 数を週ごとに記録します。
- 分かること — 許可リストまたはファイアウォールルールの修正が効いたか、新しい 403 が増えているかです。検証済み Googlebot を許可するか公開パスを開いた後は、修正した URL の件数がゼロに近づくはずです。意図的にクロールさせない URL だけなら横ばいでも問題ありませんが、増加は通常、WAF/CDN ルールまたは IP 範囲の更新が新たに Googlebot を捕捉していることを示します。
- 取得方法 — GSC の ページのインデックス登録レポートを 403 行でフィルタし、URL 検査 → ライブ URL をテストで個々の URL を確認します。古いスナップショットではないことを確認するためです。
- ベンチマーク/現実的な範囲 — 普遍的な目標はありません。実際に何 URL を登録したいかによります。正直な基準は、登録したい URL の 403 がゼロであり、それ以外では件数が増えず横ばいであることです。傾向を判断する前に、自分の基準値を記録します。
- 頻度 — 修正直後は件数が安定するまで毎週、その後は回帰確認として毎月行います。CDN や Googlebot の IP 範囲更新でブロックが静かに再発することがあるためです。
手順書: 診断、修正、検証
403 のワークフローは短い順序付きループです。Googlebot としてブロックを再現し、これから通す身元を確認する前に、許可リスト追加へ飛びつかないでください。
1. ライブであり古くないことを確認する。 影響を受けた URL で GSC の URL 検査 → ライブ URL をテストを実行し、キャッシュされた古いレポートではなく、現在 Google が 403 を受け取っていることを確認します。
2. 自分ではなく Googlebot として再現する。 Googlebot の user-agent で URL を取得します。できれば自分のネットワーク外かつ複数地域から行います。通常のブラウザーは Cookie、実際の user-agent、JS/CAPTCHA チャレンジを通過する能力を持ちますが、Googlebot のリクエストには通常それがなく、同じルールが発動しないことがあります。どの差がブロックを引き起こしたかを決めつけず、ログを左右に並べて比較します。
3. ルールを見つける。 CDN/WAF/ファイアウォールのログで、Googlebot のリクエストに発動した正確なルールを確認します。ルール ID とトリガー(user-agent、IP、チャレンジ、レート制限)が、変更すべき箇所を示します。
4. 許可リストに追加する前に、本物の Googlebot とカテゴリを検証する。 これから許可するリクエストが本物の Googlebot であることを、reverse + forward DNS、またはそのクライアントカテゴリに対応する IP 範囲リストで確認します。通常の Googlebot、特別用途のクローラー、ユーザー起点のフェッチャーは別々のリストを公開しています。検証しないと偽装者に穴を開けたり、間違ったリストで検証したりすることになります。
5. 原因に応じて修正する。 WAF/CDN ルールなら、身元/IP 範囲に基づく検証済み Googlebot の狭い例外を特定のルートとルールに設定します。公開コンテンツへのログイン/Cookie 要件なら削除します。403 を返すレート制限なら 429(または 503)に置き換えます。
6. 検証する。 URL 検査 → ライブ URL をテストが 200 を返すことを確認し、403 行で 修正を検証、優先 URL では インデックス登録をリクエストします。Google が 200 を再クロールすれば再登録は自動的に進みます。数週間たっても 403 区分の件数が減る傾向を示さないなら、新しい原因を推測せず、手順 2 に戻って再現します。
すぐ使える AI プロンプト
生の診断出力から 403 の原因を分類するための、コピー&ペースト用プロンプトです。原因を素早く切り分ける助けになりますが、変更前に必ず実際のサーバー/ファイアウォール設定で結論を確認してください。
curl の出力から考えられる原因を分類する
I'm diagnosing a "Blocked due to access forbidden (403)" status in Google
Search Console. Below is the raw output of a request made with Googlebot's
user-agent (curl -A "...Googlebot..." -I). Based on this output alone,
classify the most likely cause as one of: (1) CDN/WAF bot-management
challenging or blocking non-browser clients, (2) server firewall / mod_security
rule flagging the crawl pattern as abuse, (3) user-agent or referrer/hotlink
rule, (4) geo/IP blocking excluding Googlebot's IP ranges, (5) a login/cookie
requirement on content that should be public, (6) a rate-limit rule misusing
403 instead of 429. Explain which specific header or detail in the output
pointed you to that answer, and tell me what's missing if you can't tell for
sure.
CURL OUTPUT:
[paste]WAF/ファイアウォールのログ行から原因を分類する
I'm investigating why Googlebot is getting a 403 on a page I want indexed.
Below is a log line (or a few) from my WAF/CDN showing a blocked request. Tell
me whether this looks like a bot-identity rule (blocking by user-agent or IP
range), a challenge/CAPTCHA rule, or a rate-limit rule misusing 403, and what
I'd need to allowlist — by IP range or reverse-DNS — to let verified Googlebot
through without disabling the rule entirely.
LOG LINE(S):
[paste]修正を適用する前に健全性を確認する
I'm about to allowlist a set of IPs as "Googlebot" in my WAF, because a page
I want indexed is currently returning 403 to the crawler. Here's the evidence
I have that these requests are genuinely Googlebot: [describe reverse-DNS or
IP-range check]. Point out anything I might be missing — e.g. whether I should
verify by both reverse and forward DNS, whether I should match Google's
published IP-range JSON instead, or whether allowlisting by user-agent alone
would leave a hole for spoofers. テスト: 「アクセス禁止(403)によるブロック」
403 の意味、401 との違い、診断と修正の方法についての 5 問です。各問に答えてから、確認してください。
403 の診断と修正に使うツール
- HTTP Status Checker — 影響を受けた URL(または一括)を貼り付け、403 ステータスコード、完全なレスポンスチェーン、ブロックに到達する前のリダイレクトを確認します。
- Googlebot Verifier — WAF やファイアウォールのルールを越えて許可する前に、Googlebot を名乗る IP が本物か(公開 IP 範囲と reverse DNS)を確認します。
- Google Search Console — URL 検査 → ライブ URL をテスト — Googlebot が現在受け取っている正確なレスポンスに最も近い情報です。
curl -A "...Googlebot..."— Googlebot の user-agent で URL を取得し、生のステータス行を読む最速の方法です。- WAF/CDN のファイアウォールイベントログ(Cloudflare、Akamai、Sucuri など) — Googlebot の IP 範囲に 403 を返した特定のルールを見つけます。
修正が本当に効いたことを証明する
検証済み Googlebot を許可し、公開コンテンツを開き、またはレート制限ルールを 429 に置き換えた後、次のチェックで「設定を変えた」ことと「Google がページに到達できる」ことを分けます。順番に実行してください。
テスト 1 — Googlebot の user-agent リクエストが 200 を返す
- 実行するテスト — Googlebot の user-agent で影響を受けた URL を取得します(または HTTP Status Checker で確認します)。
- 期待する結果 — ステータス行が
HTTP/1.1 200 OKになります。 - 失敗の解釈 — まだ
403なら、ファイアウォール/WAF ルールが実際には更新されていないか、誤った IP 範囲を許可しています。403ではなく401になったなら、ブロックを認証ウォールに置き換えただけなので、その経路を別に確認します。 - 監視期間 — 即時。ルール変更が有効になるとサーバーはすぐ応答します。
- ロールバック条件 — パスを開いたことで本来制限すべきコンテンツが露出した場合は、ブロックを戻し、より狭いルールで検証済み Googlebot を IP/reverse DNS により許可します。
テスト 2 — Google がページに到達できることを確認する
- 実行するテスト — Google Search Console の対象 URL で URL 検査 → ライブ URL をテストを実行します。
- 期待する結果 — ライブテストが成功し、アクセス禁止エラーなしでページのコンテンツが表示されます。
- 失敗の解釈 — Googlebot の user-agent 取得は通るのにライブ URL テストが 403 のままなら、user-agent 文字列ではなく Google の公開 IP 範囲に限定されたルールを疑います。ファイアウォールログで 2 つ目のルールを確認します。
- 監視期間 — 修正後すぐから数分。
- ロールバック条件 — なし。これは読み取り専用テストです。まだ失敗するならロールバックせず、テスト 1 の失敗分岐に戻ります。
テスト 3 — ページのインデックス登録レポートで 403 が消える
- 実行するテスト — ページのインデックス登録レポートの「アクセス禁止(403)によるブロック」で 修正を検証を使い、その後数週間の区分件数を確認します(測定方法タブを参照)。
- 期待する結果 — URL が 403 区分から外れ、以前登録されていた場合は、Google が 200 のページを再クロールするにつれて時間をかけてインデックスに戻ります。
- 失敗の解釈 — 再登録は自動ですが即時ではありません。検証が遅いことを新しい失敗と解釈しないでください。数週間たっても 403 区分の件数が減らないなら、テスト 1 を再実行して修正が維持されていることを確認します。CDN キャッシュまたは Googlebot の IP 範囲更新でブロックが静かに再発することがあります。
- 監視期間 — 数日から数週間。403 区分の件数で追跡します。
- ロールバック条件 — テスト 1 が再び失敗した場合だけルール自体を見直します。ページのインデックス登録レポートの反映タイミングを追いかけないでください。
時間を使う価値のあるリソース
公式
- ページのインデックス登録レポート(Google) — 403 と 401 の項目を逐語的に確認できます。
- HTTP ステータスコードが Google 検索に与える影響(Google) —
4xxの扱いと、レート制限に 401/403 を使わないルールです。 - Googlebot の検証(Google) — reverse DNS と公開 IP 範囲です。
- Don’t 404 my yum(Google、2023) — Googlebot のスロットリングに 403/404 を使わないことを説明しています。
関連する自分の記事
- Technical SEO ビギナーズガイド — このようなクロールアクセス問題が全体像のどこに位置付くかを説明します。
- Robots.txt と SEO: 知っておくべきこと — 意図せずクロールをブロックするもう 1 つの一般的な方法です。
他の情報源
- r/TechSEO — CDN による Googlebot ブロックなど、クロール/インデックスのデバッグを扱うコミュニティです。
- Google、Googlebot のクロール速度制限に 403 または 404 を使わないよう警告(Search Engine Land) — Gary Illyes の「Don’t 404 my yum」の指針と、代わりに使う 429/503 を解説します。
- Google: Googlebot のレート制限に 403/400 エラーレスポンスを使わないで(Search Engine Journal) — 同じ Illyes の投稿を紹介し、追加の文脈を説明します。
- Googlebot をブロックする最も一般的な理由はファイアウォール/CDN(Search Engine Roundtable) — Google Search Relations が、Googlebot のブロックの大半は意図しない CDN/ファイアウォールルールだと説明しています。
- Googlebot を偽装するボット(johnmu.com) — user-agent を信頼せず reverse DNS で Googlebot を検証すべき理由を John Mueller が説明します。
- 「アクセス禁止(403)によるブロック」の修正方法(Onely) — WAF/CDN の詳細と、診断 → 修正ループを扱う実務ガイドです。
変更履歴
2026年8月8日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年7月17日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。