XserverのWAF誤検知で501エラー！コード付き記事が投稿できない原因と完全対策ガイド【WordPress】

「WordPressで技術記事を投稿しようとしたら、突然501 Not Implementedエラーが出て更新できない！」

「画面には『MOVE/COPYなどのメソッドに対応していません』と表示されるけど、そんな操作した覚えがない…」

技術ブログを運営していると、一度はぶつかる”あるある”トラブルがこれです。特に、PHPやJavaScript、シェルコマンドなどのコードサンプルを含む記事を書いているときに頻発します。

結論から言うと、この問題の原因の多くはXserverのWAF（Web Application Firewall）が記事本文中の文字列を攻撃と誤認してブロックしていることにあります。WordPress自体が壊れたわけではありません。

この記事では、501エラーの「今すぐ復旧したい！」という緊急対応から、「二度と同じ目に遭いたくない」という再発防止策まで、すべてを網羅した完全ガイドをお届けします。

この記事で分かること

• 501 Not Implementedエラーの”本来の意味”と、Xserverで起きるときの実態
• XserverのWAFが何を見て、どの項目が誤検知しやすいかの詳細
• 最短で原因を確定する切り分け手順（反映遅延・キャッシュ問題も含む）
• WAFを”極力弱めずに”更新する現実的な対策4選
• サポートへの連絡テンプレートと再発防止チェックリスト

1. 結論：原因は「WAFがPOST本文を弾いている」ことが多い

まず最初に結論をお伝えします。

WordPressの記事投稿・更新は、通常POSTメソッドで行われます。それなのにエラーページには「MOVE/COPYなどのメソッドに対応していません」と表示される――この違和感の正体は、以下の流れで説明できます。

つまり、あなたが変なHTTPメソッドを送ったわけではなく、正常なPOSTリクエストがWAFによって途中でブロックされているのです。

実際、複数の事例報告で、WAFの「コマンド対策」をOFFにすると501エラーが解消したことが確認されています。これが最も一般的な原因です。

2. 501 Not Implementedとは何か？（技術的背景）

HTTPの501 Not Implementedは、HTTPステータスコードの一つで、「サーバーがそのリクエストの処理に必要な機能（特にメソッド）を実装していない」場合に返されるものです。

RFC 9110での定義

HTTPの標準仕様であるRFC 9110（HTTP Semantics）では、501ステータスコードについて以下のように定義されています。

「501 (Not Implemented) ステータスコードは、サーバーがリクエストメソッドをサポートしておらず、処理できないことを示す」

本来であれば、WebDAVなどで使用されるMOVEやCOPYといった特殊なHTTPメソッドを、対応していないサーバーに送った場合に返されるエラーです。

WordPressでは本来発生しないエラー

重要なポイントは、WordPressの通常操作では、MOVE/COPYといったメソッドは使用されないということです。記事の投稿・更新・削除は、すべてGETまたはPOSTメソッドで行われます。

したがって、WordPress操作中に501エラーが出た場合は、「本当にMOVE/COPYが送られた」のではなく、「何らかの防御レイヤー（WAFなど）がリクエストをブロックし、その結果として501エラーページが表示されている」と解釈するのが現実的です。

なぜエラーメッセージが紛らわしいのか

Xserverでは、WAFによるブロック時に専用のエラーページではなく、汎用的な501エラーページが表示されることがあります。これは、WAFがリクエストを拒否した後のフォールバック処理の結果であり、エラーメッセージの内容（MOVE/COPYなど）は実際の原因を正確に反映していない場合があります。

このため、「501エラー＝変なメソッドを送った」と思い込んでしまうと、原因究明が遠回りになってしまいます。

3. XserverのWAFの仕組みと誤検知が起こる理由

WAF（Web Application Firewall）とは

WAF（Web Application Firewall）は、Webアプリケーションを狙った攻撃からサーバーを守るためのセキュリティ機能です。

