WordPressの403エラーの原因と直し方|管理画面・サイトが開けないときの対処法

WordPressの403 Forbiddenエラーと原因・対処法を示すアイキャッチ

WordPressで突然「403 Forbidden」と表示され、サイトや管理画面が開けなくなることがあります。記事の保存時だけエラーになる場合もあり、発生場所によって確認すべき設定が異なります。

403エラーは、サーバーがリクエストを理解したものの、対象へのアクセスを拒否している状態です。原因を特定せずにファイルを削除したり、セキュリティ機能をすべて無効化したりする必要はありません。

この記事では、403エラーが発生している場所から原因を絞り込み、安全性の高い順番で復旧する方法を解説します。

 

WordPressで403エラーが出たら最初に確認すること

最初に行うべきことは、403エラーがサイト全体で発生しているのか、特定の操作だけで発生しているのかを確認することです。

次の順番で調べると、設定変更を最小限に抑えながら原因を切り分けられます。

  1. サイトのトップページ、記事ページ、管理画面をそれぞれ開く。
  2. 別のブラウザやプライベートウィンドウでも同じエラーが出るか確認する。
  3. エラーが発生した時刻と直前に行った操作を記録する。
  4. セキュリティプラグインやWAF(不正な通信を検知・遮断する仕組み)のブロック履歴を確認する。
  5. 必要な場合だけ、プラグイン、.htaccess、ファイル権限を調べる。

複数の端末や回線で同じページが403になる場合は、サーバー側のアクセス制限が関係している可能性があります。一方、特定の回線だけで発生する場合は、IPアドレス(通信元を識別する番号)による制限なども確認対象になります。

最初からWordPressを再インストールする必要はありません。 原因の分からない状態で大きな変更を加えると、復旧が難しくなる場合があります。

 

403エラーの症状別に考えられる原因

403エラーは同じ表示でも、発生する画面や操作によって疑うべき原因が変わります。

発生する症状 主な確認対象 最初に行うこと
サイト全体が403になる サーバー設定、アクセス制限、ファイル権限 別回線で再現を確認し、サーバーログを調べる
管理画面だけ開けない セキュリティプラグイン、ログイン制限、WAF ブロック履歴とアクセス元IPを確認する
記事の保存・更新時だけ発生 WAF、REST API、プラグイン 失敗した通信とセキュリティログを照合する
特定ページだけ403になる .htaccess、ページ固有のアクセス制限 対象URLとアクセス制御ルールを確認する
プラグイン更新後に発生 更新したプラグインとその設定 更新履歴を確認し、変更前後を比較する
画像や特定ファイルだけ表示されない ファイル権限、直リンク制限、サーバー設定 対象ファイルのURLとアクセス権限を確認する

この表は原因を確定するものではありません。例えば管理画面の403エラーでも、ファイル権限が原因になっている可能性があります。実際のブロック履歴やエラーログを確認することが重要です。

WordPressの403エラーを発生場所別に分類し確認先を示した図

 

WAFやセキュリティ設定が403エラーを起こしていないか確認する

WordPressの管理画面や記事保存時に403エラーが出る場合、WAFやセキュリティ機能によって通信が遮断されている可能性があります。

WAFは不正なリクエストを防ぐための仕組みですが、正常な操作を誤って遮断する場合もあります。

 

レンタルサーバーのWAFログを確認する

レンタルサーバーの管理画面にログインし、セキュリティ設定またはWAF関連のメニューを確認してください。

  1. 403エラーが発生した日時を確認する。
  2. サーバー管理画面でWAFの検知・遮断履歴を探す。
  3. 対象URL、検知時刻、ルール番号などを照合する。
  4. 一致する遮断記録があれば、対象ルールを確認する。
  5. 誤検知と判断できた場合のみ、サーバーの案内に従って限定的な例外設定を検討する。

サーバーによっては、WAFの検知履歴を利用者が直接閲覧できない場合があります。その場合はサポート窓口に発生日時と対象URLを伝えてください。

WAF全体を恒久的に無効化することは推奨しません。 例外を設定する場合も、対象URLや遮断ルールなど、必要な範囲に限定してください。

 

