405 Method Not Allowed エラーは、ウェブサーバーがリクエストを理解しているにもかかわらず、使用された HTTP メソッドを拒否した場合に発生します。GET リクエストが POST しか受け付けないエンドポイントに到達した、セキュリティプラグインがブロックエディターからの PUT 呼び出しをブロックした、.htaccess のルールが DELETE を取り除いた、といったケースです。サーバーはあなたが何をしたいかを理解していますが、その方法では処理しようとしません。
クイックアンサー: WordPress で 405 エラーが発生する最も一般的な原因は、セキュリティプラグインが Gutenberg エディターからの PUT または DELETE 呼び出しをブロックしていること、あるいは
.htaccessのLimitExceptディレクティブです。最も手早い最初の対処法は、設定 > パーマリンク > 変更を保存で.htaccessを再生成することです。それでも解決しない場合は、セキュリティプラグインを 1 つずつ無効化して、原因となっているものを特定します。当社のテストでは、セキュリティプラグインがインストールされていない場合、設定 > パーマリンク > 保存 から.htaccessをリセットすることで、ほとんどのケースでエラーが解決しました。

405 エラーはどこに現れるか
すべての手順を試す前に、この表を使って最も可能性の高い原因に直接進んでください。
| エラーが現れる場所 | 最も可能性の高い原因 |
|---|---|
| ブロックエディターで投稿を保存できない | セキュリティプラグインが PUT または DELETE をブロック |
| フロントエンドのお問い合わせフォームまたは購入手続きフォーム | フォームプラグインが誤った HTTP メソッドを送信 |
| REST API エンドポイントまたは WP-CLI コマンド | .htaccess の LimitExcept ルール |
| サイト全体または特定の管理画面領域 | サーバーレベルの Nginx または Apache ディレクティブ |
変更を加える前に、何か問題が発生した場合にすぐ元に戻せるよう、ウェブサイトをバックアップしておきましょう。WP Staging はワンクリック復元付きの自動バックアップを提供します。設定手順については、バックアップと復元ガイドを参照してください。
.htaccess の LimitExcept 設定ミス
.htaccess の LimitExcept ディレクティブは、特定のパスでサーバーが受け付ける HTTP メソッドを制限します。よくある例は次のとおりです:
<LimitExcept GET POST>
Deny from all
</LimitExcept>
これは PUT、DELETE、PATCH をブロックしますが、これらは WordPress REST API と Gutenberg が更新や一括操作に使用しているメソッドです。セキュリティプラグインや手動編集によってこのディレクティブが追加された .htaccess は、プラグインのインストールや cPanel の設定変更の後に 405 が初めて現れた場合の原因であることがよくあります。
診断: サーバーのエラーログで、REST API パス(/wp-json/...)に対する 405 (Method Not Allowed) を含む行を確認します。そこに見つかった場合、原因はほぼ確実に LimitExcept ルールです。
修正: .htaccess ファイルをリセットする
ホスティングの cPanel にログインし、ファイルマネージャーを開きます。

WordPress インストールのルートディレクトリ(通常は public_html または www)に移動します。

ルートディレクトリ内の .htaccess ファイルを見つけます。

.htaccess ファイルを右クリックし、「ダウンロード」を選択して、コンピューターにバックアップを保存します。

もう一度ファイルを右クリックし、「名前の変更」を選んで、.htaccess.bak にリネームします。これにより、削除することなく一時的に無効化されます。

古い .htaccess を無効化した状態で、WordPress ダッシュボードの設定 > パーマリンクに移動し、変更を保存をクリックします。WordPress が問題のあるルールを含まないクリーンな .htaccess を再生成します。

サイトを確認します。405 エラーが消えていれば、古い .htaccess.bak を開き、新しいファイルと 1 行ずつ比較して LimitExcept ディレクティブを見つけます。バックアップからそれを削除して .htaccess にリネームし直すか、再生成されたバージョンをそのまま使用します。
Nginx を使用している場合、.htaccess は効果がありません。サイトのサーバーブロックまたは location ブロック内に同等の limit_except または deny ディレクティブがないか、nginx.conf を確認してください。
セキュリティプラグインによる HTTP メソッドのブロック
WP STAGING のサポートチケットによると、正常に動作している WordPress インストールで 405 を引き起こす最も一般的な原因は、セキュリティプラグインのファイアウォールがブロックエディターからの PUT または DELETE リクエストをブロックしていることです。Wordfence や Sucuri のようなプラグインでは、サーバーが受け付ける HTTP メソッドを制限できます。これらが PUT または DELETE をブロックすると、Gutenberg の保存リクエストが 405 で失敗し、エディターに一般的な保存エラーが表示されます。
診断: セキュリティプラグインを一時的に無効化し、もう一度投稿を保存してみます。405 が消えれば、そのプラグインが原因です。
修正: ブロックしているプラグインを特定する
WordPress ダッシュボードにログインし、「プラグイン」に移動します。