WAFは、サーバーに送られてくるリクエスト（URL、HTTPヘッダ、POST本文など）を検査し、あらかじめ定義された攻撃パターン（シグネチャ）に合致するものをブロックします。

これにより、SQLインジェクション、クロスサイトスクリプティング（XSS）、コマンドインジェクションなどの一般的な攻撃を防ぐことができます。

XserverのWAF設定項目

Xserverのサーバーパネルで設定できるWAF項目は、公式マニュアルによると以下の通りです。

なぜ技術記事で誤検知が起きるのか

問題は、技術ブログの記事本文には、上記の検知対象となる文字列がそのまま含まれることが多いという点です。

例えば、以下のような記事を書く場合を考えてみましょう。

• シェルコマンドの解説記事 → cd、ls、rm、curlなどのコマンドが登場
• .htaccessの設定方法 → ファイル名「.htaccess」がそのまま登場
• PHPのセッション管理解説 → session_start()などの関数が登場
• SQLクエリの書き方 → SELECT、INSERT、WHEREなどの構文が登場
• JavaScriptの解説 → <script>タグが登場

これらは、技術記事としては当然必要な内容ですが、WAFから見ると「攻撃のためのコード入力」と区別がつかないのです。

その結果、記事を投稿・更新しようとした瞬間、WordPressからサーバーに送られるPOSTリクエスト（記事本文を含む）がWAFにブロックされ、501エラーとなります。

4. 典型的な症状パターン3選

501エラーが発生する状況は、大きく3つのパターンに分類できます。自分の状況がどれに当てはまるか確認してみてください。

パターンA：特定の記事だけ更新できない（他の記事は問題なし）

これが最も多いパターンです。

他の記事は普通に投稿・更新できるのに、特定の記事だけ501エラーになる場合、その記事本文中の特定の文字列がWAFに引っかかっている可能性が高いです。

特に、コードサンプルやコマンド例を多く含む技術記事で発生しやすい傾向があります。

確認ポイント：

• 他の記事は更新できるか？
• 問題の記事に、シェルコマンドや設定ファイル名、SQL文などが含まれていないか？

パターンB：更新・公開・プレビューのみ501（編集画面には入れる）

wp-adminの編集画面自体は開けるのに、「更新」「公開」「プレビュー」ボタンを押すと501エラーになるパターンです。

これは、編集画面を開く操作（GETリクエスト）は通るが、更新を送信する操作（POSTリクエスト）がブロックされていることを示唆しています。

WAFは主にPOST本文を検査対象としているため、このパターンはWAFによるブロックの典型的な症状です。

確認ポイント：

• 記事の内容を変えずに「更新」を押しても501になるか？
• 本文を大幅に短くすると更新できるようになるか？

パターンC：サイト全体が501（wp-adminだけでなく静的HTMLも含む）

管理画面だけでなく、サイト全体が501エラーになる場合は、より広範囲の問題が考えられます。

報告されている事例では、以下のようなケースがありました。

• 広告タグの自動最適化スクリプトがWAFに引っかかった
• 外部解析ツールのスクリプトが原因だった
• CDNやキャッシュプラグインとの相互作用

このパターンは原因が多岐にわたるため、アクセスログの確認や、最近追加した外部スクリプトの確認が必要になります。

確認ポイント：

• 最近、広告タグや解析スクリプトを追加したか？
• CDNやキャッシュ系プラグインを使用しているか？
• 完全に静的なHTMLページも501になるか？

5. 切り分け手順：最短で原因を特定する方法

501エラーの原因特定で最も重要なのは、「WAFが原因かどうか」を最初に確認することです。ここを飛ばして別の原因（プラグイン、テーマ、PHPエラーなど）を疑うと、大幅に時間をロスしてしまいます。

5-1. 最短テスト：WAFが原因かどうかの確認

以下の手順を順番に試してください。

ステップ1：別の記事で更新を試す

問題が起きている記事とは別の記事（コードを含まないシンプルな記事）の更新を試みます。

• 別の記事は更新できる → 特定の記事（その本文内容）が原因の可能性が高い
• 別の記事も更新できない → サイト全体の問題。WAF以外の原因も疑う必要あり

