WordPress のブロックエディタで記事を保存した時に、「返答が正しい JSON レスポンスではありません」と表示されることがあります。このエラーは、WordPress が期待した JSON を受け取れなかった時に出ます。
重要なのは、これは必ずしも WordPress 本体の不具合ではないということです。REST API の応答に WAF の 403 ページ、PHP の警告、HTML のエラーページ、リバースプロキシの応答などが混ざると、エディタ側では JSON として解釈できず、このエラーになります。
このエラーの意味
Gutenberg は、記事の保存やプレビュー、ブロックの処理で WordPress REST API を使います。REST API は JSON を返す前提ですが、途中で別の応答に置き換わると、ブラウザ側では「正しい JSON ではない」と見えます。
| 実際に起きていること | 見え方 |
|---|---|
| WAF が REST API リクエストを拒否する | 403 HTML ページが返り、JSON として読めない |
| PHP warning / notice が混ざる | JSON の前後に文字列が入り、構文エラーになる |
| rewrite やパーマリンクが崩れる | REST API エンドポイントに正しく届かない |
| HTTPS / サイト URL がずれる | リダイレクトや mixed content で失敗する |
| リバースプロキシやキャッシュが介入する | 想定外の HTML や古い応答が返る |
したがって、まず確認するべきなのは、エディタが呼び出している REST API に何が返っているかです。
まず REST API が生きているか確認する
WordPress の REST API 自体が応答しているかを確認します。ブラウザで開いてもよいですが、サーバー側や手元から curl で確認すると、ステータスコードと Content-Type を見やすくなります。
コマンド
curl -I https://www.example.com/wp-json/
curl -s https://www.example.com/wp-json/ | head
curl -I https://www.example.com/wp-json/wp/v2/postsContent-Type が application/json になっているか、ステータスコードが 200 系かを確認します。403、404、500、HTML のログインページ、WAF の拒否ページが返っている場合は、WordPress エディタ側では JSON として扱えません。
ブラウザの開発者ツールで失敗したリクエストを見る
保存時のエラーは、ブラウザの開発者ツールで見るのが早いです。Network タブを開き、保存時に失敗している wp-json へのリクエストを確認します。
- Request URL がどの REST API エンドポイントか
- Status Code が 200、403、404、500 のどれか
- Response Headers の Content-Type が JSON か
- Response Body に WAF の HTML、PHP warning、ログイン画面が混ざっていないか
- Request Payload に WAF が反応しそうな文字列が含まれていないか
ここで実際の応答を見ると、WordPress の問題なのか、WAF / PHP / Proxy の問題なのかがかなり絞れます。
WAF / ModSecurity を確認する
WordPress の記事保存では、本文 HTML、コードブロック、URL、コマンド、SQL 風の文字列、シェル記号などが REST API のリクエスト本文に含まれます。ModSecurity や OWASP CRS は、これらを攻撃パターンと誤判定することがあります。
WAF が原因の場合、WordPress 側では JSON エラーに見えますが、実際には WAF が 403 を返しています。まず audit log を確認し、どのルール ID がどのパラメータに反応したかを見ます。
コマンド
grep -i "ModSecurity" /var/log/apache2/error.log
grep -i "Access denied" /var/log/apache2/modsec_audit.log
grep -i "wp-json" /var/log/apache2/modsec_audit.log例外を作る場合は、WordPress 全体や REST API 全体を広く除外するのではなく、対象 URL、対象ルール、対象パラメータをできるだけ狭くします。WAF を無効化すると保存は通るかもしれませんが、原因の特定にはなりません。
PHP エラーが JSON に混ざっていないか確認する
PHP の warning、notice、deprecated message が REST API の出力に混ざると、JSON として壊れます。画面上では分かりにくいですが、レスポンス本文を見ると JSON の前後に PHP のメッセージが入っていることがあります。
コマンド
grep -i "PHP Warning" /var/log/apache2/error.log
grep -i "PHP Notice" /var/log/apache2/error.log
grep -i "PHP Deprecated" /var/log/apache2/error.log本番環境では、PHP エラーを画面やレスポンスに直接出さず、ログへ出す設定にしておく方が安全です。REST API の JSON 応答にエラー文字列が混ざると、エディタやプラグインが予期しない失敗をします。
パーマリンクと rewrite を確認する
REST API は /wp-json/ を使います。パーマリンク設定や rewrite が崩れていると、REST API へのルーティングが失敗し、404 や HTML ページが返ることがあります。
確認すること
/wp-json/がブラウザで開けるか- パーマリンク設定を保存し直すと改善するか
- Apache の
.htaccessや Nginx の rewrite が正しいか - リバースプロキシで
/wp-json/が別扱いされていないか
HTTPS とサイト URL の不整合を確認する
WordPress アドレス、サイトアドレス、リバースプロキシの TLS 終端、X-Forwarded-Proto がずれていると、REST API が意図しない URL へ向いたり、リダイレクトが発生したりします。
コマンド
wp option get siteurl
wp option get home
curl -I https://www.example.com/wp-json/Kubernetes やリバースプロキシ構成では、WordPress から見た URL と外部公開 URL がずれやすくなります。HTTPS で公開しているのに WordPress 側が HTTP と認識している場合、REST API 周りの挙動が不安定になることがあります。
リバースプロキシとキャッシュを確認する
WordPress の前段に Nginx、Apache、CDN、キャッシュ、WAF がある場合、REST API の応答が途中で変えられていないかを確認します。特に、POST リクエストや認証付き REST API をキャッシュ対象にしてはいけません。
- REST API の POST が前段で拒否されていないか
- Cookie や Authorization ヘッダーが落ちていないか
- キャッシュが JSON ではなく HTML を返していないか
- アップロードサイズやリクエストボディサイズの制限に当たっていないか
対処方針
対処は、原因ごとに分けます。JSON エラーという表示だけで、WordPress を再インストールしたり、プラグインを闇雲に無効化したりするのは遠回りです。
| 原因 | 対処方針 |
|---|---|
| WAF / ModSecurity | audit log を見て、ルールと対象パラメータを狭く例外化する |
| PHP エラー混入 | エラー表示を止め、原因プラグインやテーマを修正する |
| rewrite / パーマリンク | パーマリンク再保存、Web サーバー設定確認 |
| HTTPS / URL 不整合 | siteurl / home、proxy header、TLS 終端を整える |
| リバースプロキシ / キャッシュ | REST API の POST と認証付き通信を正しく通す |
参考書籍
書籍
ModSecurity / WAF のルール、検知、例外設計を深く確認したい場合の参考書籍です。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連する記事
WordPress 更新や REST API リクエストに WAF が反応する場合の考え方です。
WordPress の外部通信を、Pod、Node、DNS、Proxy、Firewall の層で確認する記事です。
Apache と ModSecurity / OWASP CRS を使う場合の基本設定です。
まとめ
WordPress の「返答が正しい JSON レスポンスではありません」は、REST API が期待通りの JSON を返せなかった時に出るエラーです。原因は WordPress 本体だけではなく、WAF、PHP エラー、rewrite、HTTPS、リバースプロキシ、キャッシュなどにあります。
まずブラウザの開発者ツールで失敗している wp-json リクエストを確認し、実際に返っているステータスコードとレスポンス本文を見るのが近道です。
特に WAF / ModSecurity を使っている環境では、REST API の本文がルールに反応することがあります。広く無効化するのではなく、audit log を見て狭く例外を作るのが安全です。
関連記事
WordPress 更新後に ModSecurity が反応する理由 – WAF の偽陽性と例外設計を見る
WordPress が wordpress.org に接続できない時の切り分け – DNS / Proxy / Firewall / Kubernetes を確認する
コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける
WordPress のサイトマップが生成されない原因 – パーマリンクと URL 設計を確認する
WordPress のパーマリンク変更手順 – 旧 URL を守るリダイレクト設計
WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える
WordPress のメール送信が遅い原因 – sendmail / Postfix / DNS の待ち時間を切り分ける
WordPress で GA4 を使う理由 – アクセス解析を記事改善に活かす