「アクセス禁止(403)が原因でブロックされました」とは?原因と対処法を解説
「アクセス禁止(403)が原因でブロックされました」は、Googlebotがページにアクセスしようとした際にサーバーから403 Forbiddenレスポンスを受け取り、インデックスできなかった状態を示すエラーです。
ただし、admin-ajax.phpやwp-jsonなどWordPressのシステムリソースが対象であれば、対処不要なケースも多くあります。
重要なのは「対処が必要なページかどうか」を正しく判断し、必要な場合のみ原因に応じた修正を行うことです。
Google公式ドキュメントとGary Illyes(Google Search Relationsチーム)の公式見解をもとに解説していきます。
インデックス状態の把握が大変という方は、SEOサイト管理自動化ツール「inSite(インサイト)」を試してみてください。
inSiteのインデックスチェック機能では、サイト内のページのクロール状態を毎日自動でチェックします。
どれだけのページがインデックスされてなくて原因は何なのか、クローラーは定期的に来ているのかといった情報を常に監視することができます。

1ページずつURL検査をしなければわからないインデックス状態。
inSiteを使えばこれを常に把握できるため、効率よくSEOにおける有効な打ち手を考えることができます。
ページのインデックス率向上や、ページの評価をアップさせるリライトの効率化にかなり使えると思うので、ぜひお試しください。
「アクセス禁止(403)が原因でブロックされました」とは?

