WordPressの403 Forbiddenエラー原因と直し方完全ガイド｜管理画面・記事保存時のWAF解除から.htaccess・パーミッション復旧まで

「WordPressで記事を保存しようとしたら『403 Forbidden』と表示されて下書きが保存できない…」
「管理画面（/wp-admin/）に突然アクセスできなくなり、閲覧権限がないと弾かれてしまう…」――このような突然の403エラーに頭を抱えていませんか？

HTTPステータスコード「403 Forbidden（閲覧禁止・アクセス拒否）」は、サーバー上に要求したファイルやページが存在しているものの、セキュリティ機能（WAFやアクセス制限）や権限設定（パーミッション）によって閲覧・実行が意図的に遮断された状態を示しています。

🚨 403 Forbiddenエラー発生時の緊急初動チェック

記事のデータやサイトが消滅したわけではない：サイトが壊れたりデータベースが吹き飛んだわけではありません。アクセス権限やセキュリティブロックを解除すれば、元の状態へ即座に復旧可能です。
発生場所で原因が9割特定できる：
- 記事の保存・更新時 ➔ ほぼ100% サーバーの「WAF（Web Application Firewall）による誤検知」
- 管理画面（ログイン）アクセス時 ➔ サーバーの「海外IP制限」「.htaccessのIP制限」または「セキュリティプラグイン」
- サイト全体（トップページ等） ➔ 「index.phpの欠落」「パーミッション不整合」「.htaccessの構文エラー」
焦って再インストールしない：WordPressの再インストールは不要です。各原因に応じた適切な設定変更を行うことで、最短数分で解決できます。

本記事では、WordPressで403 Forbiddenエラーが発生する根本原因をシチュエーション別に完全網羅し、主要レンタルサーバー（エックスサーバー、ConoHa WING、ロリポップ、さくらインターネット）ごとの具体的な解除手順から、.htaccess・パーミッションの修正方法、再発防止のセキュリティ運用まで、ステップバイステップでわかりやすく解説します。

WordPressの「403 Forbidden」エラーとは？発生の仕組みと基本概要

トラブルをスムーズに解決するために、まずは403 Forbiddenエラーがどのような仕組みで発生しているのか、基本を押さえておきましょう。

403 Forbidden（アクセス拒否）が意味すること

Webサーバーとブラウザの通信では、リクエストの結果を示す「HTTPステータスコード（3桁の数字）」が返されます。その中で400番台は「クライアント（閲覧者・送信側）側のエラー」に分類されます。

「403 Forbidden」は、直訳すると「禁止されている」という意味であり、サーバー側が「要求されたファイルやディレクトリの存在は認識しているが、セキュリティ設定・アクセス制御・権限設定により、あなたにはその操作や閲覧を許可しない」と判断してアクセスをブロックしたことを示します。

500エラーや404エラーとの決定的な違い

WordPressで頻発する他の主要なHTTPエラーコードとの違いを整理すると、以下のようになります。

ステータスコード	エラーの名称	状態・発生原因	データへの影響
403	Forbidden（アクセス拒否）	ファイルは存在するが、WAF・権限・.htaccessによりアクセスが遮断されている	データは無事（設定解除で即時復旧）
404	Not Found（未検出）	指定したURLに対応するページやファイル自体が存在しない	URLの指定ミスまたは削除
500	Internal Server Error	PHPの致命的構文エラーやメモリ不足でサーバー側がクラッシュした	コードやプラグインの不具合
503	Service Unavailable	アクセス集中やメンテナンスモード等で一時的にサービス停止中	一時的な過負荷・更新中

このように、403エラーはプログラムがクラッシュしているのではなく、「セキュリティフィルターやサーバーの門番が意図して通せんぼをしている状態」です。したがって、どの門番（WAF、.htaccess、パーミッション、セキュリティプラグイン）がブロックしているのかを特定すれば、安全かつ確実に復旧できます。

【最短1分で特定】403エラーの3大発生シチュエーションと原因切り分けチャート

403エラーの解決で最も重要なのは、「どの画面・どの操作で403エラーが表示されたか」を確認することです。発生シチュエーションによって原因が明確に分かれます。

📊 403 Forbidden 原因特定フローチャート

