WordPressの記事保存、フォーム送信、外部連携、REST APIで「405 Method Not Allowed」と表示されることがあります。ページは開けるのに送信だけ失敗する、APIテストではGETは通るのにPOSTやDELETEが拒否される、といった症状です。
405は、サーバーが受け取ったHTTPメソッド自体は知っているものの、そのURLでは許可していない状態です。URL、GET・POST・PUT・PATCH・DELETE・OPTIONSなどのメソッド、REST APIのルート、CDN・WAF、Webサーバー設定を分けて確認します。
405を直すために、すべてのHTTPメソッドを許可したり、WAFや認証を全面停止したりしないでください。必要なURLに、必要なメソッドだけを許可することが安全な復旧の基本です。
先に結論：405エラーは8段階で確認する
- 送信を止め、記事本文やフォーム入力を退避する
- 失敗した完全なURL、HTTPメソッド、時刻を記録する
- GETで開く画面と、POSTなどの送信操作を分ける
- 応答の
Allow、Server、CDN識別情報を確認する - WordPress REST APIのルートと対応メソッドを確認する
- リダイレクト、CDN・WAF、Webサーバーの順に発行元を絞る
- クライアントか対象URLの設定だけを修正する
- 復旧後に不要なメソッドが拒否されることも確認する
記事保存で別のエラー文言も出る場合は、WordPressの「正しいJSONレスポンスではありません」を直す確認順も使い、実際のHTTP 405と応答本文を確認してください。
405 Method Not Allowedとは？
RFC 9110の405 Method Not Allowedは、要求行のメソッドをサーバーは認識しているものの、対象リソースでは対応していない状態です。405を返すオリジンサーバーは、現在対応するメソッドをAllowヘッダーで示す必要があります。
たとえば、読むためのURLへGETを送る、作成用エンドポイントへPOSTを送る、削除用エンドポイントへDELETEを送る、という対応があります。同じURLでも複数メソッドを受け付ける場合があり、URLだけを見ても正しい操作かは判断できません。
405は「ログインできない」「権限が足りない」と同じではありません。認証情報が不足する401、要求を理解した上で拒否する403、URLやルートが見つからない404とは切り分けます。
401・403・404・405・415の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 401 Unauthorized | 有効な認証情報がない、または拒否された | 認証方式、資格情報 |
| 403 Forbidden | 要求は理解されたが処理を拒否された | 権限、WAF、アクセス制限 |
| 404 Not Found | 対象リソースやルートが見つからない | URL、公開状態、ルート登録 |
| 405 Method Not Allowed | メソッドは認識されたが対象URLでは非対応 | Request Method、Allow、ルート仕様 |
| 415 Unsupported Media Type | 送信形式が対象メソッドで非対応 | Content-Type、本文形式 |
認証が疑われる場合はWordPressの401 Unauthorizedを直す手順、WAFや権限の拒否ならWordPressの403 Forbiddenを直す手順、通常のページが見つからない場合はWordPressの404エラーを直す確認順へ進みます。
WordPress REST APIでは405以外になる場合がある
WordPress REST API公式のRoutes and Endpointsでは、URLのルートとHTTPメソッドの組み合わせでエンドポイントが決まります。GET、POST、PUT、DELETE、OPTIONSなどは役割が異なり、登録された組み合わせだけが処理されます。
ただし、WordPressコアがルートとメソッドの組み合わせを見つけられない場合、必ず405を返すわけではありません。WordPressのWP_REST_Server公式コード資料では、「URLと要求メソッドに一致するルートがない」というrest_no_routeをHTTP 404で返す実装が確認できます。
そのため、405ならWebサーバーやCDNが必ず原因とも、WordPress本体が必ず原因とも断定できません。独自プラグインや外部APIが405を返す場合もあります。実際の応答本文、Allow、応答ヘッダー、各層のログを照合します。
最初の10分で行う安全な初動
1．入力内容を退避し、再送信を止める
記事保存やフォーム送信で失敗したら、本文や入力内容をローカルの安全な場所へコピーします。外部ツールやAPIクライアントの自動再試行も止めます。POSTなどは同じ要求でも新しいデータを作る可能性があるため、エラー後の連打を避けます。
管理画面や通知で、処理が途中まで成功していないか確認します。405画面が出ても、CDNやプラグインが応答を書き換えた可能性があるため、保存・注文・登録が絶対に失敗したとは断定しません。
2．完全なURLとHTTPメソッドを記録する
発生時刻とタイムゾーン、操作、完全なRequest URL、Request Method、Status 405、応答本文を記録します。ブラウザのNetworkでは、失敗した要求を一つ選び、リダイレクト前後のURLとメソッドも確認します。
Cookie、Authorization、nonce、APIトークン、フォームの個人情報は保存・共有しません。HARをサポートへ送る場合も秘密値と本文を削除し、URL、メソッド、ステータス、時刻、要求IDを中心に伝えます。
3．GET表示と送信操作を分ける
ページを開くGETが405なのか、フォームのPOSTやAPIのPUT・PATCH・DELETE・OPTIONSだけが405なのかを分けます。公開ページのGETまで405なら、サーバーや転送設定の影響を優先します。特定機能の送信だけなら、そのフォームやAPIルートを優先します。
同じURLへ別メソッドを手当たり次第に送らないでください。削除や更新を伴うメソッドが通ると、データを変更する可能性があります。仕様書、REST APIインデックス、プラグイン公式資料で対応メソッドを先に確認します。
どの層が405を返したか特定する
応答のAllowにGETやPOSTなどがあれば、対象URLが現在受け付けるメソッドの手がかりになります。ただし、Allowがない405や、実際の動作と矛盾する値なら、独自実装や中継層の応答も疑います。
| 確認場所 | 手がかり | 主な確認内容 |
|---|---|---|
| ブラウザ・外部ツール | 想定と違うメソッド、古いAPI URL | クライアント設定、送信先、更新履歴 |
| CDN・WAF・プロキシ | 独自画面、識別ID、配信元ログに要求なし | 許可メソッド、ルール、キャッシュ |
| Webサーバー | アクセスログに405、静的URLへのPOST | location、転送、メソッド制限 |
| WordPress・プラグイン | JSON応答、プラグイン固有コード | RESTルート、フォームaction、更新差分 |
| 外部API | 相手サービスのエラー本文 | API版、URL、対応メソッド、認証 |
405は仕様上キャッシュ可能な応答です。CDNやプラグインの設定によっては、修正後も古い405が残る可能性があります。ただし、最初から全キャッシュを消すのではなく、設定修正後に対象URLとメソッドのキャッシュだけを確認します。
原因別の安全な直し方
1．フォームの送信先やメソッドが違う
フォームの送信先URL、固定ページURL、REST API URL、外部サービスURLを混同していないか確認します。フォームやプラグインの更新後にURLが変わった、テスト環境の送信先が残った、静的ファイルへPOSTしている、といった差分を調べます。
お問い合わせフォームなら、フォーム本体の設定、完了ページ、JavaScriptの送信先、キャッシュを分けます。メールが届かないだけで405がない場合は、WordPressからメールが届かないときの確認手順が対象です。
2．REST APIのURLとメソッドが一致していない
WordPressのREST APIインデックスや対象プラグインの公式資料で、ルートと対応メソッドを確認します。GETで取得するURLへPOSTを送る、コレクション用URLと個別IDのURLを取り違える、古いAPIバージョンを使うなどのずれを修正します。
一部のクライアントがDELETEなどを送れない場合、WordPress REST APIは_methodまたはX-HTTP-Method-Overrideを利用する仕組みを持ちます。WordPress公式のmethod override資料では、POST要求でだけ使うよう案内されています。対応確認なしにGETへ付けたり、認証を回避する目的で使ったりしません。
3．リダイレクト先が送信を受け付けない
HTTPからHTTPS、www有無、旧ドメイン、新しいREST APIパスへの転送を確認します。フォームやAPIの送信URLは、転送前ではなく最終の正規URLへ直接合わせます。転送途中でメソッドや本文が変わる可能性があるためです。
転送が何度も続く場合は、WordPressのリダイレクトループを直す確認順で、WordPress、CDN、Webサーバーの転送を分けてください。
4．CDN・WAF・プロキシがメソッドを拒否する
CDN・WAFのイベントログで、対象URL、メソッド、送信元、要求IDを確認します。DELETEやPUTだけでなく、ブラウザの外部連携で使われるOPTIONSが中継層で拒否され、実際の送信前に405になる場合もあります。
全メソッド許可へ変えるのではなく、正当な送信元、対象パス、必要なメソッド、認証条件を限定します。WAFを停止したままにせず、検証後はルールとログを確認して防御を戻します。
5．Webサーバーのパス設定がWordPressへ届いていない
静的ファイル用のパス、管理画面、/wp-json/、独自APIパスで処理先が異なる場合があります。アクセスログで405を返したlocationや仮想ホストを確認し、WordPressへ渡すべき要求が別の処理へ入っていないかをサーバー会社へ確認します。
.htaccessやNginx設定を丸ごと置き換えず、変更前の設定と戻し方を保存します。本番での直接変更を避ける方法はWordPressのテスト環境を作る手順で確認できます。
6．プラグイン・テーマ・独自コードのルートが変わった
更新直後から発生した場合は、変更履歴、RESTルート、フォームaction、JavaScriptの送信先を確認します。プラグインを一括停止せず、ステージング環境またはホストの安全な切り替え方法で、原因候補を一つずつ比較します。
独自RESTルートでは、必要なメソッドと権限確認を正しく登録する必要があります。メソッドを増やしてエラーだけ消すのではなく、読み取り・作成・更新・削除の処理と権限を一致させます。不要プラグインの整理はWordPressプラグインを安全に減らす方法を参考にしてください。
7．外部APIの仕様やバージョンが変わった
決済、CRM、投稿、バックアップなど相手側APIのURL、バージョン、対応メソッド、廃止予定を公式資料で確認します。405を認証エラーと誤解してWordPressの主パスワードを変えず、外部連携ごとの資格情報と設定を分けます。
APIキーやApplication PasswordをURLへ移して回避しないでください。認証情報の扱いはWordPressの401 Unauthorizedを直す確認順で整理できます。
405対応でやってはいけないこと
- サーバーですべてのHTTPメソッドを許可する
- WAF、認証、nonce、REST APIを全面停止する
- GET、POST、PUT、DELETEを手当たり次第に送る
- 更新・削除要求を連打する
- 認証情報や個人情報をURLへ移す
- 405を正常な200応答へ見せかける
.htaccessやサーバー設定を丸ごと削除する- 全プラグイン停止とキャッシュ全消去を同時に行う
Allowだけを見て発行元を断定する- 修正後に不要メソッドが拒否されるか確認しない
復旧後に確認すること
- 対象URLへ正しいメソッドで一度だけ成功する
- 公開ページのGETと管理画面が正常に開く
- 記事保存、フォーム、外部連携が必要な範囲で動く
- 不要なメソッドは引き続き拒否される
- 認証、nonce、WAFなど必要な防御が有効である
- 転送後もURL、メソッド、本文が意図どおりである
- CDNやプラグインに古い405が残っていない
- アクセスログで405が繰り返されていない
公開ページのGETが意図せず405を返している場合は検索にも影響します。GoogleのHTTPステータス公式資料では、429以外の4xxを返すURLの内容は検索に利用されず、既存URLも時間とともにインデックスから外れると説明されています。APIのPOST専用URLと、検索対象の公開ページを分けて確認します。
サポートへ伝える情報
- 発生日時とタイムゾーン
- 完全なRequest URLとRequest Method
- HTTP 405と応答本文
Allow、Server、CDN識別ID- GET表示と送信操作の比較結果
- リダイレクト前後のURLとメソッド
- WordPress、プラグイン、外部APIの更新履歴
- 秘密情報を伏せた要求IDとログ
- 直前に変更したWAF・サーバー・フォーム設定
「405を直してください」だけでなく、「7月22日16時、公開ページのGETは200。問い合わせ送信のPOSTだけ405。AllowはGET、HEAD。CDN識別IDあり、配信元ログにPOSTなし」のように伝えると、調査する層を絞れます。
よくある質問
405ならAllowに書かれたメソッドへ変えればよいですか？
必ずしもそうではありません。目的が更新なのにGETしか許可されていない場合、送信先URLが違う可能性があります。データを変える前に、対象機能の公式仕様と正しいURLを確認してください。
パーマリンクを保存し直せば直りますか？
RESTルートや書き換え設定が壊れている場合は候補ですが、すべての405に効く万能策ではありません。公開記事まで404になるなど書き換え固有の症状があるときだけ、バックアップ後に対象を確認します。
キャッシュ削除で直りますか？
設定修正後も古い405が残る場合は候補です。ただし、誤ったURLやメソッド、WAF・サーバー設定が原因ならキャッシュだけでは直りません。先に発行元と設定差分を確認します。
WordPress REST APIで違うメソッドを送ると必ず405ですか？
必ずではありません。WordPressコアは、URLとメソッドに一致するルートがないと404のrest_no_routeを返す場合があります。405が出たら、WordPressへ届く前の層や独自実装も含めて確認します。
OPTIONSだけ405になるのはなぜですか？
ブラウザの外部連携で、実際の送信前にOPTIONSを使う場合があります。CDN、WAF、プロキシ、WebサーバーがOPTIONSを拒否すると、POSTなど本来の要求まで進みません。対象Originとパス、必要メソッドを確認し、全サイトへ無制限に許可しないでください。
まとめ
WordPressの405 Method Not Allowedは、サーバーが知っているHTTPメソッドを、対象URLでは受け付けない状態です。完全なURL、Request Method、Allow、応答本文を記録し、クライアント、CDN・WAF、Webサーバー、WordPress・プラグイン、外部APIを分けます。
安全な復旧の基本は、必要なURLに必要なメソッドだけを対応させ、不要なメソッドと防御を開放しないことです。発行元を判断できない場合は、URL、メソッド、時刻、Allow、比較結果をそろえてホストや開発元へ相談してください。