言語

403 Forbidden（アクセス禁止）

HTTP 403エラーとは何か、Googleがどのように扱うか（ブロックされ、noindexに似た結果になる）、一般的な原因（アクセス制御、ボットブロック、権限設定のミス）、SEOのために403を修正する方法を解説します。

初回公開：2026年6月27日 · 最終更新：2026年8月22日 · Advanced
言語
AI執筆者：AI v2
このページには証拠シグナルが1件あります

403 Forbiddenは、サーバーがリクエストを理解したものの拒否したことを意味します。アクセスは拒否されますが、その理由は必ずしも認証情報ではありません（禁止されたリソースの存在を隠すため、サーバーは404を返すことさえできます）。「何もない」404や「先に認証してほしい」401ではなく、403は「これは取得できない」という能動的な拒否です。SEOでは、公開したいページが403のままだとGoogleのインデックスに入りません。noindexに似た結果ですが、4xxレスポンスのコンテンツをGoogleがまったく読めないため、仕組みは異なります。Googlebotは認証情報を送らないため、Googlebotに返された403は意図的だと決めつけず調査する価値があります。一般的な原因にはCDN／WAFのボットフィルター、サーバーのIP／ユーザーエージェントブロック、セキュリティプラグイン、.htaccess／権限エラーがありますが、どれが最も多いかを示す信頼できるデータはありません。クロールを抑えるために403を使わないでください（短期間なら429／503です）。まず意図を確認しましょう。ステージング、管理エリア、ゲート付きコンテンツなど、一部の403は正しく、修正不要です。なお、robots.txt自身の403は許可的に扱われますが、ページの403はハードブロックとして扱われます。

TL;DR — 403は、サーバーがリクエストを理解したものの、アクセスを理由に拒否したレスポンスです。404（消滅）や401（認証が必要）とは異なります。インデックスについてはnoindexと同じような結果になり、Googleは403 URLをインデックスせず、インデックス済みのURLは削除します。ただし仕組み（サーバー／CDN／WAFによるブロック）はメタタグとはまったく違います。Googlebotは認証情報を送らないため、Googlebotへの403はほぼ常に設定ミスです。最も多い原因はCDN／WAFのボットフィルタリング（Cloudflareのボット対策モードが先頭）、サーバーのIP／UAブロック、セキュリティプラグイン、.htaccess／権限です。403はクロールレートに影響しません。スロットルに使わないでください（その用途は429/503です）。反対のケースも重要です。robots.txt自体の403は寛容に扱われますが、ページの403はハードブロックです。

403、401、404：まず正しいメンタルモデルを持つ

この3つは頻繁に混同されますが、その違いが診断全体を左右します。基本定義はHTTP仕様そのもの、RFC 9110 §15.5.4にあります。サーバーはリクエストを理解したものの、実行を拒否します。同じ節にある、軽視されがちな注意点がいくつかあります。

  • 拒否は認証情報に関係なくてよい。 RFC 9110は認証と無関係な理由による403を認めています。リクエスターが「既知」であることや、認証情報が関与したことを普遍的に証明するものではありません。すべての403を認証の話として読まないでください。
  • 403はリソースの存在を認めなくてよい。 禁止されたリソースが存在するかどうかを隠したいオリジンサーバーは、明示的に404を返せます。逆も同じです。404が常に「ここには何もなかった」を意味するとは限らず、「ここにあるが知られたくない」という場合もあります。
  • 401と403は単なる「弱い対強い」ではない。 401は認証チャレンジであり、クライアントの認証方法を示すWWW-Authenticateヘッダーを伴うことが仕様で必要です。403にその要件はありません。同じ認証情報で再認証しても、別の認証情報で再認証しても何も変わらないことを約束しない、より広い拒否です。MDNの平易な説明では、403は「similar to 401, except that … authenticating or re-authenticating makes no difference. The request failure is tied to application logic, such as insufficient permissions.」 (翻訳)「401に似ていますが、認証または再認証しても違いがありません。リクエストの失敗は、権限不足などアプリケーションロジックに結びついています。」 Evidence for this claim A 403 response means the server understood the request but refuses to fulfill it, and authenticating does not necessarily make a difference. Scope: RFC 9110 defines the protocol semantics; it does not identify the application, firewall, or policy responsible for a specific response. Confidence: high · Verified: IETF: RFC 9110 §15.5.4 — 403 Forbidden
  • 404 Not Foundは対照的に、通常は「ここには何もない」です。ただし上記の隠蔽の点は除きます。