記事の投稿・更新ボタンを押した時、またはカスタマイザー・ウィジェットの保存時に403が出る？
- ➔ 【原因①: サーバーWAFの誤検知】（記事内のHTML/JavaScript/iframe/SQL風文言を攻撃と誤認）
管理画面（https://example.com/wp-admin/）やログイン画面にアクセスした時に403が出る？
- ➔ 【原因① or ② or ④】（サーバーの海外IP制限、.htaccessによるアクセス制御、セキュリティプラグインのURL変更機能）
サイトのトップページや公開中の全記事にアクセスした時に403が出る？
- ➔ 【原因③ or ⑤ or ②】（index.phpの欠落、ファイル/フォルダのパーミッション不整合、.htaccess構文エラー）

ここからは、それぞれの原因と具体的な復旧手順を詳しく解説していきます。

原因①: サーバーWAF（Web Application Firewall）の誤検知と解除手順

WordPressで最も発生頻度が高い403エラーの原因が、レンタルサーバーに標準搭載されている「WAF（Web Application Firewall）」による誤検知です。

なぜ記事保存時やウィジェット更新時にWAFが作動するのか？

WAFは、SQLインジェクションやクロスサイトスクリプティング（XSS）などのWeb攻撃からサイトを守るため、送信されるデータの中に悪意あるプログラムコードが含まれていないかを常時監視しています。

しかし、WordPressの管理画面から以下のような内容を投稿・保存しようとした際、WAFの検知ルール（シグネチャ）に合致してしまい、「正当な管理者による保存操作」が「サイバー攻撃」と誤認されて通信が遮断（403 Forbidden）されてしまいます。

記事本文やウィジェットに貼り付けたJavaScriptコード（Googleタグマネージャー、計測タグ、広告コードなど）
YouTubeやSNS、地図などの埋め込みタグ（<iframe>、<script>）
アフィリエイトリンクや特殊なパラメータ付きURL
SQLコマンドに類似した文字列（例: SELECT, UNION, WHERE, DROP などの技術解説文）
HTMLタグの直接編集やカスタマイザーでの追加CSS/JSの保存

⚠️ WAF全体を無効化（OFF）にしたまま運用するのは危険です
WAFを完全にOFFにするとサイトの脆弱性攻撃耐性が著しく低下します。復旧のベストプラクティスは、「遮断ログを確認し、該当するシグネチャ（攻撃検知ルール）のみを除外登録（ホワイトリスト化）する」ことです。一時的にWAFをOFFにする場合でも、作業完了後に必ずONへ戻しましょう。

エックスサーバー（Xserver）でのWAF解除・ログ確認手順

エックスサーバーでは、サーバーパネルからWAFログの確認とシグネチャの除外、または一時停止が行えます。

🛠 エックスサーバーでの手順

エックスサーバーの「サーバーパネル」にログインします。
「セキュリティ」カテゴリ内の「WAF設定」をクリックします。
対象のドメインを選択します。
「WAF設定」タブで、遮断された要因（通常は「XSS（クロスサイトスクリプティング）」または「SQL（SQLインジェクション）」）を確認します。
特定シグネチャの除外を行う場合：
- 「ログ照会」タブを開き、エラーが発生した日時のログ（アクセス元IPアドレス、検知されたシグネチャ名）を確認します。
- 除外したいシグネチャを「シグネチャ除外設定」に追加します。
一時的にWAFを無効化する場合：
- 該当項目の設定を「OFF」にして「確認画面へ進む」＞「設定する」をクリックします。
- ※設定反映まで約数分〜10分程度かかります。記事を保存・更新した後、必ず「ON」に戻してください。

ConoHa WINGでのWAFログ除外手順

ConoHa WINGでは、コントロールパネルから検知ログを確認し、ワンクリックで除外登録（許可）が可能です。

🛠 ConoHa WINGでの手順

ConoHa WINGのコントロールパネルにログインします。
左側メニューの「サイト管理」＞「サイトセキュリティ」を開きます。
上部タブの「WAF」を選択します。
「ログ」一覧に、403エラーが発生した時刻と一致する検知ログ（攻撃タイプ: XSSやSQLなど、対象URL）が表示されていることを確認します。
該当ログの右側にある「除外」ボタンをクリックします。
除外リストに登録され、数秒〜数分で制限が解除されます。WordPress側で再度保存を試してください。

ロリポップ（LOLIPOP!）でのWAF設定と.htaccess除外手順

ロリポップ！では、管理画面のログ参照機能と.htaccessによるシグネチャ除外設定を組み合わせて対応します。

🛠 ロリポップ！での手順