有効なプラグインをすべて選択し、上部の「一括操作」ドロップダウンを開いて「無効化」を選び、「適用」をクリックします。

すべてのプラグインを無効化した後、405 エラーが消えたかどうかを確認します。消えていれば、各プラグインを 1 つずつ再有効化し、そのたびにサイトをテストして、エラーが再発するまで続けます。それがリクエストをブロックしているプラグインです。
特定できたら、そのプラグインのファイアウォールまたは HTTP メソッドの設定を確認します。Wordfence の場合は、Firewall > All Firewall Options で許可されている HTTP メソッドを確認し、PUT と DELETE が含まれていることを確かめます。Sucuri の場合は、Hardening の設定で HTTP メソッドの制限がないか確認します。
サーバー設定(Nginx と Apache)
.htaccess をリセットしプラグインを無効化した後も残る 405 は、通常ウェブサーバーの設定を指し示しています。Apache では、バーチャルホスト設定ファイル内の Limit および LimitExcept ディレクティブが、サイト全体でメソッドをブロックすることがあります。Nginx では、サーバーブロックまたは location ブロック内の limit_except GET POST {} ブロックが同じ効果を持ちます。
診断: サーバーログを確認する
アクセスログは、すべてのリクエストを HTTP ステータスコードとともに記録します。エラーログは、サーバーがリクエストを拒否した理由を記録します。エラーを返したパスの近くに 405 または method not allowed を含む行がないか探します。
ほとんどの共有ホスティングのコントロールパネルでは、ログは「Logs」または「Metrics」セクションで確認できます。VPS や専用サーバーの場合は、/var/log/apache2/error.log または /var/log/nginx/error.log を確認します。
修正: サーバー設定を更新する
Apache の場合は、サイトのバーチャルホスト設定ファイル(通常は /etc/apache2/sites-enabled/ 以下)を見つけ、<Limit> または <LimitExcept> ブロックを探します。必要な HTTP メソッドを追加するか、制限を削除します。
Nginx の場合は、サイトのサーバーブロック内の limit_except ブロックを見つけ、不足しているメソッドを追加するか、設定に必要なければブロックを削除します。
設定を編集した後、サーバーを再読み込みします:
# Apache
sudo systemctl reload apache2
# Nginx
sudo systemctl reload nginx
共有ホスティングでは、グローバルなサーバー設定を直接編集することはできません。ホスティングのサポートに連絡し、ブロックされている HTTP メソッドと 405 を返す具体的な URL パスを伝えてください。
WordPress REST API のメソッド制限
WordPress は、Gutenberg の保存、プラグインの同期操作、WP-CLI コマンドに REST API を使用します。REST API が無効になっている場合、またはプラグインやテーマのフックが特定の HTTP メソッドを拒否している場合、/wp-json/ で始まるパスで 405 エラーが表示されます。
当社のテストでは、ブロックエディターでの REST API メソッドエラーは、プラグインやテーマの REST 認証フィルターと、セキュリティプラグインのメソッド許可リストの組み合わせが原因であることが最も多いです。デバッグモードを有効にすると、どのコンポーネントがリクエストを拒否しているかがわかります。
修正: WordPress のデバッグモードを有効にしてエラーを追跡する
wp-config.php を開き、define('WP_DEBUG', false) を define('WP_DEBUG', true) に変更します。さらに define('WP_DEBUG_LOG', true) を追加して、エラーを wp-content/debug.log に書き出すようにします。ファイルを保存します。