ステップ2：問題の記事の本文を短くして試す

問題の記事を開き、本文のコード部分をごっそり削除してから更新を試みます。

• 更新できた → 削除した部分にWAFのトリガーとなる文字列がある
• まだ更新できない → 残っている部分にもトリガーがある、または別の原因

ステップ3：WAFの「コマンド対策」をOFFにして試す

Xserverサーバーパネルにログインし、「コマンド対策」だけを一時的にOFFにしてから更新を試みます。

• コマンド対策OFFで更新できた → コマンド対策が原因でほぼ確定
• まだ更新できない → 他のWAF項目（ファイル対策、PHP対策など）も順番にOFFにして切り分け

5-2. WAF設定の反映遅延に注意（ここで詰まる人が多い）

XserverのWAF設定は、変更してもすぐには反映されないことがあります。これが原因で「設定を変えたのに直らない」と混乱する方が多いです。

5-3. キャッシュの影響を排除する

WAF設定を変更しても効果がないように見える場合、キャッシュが原因のことがあります。以下を徹底してください。

ブラウザ側のキャッシュ排除

• シークレットウィンドウ（プライベートブラウジング）で試す
• ブラウザのキャッシュを完全にクリアする
• 可能であれば、別のブラウザや別のデバイスで試す
• スマートフォンのモバイル回線など、別のネットワークから試す

WordPress・サーバー側のキャッシュ排除

• WordPress側でキャッシュ系プラグイン（WP Super Cache、W3 Total Cacheなど）を使用している場合は、一時的に無効化するか、キャッシュをパージ（削除）
• Cloudflare等のCDNを使用している場合は、CDNのキャッシュもパージ
• Xserverの「Xアクセラレータ」機能を使用している場合も注意

6. 誤検知しやすいWAF項目と”地雷ワード”一覧

技術記事でWAFに引っかかりやすい項目と、具体的な「地雷ワード」を詳しく解説します。

6-1. コマンド対策（最も誤検知が多い）

Xserverのマニュアルでは、「kill、ftp、mail、ping、ls等のコマンドに関連する文字列」を検知すると明記されています。技術記事で最も誤検知しやすい項目です。

引っかかりやすいワード・パターン

特に危険なパターン：

• cdは非常に短い文字列ですが、誤検知の報告が多い
• セミコロン;との組み合わせは、シェルのコマンド区切りと見なされやすい
• 「コピペですぐ実行できる形式」のワンライナーは特に危険

6-2. ファイル対策（.htaccess解説記事は要注意）

Xserverマニュアルでは、.htaccess、.htpasswd、httpd.confなどのサーバー設定系ファイル名を検知対象としています。

引っかかりやすいワード

• .htaccess
• .htpasswd
• httpd.conf
• php.ini（ファイル対策またはPHP対策）
• wp-config.php（場合による）

.htaccessの設定方法を解説する記事は、ファイル名自体がそのまま地雷ワードになるため、特に注意が必要です。

6-3. メール対策

「to、cc、bcc」などのメールヘッダに関連する文字列が検知対象です。

引っかかりやすい場面

• メール送信フォームの解説記事
• PHPのmail()関数の解説
• SMTPの設定方法の解説
• Contact Form 7などのプラグイン設定解説

6-4. PHP対策

「session」やファイル操作関連、危険度の高い関数等が検知対象です。

引っかかりやすいワード・関数名

• session_start()、$_SESSION
• eval()、exec()、system()、shell_exec()
• file_get_contents()、file_put_contents()
• include、require（動的パス指定時）
• preg_replace()の/e修飾子（古いPHPの脆弱性）

プラグイン開発やPHPセキュリティの解説記事で引っかかりやすい項目です。

6-5. XSS対策・SQL対策

XSS対策で引っかかりやすいワード

• <script>タグ
• javascript:スキーム
• onerror、onclick等のイベントハンドラ
• document.cookie

SQL対策で引っかかりやすいワード