ロリポップ！の「ユーザー専用ページ」にログインします。
「セキュリティ」＞「WAF設定」を開きます。
対象ドメインの「ログ参照」をクリックし、エラーが出た日時の「検出されたシグネチャ名（例: sqli-xxx や xss-xxx）」をメモします。
推奨方法（.htaccessによるシグネチャ除外）：
- ロリポップFTPまたは通常のFTPソフトで、ドキュメントルート直下の.htaccessを開きます。
- ファイルの先頭に以下のように記述して保存します：
```
SiteGuard_User_ExcludeSig [メモしたシグネチャ名]
```
一時的に無効化する場合：
- WAF設定画面で対象ドメインの「無効にする」をクリックします（反映に5〜10分程度要します）。保存後に再度「有効にする」へ戻します。

さくらのレンタルサーバでのWAF設定確認

さくらのレンタルサーバでも同様にコントロールパネルから操作できます。

🛠 さくらのレンタルサーバでの手順

「サーバーコントロールパネル」にログインします。
「Webサイト/ドメイン」＞「WAF設定」を開きます。
対象ドメインの「設定」をクリックし、WAF利用設定を一時的に無効化するか、ログ一覧から遮断内容を確認して例外設定を行います。

原因②: .htaccessファイルの記述ミス・アクセス制限の修正

サーバーのWebサーバーソフトウェア（ApacheやLiteSpeedなど）の設定を制御する「.htaccess（ドット・エイチティーアクセス）」ファイルに誤った記述があると、403エラーが発生します。

.htaccessで403エラーが発生する典型的なパターン

IP制限の記述ミス：Deny from all や Require ip xxx.xxx.xxx.xxx で自社IP以外のアクセスを遮断しているが、プロバイダの動的IP変更により自身のIPアドレスが変わってしまった。
セキュリティプラグインによる自動追記：セキュリティ系プラグイン（All In One WP Security、SiteGuard等）がアクセス制限ルールを追記した際に構文が競合した。
Basic認証の記述パスの誤り：.htpasswd へのフルパスが間違っている。
全アクセス拒否ルールの存在：Order deny,allow Deny from all などが誤った階層に配置されている。

.htaccessのバックアップと初期化（デフォルト復元）手順

.htaccessが原因と疑われる場合は、FTPソフト（FileZilla等）またはサーバーのファイルマネージャーを使用して、一度バックアップを取った上でWordPress標準の初期状態に戻すのが最も確実です。

📋 .htaccess初期化の3ステップ

FTPでWordPressのインストール階層（wp-config.phpがあるディレクトリ）にある .htaccess をPCにダウンロードし、.htaccess_backup として複製保存します。

サーバー上の .htaccess を開き、内容を以下の「WordPress標準コード」のみに書き換えて上書き保存します：

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

ブラウザのキャッシュをクリアしてサイトや管理画面にアクセスし、403エラーが解消されるか確認します。

原因③: ファイル・ディレクトリのパーミッション（権限）の不整合と修正

Linuxサーバー上のファイルやフォルダには、「誰が読み取り・書き込み・実行できるか」を制御するパーミッション（アクセス権限）が設定されています。この権限設定が適切でない場合、Webサーバーがファイルを読み込めず403 Forbiddenを返します。

WordPressの推奨パーミッション一覧

WordPress公式およびセキュリティ標準で推奨されるパーミッションは以下の通りです。

対象	推奨パーミッション	設定の理由・備考
すべてのディレクトリ（フォルダ）	`755` （または `705`）	所有者に全権限、グループ・他者に読み取り・実行権限を付与
通常のファイル（.php, .html, 画像等）	`644` （または `604`）	所有者に読み書き、グループ・他者に読み取りのみ付与
`wp-config.php`（最重要設定ファイル）	`600` （または `400` / `440`）	DBパスワード保護のため所有者のみ読み取り（または読み書き）に厳格制限
`.htaccess` ファイル	`644` （または `604`）	Webサーバーが読み取り・更新可能な標準権限

🚨 「パーミッション 777」は絶対NG！逆に403エラーの原因になります
「権限を全部許可すれば動くだろう」と安易にディレクトリやファイルを 777（誰でも書き込み可能）に設定すると、現代のレンタルサーバー（suEXECやCGIモード稼働サーバー）ではセキュリティ防御機構が働き、サーバー側が強制的に「403 Forbidden」を返してアクセスを遮断します。権限は必ず 755 / 644 を遵守してください。

FTPソフト（FileZilla等）でのパーミッション一括変更手順