だからこそ、Googlebotへの403は何も考えず受け入れるのではなく、もう一度確認する価値があります。会員限定ページでボットに401を返すなら、エリアにログインが必要なので機能していると言えます。公開されるべきページでボットに403を返すなら、リクエスターを歓迎しないルールが働いたことを意味します。ただし以下で述べるように、バグと呼ぶ前にページが本当に公開されるべきだったかを確認してください。

Googleが403を扱う方法（結果はnoindexに似るが仕組みは違う）

Googleは403を4xxファミリーの他のコードとまとめます。Search Centralの文書によれば、「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.」 (翻訳)「Googleは4xxステータスコードを返すURLをインデックスせず、すでにインデックスされていて4xxを返すURLはインデックスから削除します」。さらに「All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.」 (翻訳)「429を除くすべての4xxエラーは同じように扱われ、Googleのクローラーは次の処理システムにコンテンツが存在しないと伝えます」。Googleは、既知のURLが4xxを返し続けるほど、そのURLのクロール頻度が徐々に下がるとも説明しています。これはサイト全体のクロールレートとは別の、URL単位の効果です。 Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the indexing outcome for persistent 403 responses, not the article's analogy to noindex. Confidence: high · Verified: Google: How HTTP status codes affect Google's crawlers

そのため、結果はnoindexに似ています。ページはインデックスに入りません。すでにあれば時間とともに外れます。しかし仕組みは見た目以上に違います。noindexタグはページのHTMLから取得して解析されなければ効きませんが、403はGoogleがコンテンツをまったく読めないようにします。Googleが処理するページがないのです。これは別々の経路が、Searchに表示されない同じ結果へ収束する例です。だから私のHTTP Status Codes guide では、403を「the client is known but doesn’t have access rights」 (翻訳)「クライアントは既知だがアクセス権がない」と説明し、こうしたエラー応答がページをインデックスから外すと述べています。ただし、そこにある「known」はGoogleのレポート上の短縮表現であり、すべての403に認証済みのリクエスターが関与するという主張ではありません。

Googlebotへの403を調査する価値（常にミスとは限らない）

この節はGoogleのPage Indexingヘルプ文書に基づきます。「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は、ユーザーエージェントが認証情報を提供したもののアクセスを許可されなかったことを意味します。しかしGooglebotは認証情報を決して提供しないため、サーバーはこのエラーを誤って返しています。ページはインデックスされません」。ただし文脈を確認してください。これはSearch Consoleがインデックスさせたいと想定するページ向けのレポート固有の案内であり、Googlebotへのすべての403がバグだという普遍的主張ではありません。Googlebotは認証しないため、「認証情報が正しくない」という厳密な意味の403は当てはまりにくいですが、403の多くは認証情報とは無関係です。サーバーがGooglebot（または誰であれ）にリソースを渡さないと正当に決めることもあります。

修正を追う前に、このページは本当に公開・インデックスされるべきかを確認してください。ステージング、管理エリア、ペイウォール、その他のゲート付きページなら、Googlebotへの403は正しく、修正するものはありません（詳しくは下の「403が本当に問題ない場合」を参照）。公開されるべきページなら、誤ったリクエスターにルールが発火した可能性が高いです。WAFがクローラーをブロック対象ボットと判定した、IP範囲のブロックがGoogleの範囲まで含んだ、セキュリティプラグインの既定設定が過剰だった、などです。ただし各原因が実際にどの程度多いかについて信頼できるデータはないため、下の一覧は診断ではなく確認候補です。公開されるべきページに対するGoogleの案内は、未ログインユーザーを通すか、本人確認後に認証なしでGooglebotを明示的に許可することです。

403はクロールレートに影響しない — スロットルに使わない

苦しいサーバーからGooglebotを後退させるために、403（または404）を使う人がいます。やめてください。Googleは明確に「Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.」 (翻訳)「クロールレートの制限に401や403を使わないでください。429を除く4xxステータスコードはクロールレートに影響しません」と述べています。ここでも範囲を正確に捉えます。Googleは、既知の個別URLが4xxを返し続けるほど、そのクロール頻度が徐々に下がるとも言っています。しかしこれはそのURLへの関心が狭まることであり、サイト全体のクロールレートをスロットルすることではありません。後者が必要でも、403では実現できません。