• SELECT、INSERT、UPDATE、DELETE
• UNION、JOIN
• DROP TABLE、TRUNCATE
• OR 1=1、' OR ''='（典型的なSQLインジェクションパターン）

セキュリティ解説記事は”地雷の宝庫”になりやすいです。攻撃手法を解説するために、まさにWAFが検知したい文字列をそのまま掲載することになるためです。

7. 対策A：WAFの該当項目を一時OFFにする（最短復旧）

まずは最短で復旧する方法から解説します。多くの場合、WAFの「コマンド対策」を一時的にOFFにすることで更新が可能になります。

手順の全体像

1. 作業する時間を決める（できればアクセスの少ない時間帯）
2. WAFの該当項目をOFFにする
3. 反映を待つ（最大1時間）
4. 記事を更新する
5. WAFをONに戻す
6. 反映を確認する

具体的な手順

ステップ1：Xserverサーバーパネルにログイン

Xserverのサーバーパネル（https://www.xserver.ne.jp/login_server.php）にログインします。

ステップ2：WAF設定画面を開く

サーバーパネルの「セキュリティ」セクションから「WAF設定」を選択します。

ステップ3：対象ドメインを選択

WAF設定を変更したいドメインを選択します。

ステップ4：「コマンド対策」をOFFに変更

各WAF項目の一覧が表示されるので、まず「コマンド対策」のみをOFFに変更します。他の項目（XSS対策、SQL対策など）はONのままにしておきます。

ステップ5：反映を待つ

設定変更後、反映まで最大1時間程度待ちます。すぐにテストして「変わらない」と判断しないでください。

待っている間に、以下の準備をしておくとスムーズです。

• シークレットウィンドウを開いておく
• 更新したい記事の編集画面を開いておく
• キャッシュ系プラグインを一時停止しておく

ステップ6：記事を更新する

反映を待った後、シークレットウィンドウからWordPress管理画面にログインし、問題の記事を更新してみます。

更新が成功したら、すぐに次のステップに進みます。

ステップ7：WAFをONに戻す

記事の更新が完了したら、必ずWAFの設定をONに戻してください。

「コマンド対策」をONに戻し、再度反映を待ちます。

ステップ8：正常動作を確認

WAFをONに戻した後も、サイトが正常に表示されることを確認します。

この方法の注意点

• WAFをOFFにしている間はセキュリティが低下します。作業時間は最小限に抑えてください
• 同じ記事を再度編集する際は、再びこの手順が必要になります
• 頻繁に技術記事を書く場合は、後述する「対策B：コードの外出し」を検討してください

8. 対策B：コードを外出しにする（再発防止）

WAFの一時OFFは応急処置として有効ですが、技術記事を書くたびに同じ作業が必要になります。根本的な再発防止のためには、「コードを本文に直接書かない」運用が効果的です。

なぜ外出しが有効なのか

WAFが検査するのは「WordPressへ送信されるPOSTリクエストの本文」です。したがって、地雷ワードがWordPress管理画面を経由しないようにすることで、誤検知を回避できます。

具体的な外出し方法

方法1：GitHub GistやGitHubリポジトリを活用

コードサンプルをGitHub GistやGitHubリポジトリに置き、記事からはリンクや埋め込みで紹介する方法です。

メリット：

• シンタックスハイライトが自動的に適用される
• コードの更新が記事本体と独立して行える
• 読者がそのままフォーク・クローンできる
• バージョン管理ができる

記事での紹介方法：

• Gistの場合：埋め込み用スクリプトタグを使用
• リポジトリの場合：特定ファイルへのリンクを掲載

方法2：ダウンロードファイル（ZIP/TXT）として添付

長いコードや設定ファイルは、ZIPやTXT形式でダウンロードできるようにし、記事本文には要点のみを記載する方法です。

メリット：

• 記事本文がスッキリして読みやすくなる
• 読者がそのまま使えるファイルを提供できる
• 複数ファイルをまとめて配布できる

実装方法：

