「403が出たら、パーミッションや.htaccessなど、思い当たる設定を片端から確認していくしかない」。そう考えてしまうのは、画面に表示されるのが403という数字と短い英文だけで、どこが拒否しているのかまでは書かれていないからです。復旧を急いでいる場面ほど、どこから手を付けるかで迷います。
しかし、記事を公開する側としてサイトの運用にも立ち会ってきた弊社の立場から言えるのは、原因を並べた一覧は最初に開くものではない、ということです。上から順に試していく進め方は、時間がかかるだけでなく、無関係な箇所を書き換えて別のエラーを呼び込むこともあります。その403が誰に対して出ているのかを先に確定させてから一覧に戻ると、確認する項目は大きく減ります。
本記事では、403 Forbiddenの意味と401エラー・404エラーとの違いから、誰に出ているのかを確かめる手順と管理者側・閲覧者側それぞれの対処、そして検索でのインデックスへの影響までを、検索からの集客を支援してきた立場で順を追ってお伝えします。
- 403 Forbiddenの意味と読み方、401エラー・404エラーとの違い
- 原因の一覧に入る前に確かめる「誰に出ているのか」の切り分け手順
- 管理者側で起きる9つの原因と、それぞれどこを見れば判別できるか
- 閲覧者側で試せる確認と、そこでは直せない範囲の線引き
- 403を放置した期間に、インデックスと検索流入で起きること
403 Forbiddenとは、サーバーがアクセスを拒否した状態を示すエラー
403 Forbiddenとは、Webサーバーがリクエストの内容を理解したうえで、その処理を拒否したことを表すHTTPステータスコードです。読み方は数字部分が「よんまるさん」または「よんゼロさん」、Forbiddenは「フォービドゥン」と読みます。日本語に置き換えると「禁止されている」という意味になり、ブラウザや環境によっては「アクセスが拒否されました」「許可されていません」と日本語で表示される場合もあります。
HTTPステータスコードは3桁の数字で、先頭の数字によって大きく5つに分かれます。200番台は成功、300番台は転送、400番台はリクエスト側に起因するエラー、500番台はサーバー側の障害を示します。403は400番台に属するため、分類上は「クライアントエラー」に入ります。ただし現場の感覚としては、403の多くはサイト管理者側の設定に原因があります。
MDNのドキュメントでは、403は401と似ているものの、認証あるいは再認証を行っても結果が変わらない点が異なると説明されています。リクエストの失敗は、リソースに対する権限の不足や、アプリケーション側の条件を満たしていないことに起因するという整理です。
※ 出典 MDN Web Docs「403 Forbidden - HTTP」
なお仕様上は、サーバーがリソースの存在そのものをクライアントに知らせたくない場合、403ではなく404を返してもよいとされています。管理用のURLを隠す目的で、あえて存在しないふりをする設計は珍しくありません。裏を返せば、403が返ってきた時点で、そのURLに何かが存在することだけは分かるわけです。切り分けの出発点として覚えておくと役に立ちます。
関連記事：【2025年最新版】初心者でもできるSEOのやり方完全ガイド | 上位表示するための具体的な方法を徹底解説
401エラー・404エラーとの違いを先に押さえる
403の対処を遠回りさせる原因の多くは、401エラーや404エラーと混同したまま作業を始めてしまう点にあります。3つの違いを先に押さえておくと、確認しに行く場所が変わってきます。
ステータスコード | 表している状態 | 認証すれば見られるか | まず疑う場所 |
|---|---|---|---|
401 Unauthorized | 認証が必要、または認証に失敗している | 見られる可能性がある | ログイン情報、認証の仕組み |
403 Forbidden | 認証の有無にかかわらず拒否されている | 認証しても変わらない | サーバー設定、アクセス制限、WAF |
404 Not Found | 指定されたURLにリソースが見つからない | 認証しても変わらない | URLの綴り、ファイルの配置 |
401は「あなたが誰か分からない、もしくは名乗り方が間違っている」、403は「あなたが誰かは分かったうえで、それでも見せない」と読み替えると区別しやすくなります。判断材料として分かりやすいのは、ログインを求められるかどうかでしょう。IDとパスワードの入力を促されるなら401の側、何も聞かれずに拒否されるなら403の側と考えて差し支えありません。
Web担当者ログインしている状態なのに403が出ます。これは権限の問題なのでしょうか。
Writers-hub編集部
アプリケーション側の権限設定か、その手前に置かれたアクセス制限のどちらかです。ログイン後の特定の画面でだけ403が出るなら前者、サイト全体で出るなら後者を先に確認してください。同じ画面を管理者権限の別アカウントで開いてみて、再現するかどうかで切り分けられます。
関連記事：SEO記事の検索順位が突然下がった——原因特定から復旧までのフローチャート
まず「誰に対して403が出ているのか」を切り分ける
ここからが実務の話になります。原因の一覧を上から順に試す進め方は、時間がかかるだけでなく、途中で設定を触りすぎて状況を悪化させる危険もはらんでいます。手を動かす前にやるべきなのは、403が誰に対して出ているのかを確定させることです。
スマートフォンのWi-Fiを切り、モバイル回線で開いてみます。ここで表示されるなら、IPアドレス単位の制限か、セキュリティ機能が自分の回線を弾いている可能性が高くなります。
拡張機能やCookie、キャッシュの影響を外した状態を作ります。シークレットウィンドウで表示されるなら、原因はブラウザ側にあります。
自分の環境だけの問題なのか、全員に出ているのかがここで確定します。外部のステータス確認ツールで応答コードを取得する方法でも構いません。
人間のブラウザには見えていても、Googlebotにだけ403が返っている場合があります。取得結果に403が出ていれば、検索エンジン向けの経路で拒否されています。
プラグインの更新、サーバー設定の変更、セキュリティ機能の有効化。心当たりを時系列で並べるだけで、候補は大きく減ります。
この5つを終えた時点で、原因は「全員に出ている（サーバー側の設定）」「自分だけに出ている（回線・端末・アカウント）」「特定のクローラーにだけ出ている（bot対策やWAF）」の3つに絞り込まれます。
この状態まで持ち込んでから原因の一覧に戻ると、確認する項目は数分の一で済みます。逆に、切り分けを飛ばして設定ファイルを開いてしまうと、無関係な箇所を書き換えて別のエラーを呼び込みかねません。
関連記事：Googleで検索上位を獲得する方法15選！SEO対策の仕組みからコツまで徹底解説
エラー画面の見た目から、どこが拒否しているかを絞る
切り分けと並行して、もう一つ手がかりになるものがあります。目の前に表示されているエラー画面そのものです。
403を返している主体は、Webサーバーだけとは限りません。サーバーの手前にCDNやWAFが置かれていれば、そちらが返している場合もありますし、レンタルサーバー事業者が独自のエラーページを用意していることもあります。画面の見た目と文言で、拒否している層が判別できます。
素っ気ない白背景に短い英文が数行並ぶだけの画面なら、Webサーバーソフトの既定のエラーページである可能性が高いと考えられます。サーバーソフトの名称が小さく添えられているケースもあり、その場合はサーバー本体まで到達したうえで拒否されたと判断できます。
一方、サイトのロゴや事業者名が入ったデザイン付きの画面や、403とは別の番号が併記された画面が出るのであれば、サーバーの手前で止められています。CDNやセキュリティサービスは独自のエラー番号を持っていることが多いため、403ではなくその番号で調べたほうが、原因にたどり着くのは早いでしょう。
ブラウザの開発者ツールを開き、ネットワークタブから該当のリクエストを選ぶと、レスポンスヘッダーが確認できます。サーバーソフトの名称やCDNの識別子が含まれていれば、どこが応答を返したかはほぼ確定します。見た目だけで判断がつかないときは、ここまで踏み込んでください。
管理者側で起きる403の原因と直し方
全員に403が出ていると分かったら、管理者側の設定を見ていきます。実務で遭遇する頻度が高い順に並べると、次のように整理できます。
原因 | よくある状況 | 確認する場所 |
|---|---|---|
ファイルとディレクトリの権限設定 | FTPでアップロードした直後 | パーミッションの値 |
.htaccessの記述ミス | 直前に編集した、リダイレクトを追加した | .htaccessの該当行 |
indexファイルが置かれていない | 新しくディレクトリを作った | ディレクトリ直下のindex.htmlやindex.php |
アップロード先の誤り | 公開ディレクトリの1階層上に置いた | 公開ディレクトリのパス |
WAFなどセキュリティ機能の誤検知 | 記事の保存時やフォーム送信時に出る | 事業者の管理画面にあるWAFのログ |
IPアドレスや国単位のアクセス制限 | 社外や海外からだけ見えない | サーバーやCDNの制限設定 |
プラグインやモジュールの競合 | 更新した直後から出はじめた | 直前に更新したもの |
サーバーアカウントの停止 | サイト全体が見えない | 契約状況と支払い状況 |
アクセス集中による同時接続の制限 | 特定の時間帯にだけ出る | アクセスログ |
権限設定については、一般的なレンタルサーバーでディレクトリが755、ファイルが644を既定としています。FTPソフトの設定によっては別の値でアップロードされ、読み取りが許可されない状態が生まれます。
ここで注意したいのは、パーミッションを777に変更すれば直るという情報を鵜呑みにしないことです。誰でも書き込める状態は、そのまま改ざんの入口になります。読み取りができない原因を特定しないまま権限を緩めるのは、エラーを別の問題にすり替えているにすぎません。
.htaccessを編集する前に、必ず元のファイルをダウンロードして手元に保存してください。1行間違えるだけでサイト全体が403や500になり、管理画面からも復旧できなくなります。編集後に表示が戻らないときは、原因を探す前に保存しておいたファイルへ戻すのが安全です。
WAFの誤検知は、症状が特徴的なので見分けがつきます。サイトの閲覧はできるのに、記事の保存やフォームの送信といった書き込み操作だけが403になる。この場合、WAFが投稿内容を攻撃パターンとして判定しています。事業者の管理画面でWAFのログを確認し、該当する検出項目だけを一時的に除外するか、作業中に限ってWAFを止めて保存し直す対応になります。全体を無効にしたまま放置する運用は避けてください。
indexファイルの不在は、ディレクトリ一覧の表示が禁止されている環境で起こります。ファイル一覧を見せない設定そのものは妥当なので、index.htmlを置くか、そのディレクトリを直接開かせない構成に変えるかを選ぶことになります。
閲覧者側でできる確認と、できないこと
自分だけに403が出ている場合、あるいは他社のサイトで403に遭遇した場合、閲覧している側で試せることは限られます。それでも確認する価値のある項目を挙げておきます。
- URLの綴りと、httpとhttpsの取り違えを確認する
- 末尾のスラッシュの有無を変えて開き直す
- ブラウザのキャッシュとCookieを削除する
- 拡張機能を止めるか、シークレットウィンドウで開く
- VPNやプロキシを使っているなら切断して試す
- 会員向けページなら、ログイン状態と付与されている権限を確認する
上から順に一つずつ試すより、まずシークレットウィンドウで開いてみるほうが早く終わります。そこで正常に表示されるなら、原因はキャッシュか拡張機能のどちらかに絞られるからです。
一方、次に挙げる状態は、閲覧者側で何を試しても変わりません。
- サーバー上のファイル権限が誤っている
- .htaccessでアクセスが制限されている
- サイト側でIPアドレスや国が制限されている
- レンタルサーバーの契約が停止している
- 公開範囲が社内や会員に限定されている
いずれもサイト側の設定に属する話です。他社のサイトで繰り返し403が出るなら、問い合わせ窓口へ連絡したほうが確実でしょう。その際、発生した日時、開こうとしたURL、使っている回線と端末、画面に表示された文言をそのまま伝えると、相手側の調査が短く済みます。
403エラーがSEOとインデックスに与える影響
自社サイトで403が出たとき、復旧作業と同じくらい気にかけたいのが検索エンジンへの影響です。
Googleは、403を含む4xxのステータスコードを返すURLについて、そのコンテンツを使用せず、すでにインデックスに登録されていたURLはインデックスから削除すると公式に説明しています。403が続いたページは、検索結果から消えます。
※ 出典 Google 検索セントラル「HTTP ステータス コード、ネットワーク エラー、DNS エラーが Google 検索に与える影響」
一時的な障害を示す500番台とは扱いが異なる点に注意してください。500番台であれば、Googleはクロールの頻度を落としつつ、しばらくインデックスを保持します。対して4xxは「存在しない」と解釈されるため、復旧が遅れた分だけ失われるページが増えていきます。
実務で厄介なのは、人間には正常に見えているのにGooglebotにだけ403が返っているケースです。bot対策やWAFの設定を強めた際、Googlebotのアクセスまで遮断してしまう事故は起こり得ます。ブラウザで確認しても異常が見つからないため、Search Consoleで除外されたページが増えるまで気づけません。
もう一つ見落とされやすいのが、robots.txtが403を返している状態です。Googleは、robots.txtに429以外の4xxが返る場合、robots.txtが存在しないものとして扱うと説明しています。クロールを制御しているつもりで、実際には制限なしと解釈されている状態が生まれるわけです。同じドキュメントでは、クロール頻度を落とす目的で401や403を使わないよう明記されています。
※ 出典 Google 検索セントラル「robots.txt の書き方、設定と送信方法」
復旧したあとは、Search ConsoleのURL検査から再クロールをリクエストしてください。対象ページが多い場合はサイトマップの再送信もあわせて行います。ただし反映は即時ではなく、規模によっては数週間を要します。復旧後しばらくは、インデックス登録数と表示回数の推移を並べて確認しておくと安心です。
エラーは直った。では、落ちた検索流入をどう戻しますか
403が続いた期間の分だけ、インデックスと表示回数は目減りしています。復旧後にどのページから再クロールを促し、どの記事を優先して手を入れるか。Search Consoleの数値をもとに、着手する順番から一緒に組み立てます。
403を再発させないための運用
403の対応で最も消耗するのは、原因を探している時間そのものです。同じ状況を繰り返さないために、平時のうちに決めておけることがあります。
主要なページを外部から定期的に確認し、200以外が返ったら通知が届く状態を作ります。無料で使える監視サービスでも十分に機能します。気づくまでの時間が、失うページ数をそのまま左右します。
.htaccess、WAFの設定、アクセス制限。変更前のファイルを保存し、いつ何を変えたかを1行で残しておきます。復旧の速さはこの記録で決まります。
誤検知を避けるために外した項目は、理由と日付をあわせて残してください。担当者が変わったあと、なぜ外されているのか分からない設定は、いずれ元に戻されます。
プラグインの更新やサーバー設定の変更のあとに、トップページと主要な下層ページを実際に開きます。数分の確認で、数日分の損失を避けられます。
人間の目に触れないところで起きている拒否は、ここにしか現れません。
順番に眺めると、どれも大がかりな仕組みではないと分かるはずです。復旧の速さを決めているのは技術力よりも、変更を記録に残しているかどうかという運用習慣に近い部分でした。
経営者監視まで入れるのは、うちの規模だと大げさではありませんか。
Writers-hub編集部
サイトの規模ではなく、そのページから問い合わせや申し込みが発生しているかどうかで判断してください。1日止まって失うのが数件だとしても、気づくのが1週間後なら影響は残ります。まずは無料の監視サービスで、主要な数ページだけ見ておく形から始めるのが現実的です。
なお、エラー画面をそのまま出しっぱなしにしない工夫も効果があります。閲覧者向けの403ページに、問い合わせ先や関連ページへの導線を置いておくと、原因を報告してもらえる確率が上がります。管理者が気づく前に、読者が教えてくれることは意外と多いものです。
復旧のたびに記事の更新が止まってしまうなら
障害対応やサーバー周りの確認に時間を取られると、公開予定だった記事が後ろにずれていきます。キーワードの選定から執筆、入稿までを引き受けるため、担当者の手が塞がっている期間も更新を止めずに済みます。
403 Forbiddenについてよくある質問
最後に、サイト運用の現場で受けることの多い質問をまとめました。
数字部分は「よんまるさん」または「よんゼロさん」、Forbiddenは「フォービドゥン」と読みます。日本語では「禁止されている」という意味で、アクセスが拒否された状態を表します。
アクセス集中による一時的な制限であれば、時間をおいて解消する場合があります。ただし設定に原因があるなら、直さない限り出続けます。数十分待っても変わらないようなら、設定側を疑ってください。
モバイル回線など、別の回線から同じURLを開いてください。そこで表示されるなら、IPアドレス単位の制限かセキュリティ機能が自分の回線を弾いている可能性があります。表示されないのであれば、サイト側の設定です。
端末そのものより、回線とブラウザの違いが影響しています。Wi-Fiとモバイル回線を切り替えて再現するかを確かめ、ブラウザのキャッシュを削除したうえでもう一度試してみてください。
直前に更新したプラグインか、セキュリティ機能による管理画面のアクセス制限が候補になります。FTPでプラグインのフォルダ名を変更して無効化し、管理画面に入れるかどうかで切り分けられます。
Googleは4xxを返すURLをインデックスから削除するため、403が続いたページは検索結果に表示されなくなります。復旧しても元の状態に戻るまで時間がかかるので、早く直すほど損失は小さく収まります。
管理用URLの存在を知らせたくない場合には、404を返す設計が採られます。仕様上も認められている扱いです。ただし公開すべきページに404を返すと、インデックスから削除される点は403と変わりません。
ここまでの内容を自社サイトに当てはめてみて、優先順位の付け方に迷う場合もあるかもしれません。
復旧はできた。次に何から手をつけるか決めきれないときは
インデックスの戻し方、既存記事の見直し、新規記事の計画。どこから着手すべきかは、サイトの規模と落ち込みの幅によって変わります。Search Consoleの数値を一緒に見ながら、次の一手を整理するところからでも構いません。
まとめ
403 Forbiddenは、サーバーがリクエストを受け取ったうえで応答を拒んだ状態を示すエラーです。ページが存在しないという意味ではなく、見せないという判断がどこかで下されています。
対処の順番をもう一度たどると、まず誰に出ているのかを別回線と別ブラウザで切り分け、次にエラー画面とレスポンスヘッダーで拒否している層を絞り、そのうえで権限設定、.htaccess、WAFの順に確認していく流れになります。原因の一覧を上から試すのではなく、切り分けを先に置く。この順番を守るだけで、復旧までの時間は目に見えて短くなりました。
そして直して終わりにせず、Search Consoleでインデックスの状態を確認するところまでを一続きの作業として組んでください。403が返っていた期間の分だけ、検索からの流入は確実に落ちています。
合同会社Writers-hubでは、SEO記事の制作と、検索経由の集客支援を行っています。サーバーの復旧作業そのものは技術担当の領域ですが、復旧後にどのページから流入を戻していくか、そのために何を書き足すべきかという判断はお手伝いできます。障害対応に追われて更新が止まったままという段階からのご相談も歓迎しています。