セキュリティプラグインのブロック履歴を確認する

ログイン保護やアクセス制限を行うプラグインを使用している場合は、その管理画面でブロック履歴を確認してください。

自分のIPアドレスが遮断されている場合、管理画面だけにアクセスできなくなることがあります。

管理画面へ入れない場合は、後述するプラグインの一時停止方法を参考にしてください。ただし、停止中は保護機能が弱まるため、必要な時間だけ検証し、確認後に元の設定へ戻すことが重要です。

 

Cloudflareを利用している場合

CloudflareなどのCDN(Webコンテンツを配信する中継ネットワーク)を利用しているサイトでは、Cloudflare側と元のWebサーバー側のどちらが403を返しているか確認します。

Cloudflareの公式資料では、Cloudflare側のセキュリティ機能による403と、オリジンサーバー(元のWebサイトを配信するサーバー)による403を区別しています。

Cloudflareのセキュリティイベントで対象通信を確認し、該当する遮断ルールがあるか調べてください。イベントが見つからない場合も、それだけで原因を断定せず、サーバー側のログと照合します。

参考:Cloudflare公式:403エラーの解説

 

プラグインが原因かどうかを確認する

セキュリティプラグインやアクセス制御機能を持つプラグインの設定変更後に403エラーが発生した場合は、該当プラグインを優先して調べます。

 

管理画面にログインできる場合

  1. WordPressの「プラグイン」から「インストール済みプラグイン」を開く。
  2. エラー発生直前に更新・設定変更したプラグインを確認する。
  3. 必要なバックアップを取得する。
  4. 疑わしいプラグインを一つだけ一時停止する。
  5. 403エラーが改善したか確認する。
  6. 改善した場合は、そのプラグインのアクセス制御設定や更新内容を調査する。

複数のプラグインを同時に停止すると、原因の特定が難しくなります。原則として一つずつ検証してください。

 

管理画面にログインできない場合

サーバーのファイルマネージャーやSFTP(暗号化されたファイル転送方式)から、プラグインのフォルダー名を一時的に変更する方法があります。

  1. サーバーのファイルマネージャーまたはSFTPで接続する。
  2. WordPressの「wp-content/plugins」フォルダーを開く。
  3. 対象プラグインのフォルダー名を控える。
  4. バックアップを取得したうえで、対象フォルダー名を一時的に変更する。
  5. 管理画面へアクセスし、403エラーが解消したか確認する。
  6. 検証後は元のフォルダー名へ戻し、プラグインの状態と設定を確認する。

フォルダー名の変更はWordPressからプラグインを読み込めなくする操作です。対象によっては決済、フォーム、キャッシュ、セキュリティなどの機能が停止するため、影響範囲を確認してから行ってください。

ファイル操作の詳しい方法は、WordPressのプラグインをサーバー側から削除・操作する方法も参考になります。

なお、プラグインを停止しても403エラーが続く場合は、WAFやサーバーのアクセス制御など、別の原因を調査してください。

 

.htaccessの設定を確認する

.htaccessは、主にApache系Webサーバーでアクセス制御やURLの書き換えなどを設定するファイルです。

このファイルに誤ったアクセス制限が記述されていると、特定ページやサイト全体で403エラーが発生する場合があります。

 

.htaccessを確認する手順

  1. サーバーのファイルマネージャーまたはSFTPでWordPressの設置先を開く。
  2. 隠しファイルの表示を有効にする。
  3. 対象の.htaccessをダウンロードし、バックアップを保存する。
  4. 直近に追加・変更されたアクセス制限の記述を確認する。
  5. 変更履歴がある場合は、正常だった時点の設定と比較する。

アクセスを拒否するルール、IPアドレス制限、セキュリティプラグインが追加したルールなどが確認対象になります。

原因の疑いが強い設定だけを検証環境で変更し、問題が解消するか確認してください。改善しなければ元のファイルへ戻します。

.htaccessを無条件に削除したり、内容をすべて初期化したりしないでください。 WordPress以外のリダイレクト、認証、セキュリティ設定が含まれている場合があります。