• WordPressのメディアライブラリにアップロード
• ダウンロードリンクを記事に挿入

方法3：画像（スクリーンショット）で提示

重要な設定内容やコマンドを、テキストではなく画像として掲載する方法です。

メリット：

• WAFに検知されない
• 実際の画面と同じ見た目で伝えられる
• コピペによる事故（間違ったコマンドの実行など）を防げる

注意点：

• 読者がコピペできないので、併用する場合は外部リンクも用意
• 画像内のテキストは検索エンジンにインデックスされにくい

方法4：PDF形式で配布

コマンド集や設定ファイルのサンプルをPDF化して添付する方法です。

メリット：

• 読み物として整理しやすい
• 印刷して参照できる
• フォーマットが崩れにくい

外出し運用のコツ

• 記事本文には「何をするコードか」の説明と、重要なポイントだけを記載
• 完全なコードは外部リソースへ誘導
• 「詳細なコードはGistをご覧ください」のように案内

この運用は、WAF対策だけでなく、記事の可読性向上にもつながります。長大なコードブロックで記事が埋め尽くされるよりも、要点を絞った解説の方が読者にとっても親切です。

9. 対策C：危険な表記を避ける（読者の安全も守る）

この対策は「WAF回避」が主目的ではなく、読者の事故防止が本来の目的です。ただし、結果的にWAFの誤検知を減らす効果もあります。

危険な”実行直結”表記を避ける

具体例：危険なコマンドの扱い

例えば、rm -rf /のような危険なコマンドを解説する場合。

避けるべき書き方：

• コマンドをそのままコピペ可能な形で掲載
• 具体的な破壊対象（ルートディレクトリなど）を完成形で表示

推奨される書き方：

• 概念説明に留める（「ルートディレクトリ以下を再帰的に削除するコマンドがある」など）
• 具体的なパスを伏せる（rm -rf [対象パス]のように）
• 警告文を併記する

ワンライナーは分割して説明

複数のコマンドを;や&&で連結したワンライナーは、WAFに引っかかりやすいだけでなく、読者が内容を理解せずにコピペ実行してしまうリスクもあります。

推奨される書き方：

• 各コマンドを分割して、1行ずつ説明を加える
• 「このコマンドは〇〇を実行します」と明記
• 実行前に確認すべきポイントを記載

セキュリティ攻撃文字列は完成形で載せない

SQLインジェクションやXSSの解説記事で、実際に動作する攻撃コードを完成形で掲載することは避けましょう。

推奨される書き方：

• 攻撃の原理を文章で説明
• 一部を伏せ字にする
• 「このパターンが含まれていたら危険」という検知ルールとして紹介

この対策は、技術ブログの社会的責任の観点からも重要です。悪意ある読者が攻撃コードをそのまま悪用することを防ぐ効果もあります。

10. 対策D：管理画面の入口を堅くする（WAF一時OFF時の防御）

WAFを一時OFFにすることに不安を感じる場合、代わりに管理画面へのアクセス自体を制限することで、セキュリティを補完できます。

IP制限をかける

管理画面（/wp-admin/やwp-login.php）へのアクセスを、特定のIPアドレスからのみに制限します。

実装方法：

• .htaccessでIP制限を設定
• Xserverのアクセス制限機能を利用
• セキュリティプラグイン（Wordfenceなど）で設定

注意点：

• 固定IPアドレスがない場合は運用が難しい
• VPN経由でのアクセスを検討する手もある

Basic認証を追加する

管理画面にアクセスする際、WordPressのログイン前にBasic認証を要求する設定です。

効果：

• 二重のパスワード保護
• ブルートフォース攻撃の軽減

注意点：

• admin-ajax.phpを使う機能（コメント投稿など）に影響する可能性
• 設定によってはサイト表示に影響することも

二要素認証（2FA）を導入する

WordPressのログインに二要素認証を追加します。Google Authenticatorなどのアプリを使用します。

代表的なプラグイン：

• Google Authenticator
• Wordfence Security
• Two Factor Authentication

