アクセス禁止(403)によるブロック

Google Search Console の「アクセス禁止(403)によるブロック」の意味、ブラウザーでは開けるのに Googlebot が 403 になる理由、401 との差、診断・修正・検証の方法を説明します。

初回公開:2026年6月23日 · 最終更新:2026年8月8日 · Advanced
言語
このページには証拠シグナルが 2 件あります

*"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 — 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 つの区分に分類します。

  1. 公開してインデックス登録する URL。 403 は意図しない状態です。以下の診断 → 修正 → 検証ループを進めます。
  2. 公開するがインデックス登録しない URL。 robots.txt で解決しようとしないでください。robots.txt の disallow は独立したクロールゲートで、専用のページのインデックス登録理由(「robots.txt によりブロック」)があります。このステータスが報告する HTTP 403 自体を発生させるものではありません。通常の 200 を返し、noindex ディレクティブ(または適切なリダイレクト/削除)を使います。
  3. 意図的に非公開または禁止する URL。 リクエスト元が到達すべきでないリソースなら、403 は正しい意図的な結果かもしれません。このレポートに出ている場合の対応は、アクセスルールを誤りと決めつけることではなく、サイトマップや内部リンクなどで URL が発見可能になっていないかを直すことです。ドアを開けるのではなく、発見シグナルを整理します。
  4. 存在させるべきでない URL、または存在を確認したくない URL。 SEO の都合ではなく、アプリケーションのセキュリティポリシーに従ってレスポンスを選びます。URL の存在を確認させたくない場合は、403 も 404 も正当な選択肢です。
Evidence for this claim A robots.txt disallow is a separate crawl gate and Page indexing reason; it does not itself generate the HTTP 403 response required for the Blocked due to access forbidden (403) reason. Scope: verified Search Console properties Confidence: high · Verified: Page indexing report

ここから先は、実際にクロールおよびインデックス登録したい URL(ケース 1)を前提にします。

403 と 401 を見分ける方法

この 2 つはレポート上の兄弟で、多くの解説が「403 は認証情報を求めない、401 はログインウォール」という経験則で混同します。しかし、それだけでは信頼できません。認証層の設定ミスでも 403 が返り、この行に入ることがあります。真の手がかりはレスポンスそのものです。

  • 401(未認証)。 RFC 9110 では、有効な認証資格情報がなく、レスポンスに WWW-Authenticate チャレンジヘッダーを含める必要があります(HTTP 認証やログインウォール)。Google は認証が必要だと伝えられましたが、通過できませんでした。
  • 403(アクセス禁止)。 より広い拒否です。RFC 9110 は「サーバーがリクエストを理解したが、履行を拒否した」状態と定義しており、認証情報があってもなくても起こります。実務上、この行ではファイアウォール/CDN/WAF やセキュリティルールによるブロックが頻繁に見られますが、認証チェックの不具合、レートリミッター、意図的なアクセス制御でもアプリケーションは 403 を返します。
Evidence for this claim A 401 response means valid authentication credentials are missing and must include a WWW-Authenticate challenge; a 403 is a refusal that can occur with or without credentials. Scope: 401 and 403 responses Confidence: high · Verified: RFC 9110: HTTP Semantics

特定の URL で見分けるには、レポートのラベルから仕組みを推測せず、返されたステータスとヘッダーを確認します。レスポンスに WWW-Authenticate ヘッダーがあるでしょうか。どちらも結果は同じ(インデックス登録されない)で、修正方法も(検証済み Googlebot を通す、または匿名ユーザーにコンテンツを開く)重なることが多いため、判別できたら同じ診断ループをどちらの行にも適用できます。

403 がインデックス登録に与える影響

Googlebot が 403 を受け取ると、次の 3 つが起きます。

  1. コンテンツが無視されます。 Google は 4xx URL のコンテンツを利用しないため、ページ上の内容は何もインデックス登録されません。
  2. 登録済みなら URL が削除されます。 403 は、以前ランキングしていたページもインデックスから外します。これは「追加登録されない」だけでなく、「検索結果から落ちる」問題です。
  3. クロール頻度が低下します。 Google は 4xx URL を時間の経過とともに少ない頻度でクロールするため、長期間の 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 が「速度を落とす」と解釈するコードであり、効果は永続的ではなく一時的です。

診断方法

  1. URL 検査 → ライブ URL をテスト。 Search Console で影響を受けた URL をテストし、古いレポートではなく、現在 Google が 403 を受け取っていることを確認します。このテストは特定の Google クライアントである Google-InspectionTool のアクセスを確認するものです。ライブテストに成功しても、通常の Googlebot が次回クロールで同じ WAF、地域、キャッシュ、レート制限の経路を通るとは限りません。
  2. Googlebot として再現。 通常のブラウザーからテストせず、Googlebot の user-agent で、できれば自分のネットワーク外かつ複数地域から URL を取得します(Google は主に米国からクロールしますが、米国からのリクエストがブロックされると他国へ移ることがあるため、1 地域の成功だけでは世界全体のアクセスを証明できません)。同じルールを発動させるためです。(コマンドは Scripts タブにあります。)
  3. CDN/WAF/ファイアウォールのログを読む。 Googlebot のリクエストで発動した正確なルールを見つけます。レスポンスヘッダー、ルール ID、トリガー(user-agent、IP、チャレンジ、レート制限)を通常のブラウザーアクセスのログと比較し、原因を決めつけません。
  4. 本物の 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 を返すはずです。次の手順を行います。

  1. URL 検査 → ライブ URL をテストで、現在のライブレスポンスが 200 であることを確認します。
  2. 優先度の高い URL では インデックス登録をリクエストし、またはページのインデックス登録レポートの「アクセス禁止(403)によるブロック」行で 修正を検証をクリックします。
  3. Google が 200 を再クロールすると、再登録は 自動的に進みます。正確な速度について公式の保証はなく、URL は通常のクロールも通過してから再表示されます。ブロックを削除し、正常なレスポンスを確認したら、あとは Google が再クロールする時間を待てばよく、手動で追加の操作をする必要はありません。
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

ここで扱った未登録理由とレポート上の分類の全体像は、ページのインデックス登録レポートの概要を参照してください。兄弟ステータスの「Blocked due to unauthorized request (401)」は、この問題における 401 版です。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.