また、Nginxなどの環境では.htaccessが使用されないため、Webサーバーの種類を確認してから調査してください。

 

ファイル・フォルダーのアクセス権限を確認する

WordPress公式ドキュメントでは、403エラーの原因としてサーバーやファイルシステムの権限設定を挙げています。

ファイル権限とは、サーバー上のファイルやフォルダーに対して、読み取り・書き込み・実行などを許可する設定です。

 

755と644の意味

一般的な構成では、フォルダーに755、通常のファイルに644が使われることがあります。

対象 一般的な設定例 意味
フォルダー 755 所有者は読み書きとアクセスが可能。その他の利用者は読み取りとアクセスが可能
通常のファイル 644 所有者は読み書きが可能。その他の利用者は読み取りが可能

ただし、必要な権限はサーバーの実行ユーザー、所有者、グループ、セキュリティ構成によって異なります。すべての環境で755と644が正解になるわけではありません。

特にwp-config.phpなどの重要ファイルは、サーバー環境に合わせてより厳しい権限を使用する場合があります。

WordPressのフォルダー権限755とファイル権限644の読み書き・実行権限の違い

 

アクセス権限を確認する手順

  1. サーバーのファイルマネージャーまたはSFTPで対象ファイルを確認する。
  2. エラーが発生するファイルやフォルダーの現在の権限を記録する。
  3. サーバー事業者が推奨する権限と比較する。
  4. 必要であれば、対象を限定して設定を修正する。
  5. サイト表示と管理画面の動作を確認する。

403エラーを直す目的で、すべてのファイルやフォルダーを777に変更しないでください。 777は広範囲に書き込みを許可する設定であり、セキュリティ上の危険があります。

権限が正しく見えても、所有者や親フォルダーの設定によってアクセスできない場合があります。原因が特定できなければ、サーバー事業者へ確認してください。

参考:WordPress公式:ファイル権限の変更

 

記事の保存・更新時だけ403エラーになる場合

WordPressの投稿画面で記事を保存・更新したときだけ403エラーが出る場合は、通常のページ表示とは異なる通信が遮断されている可能性があります。

ブロックエディターでは、REST API(WordPressと外部・内部のプログラムがデータをやり取りする仕組み)が使用されます。

そのため、編集画面の表示は正常でも、保存時の通信だけが失敗することがあります。

 

ブラウザの開発者ツールで失敗した通信を確認する

  1. 編集途中の文章を別の場所へ保存し、作業内容を保護する。
  2. ChromeなどのブラウザでF12キーを押し、開発者ツールを開く。
  3. 「Network」タブを選択する。
  4. 必要な場合は通信履歴の保持を有効にする。
  5. 記事の保存操作を再実行する。
  6. ステータスが403になった通信を確認する。
  7. Request URL、Response、発生時刻などを確認する。

Request URLは通信先のURL、Responseはサーバーから返された応答内容です。

通信先に「/wp-json/」が含まれる場合は、REST APIに関係するリクエストである可能性があります。ただし、403の原因が必ずREST API自体にあるとは限りません。

WordPressの認証情報、セキュリティプラグイン、WAF、サーバー設定などを併せて確認してください。

なお、認証トークンやCookie(ログイン状態などを保持する情報)を含む通信情報を、そのまま第三者へ公開しないでください。

開発者ツールのNetworkパネルで403ステータスの通信を確認する概念図

 

REST APIの認証エラーを確認する

WordPressの公式開発資料では、REST APIへのリクエストで無効なnonce(リクエストの正当性を検証するための値)が使用された場合、403エラーが返されるケースが説明されています。

ブラウザの開発者ツールで「rest_cookie_invalid_nonce」などの応答が確認できる場合は、認証状態や通信の送信先を調べてください。

まずは作業内容を保護したうえで、ログイン状態を確認し、必要に応じて再ログインします。

キャッシュプラグインや独自のJavaScriptを利用している場合は、古い認証情報を含むページが配信されていないかも確認対象です。

参考:WordPress公式:apiFetch

 