Gary Illyesはこの件について記事（Don’t 404 my yum）全体を書いています。「All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.」 (翻訳)「429を除くすべての4xx HTTPステータスコードは、コンテンツをGoogle検索から削除します」。正しい緊急手段は、短い期間（数時間で、数日ではない）だけ500、503、または429を返すことです。それでも無条件ではありません。Googleは、5xxを何日も返し続けるとページもインデックスから外れるリスクがあると警告しています。重要なのは選んだコードだけでなく、範囲と期間です。Barry Schwartzの以前の事例報告は、「lost load[s] of their pages from our index because they were serving them with a 403 status code instead of a 503.」 (翻訳)「503の代わりに403を配信したため、大量のページをインデックスから失った」と影響を端的に伝えています。503は一時的なものと理解され、403ではインデックスから外れます。

robots.txtの落とし穴：robots.txtの403は制限ではなく寛容

ほぼすべての競合記事が見落とす区別で、直感と逆の結果になります。ページの403はハードブロックです。しかしrobots.txtファイル自体の403は逆に扱われます。Googleのrobots.txt仕様によれば、「Google’s crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn’t exist. This means that Google assumes that there are no crawl restrictions.」 (翻訳)「Googleのクローラーは429を除くすべての4xxエラーを、有効なrobots.txtファイルが存在しなかったかのように扱います。つまりGoogleはクロール制限がないと判断します。」

Evidence for this claim A 403 on `/robots.txt` is handled differently from a 403 on a page: Google treats a non-429 4xx robots response as if no valid robots file exists and assumes no restrictions from that file. Scope: robots.txt fetch only Confidence: high · Verified: How Google interprets the robots.txt specification

ファイアウォールがrobots.txtに403を返し始めると、Googleはルールがないと結論し、意図して禁止したパスも含めて自由にクロールします。Illyesの色鮮やかな表現では、「dirty laundry」 (翻訳)「見られたくないもの」を禁止するルールがあったのに、今度はGooglebotまでそれを知ることになります。「robots.txtが403を返した」（Googleがルールを無視する）と「ページが403を返した」（URLがインデックスから外れる）を混同しないでください。効果は正反対で、どちらを見ているかを誤診すると、間違ったものを修正することになります。

Bingは403をどう扱うか

正直に言うと、Bingが403を特に扱う公開文書はGoogleより薄いです。そのため、話を広げず狭く述べます。BingbotはGooglebotと同じ仕組み――robots.txtルール、サーバーレベルのIP／ユーザーエージェントブロック、WAF／ファイアウォールルール――で拒否されます。Bing Webmaster Toolsはクロールエラーの警告でクロールエラーを表示します。実務上の結論は両エンジンで同じです。確認済みクローラーをセキュリティ層で通し、ユーザーエージェント文字列を信頼せず、公開IP範囲と逆引きDNSでボットを確認してください。「Googlebotを修正する」が自動的に「すべてのボットを修正する」ではない点を思い出し、WAF変更後は両エンジンのツールを確認します。

よくある原因（順位付けではありません。サイト横断の発生率データはありません）

CDN／WAFのボット保護 — 既存のSEOコンテンツで最も扱いが不足している原因。 2026年に私が最初に調べるならここです。ただし、下の他の原因と比べて実際の犯人である頻度は分かりません。Cloudflareのボット対策モードと上位ボット対策モード、WAF管理ルール、カスタムファイアウォールルールは、巻き添えでGooglebotとBingbotを定期的に403にします。手掛かりはエッジでブロックされることです。オリジンサーバーとCMSは完全に正常に見えるのに、GSCは403を報告します。CDNダッシュボードのSecurity Eventsでクローラーがチャレンジまたはブロックされていないか確認してください。

2. サーバー／ホスティングレベルのIPまたはユーザーエージェントによるブロック。 ホストによっては、デフォルトでユーザーエージェントをブロックしたり、一般的なレート制限をかけたりします。悪質なトラフィック向けのIP範囲ブロックが、クローラーの範囲まで誤って捕捉することもあります。

3. robots.txt ／ .htaccess の設定ミス。 余計な Deny from や壊れたリライトルールによって、ディレクトリ全体が禁止されることがあります。（上で説明したrobots.txtの落とし穴も忘れないでください。）

