WordPressのREST API、プラグイン連携、外部サービス、管理画面の保存で「501 Not Implemented」が返ることがあります。URLは正しそうなのに処理されない、更新後から特定操作だけ失敗する、といった症状です。
501は、要求を処理するために必要な機能をサーバーがサポートしていない状態です。代表例は、サーバーが要求されたHTTPメソッドを認識していない、またはどの資源にも実装できない場合です。
501を見て、すぐにWordPress本体や全プラグインを再インストールしないでください。501を返したのがCDN、WAF、プロキシ、Webサーバー、プラグイン、外部APIのどこかで対処が変わります。
先に結論：501エラーは8段階で確認する
- 編集中の本文や送信内容を別の安全な場所へ退避する
- URL、HTTPメソッド、時刻、操作、501、応答本文を記録する
- 同じURLの通常閲覧と、失敗した操作を分ける
- 要求メソッドがAPI仕様と一致するか確認する
- 501と405、404、500、502を区別する
- CDN・WAF・プロキシ・Webサーバー・WordPressの発行元を特定する
- 対応済みの正規メソッドや公式の代替手段へ一か所だけ修正する
- 処理結果、キャッシュ、重要機能、再発の有無まで確認する
メソッド自体は認識されているが対象URLで許可されない場合は、WordPressの405 Method Not Allowedを直す確認順を使います。要求の形式が解釈できない場合はWordPressの400 Bad Requestを直す確認順が適切です。
501 Not Implementedとは？
RFC 9110の501 Not Implementedは、要求を満たすために必要な機能をサーバーがサポートしていない状態です。要求メソッドを認識せず、どの資源にも対応できない場合に適切とされています。
一方、GETやPOSTなどのメソッドをサーバーは理解し、他のURLでは実装しているものの、対象URLでは許可していない場合は405が基本です。501と405は「できない」という見た目が似ていますが、対応範囲が違います。
WordPress REST APIはルートごとに対応するHTTPメソッドを登録します。標準ルートへのメソッド不一致が常に501になるわけではなく、WordPressへ届く前の中継層や、独自APIが501を返す場合があります。
501応答は、明示的なキャッシュ制御がなければヒューリスティックにキャッシュ可能です。修正後も同じ501が見えるときは、CDNやプロキシに古い応答が残っていないかも確認します。
405・500・501・502の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 405 Method Not Allowed | メソッドは認識済みだが対象では不許可 | URL、Allow、ルートの対応メソッド |
| 500 Internal Server Error | 処理中に予期しない問題が起きた | エラーログ、直前変更、PHP |
| 501 Not Implemented | 必要機能やメソッドをサーバーが未対応 | 実際のメソッド、実装層、API仕様 |
| 502 Bad Gateway | 中継層が上流から無効な応答を受けた | CDN・プロキシと上流サーバー |
画面に「未対応」と出ても、実際のHTTPステータスが501とは限りません。ブラウザのNetwork欄、APIクライアント、サーバーログで番号と要求メソッドを確認してから対処します。
WordPressで501が出る主な原因
1．クライアントが未対応のHTTPメソッドを送っている
プラグインや外部アプリが、サーバーやAPIで実装されていないメソッドを送ると501になる場合があります。メソッド名の誤字、独自メソッド、WebDAV用メソッド、API版変更後の古いクライアントが候補です。
メソッド名を画面文言から推測せず、実際のRequest Methodを確認します。GETへ変えれば画面が開くとしても、更新・削除をGETで代用しないでください。処理の意味と安全性が変わります。
2．CDN・WAF・プロキシがメソッドを認識または転送できない
WordPressとWebサーバーが対応していても、前段のCDN、WAF、ロードバランサー、リバースプロキシが未知のメソッドを拒否したり、転送設定を持たなかったりする場合があります。
WordPressのアクセスログへ要求が到達していない、CDNの応答ヘッダーがある、オリジンへ直接行う安全な検証では別の結果になる場合は、中継層を優先して確認します。
3．Webサーバーまたはモジュールが必要機能を提供していない
WebDAV、プロキシ、圧縮、特定のゲートウェイ機能など、要求に必要なモジュールが無効・未導入の場合があります。サーバー移行、構成変更、コンテナ差し替え後に始まったなら、旧環境との機能差を確認します。
不足モジュールを片端から有効化せず、そのサイトと要求に本当に必要か、提供元が対応する構成か、セキュリティ影響を確認します。共有サーバーでは管理者へ相談します。
4．プラグインのRESTルートとクライアントのAPI版がずれている
プラグイン更新でルート、名前空間、対応メソッドが変わり、古い外部アプリが廃止済みの操作を送る場合があります。新旧API版を混在させると、WordPress側または外部ゲートウェイが501を返すことがあります。
ルートのインデックス、プラグインの変更履歴、現在のAPI仕様を確認します。URLだけでなく、HTTPメソッド、認証方式、Content-Type、要求本文も同じ版の仕様へそろえます。
5．外部APIが機能をまだ提供していない、または廃止した
WordPressから接続する決済、メール、画像処理、ストレージ、分析APIが、地域、契約、API版、エンドポイントによって機能を提供していない場合があります。WordPressのURLに見えても、サーバー側処理が外部APIの501を受け取っていることがあります。
外部サービスの障害情報、API資料、対象機能の提供範囲、廃止案内を確認します。利用できない機能を再送し続けず、公式の代替手段や対応版を使います。
6．エラーページやキャッシュが古い501を返し続けている
原因を修正しても、CDN、リバースプロキシ、ブラウザ、Service Workerに501応答が残る場合があります。別URLやクエリを無計画に追加するのではなく、Age、Via、キャッシュ状態を見て該当URLだけを更新します。
キャッシュ削除で一時的に直っても、未対応メソッドを送る原因が残れば再発します。生成元とキャッシュの両方を確認します。
最初の10分で行う安全な初動
1．送信内容を退避し、同じ操作の連打を止める
記事本文、フォーム入力、外部ID、アップロード対象を安全な場所へ退避します。作成、注文、送信、削除の操作は、前回結果を確認するまで再実行しません。501の前後で一部だけ処理された可能性も確認します。
発生時刻、画面、対象URL、HTTPメソッド、501、リクエストID、直前の更新を記録します。AuthorizationやCookieは記録へ貼らないでください。
2．公開閲覧と状態変更操作を分ける
公開ページのGETも501なら、サイト全体やWebサーバー層の問題を優先します。閲覧は正常で、特定の保存・削除・同期だけ501なら、その要求メソッドとルートを確認します。
別ブラウザで公開ページを確認するのは安全ですが、注文や削除など状態を変える処理を別環境から再現しません。テスト環境とテストデータを使います。
3．実際のメソッドと最終URLを確認する
Network欄でRequest Method、Request URL、転送後の最終URL、Response Headers、Response本文を確認します。JavaScriptコードの想定ではなく、送信された事実を記録します。
POSTが転送後に別メソッドへ変わる、X-HTTP-Method-Overrideが追加される、プロキシが独自メソッドを拒否する場合もあります。各層の前後で違いを確認します。
どの層が501を返したか特定する
| 確認層 | 見るもの | 判断の手がかり |
|---|---|---|
| ブラウザ・外部アプリ | 実際のメソッド、URL、Override、API版 | 仕様どおり送っているか |
| CDN・WAF | イベント、許可メソッド、応答ヘッダー | オリジン前で拒否したか |
| プロキシ・Webサーバー | アクセスログ、モジュール、転送設定 | 機能やメソッドを実装しているか |
| WordPress・プラグイン | REST名前空間、登録ルート、対応メソッド | 独自APIが501を返したか |
| 外部API | 外部URL、API版、提供範囲、リクエストID | 外部機能が未提供・廃止か |
WordPress REST APIのRequests資料では、要求メソッドがルートのエンドポイントへ対応づけられる仕組みが説明されています。Routes and Endpoints資料で、対象ルートが対応するメソッドも確認できます。
WordPressに同梱されたステータス説明には501がありますが、それだけでWordPress本体が発行元とは判断できません。サーバーや外部APIから受け取った501を、プラグインが画面へ表示している場合もあります。
原因別の安全な直し方
1．API仕様に合うURLとメソッドへ戻す
現在のAPI資料とルート一覧を確認し、取得、作成、更新、削除に対応する正規メソッドを使います。名称が似た別ルートや古いAPI版へ送っていないか、対象IDを含むURLかも確認します。
メソッドをGETへ変えてエラーだけ消すのではなく、実行したい操作の意味に合う方法を選びます。更新や削除を安全でない代替方法へ置き換えません。
2．WordPress公式のメソッド上書き機能は仕様範囲で使う
クライアントやファイアウォールがDELETE等を送れない場合、WordPress REST APIには、資料で案内される_methodパラメータやX-HTTP-Method-Overrideがあります。ただし、対象エンドポイントがその操作を正式にサポートする場合だけ使います。
WAFを回避する裏口として使わず、認証、権限、nonce、監査ログが正しく働くことを確認します。外部APIには同じ仕組みがない場合があります。
3．中継層の対応メソッドと転送設定をそろえる
CDN、WAF、ロードバランサー、プロキシが必要な正規メソッドを扱えない場合は、提供元の対応範囲を確認します。必要なパスとメソッドだけを許可し、サイト全体の制限を外しません。
転送先のHost、Scheme、パス、認証ヘッダー、メソッドが維持されるかをテストします。一つの層を変更したら結果を確認し、複数層を同時に変えません。
4．必要なサーバー機能は管理者が限定して有効化する
Webサーバーの機能やモジュール不足と確認できた場合は、サーバー会社または管理者へ、対象URL、メソッド、必要機能、公式要件を伝えます。不要なWebDAVやプロキシ機能を広く有効化すると攻撃面が増えます。
共有サーバーで対応できない機能なら、プラグインや連携方法の公式な代替を検討します。未確認の設定断片を本番へ貼り付けないでください。
5．プラグインと外部アプリの対応版をそろえる
API版のずれなら、変更履歴と互換表を確認し、戻せる状態を用意してから片方ずつ更新します。古いクライアントが廃止メソッドを送る場合は、正式対応版へ更新するか、提供元の移行手順を使います。
本番前にはWordPressのテスト環境を作る手順で、閲覧、保存、認証、同期、エラー応答を確認します。
6．修正後に対象URLの古い501キャッシュを更新する
発行原因を直した後、CDNやプロキシへ古い501が残る場合は対象URLだけを消去します。エラー応答を長期間保存しないキャッシュ規則も確認します。
保存時にHTMLの501ページが返り、「正しいJSONレスポンスではありません」も出る場合は、WordPressのJSONレスポンスエラーを直す手順で、修正後のREST応答がJSONへ戻ったことを確認してください。
やってはいけない対処
- 501を見てWordPress本体や全プラグインを再インストールする
- 更新・削除処理をGETへ置き換える
- WAFや認証をサイト全体で無効化する
- 必要性を確認せずサーバーモジュールを大量に有効化する
- 未知のメソッドを許可リストへ無条件に追加する
- CDN、プロキシ、Webサーバー、WordPressを同時に変更する
- 前回結果を見ず作成・注文・通知を再送する
- 古い501をキャッシュしたまま原因修正を失敗と判断する
復旧後の確認チェックリスト
- 公開ページのGET・HEADが正常に応答する
- 対象APIのURLとメソッドが現行仕様に合う
- 作成・更新・削除が正しい権限で一度だけ完了する
- CDN・WAF・プロキシが必要なメソッドだけを扱う
- WordPressのRESTルートと外部アプリのAPI版が一致する
- 不要なサーバー機能を有効化していない
- 古い501キャッシュが残っていない
- JSON応答がHTMLエラーページへ変わっていない
- 注文、通知、同期に重複がない
- エラーログと監視で501が増え続けていない
公開URLが501を返し続ける場合、検索クローラーも本文を取得できません。GoogleのHTTPステータスコード解説に沿って、主要公開ページが200を返すことを確認します。
自力で直せないときに伝える情報
- 発生日時、対象URL、HTTPメソッド
- 公開閲覧と保存・同期での違い
- 秘密値を伏せた応答本文、応答ヘッダー、リクエストID
- WordPressとプラグインの版
- REST名前空間、API版、対象機能
- CDN・WAF・プロキシ・Webサーバーの構成
- WordPressアクセスログへの到達有無
- 直前の移行、更新、サーバー変更
- すでに試した一変更と結果
WordPressの独自RESTルートならプラグイン開発元、外部URLならサービス提供元、WordPressへ届く前ならサーバー会社やCDNへ相談します。認証情報、Cookie、APIキーは共有しないでください。
よくある質問
501と405はどう違いますか？
501は必要機能や要求メソッドをサーバーが実装していない状態です。405はメソッド自体を認識・実装しているものの、対象URLでは許可されない状態です。URL、メソッド、Allow、発行元を確認します。
プラグイン停止で直りますか？
独自APIの不具合なら候補ですが、CDNやWebサーバー、外部APIが発行元なら直りません。全停止ではなく、ルートの名前空間とログから担当プラグインを特定し、テスト環境で確認します。
501は一時的なサーバー障害ですか？
必ずしも一時的ではありません。未実装の機能は待つだけでは使えるようになりません。現在の仕様、提供範囲、対応版を確認し、正規の代替方法へ修正します。
まとめ
501 Not Implementedは、要求を処理するための機能をサーバーがサポートしていない状態です。WordPressでは、クライアント、CDN・WAF、プロキシ、Webサーバー、RESTルート、外部APIを分けます。
- 入力を退避し、URLと実際のメソッドを記録する
- 501と405・500・502を区別する
- 501を返した層を特定する
- 現行API仕様に合うメソッドと対応版へそろえる
- 必要な機能だけを安全に有効化する
- 修正後に古い501キャッシュと重要機能を確認する
501の解決は、機能を無理に通すことではなく、どの層が何を未実装なのかを確認し、対応済みの正規経路へそろえることです。