原因が分からない場合はサーバーのエラーログを確認する

403エラーが解消しない場合は、サーバーのエラーログやアクセスログを確認してください。

エラーログはサーバー内部で発生した問題を記録するもので、アクセスログはどのURLへどのようなリクエストが送られたかを調べるための記録です。

ただし、ログの保存場所や記録内容はレンタルサーバーによって異なります。

確認するときは、次の情報を整理してください。

  • 403エラーが発生した日時
  • エラーになったURL
  • 発生した操作
  • 利用しているブラウザと端末
  • 別回線でも再現するか
  • 直前に更新・変更したプラグインやサーバー設定
  • ログに表示されたエラーや遮断ルール

これらをサーバー事業者へ伝えると、原因調査に必要な情報を共有しやすくなります。

WordPress公式のインストールFAQでも、サーバーの権限や設定を確認しても解決しない場合は、ホスティング事業者へ問い合わせることが案内されています。

 

403エラーの再発を防ぐための対策

403エラーの再発防止では、原因になった設定を修正するだけでなく、変更履歴を追跡できる運用が重要です。

  • 変更前にバックアップを取得する: ファイルとデータベースを必要に応じて保護します。
  • プラグインを一つずつ更新する: 問題が発生した場合に変更箇所を特定しやすくなります。
  • WAFの遮断履歴を確認する: 誤検知が発生した場合は対象ルールを限定して対処します。
  • ファイル権限を適切に管理する: 不必要に広い書き込み権限を与えないようにします。
  • 検証環境を活用する: 本番サイトに影響する設定変更は可能な限り事前に検証します。
  • 変更日時を記録する: 更新したプラグイン、変更した設定、作業者などを残します。

セキュリティ機能をすべて停止して403エラーを回避するのではなく、正常な操作を許可しながら必要な保護を維持することが大切です。

 

WordPressの403エラーに関するよくある質問

403エラーと404エラーの違いは何ですか?

403はリクエスト先へのアクセスが拒否された状態、404は要求されたリソースが見つからない状態を示します。

404エラーで管理画面へ入れない場合は、WordPressの404 File Not Foundエラーの対処方法をご確認ください。

HTTPステータスコード(Webサーバーが処理結果を示す3桁の番号)の違いは、HTTPステータスコード一覧と意味でも解説しています。

 

403エラーが出たらWordPressを再インストールすべきですか?

通常、最初に再インストールする必要はありません。WAF、プラグイン、アクセス制御、ファイル権限などの問題であれば、WordPress本体を再インストールしても解決しない可能性があります。

まずは原因の切り分けを優先してください。

 

403エラーは放置しても直りますか?

一時的なアクセス制限が解除されることで改善する場合はありますが、ファイル権限や.htaccessなどの設定が原因であれば、設定変更が必要になる可能性があります。

放置して改善するとは限らないため、発生状況とログを確認してください。

 

自分のパソコンだけ403エラーになるのはなぜですか?

アクセス元IPの制限、VPN(通信経路を保護・変更する仕組み)、セキュリティ機能による遮断などが考えられます。

別のブラウザや回線で再現するか確認し、差がある場合はアクセス元に関連する制限を調べてください。

 

まとめ|WordPressの403エラーは発生場所から原因を絞り込む

WordPressの403エラーは、アクセスが拒否されたことを示すものであり、表示だけで原因を一つに特定することはできません。

まずはサイト全体、管理画面、特定ページ、記事保存時のどこで発生しているか確認してください。そのうえでWAF、セキュリティプラグイン、.htaccess、ファイル権限、サーバーログを順番に調べると、不要な変更を避けながら復旧を進められます。

原因を確認できない場合は、エラー発生時刻と対象URL、実施した確認内容を整理し、レンタルサーバーのサポートへ相談してください。

PR記事一覧

Ads Blocker Image Powered by Code Help Pro

広告ブロックを検出しました!

ブラウザの拡張機能を使用して広告をブロックしていることが検出されました。

ブラウザの広告ブロッカーなどの機能を無効にして「更新」をクリックして下さい。

You cannot copy content of this page