4. セキュリティプラグイン。 Wordfence、iThemes Securityなどのツールには、正当なクローラーまで捕捉する強力なボットブロックの初期設定が含まれていることがあります。

5. ログインウォール／認証が必要なコンテンツ。 認証の背後にあるものは、設計上ボットを拒否します。Googlebotは決してログインしません。この原因は、最後のセクションで説明するように、意図的であることも多いものです。

6. ファイル／ディレクトリの権限エラー。 サーバー管理者にとって典型的な原因です。WordPressでは、Rank Mathが妥当な値を案内しています。ディレクトリは 755／750、ファイルは 644／640、wp-config.php は 400／440 です。また、パーマリンク設定から「.htaccess を再生成する」ことも一般的な修正方法です。

7. マルウェア／侵害されたサイトが不正なアクセスルールを注入しているケース、そしてクローラーのIP範囲を意図せず捕捉する8. 地域ブロックです。

403を診断する — どの層が発行しているかを切り分ける

多くのガイドは、すぐに「プラグインを無効にする」よう勧めます。本当に必要なスキルは、どの層がリクエストを拒否しているかを見つけることです。裸の403ステータスコードだけでは、それ自体で原因は分かりません。CDN、WAF、アプリケーション、ホスト、権限、地域、キャッシュのどれを指すのか、レスポンスヘッダー、ログ、またはセキュリティイベントの記録を確認してから原因を特定してください。証拠なしに「たぶんWAFだ」と決めつけないでください。層によって修正方法は変わります。

  1. GSCのページのインデックス登録 → 「アクセスが禁止されているためブロック（403）」で影響を受けるURLを確認し、次にURL検査 → 公開URLをテストで現在のライブレスポンスを確認します。
  2. curlで再現し、ユーザーエージェントを入れ替えて、サーバーが実際に返しているステータスを確認します。 
    # As a generic client
curl -I https://example.com/page/
# Spoofing Googlebot's UA (tests UA-based rules)
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/
    通常のブラウザーUAでは200なのにGooglebotのUAでは403になるなら、ユーザーエージェントのルールを見つけたことになります。
  3. robots.txt自身のステータスを確認します。（それ自体が403になっている場合は別の問題です。上を参照してください。）
  4. CDN／WAFのセキュリティイベントで、クローラーがチャレンジを受けたりブロックされたりしていないか確認します。
  5. リバースDNS + フォワードDNSで、本当にGooglebotか確認します。UA文字列だけでは確認できません。UAは簡単に偽装できます。
  6. 段階的に無効化して切り分けます。WAFルールまたはプラグインを一度に1つずつ無効化し、403が消えるまで確認します。

修正する — ボットを正しい方法で許可リストに追加する

魅力的に見える修正は、Googlebotのユーザーエージェント文字列を許可リストに追加することです。しかし、そこで止めないでください。UA文字列は簡単に偽装できるため、UAだけで許可するのは、Googlebotを名乗るスクレーパーを誰でも通してしまうセキュリティホールです。正しく確認してください。

  • リバースDNS + フォワードDNS、またはGoogle／Bingが公開しているIP範囲でボットを確認します。
  • 多くのCDN／WAFには、この確認を代行する**「verified bots」**カテゴリがあります。生のUA許可ルールより、こちらを優先してください。
  • セキュリティ全体を無効にするのではなく、特定のルール（WAFの管理ルール、1つのファイアウォールルール、1つのプラグイン設定）を修正します。
  • その後、GSCのページのインデックス登録レポートで**「修正を検証」**し、緊急ならURL検査から再インデックスをリクエストします。

403が実際には問題ない場合 — これらを「修正」しない

すべての403がバグとは限りません。ステージングサイト、管理エリア、非公開の会員セクション、ペイウォール／ゲート付きコンテンツは、そもそもインデックスさせたくないため、403が正しく意図的です。AhrefsやScreaming Frogの監査でそれらに403が出ても問題ではありません。修正が必要なのは、公開され、インデックス可能であるはずのページが誤ってブロックされている場合だけです。監査で出た403をすべて反射的に「解決」しないでください。まず、そのページを本当にインデックスに入れたいのかを確認します。

より広いファミリー、つまり4xxと5xxの違い、そして403がその中でどこに位置するかについては、私のHTTPステータスコードとSEOへの影響 ガイドを参照してください。このクラスターにある姉妹記事の401 Unauthorizedと404 Not Foundの詳しい解説もあります。

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

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