FTPソフト（FileZilla等）でサーバーに接続します。
WordPressのインストールディレクトリ（public_html等）内の全ファイル・フォルダを選択し、右クリックして「ファイルのパーミッション」を選択します。
ディレクトリのみを一括変更：
- 数値に 755 を入力＞「サブディレクトリを含める」にチェック＞ 「ディレクトリにのみ適用」を選択して実行。
ファイルのみを一括変更：
- 数値に 644 を入力＞「サブディレクトリを含める」にチェック＞ 「ファイルにのみ適用」を選択して実行。
wp-config.php のみ個別で右クリックし、パーミッションを 600（サーバー仕様によっては 644）に設定します。

原因④: セキュリティプラグインの設定・競合による遮断と無効化手順

セキュリティ対策プラグイン（SiteGuard WP Plugin、Wordfence Security、iThemes Security、All In One WP Securityなど）が、管理者のアクセスを不正ログインや攻撃と判定してブロックしているケースです。

よくあるプラグインによる403の原因

ログインURL変更機能：SiteGuard 等で標準の /wp-login.php や /wp-admin/ が別のURL（例: /login-xxxx/）に変更されているため、従来の管理画面URLにアクセスすると403 Forbiddenになる。
ログインロック・IPブロック：パスワードを数回間違えたことで、管理者のIPアドレスが一時的または恒久的にブラックリストに登録された。
管理画面アクセス制限（海外IP・特定IPブロック）：管理者の接続環境（テザリング、VPN、海外プロキシ）が変わったことで制限対象になった。

管理画面に入れない場合にFTPでプラグインを強制無効化する方法

管理画面にログインできない状態でも、FTPソフトを使えば安全にプラグインを一時停止できます。

🛠 プラグイン強制無効化の手順

FTPソフトでサーバーに接続し、/wp-content/plugins/ ディレクトリを開きます。
疑わしいセキュリティプラグインのフォルダ名（例: siteguard）を右クリックし、名前を一時的に siteguard_temp などに変更（リネーム）します。
フォルダ名が変わることでWordPressがプラグインを認識できなくなり、強制的に無効化されます。
再度ブラウザから管理画面（/wp-admin/）にアクセスし、ログインできるか確認します。
無効化によってログインできた場合は、プラグインの設定画面（アクセス制限ルールや除外IP）を見直してからフォルダ名を元に戻します。

原因⑤: index.php / index.html の欠落・配置ミス

サイト全体（ドメインのトップページ）にアクセスした際に403エラーが出る場合、ルートディレクトリに「トップページを表示するためのindexファイル」が存在しないことが原因の可能性があります。

ディレクトリ一覧表示（Directory Listing）の禁止と403

Webサーバーは、ユーザーがディレクトリ（例: https://example.com/）にアクセスした際、通常はその中にある index.html や index.php を自動的に探して表示します。

しかし、ファイルの移動作業や誤削除によって index.php が存在しない場合、サーバーはセキュリティ保護（ディレクトリ構造の丸見え防止）のために「Directory Listing（一覧表示）禁止」を発動し、403 Forbiddenエラーを返します。

🛠 index.phpの確認と復旧手順

FTPでWordPressのドキュメントルートを開き、index.php が存在するか確認します。
ファイルが存在しない、またはファイルサイズが0バイトになっている場合は、WordPress日本語公式サイトから同バージョンのZIPファイルをダウンロードし、中にある index.php をサーバーの同一階層に再アップロードします。

403エラーを二度と起こさないための5大予防策＆セキュリティ管理

403エラーの復旧が完了したら、今後同様のトラブルでサイト運営や業務がストップしないよう、以下の5つの予防策を講じておきましょう。

WAFは「無効化」ではなく「シグネチャ除外（ホワイトリスト登録）」で運用する
記事保存でWAFが引っかかるたびにWAF全体をOFFにしてしまうと、外部からのサイバー攻撃に対して無防備になります。必ず検知ログを確認し、誤検知されたシグネチャのみを除外する運用を徹底してください。
.htaccessやファイルの変更前には必ずバックアップを取得する
プラグインの導入やサーバー設定変更を行う際は、事前に .htaccess や wp-config.php のバックアップを手元に保存する習慣をつけましょう。
管理者のIPアドレスを固定または把握しておく
.htaccessやプラグインでIP制限を設定する場合は、プロバイダの動的IP割り当てによるIP変更に注意し、ログイン不可になった場合の解除手段（FTP接続情報）を常に手元に確保しておきます。
自動バックアッププラグイン・サーバー自動バックアップの併用
万一の設定破損やファイル破損に備え、サーバー側の自動バックアップ機能（過去14日間の自動保存等）に加え、プラグイン等で外部ストレージ（Googleドライブ等）へのバックアップを二重化します。
MozCheckによる定期的なセキュリティ診断を実施する
403エラーはセキュリティ機能の正常な作動によるものが多いですが、サイト内に古いプラグインや不要な権限設定が残っていると、誤検知や脆弱性の温床になります。定期的にサイト全体の安全性を監査しましょう。