405 エラーを再現し、wp-content/debug.log を開いて、REST API の認証エラーやフィルターの競合を探します。原因となっているフックやプラグインが見つかったら、その設定を更新するか、プラグインの作者に連絡します。
トラブルシューティングが終わったら、WP_DEBUG を false に戻します。
設定手順については、WordPress デバッグログを有効にする方法を参照してください。
お問い合わせフォームプラグインが誤った HTTP メソッドを送信する
一部のお問い合わせフォームや購入手続きプラグインは、POST しか受け付けないエンドポイントに GET リクエストでデータを送信したり、サーバーが受け付けない非標準のメソッドを使用したりします。これにより、管理画面ではなくフロントエンドで 405 が発生します。
WP STAGING のサポートによると、このパターンは、プラグインのアップグレードが送信先エンドポイントの URL を変更したにもかかわらず、フォームの method 属性を更新しなかった場合に現れます。プラグインは古いメソッドを使って新しいエンドポイントにリクエストを送り始め、サーバーが 405 を返します。
診断: ブラウザの DevTools(F12)を開き、Network タブに移動して、フォームを送信します。405 を返すリクエストを見つけます。Method 列を確認します。POST すべきフォームで GET が表示されている場合や、その他の予期しないメソッドが表示されている場合は、プラグインの設定が誤っています。
修正: まずプラグインを最新バージョンに更新します。エラーが続く場合は、プラグインの設定でフォームのメソッドまたは送信先 URL のオプションを確認し、サーバーが受け付ける内容と一致しているか確かめます。プラグインにそのような設定がない場合は、Network タブで確認したリクエストのメソッドと URL を添えて、プラグインの作者に連絡します。
一般的なトラブルシューティング
上記の原因別の修正でエラーが解決しなかった場合は、次の手順を順番に試してください。
ページを再読み込みする
一時的なサーバーの不具合や古いブラウザキャッシュが、一度きりの 405 を引き起こすことがあります。Windows では Ctrl + Shift + R、macOS では Command + Shift + R でハードリロードし、新しいリクエストを強制的に送信します。
URL の誤りを確認する
URL に入力ミス、余分なスラッシュ、誤った位置の文字がないかダブルチェックします。不正な形式の URL は、送信したメソッドを受け付けないエンドポイントにルーティングされることがあります。
最近の変更を元に戻す
プラグイン、テーマ、または WordPress コアの更新後に 405 が現れた場合は、その変更をロールバックします。プラグインの場合、WP Rollback で以前のバージョンに戻すことができます。ロールバックのたびにサイトをテストし、どの更新がエラーを引き起こしたかを確認します。
データベースの最近の変更を調べる
データベースに書き込みを行うプラグインやテーマが、まれにリクエストのルーティングを妨げることがあります。予期しない変更を確認するには、次の手順を実行します:
- cPanel にログインし、phpMyAdmin を開きます。

- 左側のサイドバーから、WordPress インストールに関連付けられたデータベースを選択します。

最近アンインストールしたプラグインが残した孤立したテーブルを wp_options と wp_usermeta で探します。残っている行を削除し、405 が解消するかどうかを確認します。
デフォルトテーマに切り替える
REST API ルートを正しく登録していないテーマは、それらのパスで 405 を引き起こすことがあります。同梱のデフォルトテーマに切り替えることで、この可能性を排除できます。
ダッシュボードの外観 > テーマに移動し、WordPress のデフォルトテーマを有効化します。

デフォルトテーマを有効にした状態で 405 が消えた場合、問題は元のテーマにあります。テーマの functions.php にあるカスタムの register_rest_route 呼び出しを確認するか、テーマの作者に連絡します。
修正がうまくいかない場合の対処法
上記のすべてのセクションを試しても 405 が続く場合、訪問者のブラウザとサーバーの間にある CDN やリバースプロキシが、リクエストが WordPress に到達する前に HTTP メソッドを取り除いたり書き換えたりしている可能性があります。
CDN または WAF のレイヤーを確認する。 ホスティングのコントロールパネルや DNS プロバイダのダッシュボードでは、通常、CDN や Web アプリケーションファイアウォールが有効かどうかを確認できます。有効な場合は、そのファイアウォールルールに HTTP メソッドの許可リストがないか確認します。CDN サービスには、GET と POST のみを許可するルールがあることが多く、これがリクエストが WordPress に到達する前に PUT、DELETE、PATCH に対して 405 を返します。
ロードバランサーの設定を確認する。 サイトがロードバランサーの背後で動作している場合は、リスナーやバックエンドの設定が非標準の HTTP メソッドを拒否していないことを確認します。
プロキシを一時的にバイパスして原因を切り分ける。 テストリクエストをオリジンサーバーに直接ルーティングして 405 が消えるなら、プロキシがメソッドをフィルタリングしています。CDN プロバイダやシステム管理者と協力して、メソッドの許可リストを調整してください。
まとめ
WordPress の 405 Method Not Allowed エラーの根本原因は、いくつかに限られます。.htaccess の LimitExcept ディレクティブ、REST API のメソッドをブロックするセキュリティプラグイン、サーバーレベルの設定ルール、誤った HTTP メソッドを送信するプラグイン、あるいは上流でリクエストをフィルタリングする CDN です。.htaccess のリセットから始めて各原因を順番に試していけば、ほとんどのケースで問題は解決します。
変更に失敗して元に戻す必要がある場合は、WP Staging バックアップと復元ガイドが、数回のクリックで復旧する手順を説明しています。