WordPressで投稿や固定ページ、サイトエディターの内容を保存したときに、次のエラーが出ることがあります。
更新に失敗しました。返答が正しい JSON レスポンスではありません。このメッセージだけでは原因は特定できません。WordPressがREST APIへ送ったリクエストに対して、JSONではなく403のHTML、ログイン画面、WAFの拒否画面などが返ったときにも同じ表示になるためです。
この記事では、最初にレスポンスを確認し、WAF・認証・URL設定・パーマリンクのどこに原因があるかを順番に切り分けます。
最初に確認すること
ブラウザの開発者ツールを開き、保存操作をもう一度実行します。
- F12キーで開発者ツールを開く
- 「Network」を選ぶ
- WordPressで保存を実行する
- 赤く表示された
wp-jsonまたは?rest_route=のリクエストを開く - Status、Request URL、Responseを確認する
特に重要なのは、HTTPステータスとレスポンス本文です。
| 確認結果 | 疑う原因 | 次に行うこと |
|---|---|---|
| 403とWAF・ForbiddenのHTML | サーバーWAFまたはセキュリティ機能 | WAFログで同時刻の検知を確認 |
| 401またはログイン画面 | 認証切れ、Nonce、Cookie | 再ログインとキャッシュ削除 |
| 404 | REST API URL、パーマリンク、リライトルール | パーマリンク設定を再保存 |
| 500 | PHPエラー、テーマ、プラグイン | WordPressデバッグログを確認 |
| 200だがHTML | キャッシュがREST APIへ誤ったページを返している | REST APIをキャッシュ対象外にする |
403でWAFの拒否画面が返る場合
保存時のリクエストが403で、レスポンスに「Forbidden」「閲覧できません」「WAF」などが含まれる場合、WordPressより前段のセキュリティ機能がREST APIを遮断している可能性があります。
ブロックエディターやサイトエディターは、ブロック設定やスタイルをJSONとして送信します。正常なJSONでも、文字列の組み合わせによってWAFがスクリプトやSQL攻撃と誤判定することがあります。
WAFログで照合する
- レンタルサーバーの管理画面でWAFログを開く
- 保存に失敗した時刻と一致する検知を探す
- 対象URLと検知ルールを記録する
- 同じ操作を再現し、毎回同じルールで止まるか確認する
ログを確認せず、WAF全体を無効化するのは避けます。まず対象URLと検知ルールを限定してください。
除外設定は最小範囲にする
WAF除外が必要な場合も、サイト全体や /wp-json/* 全体ではなく、実際に拒否された管理用エンドポイントへ範囲を限定します。除外後は、保存できることとWAFログに新たな異常がないことを確認します。
また、WordPressは /wp-json/... 形式だけでなく、?rest_route=/... 形式でREST APIへアクセスする場合があります。サーバーやキャッシュ側で除外を設定するときは、実際のRequest URLを基準にします。
403でもWAF以外が原因になるケース
ログイン状態やNonceの期限切れ
長時間エディターを開いたままにすると、認証情報が期限切れになることがあります。一度内容を退避し、WordPressへ再ログインしてから保存を試します。
セキュリティプラグインの制限
SiteGuardなどのセキュリティプラグインがREST APIや管理画面へのアクセスを制限している場合があります。設定を無条件に無効化せず、拒否ログ、対象URL、ユーザー権限を確認します。
キャッシュがHTMLを返している
HTTPステータスが200でも、ResponseがJSONではなくサイトのHTMLになっていることがあります。この場合はページキャッシュやCDNがREST APIを通常ページとして処理している可能性があります。キャッシュ除外は wp-json だけでなく、rest_route= を含むリクエストも対象になるか確認します。
404の場合に確認すること
- WordPress管理画面の「設定」→「パーマリンク」を開く
- 設定を変えずに「変更を保存」を押す
- サイトURLとWordPressアドレスに不一致がないか確認する
- リバースプロキシやサブディレクトリ構成の場合はREST APIの転送先を確認する
URL変更時の確認項目は、WordPressのURL変更にもまとめています。
500の場合に確認すること
500はPHP側で処理に失敗している可能性があります。WordPressのデバッグログ、サーバーのPHPエラーログ、直前に変更したテーマやプラグインを確認します。
本番環境で画面へエラーを直接表示するのではなく、ログへ記録して調査します。プラグインを停止する場合も、バックアップと影響範囲の確認を先に行います。
安全な切り分け順
- 編集内容を別の場所へ退避する
- Networkで失敗リクエストのStatusとResponseを確認する
- 403なら同時刻のWAF・セキュリティログを確認する
- 401なら再ログイン、404ならパーマリンク、500ならPHPログを確認する
- 変更は最小範囲で行い、保存後に元へ戻せるよう記録する
- 修正後、投稿・固定ページ・サイトエディターで再現確認する
よくある質問
WAFをすべて無効にすれば直りますか？
直る場合はありますが、推奨しません。まずログでWAFが原因だと確認し、必要なエンドポイントまたは検知ルールだけを限定的に除外します。
プラグインを全部停止する必要がありますか？
最初から全停止する必要はありません。HTTPステータスとレスポンスを確認すれば、WAF、認証、URL、PHPエラーのどこを調べるべきか絞れます。
「正しいJSONレスポンスではありません」はJSONの書き方の問題ですか？
必ずしもそうではありません。WordPressがJSONを期待しているのに、403の拒否画面など別形式のレスポンスを受け取った場合にも表示されます。
まとめ
「返答が正しいJSONレスポンスではありません」は原因名ではなく、REST APIから期待したJSONが返らなかったことを示すメッセージです。最短の調査方法は、NetworkでStatusとResponseを確認することです。
- 403＋拒否HTML：WAFまたはセキュリティ機能
- 401：認証・Nonce
- 404：URL・パーマリンク
- 500：PHPエラー
- 200＋HTML：キャッシュ設定
WAFが原因の場合は、ログで証拠を確認し、除外範囲を必要最小限にすることが重要です。
