↗付きの用語リンクは、別タブで説明を開きます。
WooCommerceを運営していると、商品や注文の更新、外部ツールとの連携、WordPress REST APIへの書き込みなど、特定の操作だけで「501 Not Implemented」が表示されることがあります。トップページや商品ページは閲覧できるのに、保存やAPI処理だけが失敗する場合、画面表示の確認だけでは原因を判断できません。
MO-LIBが関わるサイト運用でも、WordPressとWooCommerceの処理中に501エラーが発生し、サーバー側のセキュリティ設定を含めて調査が必要になった事例がありました。ただし、調査途中の状況だけでWAFやレンタルサーバーを原因と断定することはできません。本記事では個別の会社名や契約情報を使用せず、同様の問題が起きたときの確認手順として一般化します。
501 Not Implementedとは
HTTPの標準仕様では、501 Not Implementedは、サーバーがリクエストを実行するために必要な機能をサポートしていない場合に返されるステータスコードです。一方、実際のWordPress運用では、サーバー、プロキシ、WAF、セキュリティプラグインなどがリクエストを遮断した結果として、501に見える応答が返る可能性もあります。
そのため、「501だからサーバーが古い」「WAFを切れば直る」と一つの原因へ決めつけず、どの操作・URL・HTTPメソッド・送信内容で発生したのかを残すことが出発点になります。
最初に記録する項目
- エラーが発生した日時とタイムゾーン
- 操作した管理画面、URL、対象の商品・注文・投稿
- 閲覧、保存、更新、削除、外部連携などの操作内容
- GET、POST、PUT、DELETEなど、分かる範囲のHTTPメソッド
- 表示されたステータスコードとエラーメッセージ
- 同じ操作が毎回失敗するか、特定の文字やデータだけで失敗するか
- 直前に行ったWordPress、WooCommerce、テーマ、プラグイン、PHP、サーバー設定の変更
- 通常ページ、管理画面、REST APIのどこまで正常か
サーバー会社へ調査を依頼する場合も、発生日時と再現手順があるとログを照合しやすくなります。パスワード、APIキー、注文者情報、決済情報は記事や一般の問い合わせ文へ貼り付けないでください。
切り分けは影響範囲の確認から始める
1. 公開ページと管理画面を分けて確認する
トップページ、商品ページ、カート、購入手続き、WordPress管理画面、WooCommerceのステータス画面を分けて確認します。サイト全体が停止しているのか、管理画面の一機能だけなのかで、調査する範囲が変わります。
2. REST APIの読み取りと書き込みを分ける
WordPress REST APIでは、一般にGETは取得、POSTは作成、PUTは更新、DELETEは削除に使われます。公開情報のGETが成功しても、認証付きのPOSTやPUTだけが失敗することがあります。読み取り成功だけでAPI全体が正常と判断せず、問題が起きたものと同じ操作を確認します。
3. 送信内容による差を確認する
長いHTML、特定のタグ、スクリプトに似た文字列、URL、JSON、特殊記号などを含むときだけ失敗する場合、WAFなどの検知条件に触れている可能性があります。ただし、実際の検知ログを確認せずにWAFが原因と断定しないでください。
XServerのWAFを確認するときの注意点
XServerのWAFは、有害な可能性のあるアクセスを検知するための機能です。公式マニュアルでは、設定の追加・変更後、反映まで最大30分程度かかる場合があると案内されています。また、WAFだけで不正アクセスを完全に防げるものではなく、WordPressやプラグインを最新で安全な状態に保つ必要があります。
原因調査のために設定を変更する場合は、次の順序を守ります。
- 対象ドメインを確認する
- 変更前のWAF設定をスクリーンショットやメモで残す
- バックアップと復旧方法を確認する
- 変更する項目を一つに絞る
- 反映時間を待って、同じ操作で再現を確認する
- 結果と発生時刻を記録する
- 調査後に必要な保護設定へ戻し、再度動作を確認する
本番環境でWAFを一括無効にしたまま運用する方法は勧められません。設定変更が必要か判断できない場合は、再現手順と時刻を添えてXServerへ相談します。
WooCommerce側で確認すること
WooCommerceの公式ドキュメントでは、トラブル調査にシステムステータスレポートを活用し、プラグインやテーマの競合を確認する方法が案内されています。競合テストを行う場合は、本番サイトへ直接影響を与えないよう、バックアップまたはステージング環境を準備します。
- WooCommerce > ステータスでシステムレポートを保存する
- WordPress、WooCommerce、テーマ、関連プラグインのバージョンを確認する
- PHP、MySQLまたはMariaDB、メモリ上限、HTTPSの状態を確認する
- WooCommerceのログとWordPressのデバッグログを確認する
- キャッシュやセキュリティ系プラグインの影響を確認する
- ステージング環境で標準テーマと必要最小限のプラグイン構成を試す
- 停止したプラグインを一つずつ戻し、同じ操作を再現する
本番の注文処理中にプラグインを一括停止すると、決済、在庫、メール、外部連携へ影響することがあります。実施日時と影響範囲を決め、必要に応じて制作会社や保守担当者と共有してください。
PHPやサーバー環境も確認する
WooCommerceの推奨環境は更新されるため、公開時点の公式要件を確認します。古いPHPやデータベースが直ちに501の原因になるとは限りませんが、サポート終了済みの環境ではセキュリティや互換性の問題を切り分けにくくなります。
PHPを更新する場合も、先にバックアップを取り、テーマとプラグインの対応状況を確認し、可能であればステージング環境でテストします。エラー解消だけを目的に複数の設定を同時変更すると、何が原因だったか分からなくなるため避けます。
XServerや制作会社へ伝える情報
- 対象ドメインと利用しているWordPressサイト
- 501が発生した正確な日時
- 再現できる操作手順
- 対象URLとHTTPメソッド
- 正常な操作と失敗する操作の違い
- 変更前後のWAF、PHP、プラグイン等の設定
- WooCommerceシステムステータスの必要部分
- サーバー側ログの確認を依頼したい時間帯
注文情報や認証情報を渡す必要がある場合は、問い合わせ窓口の安全な方法を確認し、公開チャットや記事本文へ記載しないようにします。
復旧後に確認すること
- 同じ操作を複数回行って501が再発しないか
- 商品・注文・投稿が重複作成されていないか
- 注文ステータス、在庫、決済、メール、外部システム連携が一致しているか
- 変更したWAFやプラグイン設定が適切な状態へ戻っているか
- キャッシュ削除後も正常に動作するか
- 原因、対応、担当、発生日時、復旧日時を障害記録へ残したか
タイムアウトやエラー後に同じ更新をすぐ再送すると、サーバー側では処理が完了しており、商品や投稿だけが重複することがあります。再送前に対象データを読み戻してから判断します。
まとめ
WooCommerceで501 Not Implementedが表示された場合は、WAFだけを疑うのではなく、発生操作、HTTPメソッド、送信内容、REST API、プラグイン・テーマ、PHP、サーバー設定を順番に確認します。変更前の記録とバックアップを残し、一項目ずつ変更して同じ手順で再現することが重要です。
今回の元事例は調査結果が確定していないため、特定の設定を原因とする成功事例ではなく、安全な切り分け方法として整理しました。環境によって原因と影響範囲は異なるため、判断が難しい場合はサーバー会社、制作会社、保守担当者へ相談してください。
