ページを開こうとしたら、画面に「403 Forbidden」とだけ表示されて先に進めない。
「自分のスマートフォンやパソコンに問題があるのか」
「自分で直せるのか、それともサイトの管理者に連絡するべきなのか」
といった経験のある方、もしくは今迷っている方もいらっしゃるかもしれません。
403 Forbiddenは、ページを見たいという要求が、サーバー側で拒否されたことを示す表示です。ただ、この表示だけでは、なぜ拒否されたのかまでは特定できません。
閲覧者側の確認で改善する場合もあれば、サイト側で設定を確認・変更しなければ解決しない場合もあります。本記事では、403 Forbiddenの意味と主な原因、閲覧者・サイト管理者それぞれの対処法、そして検索結果への影響をまとめましたので、参考にしてください。
403 Forbiddenとは
突然「403 Forbidden」と表示されても、何が起きているのかわからず戸惑うこともあるでしょう。
403 Forbiddenは、サーバーがリクエスト（ページやファイルを送ってほしいという要求）を理解したうえで、その処理を拒否したことを示すHTTPステータスコードです。HTTPステータスコードとは、Webサーバーがブラウザなどからのリクエストに対して、処理の結果を伝えるための3桁の番号です。例えば、ページを正常に返せたときは「200」、ページが見つからないときは「404」が返されます。
HTTPの仕様では、リクエストに認証情報（IDやパスワードなど、利用者本人であることを示す情報）が含まれていた場合、サーバーはそれをアクセスの許可には不十分だと判断した、とされています。一方で、認証情報とは関係のない理由で拒否される場合があることも示されています。MDNの解説でも、403は認証や再認証を行っても結果が変わらない点で401と異なり、リソース（ページやファイルなど）に対する権限の不足などに関係するものと説明されています。
ただ、ここでいう「結果が変わらない」は、同じ権限のままログインし直しても解決するとは限らない、という意味で受け取っておくとよいでしょう。HTTPの仕様では、同じ認証情報で自動的に再試行することは勧めていない一方で、新しい、または別の認証情報で改めてリクエストすることは認めています。例えば、必要な権限を持つ別のアカウントでアクセスすると、結果が変わる場合はあります。
（参照：RFC 9110: HTTP Semantics｜IETF）
（参照：403 Forbidden – HTTP｜MDN Web Docs）
つまり、403という番号からわかるのは「拒否された」という結果までです。サーバーが拒否の理由を画面に表示している場合もありますが、表示されていない場合は、番号だけで具体的な原因や対処法を判断することはできません。
似た番号の401・404との違いは、次のとおりです。
| ステータスコード | 意味 |
|---|---|
| 401 Unauthorized | 対象にアクセスするための有効な認証情報が不足している |
| 403 Forbidden | リクエストを理解したうえで、処理を拒否している |
| 404 Not Found | 対象が見つからない、または対象があることを明らかにしない |
なお、サーバーによっては、アクセスを許可していないページの存在を知られないよう、403ではなく404を返すこともあります。また、「403が出ているのだからログインしていない」「ログインし直せば解決する」とは限りません。
まずは「アクセスが拒否された」という事実だけを押さえて、次の章で紹介する原因の候補と照らし合わせてみてください。
403 Forbiddenが表示される主な原因
同じ403が表示されていても、どこに原因があるのかは見た目だけでは判断しにくいものです。
ここでは、403が返される代表的な状況を紹介します。あくまで原因の候補であり、すべての403に当てはまるわけではありません。具体的な確認の進め方は、閲覧者向け・サイト管理者向けの対処法の章で解説します。
ファイル・ディレクトリのアクセス権限に問題がある
Webサイトを構成するファイルやディレクトリ（フォルダ）には、誰が読み取りや書き込みなどを行えるかを定めるアクセス権限があります。レンタルサーバーなどでは、この設定を「パーミッション」と呼ぶのが一般的です。
パーミッションの設定によって、Webサーバーがファイルを読み取れない状態になっていると、403が返される場合があります。レンタルサーバーを提供するさくらインターネットも、403の原因の一つとしてパーミッションの設定の問題を挙げています。
（参照：ウェブページのエラーメッセージ（40X、50X…のようなエラーコード）を知りたい｜さくらインターネット）
例えば、ファイルを新しくアップロードしたときや、サーバーを移転したときに、意図しない権限になってしまうことがあります。ただ、いつ・何を変更したのかがわからないまま、権限だけを原因と決めつけるのは避けたほうがよいでしょう。権限を疑うときは、ほかの原因の候補もあわせて確かめてみてください。
indexファイルがない、または公開先の設定が異なる
indexファイルとは、URLがファイル名ではなくディレクトリを指しているときに、表示するページとして設定されているファイルです。例えば、https://example.com/blog/ にアクセスすると、blog ディレクトリ内の index.html が表示される、という仕組みです。
Webサーバーソフトの一つであるApacheでは、indexファイルとして探すファイル名を設定でき、初期値は index.html です。設定されたindexファイルが見つからないときに、ディレクトリ内のファイル一覧を自動で表示するのは、一覧表示が許可されている場合に限られます。そのため、indexファイルがなく、一覧表示も許可されていない環境では、403が返されることがあります。さくらインターネットの資料でも、indexファイルが存在しない場合を403の原因の一つとしています。
（参照：mod_dir – Apache HTTP Server Version 2.4｜The Apache Software Foundation）
もちろん、indexファイルがないからといって、必ず403になるわけではありません。サーバーの設定によっては、ファイル一覧が表示されるなど、別の挙動になることもあります。
公開先の設定も、確認しておきたい候補の一つです。公開先とは、サイトのファイルを置いて外部に公開するためのフォルダ（公開フォルダ）のことです。例えば、ファイルを公開フォルダとは別の場所にアップロードしていた、サーバー側で指定している公開フォルダが想定と異なっていた、といった場合には、表示したいindexファイルが見つからず、403につながることがあります。
なお、ディレクトリの一覧表示を許可すると、公開するつもりのないファイル名まで外部から見えてしまうおそれがあります。403を解消する目的で、一覧表示を一律に許可するのはおすすめしません。
.htaccessなどでアクセスが制限されている
.htaccess は、Apacheなど対応するWebサーバーで使われる設定ファイルで、ディレクトリごとにアクセスの許可・拒否やリダイレクト（転送）などを設定できます。すべてのWebサーバーで使われるわけではなく、サーバーの種類や設定によっては読み込まれません。
.htaccess などで特定のディレクトリへのアクセスを拒否している場合や、許可された接続元以外からアクセスした場合には、403が返されることがあります。さくらインターネットの資料でも、.htaccess によるアクセス制限を403の原因として挙げています。
また、サーバー側の設定とは別に、会員サイトや管理画面では、CMS（WordPressなど、Webサイトのコンテンツを管理するシステム）やアプリケーションの側で403を返すことがあります。例えば、ログインはできているものの、そのアカウントに閲覧や操作の権限が与えられていない場合です。MDNの解説でも、管理者の権限が必要な操作を、その権限を持たない利用者が行おうとして403になる例が紹介されています。
会員ページや管理画面で403が出た場合は、サーバーの設定だけでなく、アカウントの権限も原因の候補に入れておくとよいでしょう。
WAFやセキュリティ機能によりアクセスが拒否されている
WAF（Web Application Firewall）は、Webサイトへの不正な通信を検知し、防御する仕組みです。レンタルサーバーの機能として提供されているものや、CDN（後述）と組み合わせて使うものなどがあります。
WAFのルールのうち、通信を遮断する設定になっているものに一致すると、アクセスが拒否され、403が返される場合があります。WAFでは、正当なアクセスを誤って不正な通信と判断してしまう「誤検知」が起こることもあります。CDNやセキュリティサービスを提供するCloudflareも、WAFのルールで誤検知が起こりうることを示したうえで、管理画面での操作やファイルのアップロードなどで誤検知が起きた場合の対応を案内しています。
（参照：Troubleshoot managed rules｜Cloudflare）
ただ、403が出たことだけを根拠に、攻撃を受けている、あるいは誤検知が起きていると判断することはできません。WAFが関係しているかどうかは、ログと設定をあわせて確かめる必要があります。これに関しては、後述します。
IPアドレスや閲覧する地域が制限されている
サイト側が、接続元のIPアドレスや、アクセスしてくる国・地域を条件に、閲覧を制限している場合があります。IPアドレスとは、インターネットに接続している機器や回線に割り当てられる番号で、通信の送り元・送り先を識別するために使われます。
例えば、管理画面には社内のネットワークからしか入れないようにしている、特定の国・地域への配信を止めている、といった設定です。AWS（Amazon Web Services）のCDNサービスであるCloudFrontでも、地域制限を有効にすると、制限対象の地域の利用者には403が返されると説明されています。
（参照：HTTP 403 status code (Permission Denied)｜Amazon Web Services）
そのため、「自宅のWi-Fiでは開けないのに、スマートフォンのモバイル回線では開ける」といったように、特定の回線や地域からだけアクセスできないこともあります。
こうした制限は、サイト運営者が意図して設定している場合もあり、制限があること自体が設定ミスとは限りません。VPN（通信を別の場所にあるサーバー経由で送る仕組み）などを使って制限をくぐり抜けようとはせず、閲覧が必要な場合はサイトの運営者に相談してください。
CDN・サーバー側のドメイン設定に不整合がある
CDN（Content Delivery Network）は、Webサイトのデータを複数の拠点にあるサーバーから配信し、表示を速く・安定させる仕組みです。また、DNSは、example.com のようなドメイン名と、実際の接続先（サーバーのIPアドレスなど）を結び付ける仕組みです。
DNSで指定した接続先と、CDNやサーバーの側に登録されているドメインの設定が一致していないと、接続先がリクエストを受け付けず、403を返すことがあります。
例えば、CloudFrontで独自ドメインを使ってサイトを配信する場合は、DNSでドメインをCloudFrontに向ける設定と、CloudFrontの配信設定にそのドメインを追加する設定の両方が必要です。DNSの設定だけを行い、配信設定にドメインを追加していないと、403が返されると説明されています。この例はCloudFrontの仕様であり、すべてのCDNやサーバーで同じ挙動になるとは限りません。
なお、DNSの名前解決（ドメイン名から接続先を調べる処理）そのものに失敗した場合は、サーバーにたどり着けないため、HTTPステータスコード自体が返ってきません。ブラウザ側で別のエラーとして表示されるため、DNSに関する問題がすべて403として表れるわけではありません。
サーバーの移転やドメインの変更の直後に403が出た場合は、DNSの設定内容と接続先が想定どおりになっているか、管理を担当している方に確認してみてください。
403 Forbiddenの対処法【閲覧者】
見たいページが開けないと、自分の端末で何を確認すればよいのか迷うこともあるでしょう。
ここでは、閲覧者の方が安全に試せる確認を、手軽なものから紹介します。確認しても改善しない場合は、無理に操作を続けず、サイトの管理者に相談してください。
URLや閲覧権限を確認する
最初に、開こうとしているURLに入力間違いがないかを確かめましょう。手入力したURLや、以前に保存したブックマーク、メールやチャットで送られてきたURLの場合は、案内された正しいページかどうかもあわせて確認しておくと安心です。
会員限定のページや、社内システム・管理画面などでは、利用しているアカウントに、そのページを見るための権限があるかどうかも確認が必要です。
サイトの案内に沿って、ログインした状態になっているか、利用条件を満たしているかを確かめることは大切です。ただ、前述のとおり、403は認証情報とは関係のない理由で返されることもあります。ログインし直しても表示が変わらない場合は、ログインの問題だけが原因とは限りません。
自分のアカウントにどこまで権限があるのかわからない場合は、サイトの運営者や、所属している組織の担当者に確認してみてください。
別のブラウザ・端末・回線で試す
URLや権限に問題がなさそうなら、403が「どの範囲で」起きているのかを比べてみましょう。自分だけなのか、特定のブラウザだけなのか、スマートフォンだけなのか、特定の回線だけなのかがわかると、原因の候補を絞り込みやすくなります。
例えば、次のような方法で、同じURLを開いてみます。
- 別のブラウザ（ChromeとSafari、Edgeなど）で開く
- 別の端末（パソコンとスマートフォンなど）で開く
- 利用できる別の回線（自宅のWi-Fiとモバイル回線など）で開く
- 可能であれば、閲覧権限のある別の人の環境で開いてもらう（一般公開のページなら、家族や同僚など）
Cloudflareの資料でも、同社の認証チャレンジ（人によるアクセスかどうかを確かめる画面）がうまく進まない場合の確認として、別のブラウザ・端末・回線で試す方法が案内されています。ただ、これは認証チャレンジに関する案内であり、すべての403に共通する手順ではありません。
（参照：Challenge solve issues｜Cloudflare）
比べた結果によって、次に確認することが変わります。
| 比べた結果 | 次に確認すること |
|---|---|
| 特定のブラウザだけで表示される | 対象サイトのキャッシュ・Cookie、ブラウザの拡張機能 |
| 特定の回線だけで表示される | VPN・プロキシの利用状況、接続元に対する制限 |
| どの環境でも表示される | URL・閲覧権限の再確認、サイト管理者への相談 |
この比較は、あくまで原因の候補を絞り込むためのものです。例えば、別の回線で開けたとしても、それだけで原因がIPアドレスの制限だと決まるわけではありません。また、回線の切り替えは、サイト側の制限を避けるためではなく、どこで問題が起きているのかを知るために行うものです。比べた結果は問い合わせのときにも役立ちますので、メモしておくとよいでしょう。
ブラウザの保存データや接続設定を確認する
特定のブラウザだけで403が表示される場合は、ブラウザに保存されているデータや、接続にかかわる設定を確認してみましょう。
ブラウザには、表示を速くするためにページのデータを保存しておく「キャッシュ」や、サイトがログイン状態や設定を保存するための「Cookie」があります。こうしたデータが影響している場合は、対象サイトのキャッシュやCookieを削除すると、表示が変わることがあります。
ただ、Cookieを削除すると、そのサイトからログアウトしたり、保存していた設定が消えたりする場合があります。Google Chromeのヘルプでも、Cookieを削除するとサイトからログアウトされることや、保存した設定が削除されることがあると案内されています。削除する場合は、すべてのサイトのデータを一度に消すのではなく、対象のサイトに絞って行うことをおすすめします。
（参照：Chrome で Cookie を削除、許可、管理する｜Google）
また、保存データを削除しても、サイト側の閲覧権限が新たに与えられるわけではありません。権限がないことが原因の場合は、削除しても状況は変わりません。
広告ブロックなどのブラウザの拡張機能や、VPN・プロキシ（通信を中継する仕組み）も、原因の候補になります。一時的にオフにして同じURLを開き、表示が変わるかどうかを比べてみてください。ただ、セキュリティにかかわる機能を、そのまま無効にし続けるのは避けたほうがよいでしょう。会社から支給された端末など、組織が設定を管理している場合は、担当者の指示に従ってください。
なお、キャッシュやCookieの削除、拡張機能の無効化などの具体的な操作は、ブラウザや端末によって異なります。お使いのブラウザ・端末の公式ヘルプを確認しながら進めてください。
解決しない場合はサイト管理者へ問い合わせる
ここまでの確認をしても改善しない場合、閲覧者側では変更できないサイトの設定が原因になっている可能性があります。その場合は、無理に操作を続けず、サイトの管理者や問い合わせ窓口に相談しましょう。
問い合わせの際に次の情報を添えると、管理者が原因を調べやすくなります。
- 403が表示されたページのURL
- 表示された日時
- どの操作をしたときに表示されたか（ページを開いた、フォームを送信した、など）
- 使用した端末・ブラウザ・回線
- 試した確認と、その結果
- エラー画面のスクリーンショット
- 画面にリクエストIDなどの識別番号が表示されている場合は、その番号
リクエストIDは、サーバーやサービスが個々のアクセスを見分けるための番号です。例えば、Cloudflareを利用しているサイトでは「Ray ID」という番号が表示されることがあり、管理者がログを照合する手がかりになります。
スクリーンショットやURLを送る前に、氏名やメールアドレス、会員番号などの個人情報や、ログイン情報が写り込んでいないかを確認してください。パスワードやCookieの中身を、一般の問い合わせ窓口に送る必要はありません。
403 Forbiddenの対処法【サイト管理者】
自社サイトで403が発生すると、早く復旧させたい一方で、どの設定から確認するべきか迷うこともあるでしょう。
ただ、思いつく設定を手当たり次第に変えていくと、何が原因だったのかがわからなくなるだけでなく、必要なアクセス制限まで外してしまうおそれがあります。サイト管理者の方は、次の方針で進めることをおすすめします。
- 発生範囲とログの確認から始め、原因の候補を絞ってから設定を点検する
- 設定を変更する前に、現在の内容を記録し、元に戻せるようにしておく
- 原因がわからないまま、複数の設定を一度に変更しない
- 変更後は、元のURL・操作・環境で再確認し、公開したいページが表示されることと、必要なアクセス制限が維持されていることの両方を確かめる
発生範囲とログを確認する
最初に、403が「どこで」「誰に」「いつ」起きているのかを書き出してみましょう。
- 全ページか、特定のURLやディレクトリだけか
- すべての利用者か、特定のユーザー・回線・地域だけか
- ページを開いたときか、フォームの送信や管理画面での保存など特定の操作をしたときか
- いつから発生しているか
発生した日時がわかったら、その直前にサイトの移転、ファイルの公開・更新、権限の変更、セキュリティ設定の変更などがなかったかを照らし合わせます。
次に、ログを確認します。ログとは、サーバーやサービスが、受け付けたアクセスや発生したエラーを、日時とともに記録したものです。403を返しているのがWebサーバーなのか、CDNなのか、WAFなのかによって、確認すべき設定が変わります。サーバー、CDN、WAFそれぞれのログやイベント情報で、該当する日時・URLのアクセスがどこで拒否されているかを確かめてみてください。
例えば、AWSの資料では、CloudFrontの前段にAWS WAFがある場合、CloudFront側ではオリジン（コンテンツの元になるサーバー）が返した403とWAFが返した403を区別できないため、WAFのルールで遮断されたリクエストを確認するよう案内しています。また、CDNを通さずにオリジンへ直接リクエストを送り、同じ403が再現するかどうかで、オリジン側の問題かどうかを切り分ける方法も示されています。ただ、CDNを経由したアクセスだけを許可し、オリジンへの直接アクセスを拒否している構成もあります。その場合は、直接アクセスで拒否されるのは正常な動作ですので、この確認は構成を把握している方が行うようにしてください。
Cloudflareの資料でも、正当なアクセスが遮断された原因を調べる手段として、セキュリティイベントの記録を確認する方法が案内されています。
利用者からリクエストIDを受け取っている場合は、発生日時やURLとあわせてログの照合に使うと、該当するアクセスを見つけやすくなります。
エラー画面の見た目や403という番号だけで、どこで拒否されているかを判断するのは難しいものです。ログで拒否された場所を確かめてから、次の確認に進んでください。
ファイル・ディレクトリのアクセス権限を確認する
ログなどから、Webサーバー側で拒否されている可能性が高いとわかった場合は、対象のファイルやディレクトリに、動作に必要なアクセス権限が設定されているかを確認します。
パーミッションの適切な値は、サーバーの構成やプログラムの種類によって異なります。利用しているサーバー会社のマニュアルや、サイトを構築した制作会社が推奨している設定に従うことを基本にしてください。一般的な設定例を目にすることもありますが、その値がすべての環境で正しいとは限りません。
とくに、権限を「777」（所有者以外も含めて、読み取り・書き込み・実行ができる状態）に変更したり、サイト全体に一括で広い権限を与えたりする方法は、表示が戻ったとしても、ファイルを書き換えられる危険が高まります。共通の解決策としてはおすすめしません。
どの値が適切か判断が難しい場合は、変更する前にサーバー会社や保守担当者に相談しましょう。
indexファイル・公開先・ドメイン設定を確認する
ディレクトリを指すURLで403が出ている場合は、indexファイルがあるかどうかを確認します。サーバーで設定されているindexファイルの名前と、実際に置いているファイルの名前が一致しているか、置き場所が正しいかもあわせて確かめておきましょう。サーバーによってはファイル名の大文字・小文字も区別されるため、例えば Index.html と index.html の違いでも見つからないことがあります。
あわせて、サイトの公開フォルダが、意図した場所を参照しているかも確認します。サーバーの管理画面などで公開フォルダの設定を変更していないか、ファイルを別のフォルダにアップロードしていないかなどを確かめてみてください。
サーバーの移転やドメインの変更の後に403が出始めた場合は、DNSで指定している接続先と、CDNやサーバー側に登録しているドメインの設定を照らし合わせます。前述のCloudFrontのように、DNSの設定だけでなく、配信設定の側にもドメインを登録しなければならないケースもあります。
DNSの設定を変更した直後は、変更が行き渡るまでに時間がかかることもあります。ただ、時間を置けば必ず解消するとは限りません。設定の内容そのものに不整合がないかを確認することが大切です。
アクセス制限やWAFの設定を確認する
.htaccess などのアクセス制御、IPアドレスや地域による制限、WAFのルールは、発生状況とログに照らし合わせて確認しましょう。会員ページや管理画面で403が出ている場合は、CMSやアプリケーション側のユーザー権限の設定も確認の対象に含めてください。
ここで大切なのは、その拒否が「意図したもの」なのか、「設定の不整合や誤検知」なのかを判断してから対応することです。例えば、海外からのアクセスを意図して制限しているのであれば、その地域の利用者に403が返されるのは想定どおりの動作です。
誤検知が確認できた場合は、保守担当者と相談しながら、影響している対象やルールに範囲を絞って調整することを検討します。Cloudflareの資料でも、特定のリクエストに対して一部のルールを適用しない例外を設ける方法や、問題のあるルールだけを無効にする方法が案内されています。そのうえで、ルールを無効にするとサイト全体のセキュリティが下がることや、ルールセット全体ではなく特定のルールに絞って無効にすることにも触れられています。
一方で、WAFをすべて停止する、すべてのアクセスを許可する、.htaccess などの設定ファイルを削除するといった対応は、表示が戻ったとしても、守るべきページまで無防備になるおそれがあります。一律の対処としては避けてください。
調整後は、利用できるべきアクセスが通るようになったかだけでなく、必要なアクセス制限が残っているかも確認しましょう。例えば、公開ページが表示できるようになった一方で、管理画面に誰でも入れる状態になっていないかを確かめておくと安心です。
サーバー会社や制作・保守担当者に相談する
原因が特定できない場合や、設定を変えたときの影響範囲がわからない場合、そもそも設定を変更する権限がない場合は、サーバー会社や、サイトの制作・保守を担当している会社・担当者に相談しましょう。
相談の際は、次の情報をまとめておくと、調査を進めてもらいやすくなります。
- 対象のURLと発生日時
- 影響している範囲と、再現する条件
- 発生の直前に行った変更
- 確認したログやエラーの内容
- リクエストIDなどの識別番号
- 試した対応と、その結果
ログを共有するときは、調査に必要な範囲に絞り、パスワードやアクセスキー、トークン（認証に使う文字列）などの機密情報が含まれていないかを確認してから渡してください。
相談の結果、表示が戻った場合も、元のURL・操作・環境で同じように表示できるか、必要なアクセス制限が維持されているかを確認しておきましょう。
403 ForbiddenがSEOに与える影響
ページが開けない状態が続くと、検索結果への影響も気になると思います。
検索結果に表示したいURLが、Googlebotに対して403を返している場合、インデックス登録に影響します。Googlebotとは、Googleがページを巡回して情報を集めるプログラム（クローラー）のことです。また、インデックス登録とは、検索エンジンがページの情報をデータベースに登録し、検索結果に表示できる状態にすることを指します。
Googleの資料では、403を含む400番台（4xx）のステータスコード（429を除く）を返すURLについて、Google検索ではインデックスに登録されないこと、すでに登録されているURLもインデックスから削除されることが示されています。なお、Googleのクローラーは429を、サーバーが過負荷であることを示すものとして扱い、一時的にクロールの速度を落とすとされています。また、以前は使われていたURLが403を返すようになった場合、Googleのシステムは時間をかけてそのURLを使わなくなると説明されています。403が一度返されたらすぐに検索結果から消える、とまでは示されていませんが、検索結果に表示したいページで403が続いている場合は、早めに確認することが大切です。
なお、同じ資料では、クロール（Googlebotによるページの巡回）の頻度を抑える目的で、401や403を使わないよう案内されています。
（参照：How HTTP status codes affect Google’s crawlers｜Google for Developers）
ただ、閲覧者の画面で403が表示されたからといって、Googlebotも同じように拒否されているとは限りません。例えば、IPアドレスや地域による制限、WAFのルールなどは、アクセス元によって結果が変わることがあります。
Googleがページをどのように把握しているかは、Google Search ConsoleのURL検査ツールで確認することが可能です。Search Consoleは、自分のサイトがGoogle検索でどのような状態にあるかを確認できる、Googleの無料ツールです。
URL検査ツールで最初に表示される結果は、直近にインデックスに登録されたときの情報であり、現在公開されているページの状態とは限りません。現在の状態は「公開URLをテスト」（ライブテスト）で確認します。
ただ、ライブテストでページにアクセスするのは、通常のGooglebotではなく、「Google-InspectionTool」という検査用のクローラーです。ライブテストが成功したことだけで、通常のGooglebotのアクセスも復旧したとは言い切れません。復旧後は、ライブテストとあわせてサーバーのアクセスログも確認し、Googlebotが実際にページを取得できているかを確かめておくとよいでしょう。
また、ライブテストで問題がないと表示されても、インデックスに登録されることや、検索結果に掲載されることが保証されるわけではありません。インデックス登録をリクエストした場合も同様です。
（参照：URL 検査ツール – Search Console ヘルプ｜Google）
本記事で参照したGoogleの資料には、復旧した後に検索結果での表示がいつ、どの程度戻るかまでは示されていません。焦って設定を何度も変えるより、まずはGooglebotがページを取得できる状態に戻っているかを、確実に確かめてください。
まとめ
確認する項目が多いときは、自分が閲覧者なのか管理者なのかを分けると、次にすることを整理しやすくなります。
403 Forbiddenは、サーバーがリクエストを理解したうえで、その処理を拒否したことを示すHTTPステータスコードです。403という番号だけでは原因を特定できないため、状況に応じた確認が必要です。
閲覧者の方は、URLや閲覧権限を確認し、別のブラウザ・端末・回線で発生範囲を比べてみてください。それでも解決しない場合は、URLや発生日時、試したことなどを添えて、サイトの管理者に相談しましょう。
サイト管理者の方は、発生範囲・ログ・直前の変更を確認し、原因の候補を絞り込んでから、関係する設定だけを慎重に見直すことが大切です。アクセス制限やWAFを一律に外すのではなく、判断が難しい場合はサーバー会社や保守担当者に相談してください。
403が表示されても、慌てずに一つずつ確認していただけたらと思います。