不要な管理者アカウントを削除する

使用していない管理者アカウントは削除し、攻撃対象を減らします。特に「admin」という名前のアカウントは標的になりやすいため、別の名前に変更することを推奨します。

ログインURLを変更する

wp-login.phpや/wp-admin/といった標準のログインURLを、独自のURLに変更する方法です。

代表的なプラグイン：

• WPS Hide Login
• All In One WP Security & Firewall

注意点：

• 変更後のURLを忘れるとログインできなくなる
• 一部のプラグインと干渉する可能性

これらの対策を組み合わせることで、「WAFを一時OFFにしている間」のセキュリティリスクを最小限に抑えることができます。

11. それでも直らない場合のトラブルシューティング

WAFの設定変更を試しても501エラーが解消しない場合は、以下のポイントを確認してください。

11-1. アクセスログで詳細を確認する

Xserverではアクセスログを確認できます。エラーが発生した時刻とURLを特定することで、原因究明の手がかりになります。

確認手順

1. サーバーパネル → 「アクセス解析」または「ログファイル」
2. 対象ドメインを選択
3. エラーが発生した日時のログを確認

確認ポイント

• エラー発生時刻のリクエストURL（/wp-admin/post.phpやadmin-ajax.phpなど）
• HTTPステータスコード（501で記録されているか）
• リクエスト元IP（自分のIPか確認）

11-2. WordPress側のデバッグログを確認する

WAFでブロックされている場合、WordPress側にはエラーログが残らないことが多いですが、別の原因（PHPエラーなど）との切り分けのために確認する価値はあります。

デバッグログの有効化方法

wp-config.phpに以下を追記（または修正）します。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

これにより、/wp-content/debug.logにエラーログが記録されます。

確認結果の解釈

• debug.logにエラーが記録されていない → WAFによるブロックの可能性が高い
• PHPエラーが記録されている → WAF以外の原因（プラグイン、テーマ、PHP構文エラーなど）を疑う

11-3. 外部スクリプト（広告・解析）が原因の可能性

記事本文以外に、サイト全体に埋め込まれているスクリプトがWAFに引っかかっている可能性もあります。

確認すべき項目

• 最近追加した広告タグ（Google AdSense、アフィリエイトタグなど）
• 解析ツール（Google Analytics、ヒートマップツールなど）
• チャットボット、ポップアップ系のスクリプト
• CDN（Cloudflare等）の設定

切り分け方法

1. 問題のスクリプトを一時的に無効化
2. 501エラーが解消するか確認
3. 解消した場合、そのスクリプトが原因

11-4. ステージング環境でテストする

本番環境での切り分けが難しい場合、ステージング（テスト）環境を用意してテストすることをおすすめします。

XserverではサブドメインやLocal by Flywheel等を使って、本番と同じ構成のテスト環境を作ることができます。

12. サポートへの相談テンプレート

上記の対策を試しても解決しない場合は、Xserverサポートに相談することを検討してください。以下のテンプレートを参考にしてください。

ポイント：

• 「WAF誤検知」という仮説を明示する
• 自分で試したこと（コマンド対策OFFで改善など）を伝える
• 発生日時を具体的に記載する（ログ調査に必要）
• 「URI単位での除外」など、希望する解決策を提案する

13. 再発防止チェックリスト

以下のチェックリストを参考に、501エラーからの復旧と再発防止を進めてください。

「まず復旧」のための最短チェックリスト

• ☐ 別の記事は更新できるか確認した
• ☐ 問題の記事のコード部分を削ると更新できるか確認した
• ☐ WAF「コマンド対策」をOFFにして反映を待った（最大1時間）
• ☐ キャッシュを排除した（シークレットウィンドウ、プラグイン停止など）
• ☐ 記事の更新が成功した
• ☐ WAFをONに戻した

「再発させない」ための運用チェックリスト