WordPressの403 Forbiddenエラーに関するよくある質問（FAQ）

Q1. WAFをOFFにしたまま放置するとどうなりますか？

A. サイトの改ざんや不正アクセスのリスクが跳ね上がります。
WAFは、既知の脆弱性やプラグインのセキュリティホールを突いた不正アクセスを水際で防ぐ極めて重要な防御壁です。OFFにしたまま放置すると、SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃による管理者アカウントの乗っ取りやマルウェア感染のリスクが高まります。必ずシグネチャ除外で対応するか、作業後にONに戻してください。

Q2. 403エラーが出ている間、SEO評価や検索順位に影響はありますか？

A. 数時間〜1日程度の短時間であれば影響はほぼありませんが、長期放置は危険です。
記事保存時や管理画面の403エラーであれば、一般閲覧者やGoogleクローラーには正常なページが返されているためSEO上の影響はゼロです。ただし、サイト全体が403エラーで閲覧不能になっている場合、数日以上放置するとGoogleのクローラーが「ページが存在しない・アクセス不能」と判断し、検索インデックスから削除されたり検索順位が急落する恐れがあります。速やかに復旧作業を行ってください。

Q3. 手順通りに試しても403エラーが直らない場合はどうすればいいですか？

A. サーバー会社のサポートにログ調査を依頼するか、WordPress専門の保守代行へご相談ください。
サーバー会社へ「403エラーが発生した正確な日時」「アクセス元IPアドレス」「アクセスしたURL」を伝えてログ照会を依頼すると、どのセキュリティ機能や設定がブロックしたかを教えてもらえます。自身での復旧が不安な場合は、専門の技術者に診断・復旧を依頼することをおすすめします。

まとめ：403エラーは発生場所を特定すれば最短数分で解決できる

WordPressの「403 Forbidden（アクセス拒否）」エラーは、画面を見た瞬間に慌ててしまいがちですが、「発生している場所（保存時 / 管理画面 / サイト全体）」を正しく切り分けることで、原因と対処法が100%明確になります。

📌 403 Forbidden 解決の要点まとめ

記事保存・ウィジェット更新時の403 ➔ サーバーの「WAF誤検知」。検知ログからシグネチャを除外登録する。
管理画面・ログイン時の403 ➔ サーバーの「海外IP制限」または「.htaccess / セキュリティプラグイン」のアクセス制御を見直す。
サイト全体の403 ➔ index.phpの存在確認、パーミッション（フォルダ:755 / ファイル:644）の統一、.htaccessの初期化。
パーミッション777は絶対禁止 ➔ サーバーのsuEXEC機能により逆に403エラーを引き起こす。

🛡️ あなたのWordPressは安全ですか？MozCheckで無料セキュリティ診断

403エラーの多くはセキュリティ機能が正常に作動している証拠ですが、同時に「古いプラグインの脆弱性」「不適切なパーミッション設定」「外部からの攻撃試行」が潜んでいるサインでもあります。

「MozCheck」なら、URLを入力するだけでWordPressのコアファイル、プラグインの脆弱性（CVE情報）、セキュリティ設定の不備を網羅的に自動診断できます。トラブルの再発を防ぎ、安全なサイト運営を続けるために、ぜひ一度無料診断をお試しください。

WordPressのトラブル・セキュリティ関連記事

Contact Form 7のスパム対策完全ガイド｜海外ボットを遮断するおすすめ設定とTurnstile・Honeypot・Akismet導入手順

2026/08/30/wordpress-maintenance-mode-not-ending-guide/”>【即時解除】WordPressメンテナンスモードが終わらない原因と直し方｜.maintenanceファイル削除からエラー再発防止まで完全ガイド

【即時復旧】WordPress「このサイトで重大なエラーが発生しました」の原因特定と直し方完全ガイド｜リカバリーモード・デバッグ手順

【最短復旧】WordPressの500 Internal Server Error完全ガイド｜PHP8系・.htaccess原因別の直し方

【原因別チェックリスト】データベース接続確立エラー（Error establishing a database connection）の最短復旧手順

【即時復旧】WordPressにログインできない原因と解決策｜4大障害別切り分けフローチャート

WordPressセキュリティ診断ツールおすすめ比較｜無料・オンライン・プラグインの選び方

WordPress監視・保守代行サービスの選び方｜費用相場と失敗しない比較ポイント