サーチコンソールの「ページのインデックス登録」レポートに表示される「アクセス禁止(403)が原因でブロックされました」とは、Googlebotがページをクロールしようとした際に、サーバーがHTTP 403 Forbiddenを返した状態を意味します。
Google公式のページインデックス登録レポートでは、このステータスについて次のように説明されています。
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.
(和訳)
HTTP 403エラーは、ユーザーエージェントが認証情報を提供したにもかかわらずアクセスを拒否された場合に発生します。しかし、Googlebotは認証情報を提供しないため、お客様のサーバーがこのエラーを誤って返していることになります。
Google公式のページインデックス登録レポート
Googlebotは認証情報を一切送信しません。
にもかかわらず403が返されるということは、サーバー側のアクセス制限設定がGooglebotのリクエストを拒否しているというわけです。
技術的に補足すると、RFC 9110 Section 15.5.4では403 Forbiddenを「サーバーがリクエストを理解したが、その認可を拒否した」と定義しています。
401(Unauthorized)が「認証されていない」状態を指すのに対し、403は「認証の有無に関係なくアクセスが拒否されている」状態です。
よくある原因としては、WAF(Webアプリケーションファイアウォール)やCDNのBot対策機能、WordPressのセキュリティプラグイン、.htaccessのアクセス制限設定、海外IPアドレスのブロックなどが挙げられます。
サーチコンソールのインデックスカバレッジレポートには403以外にもさまざまなステータスがあります。
全体像を把握したい方は「インデックスカバレッジの全ステータス一覧」も参考にしてみてください。
≫inSiteでサイトのインデックス状況をチェックしてみる(無料)
対処が必要なケースと放置してよいケースの判断基準
403ブロックが表示されたからといって、すべてのURLに対処が必要なわけではありません。
結論として、「検索結果に表示させたいページかどうか」が判断基準になります。
ここでは、対処が必要なケースと放置してよいケースを具体的に整理します。
対処が必要なケース
以下に該当するURLが403でブロックされている場合は、早急な対処が必要です。
| 対処が必要なURL | 判断ポイント |
|---|---|
| ブログ記事・コラム | 検索流入を狙うコンテンツページ |
| 商品ページ・サービスページ | ECサイトやサービスサイトの主要ページ |
| カテゴリページ | サイト構造上重要なページ |
| サイトマップに含まれるURL | 検索エンジンにインデックスさせたいと明示しているページ |
Google公式ドキュメントによると、4xxステータスコードを返すURLはインデックスされず、すでにインデックスされているURLも4xxを返し続けるとインデックスから削除されます。
検索流入を獲得したいページが403になっている場合、放置するほどSEOへの悪影響が大きくなるため、優先的に対処しましょう。
放置してよいケース
一方、以下のようなURLが403になっている場合は、対処する必要はありません。
| 放置OKなURL | 理由 |
|---|---|
| /wp-admin/admin-ajax.php | WordPressの管理用リソース。インデックス不要 |
| /wp-json/(REST API) | WordPress REST API。セキュリティプラグインがブロックしているケースが大半 |
| /wp-admin/配下のURL | 管理画面。インデックス対象外 |
| /feed/(RSSフィード) | フィードURL。インデックス不要 |
| 会員限定・パスワード保護ページ | 意図的にアクセス制限しているため正常な403 |
サーチコンソールで403ブロックの対象URLを確認し、上記に該当する場合は放置でよいでしょう。
影響範囲をまとめて把握したい場合は「インデックスに登録されていないページ数の確認方法」を参考にしてください。
≫inSiteでサイトのインデックス状況をチェックしてみる(無料)
403ブロックの主な原因と対処法
対処が必要と判断した場合、次は原因の特定と修正に進みましょう。
Googlebotが403を受け取る原因は主に4つに分類でき、原因ごとに対処法が異なります。
ここでは、各原因の確認方法と具体的な修正手順を解説します。
WAF・CDNによるGooglebotのブロック
「アクセス禁止(403)が原因でブロックされました」が発生する原因で最も多いのが、WAFやCDNのBot対策機能がGooglebotを誤ってブロックしているケースです。
CloudflareのBot Fight ModeやAWS WAFなどは、不審なBotからサイトを保護するための機能ですが、設定によってはGooglebotまでブロックしてしまうことがあります。
GoogleのGary Illyes氏も公式ブログで、CDN事業者が403を使ってGooglebotのクロールレートを制限しようとするケースが増加していると警告しています。
▼確認方法
CDNやWAFの管理画面でブロックログを確認し、Googlebotのリクエストが拒否されていないかチェックします。
▼対処法
- Cloudflareの場合は、Security > Bots > Bot Fight Modeを無効化するか、カスタムルールで「Known Bots」をスキップする設定に変更
- AWS WAFの場合は、WAFルールでGooglebotのIPレンジを許可リストに追加
Googlebotかどうかの検証には、Google公式のGooglebot検証方法に記載されている逆引きDNSルックアップや、公開されているGooglebotのIPアドレスリスト(googlebot.json)が利用できます。
なお、これはrobots.txtによるブロックとは原因が根本的に異なります。
robots.txt起因の場合は「robots.txtによりブロックされましたの対処法」を参照してください。
WordPressセキュリティプラグインの影響
「アクセス禁止(403)が原因でブロックされました」が発生する原因の2つ目は、WordPressセキュリティプラグインの影響です。
WordPressサイトでは、セキュリティプラグインがGooglebotをブロックするケースも珍しくありません。
Wordfence、SiteGuard WP Plugin、Sucuri Securityなどのファイアウォール機能がGooglebotのアクセスを不正リクエストと誤判定することがあります。
また、WP RocketやW3 Total Cacheなどのキャッシュプラグインがadmin-ajax.phpをキャッシュし、期限切れのnonceによって403が発生するケースも報告されています。
▼確認方法
- Wordfenceの場合は、Firewall > Blocking > Current Blocksで手動ブロックを確認
- Tools > Live Trafficで過去のブロックログを確認
- Firewall > Rate Limitingでレート制限設定を確認
▼対処法
プラグインの設定画面でGooglebotをホワイトリスト化するか、レート制限設定を緩和します。
プラグインを一時的に無効化してみて403が解消するかどうかを確認するのも有効な切り分け方法です。
サーバー設定(.htaccess・パーミッション)の問題
「アクセス禁止(403)が原因でブロックされました」が発生する原因の3つ目は、サーバー設定(.htaccess・パーミッション)に問題があることです。
.htaccessファイルやファイルパーミッションの設定が原因でGooglebotのアクセスが拒否されていることもあります。
.htaccessにDenyディレクティブが設定されている場合や、ファイル・ディレクトリのパーミッションが不適切な場合(Webサーバーのユーザーに読み取り権限がないなど)に403が発生します。
まれに、マルウェア感染によって.htaccessファイルが書き換えられ、意図しないアクセス拒否が発生しているケースもあります。
▼確認方法
- .htaccessファイルの内容を確認し、不審なDenyルールがないかチェック
- ファイルパーミッションを確認(一般的にはファイルが644、ディレクトリが755)
▼対処法
- .htaccessの不要なDenyルールを削除または修正
- パーミッションが不適切な場合はファイル644、ディレクトリ755に修正
- nginx環境の場合はnginx.confのlocationディレクティブを確認
IP制限・地理的アクセス制限
「アクセス禁止(403)が原因でブロックされました」が発生する原因の4つ目は、IP制限・地理的アクセス制限が設定されていることです。
海外IPアドレスをブロックしているサイトでは、Googlebotのアクセスも拒否されてしまうことがあります。
Google公式ドキュメントによると、Googlebotは主にアメリカ合衆国のIPアドレスから発信されます。
米国からのアクセスをブロックしている場合、Googlebotが他国のIPアドレスからクロールを試みることもありますが、確実にクロールできるとは限りません。
▼確認方法
サーバーのアクセスログでGooglebotのIPアドレスを確認し、ブロックリストと照合します。
▼対処法
GooglebotのIPレンジ(googlebot.json)をホワイトリストに追加しましょう。
地理的制限を維持しつつGooglebotのみ許可する設定にすることで、セキュリティと検索エンジンへの対応を両立できます。
≫inSiteでサイトのインデックス状況をチェックしてみる(無料)
対処後の確認方法とインデックス再登録の手順
原因を修正したら、実際にGooglebotがアクセスできるようになったかを確認し、インデックス再登録をリクエストしましょう。以下の手順で進めてください。
サーチコンソールのURL検査ツールで対象URLを入力し、「公開URLをテスト」をクリックします。