• ☐ 長いコードは外出し（GitHub Gist、添付ファイル、PDF）にした
• ☐ 危険なコマンドの完成形は本文に置かない運用にした
• ☐ ステージング環境で記事を整えてから本番にアップする運用にした
• ☐ 管理画面のセキュリティを強化した（2FA、IP制限、Basic認証など）
• ☐ エラー発生時のアクセスログ確認方法を把握した

14. 参考情報・出典

この記事の作成にあたり、以下の情報を参考にしました。

公式ドキュメント

• Xserver マニュアル：WAF設定
  
  WAF設定 | レンタルサーバーならエックスサーバー

  レンタルサーバー「エックスサーバー」のご利用マニュアル｜サーバーのWAFに関する設定を記載しています。

  www.xserver.ne.jp
• Xserver マニュアル：アクセスログ
  
  アクセスログ | レンタルサーバーならエックスサーバー

  レンタルサーバー「エックスサーバー」のご利用マニュアル｜「アクセスログ」の形式や確認手順に関するご案内です。エックスサーバーではアクセスログをサーバーパネルから簡単に閲覧することが可能です。

  www.xserver.ne.jp
• HTTP Semantics (RFC 9110) – 501 Not Implementedの定義
  https://www.rfc-editor.org/rfc/rfc9110.html
  
  RFC 9110: HTTP Semantics

  The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hyperte...

  datatracker.ietf.org

参考事例

• Xserverでサイトが丸ごと501（WAF誤検知・反映遅延・キャッシュの注意点）
  
  Xserverでサイトが丸ごと501になった話 ― WAF誤検知と広告自動テストの落とし穴 | Bit 有限会社ビーアイティー

  XserverでWordPressが501エラーに。静的HTMLも落ち、ログは空。キャッシュやWAF反映遅延に惑わされながら原因を追究した結果、Google広告テストとWAF誤検知が判明。

  bit.gr.jp
• WordPressプレビューで501（コマンド対策が原因、反映に最大1時間）
  
  WordPressの「変更をプレビュー」ボタンを押した後に501エラーが表示される

  WordPressの編集画面にある「変更をプレビュー」ボタンを押した後に501エラーが出てしまうと相談があったのでググったメモ。 症状：記事のプレビューページを表示しようとしてリダイレクトする このエ

  immature.01kawa.com
• 投稿本文の特定文字列で501（コマンド対策・ファイル対策など）
  
  Xserverで501 Not Implementedエラーを避けるWAF設定

  当Webサイトのこのワードプレスで 501 Not Implemented という見かけないエラーが発生し、公開・下書きとして保存・更新・プレビューの表示ができなくなった。 原因は利用しているレンタルサーバーのXserver（エックスサーバ

  henteko.net

15. まとめ

WordPressでコード付きの記事を投稿・更新しようとしたときに発生する501 Not Implementedエラーは、多くの場合XserverのWAF（Web Application Firewall）が記事本文を攻撃と誤認してブロックしていることが原因です。

覚えておくべきポイント

1. 501エラー ≠ あなたが変なことをした
   WordPressの正常なPOSTリクエストがWAFにブロックされた結果です
2. 最も多い原因は「コマンド対策」
   シェルコマンドを解説する記事で頻発します
3. WAF設定の反映には最大1時間かかる
   設定変更後すぐにテストして「直らない」と判断しないでください
4. キャッシュの影響を必ず排除する
   シークレットウィンドウ、キャッシュプラグイン停止、CDNパージを忘れずに

推奨する対応フロー

1. 緊急対応：WAFの「コマンド対策」を一時OFFにして記事を更新し、すぐにONに戻す
2. 恒久対策：コードを外出し（GitHub Gist、添付ファイルなど）する運用に切り替える
3. 防御強化：WAF一時OFF時のリスクに備えて、管理画面のセキュリティを強化しておく

この2〜3段構えの対策で、501エラーに悩まされることなく、安全に技術ブログを運営できるようになります。

技術ブログを書いている方にとって、「記事を書いたのに公開できない」というのは本当にストレスフルな状況です。この記事が、同じ問題で困っている方の助けになれば幸いです。