レスポンスが200 OKになっていれば、修正が正しく反映されています。
コマンドラインから以下のようにGooglebotのUser-Agentを指定してアクセスを確認することもできます。
curl -A "Googlebot" -I https://example.com/target-pageレスポンスコードが200であれば問題ありません。
「ページのインデックス登録」レポートの「アクセス禁止(403)が原因でブロックされました」をクリックし、「修正を検証」ボタンを押します。 Googleが対象URLを再クロールし、修正が確認できればステータスが「合格」に変わります。
この検証プロセスには通常2週間程度かかりますが、それ以上かかる場合もあります。
対象ページが多い場合は、手動での確認には限界があります。
「Inspection APIでインデックス状態を自動チェックする方法」を活用すれば、スプレッドシート上で大量ページのインデックス状態を一括で確認できます。
さらに詳しいAPI活用方法は「Search Console APIの使い方」でも解説しています。
ちなみに、サイト管理ツール「inSite(インサイト)」では、ページのインデックス状況を自動でチェックできる機能があるため、興味がある方は使ってみてください。

≫inSiteでサイトのインデックス状況をチェックしてみる(無料)
403ブロックがSEOに与える影響
403ブロックを放置した場合、具体的にどのようなSEO上のリスクがあるのでしょうか。
Google公式のHTTPステータスコードドキュメントをもとに整理します。
インデックスからの削除
4xxステータスコードを返すURLはインデックスされず、すでにインデックスされているURLが4xxを返し続けるとインデックスから削除されてしまいます。
つまり、検索流入を獲得していたページが403を返し始めると、検索結果から消えてしまう可能性があります。
クロール頻度の減少
403を返すURLへのクロール頻度は「徐々に減少する」とGoogleは公式に述べています。
Google doesn’t use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time. In the case of Google Search, Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.
Any content Google receives from URLs that return a 4xx status code is ignored.
(和訳)
Googleは、4xxステータスコードを返すURLのコンテンツを使用しません。以前使用されていたURLが現在4xxステータスコードを返している場合、GoogleのシステムはそのURLの使用を徐々に停止します。
Google検索の場合、Googleは4xxステータスコードを返すURLをインデックス登録せず、既にインデックス登録されていて4xxステータスコードを返すURLはインデックスから削除されます。
Googleが4xxステータスコードを返すURLから受け取るコンテンツはすべて無視されます。
How HTTP status codes affect Google’s crawlers
ただし、403はクロールレートそのものには影響しません。クロールレートに影響を与えるのは429ステータスコードのみです。
robots.txtが403を返す場合の二重リスク
見落としがちなリスクとして、robots.txtファイルも403を返している場合があります。
この場合、Googleはrobots.txtが「存在しないもの」として扱います。
Gary Illyes氏は公式ブログで次のように警告しています。
クライアントが robots.txt ファイルをリクエストしたときに
4xxHTTP ステータス コードが返されると、このファイル自体が存在しないものとして扱われます。仮に秘匿したい情報のクロールを禁止するルールを定めていた場合、そのことを Googlebot が認識することになります。これは双方にとって望ましいことではありません。
クロール頻度の抑制に 403 または 404 を使用しないでください
その結果、本来robots.txtでブロックしていたURLまでGooglebotのクロール対象になってしまいます。
このリスクについて詳しくは「robots.txtによりブロックされたがインデックス登録された場合の対処法」でも解説しています。
ステータスコード別のSEO影響比較
以下にステータスコード別のSEOへの影響をまとめました。
| ステータスコード | インデックスへの影響 | クロールレートへの影響 |
|---|---|---|
| 403 Forbidden | インデックスから削除 | 影響なし |
| 404 Not Found | インデックスから削除 | 影響なし |
| 429 Too Many Requests | インデックスから削除 | クロール速度が低下 |
| 503 Service Unavailable | 一時的にクロール停止 | クロール速度が低下 |
403と404 Not Found・ソフト404エラーでは原因も対処法も異なるため、混同しないよう注意してください。
≫inSiteでサイトのインデックス状況をチェックしてみる(無料)
「アクセス禁止(403)が原因でブロックされました」に関するよくある質問
403ブロックに関してよく寄せられる質問と回答をまとめました。
アクセスが拒否されました403とはどういう意味ですか?
HTTP 403 Forbiddenは、サーバーがリクエストを理解したうえで認可を拒否したことを示すステータスコードです。
サーチコンソールでこのステータスが表示されている場合、Googlebotがページにアクセスしようとした際にサーバー側のアクセス制限設定によって拒否されたことを意味します。
Googlebotは認証情報を提供しないため、WAFやIP制限、.htaccessの設定などサーバー側の問題が原因です。
403エラーの解消方法は?
403エラーの原因によって解消方法が異なります。
主な原因と対処法は以下の4つです。
- WAF・CDNのBot対策によるブロック → 設定でGooglebotを許可
- WordPressセキュリティプラグインの影響 → プラグイン設定の見直し
- .htaccessやパーミッションの問題 → 設定ファイルの修正
- IP制限・地理的制限 → GooglebotのIPレンジをホワイトリストに追加
修正後はサーチコンソールのURL検査ツールで「ライブテスト」を実行し、200 OKが返ることを確認してください。
admin-ajax.phpやwp-jsonの403は対処すべきですか?
基本的に対処は不要です。
admin-ajax.phpはWordPressの管理用リソース、wp-jsonはWordPress REST APIであり、いずれも検索結果に表示させる必要のないURLです。 セキュリティプラグインが意図的にブロックしているケースがほとんどであり、放置して問題ありません。
対処が必要なのは、ブログ記事や商品ページなど検索結果に表示させたい公開ページが403になっている場合に限られます。
403エラーと404エラーの違いは何ですか?
403(Forbidden)と404(Not Found)は、どちらも4xxクライアントエラーですが、意味が異なります。
- 403はページ自体は存在するが、サーバーがアクセスを拒否している状態
- 404はリクエストされたリソースがサーバー上に存在しない状態
SEOへの影響は類似しており、どちらもインデックスから削除されます。 ただし、403はサーバー設定の修正で解消できるのに対し、404はページの復元やリダイレクト設定が必要です。
Google Search AdvocateのJohn Mueller氏は「通常は404でクリーンにすべき」と述べており、意図的にページを非公開にする場合は403ではなく404を返すか、ソフト404エラーの対処法も参考にしてください
≫inSiteでサイトのインデックス状況をチェックしてみる(無料)
その他のインデックスステータス一覧
その他のインデックスステータスの一覧を以下の表にまとめました。他のエラーや除外が発生している方は参考にしてください。
▼インデックスステータス一覧表
| 大分類 | カテゴリ | ステータス名 | 対処の必要性 |
|---|---|---|---|
| 登録済み | – | ページはインデックスに登録済みです | 不要 |
| 警告あり | robots.txtによりブロックされましたが、インデックスに登録しました | 確認推奨 | |
| コンテンツのない状態でページがインデックスに登録されています | 確認推奨 | ||
| 未登録 | エラー | サーバーエラー(5xx) | 高い |
| リダイレクトエラー | 高い | ||
| 未承認のリクエスト(401)が原因でブロックされました | 高い | ||
| アクセス禁止(403)が原因でブロックされました | 高い | ||
| 見つかりませんでした(404) | 状況による | ||
| 他の 4xx の問題が原因で、URL がブロックされました | 高い | ||
| ソフト404 | 高い | ||
| ブロック | robots.txt によりブロックされています。 | 意図的なら不要 | |
| URL に noindex が指定されています | 意図的なら不要 | ||
| クロール・Google判断 | 検出 – インデックス未登録 | 中程度 | |
| クロール済み – インデックス未登録 | 高い | ||
| 重複・正規化 | 代替ページ(適切なcanonicalタグあり) | 不要 | |
| 重複しています。ユーザーにより、正規ページとして選択されていません | 確認推奨 | ||
| 重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました | 確認推奨 | ||
| ページにリダイレクトがあります | 不要 |
なお、全ステータスについて詳しく解説している「インデックスカバレッジとは?全ステータスの意味と対処法を解説」も参考にしてください。
また、インデックスに登録されないページ数を確認する方法は、「「インデックスに登録されていないページ数」の確認方法と対処法【放置OKなケースも解説】」を参考にしてください。
≫inSiteでサイトのインデックス状況をチェックしてみる(無料)
まとめ
「アクセス禁止(403)が原因でブロックされました」への対処のポイントを整理します。
- 403ブロックの意味
Googlebotがサーバーからアクセス拒否された状態。サーバー側の設定が原因 - 対処の判断基準
admin-ajax.phpやwp-json等のシステムリソースなら対処不要。公開ページが対象なら早急に対処 - 主な原因は4つ
WAF・CDN、セキュリティプラグイン、サーバー設定(.htaccess・パーミッション)、IP制限 - 修正後の確認
URL検査ツールのライブテストで200 OKを確認し、「修正を検証」から再クロールをリクエスト - 放置のリスク
インデックスから削除される。robots.txtが403を返す場合は全URLがクロール対象になるリスクも
まずはサーチコンソールの「ページのインデックス登録」レポートで403ブロックの対象URLを確認し、本記事の判断基準に沿って対処が必要かどうかを判別してみてください。
他のインデックス関連の問題については、「インデックスカバレッジの全ステータス一覧」や「クロール済み–インデックス未登録の原因と対処法」も参考になるでしょう。
インデックス状態の把握が大変という方は、SEOサイト管理自動化ツール「inSite(インサイト)」を試してみてください。
inSiteのインデックスチェック機能では、サイト内のページのクロール状態を毎日自動でチェックします。
どれだけのページがインデックスされてなくて原因は何なのか、クローラーは定期的に来ているのかといった情報を常に監視することができます。

1ページずつURL検査をしなければわからないインデックス状態。
inSiteを使えばこれを常に把握できるため、効率よくSEOにおける有効な打ち手を考えることができます。
ページのインデックス率向上や、ページの評価をアップさせるリライトの効率化にかなり使えると思うので、ぜひお試しください。

