WordPressのブロックエディターで記事を保存・更新・公開しようとしたとき、「更新に失敗しました。返答が正しいJSONレスポンスではありません」と表示されることがあります。このエラーは、記事本文が壊れたという意味ではありません。エディターがWordPressへ保存を依頼したものの、期待していたJSON形式の応答を受け取れなかった状態です。
原因は一つではありません。WordPress URLやHTTPSの不一致、REST APIの404・403・500、WAF、リダイレクト、プラグインの余分な出力、PHPエラー、サーバー負荷などで、JSONの代わりにHTMLのエラーページや別URLへの転送が返ると発生します。
エラーが出た直後に画面を閉じたり、更新ボタンを連打したりしないでください。まず編集中の内容を別の安全な場所へコピーし、実際に保存されているかを確認します。
この記事では、記事を失わない初動から、ブラウザで失敗した応答を確認し、原因別に安全に復旧する順番を解説します。
先に結論：JSONレスポンスエラーは8段階で確認する
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | 編集中の内容を退避する | 調査中の文章消失を防ぐ |
| 2 | 別画面で保存結果・リビジョンを確認 | 表示だけ失敗したのかを分ける |
| 3 | 簡単な新規下書きで再現範囲を比較 | 特定記事・特定ブロックか全体かを分ける |
| 4 | サイトヘルスとREST APIを確認 | WordPressが検知した通信問題を見る |
| 5 | ブラウザで応答URL・ステータス・内容を確認 | 403・404・500・転送・HTML混入を特定する |
| 6 | URL・HTTPS・パーマリンクを照合 | 保存先の経路不整合を直す |
| 7 | WAF・プラグイン・テーマ・サーバーを対象限定で確認 | JSONを壊した処理を絞る |
| 8 | 復旧後に保存・公開・画像・予約投稿を再確認 | 一部機能だけ残る障害を防ぐ |
WordPress公式のREST API Handbookは、REST APIがJSONデータを送受信し、ブロックエディターの基盤になっていると説明しています。またREST API Referenceでは、正常時だけでなくエラー応答もJSON形式を使うとされています。そのため、HTML、空の応答、転送先の画面などが返れば、エディターは正しいJSONとして処理できません。
このエラーで最初に知っておきたいこと
| 状況 | 考えられること | 最初の行動 |
|---|---|---|
| エラー後も別タブで記事が更新済み | 保存は成功したが応答の受信・解析に失敗 | リビジョンと公開状態を確認して連打しない |
| 特定記事だけ失敗 | 特定ブロック、埋め込み、メタ情報、URL規則 | 簡単な下書きと比較する |
| 全記事で保存できない | REST API、URL、認証、WAF、サーバー障害 | サイトヘルスとNetworkを確認する |
| 画像追加だけ失敗 | メディアAPI、容量、画像処理、権限 | 既知の小さな画像で比較する |
| ログインし直すと一時的に直る | Cookie、nonce、セッション、キャッシュ | 時刻と再発条件を記録する |
| 403・404・500も確認できる | アクセス拒否、経路不明、サーバー処理失敗 | ステータス別の原因へ分岐する |
「正しいJSONではない」は原因名ではなく、エディター側から見た結果です。パーマリンク再保存、キャッシュ削除、プラグイン停止のどれかを無条件で繰り返すのではなく、実際の応答を確認すると修正先を絞れます。
手順1：編集中の内容を失わないよう退避する
エラーが出ても、まず編集画面を閉じません。ブロックエディターのオプションからコードエディター表示へ切り替えて内容をコピーする、または各ブロックの文章と画像情報を安全なローカル文書へ控えます。機密情報を含む記事をオンラインの共有サービスへ貼らないでください。
別タブで投稿一覧やプレビューを開き、更新時刻、下書き・公開状態、リビジョンを確認します。保存要求がサーバーへ届き、記事は更新されたものの、応答だけが壊れた場合があります。更新済みなら同じ操作を連打せず、退避した内容と保存内容を比較します。
内容を退避する前に、再読み込み、ログアウト、ブラウザ終了をしないでください。自動保存が成功していない場合、最後の変更を失う可能性があります。
手順2：簡単な新規下書きで発生範囲を分ける
本文を退避したら、タイトルと短い段落だけの新規下書きを作り、一度だけ保存します。これが保存できるなら、元の記事固有のブロック、埋め込み、カスタムフィールド、アイキャッチ、URL、プラグイン機能が候補です。新規下書きも失敗するなら、REST API、認証、URL、WAF、サーバーなど共通経路を優先します。
特定ブロックを追加したときだけ失敗する
外部埋め込み、カスタムHTML、フォーム、再利用ブロック、プラグイン独自ブロックを追加した直後なら、複製した下書きでそのブロックだけを外して比較します。本番記事からいきなり削除せず、退避とリビジョンを確保してください。「ブロックにエラーが含まれています」という表示は、保存応答のJSONエラーとは別のブロック検証問題の場合があります。
画像追加・アイキャッチだけ失敗する
小さな既知のJPEGまたはPNGで一度比較し、ファイル固有か、すべてのアップロードかを分けます。容量、ファイル形式、画像処理、権限の確認はWordPress画像アップロードエラーの直し方へ進んでください。
手順3：サイトヘルスでREST APIの状態を確認する
WordPress管理画面の「ツール」→「サイトヘルス」で、重大な問題、おすすめの改善、REST API、ループバック、HTTPSを確認します。WordPress公式のSite Health screenは、サイトURL、HTTPS、サーバー、プラグインなどの情報を確認できる場所です。
警告文は省略せず、テスト名、エラーコード、対象URLを記録します。サイトヘルスの点数や警告を消すこと自体を目的にせず、保存失敗と同じ時刻・経路かを照合します。読み方はWordPressサイトヘルスの警告を直す順番で詳しく説明しています。
WordPress公式のREST API Frequently Asked Questionsは、REST APIを無効化すると、APIに依存するWordPress管理機能が壊れると注意しています。
エラー回避のためにREST API全体を無効化したり、認証なしで全面公開したりしないでください。エディターやプラグイン機能を壊すか、非公開データの保護を弱める可能性があります。
手順4：ブラウザで失敗した応答を確認する
原因を絞るには、ブラウザの開発者ツールで保存時の通信を確認します。ChromeではNetworkパネルを開き、記録を消してから保存を一度だけ実行します。wp-jsonを含むリクエストや赤く失敗したリクエストを選び、Request URL、Status、Response、Locationを確認します。Chrome公式のNetwork features referenceで基本操作を確認できます。
| 確認できた応答 | 意味の目安 | 次に見る場所 |
|---|---|---|
| 301・302や別URL | 保存先が転送されている | WordPress URL、HTTPS、リダイレクト |
| 401・403 | 認証切れ、権限、WAF・アクセス制限 | 再ログイン、ユーザー権限、防御ログ |
| 404 | REST APIの経路が見つからない | URL、パーマリンク、Webサーバー書き換え |
| 500・502・503 | PHP・サーバー・上流処理の失敗 | サーバーとPHPのエラーログ |
| 200だがHTML | ログイン画面、警告、メンテナンス画面などが混入 | Response先頭、転送、PHP出力 |
| 空・途中で切れている | 通信中断、タイムアウト、処理停止 | サーバー負荷、ログ、外部通信 |
401・403ならWordPressの403 Forbiddenを直す確認順、404ならWordPressの404エラーを直す手順、500なら500 Internal Server Errorの復旧手順を参照してください。転送が繰り返されていればリダイレクトループの直し方が対象です。
Responseにはサーバーパス、ユーザー情報、セキュリティ製品名が含まれる場合があります。スクリーンショットやログを公開SNSへ貼らず、必要箇所だけを伏せて公式サポートへ共有します。
手順5：WordPress URLとHTTPSを照合する
「設定」→「一般」のWordPressアドレスとサイトアドレスが、実際に開いている管理画面のドメイン・HTTPSと一致しているかを確認します。WordPress公式のSettings General screenでは、WordPress本体の場所と訪問者向けアドレスの役割が分けられています。
HTTPとHTTPS、www有無、サブディレクトリが食い違うと、エディターの保存要求が別オリジンや転送先へ向かい、Cookieや認証が正しく使えない場合があります。SSL化直後はWordPressのMixed Contentを直す手順も確認します。ただし、Mixed Contentの警告とREST API保存失敗は同じ原因とは限りません。
現在値と設置場所を確認せず、WordPress URLを推測で変更しないでください。管理画面へ入れなくなったり、公開ページが別URLへ転送されたりする可能性があります。
手順6：パーマリンクとREST APIの経路を確認する
REST APIのURLが404になる場合は、WordPressのパーマリンクとWebサーバーの書き換え規則を確認します。WordPress公式のREST API Key Conceptsは、通常のwp-json経路と、基本形式のパーマリンクで使うrest_route経路を説明しています。
管理画面へ入れる場合、「設定」→「パーマリンク」で現在の構造を記録し、構造を変更せずに保存して書き換え規則を更新する方法があります。しかし、これが有効なのは経路や規則が原因の場合です。WAF、URL不整合、PHPエラー、プラグイン出力は直りません。
パーマリンク構造そのものを別形式へ変えたり、.htaccessを確認せず削除したりしないでください。既存記事のURLが変わり、404や検索流入低下を招くおそれがあります。パーマリンクの基本はWordPress公式Customize permalinksで確認できます。
手順7：WAF・セキュリティ・キャッシュを確認する
Networkで403、チャレンジ画面、アクセス拒否のHTMLが返る場合は、WAF、CDN、セキュリティプラグイン、Basic認証、IP制限が保存要求を遮断していないか確認します。エラーが出た時刻、対象URL、操作、拒否ルールを照合し、原因となった規則だけを調整します。
キャッシュがREST APIやログイン済み管理画面の応答を保存すると、別利用者向けの画面や古いHTMLが返ることがあります。管理画面・REST API・ログインCookieをキャッシュ対象から除外する設定を、利用中サービスの公式手順で確認します。キャッシュ削除の順番はWordPressキャッシュ設定の基本を参照してください。
防御機能を全停止したまま公開運用するのは避けます。日常の基本設定はWordPressセキュリティ設定の基本に沿い、例外を追加するときもURL・操作・利用者を必要最小限にします。
手順8：プラグイン・テーマ・PHP出力を確認する
REST APIはJSONだけを返す必要があります。プラグインやテーマが警告文、デバッグ文字、空白、HTMLを出力すると、HTTPステータスが200でもJSONとして読めないことがあります。Responseの先頭にPHP Warning、HTMLタグ、ログイン画面などがあれば、同時刻のPHP・サーバーログを確認します。
WordPress公式のDebugging in WordPressを参考に、ログへの記録と公開画面への表示を分けます。Display Errorsも、本番サイトでエラーを訪問者へ表示しないよう案内しています。
直前に更新・有効化・設定変更したプラグインがある場合は、対象だけをテスト環境または安全な方法で停止して比較します。全プラグインを無記録で停止すると、フォーム、防御、キャッシュ、計測が同時に止まり、別の問題を増やします。整理方法はWordPressプラグインを安全に整理する手順を参照してください。
500、タイムアウト、空の応答なら、PHPの致命的エラー、メモリ、実行時間、ディスク容量、サーバー負荷を確認します。PHP変更直後ならWordPressのPHPバージョンを安全に更新する方法も照合し、互換性と切り戻しを優先します。
復旧後に確認する10項目
- 短い新規下書きを保存できる
- 問題が出た記事を更新できる
- 別タブで更新時刻と内容が一致する
- プレビューと公開ページが正常
- 画像追加とアイキャッチ設定ができる
- カテゴリー、タグ、メタ情報を保存できる
- 予約投稿と公開状態を変更できる
- サイトヘルスのREST API警告が解消または原因確認済み
- Networkで保存応答がJSONになっている
- PHP・サーバーログに同じエラーが増えていない
ブロックエディターだけでなく、画像、予約投稿、プラグイン設定など、REST APIを使う重要機能も確認します。大きな更新や原因プラグインの再有効化は、WordPressのテスト環境で再現してから本番へ反映すると安全です。
自分で直せないときにサポートへ伝える情報
- エラー全文と発生日時
- 投稿・固定ページ・画像など失敗した操作
- 特定記事だけか全記事か
- Networkで確認したRequest URLとHTTPステータス
- ResponseがJSON、HTML、空、転送のどれだったか
- サイトヘルスのREST API警告全文
- 直前に行った更新、SSL化、移行、WAF・CDN変更
- WordPress・PHP・使用テーマのバージョン
- エラーログの該当部分と実施済みの対処
記事本文、Cookie、nonce、認証ヘッダー、パスワード、APIキーを公開しないでください。Networkの「Copy as cURL」には認証情報が含まれる場合があるため、そのままSNSや公開フォーラムへ貼らず、公式サポートが指定する方法で必要部分だけを共有します。
再発を防ぐ運用
- 更新前に記事内容とサイト全体のバックアップを確保する
- WordPress URL・HTTPS・正規ドメインを記録する
- WAFやCDNの変更日時と担当機能を残す
- プラグイン・テーマ・PHPを一度に更新しない
- 本番画面へPHP警告を表示しない
- 管理画面とREST APIをページキャッシュから除外する
- 更新後に下書き保存、画像追加、予約投稿を試す
- サイトヘルスとエラーログを定期確認する
変更前のバックアップはWordPressバックアップの取り方、本体・テーマ・プラグインの更新順はWordPressを安全に更新する方法もあわせて確認してください。
よくある質問
パーマリンクを再保存すれば必ず直りますか？
REST APIの経路や書き換え規則が原因なら直る場合がありますが、403、500、URL不整合、WAF、プラグイン出力には効きません。Networkのステータスと応答を確認し、404や経路問題がある場合に限定して検討します。
クラシックエディターへ変えれば解決しますか？
一時的に記事を編集できる場合はありますが、REST API、WAF、URL、サーバーの問題は残ります。プラグイン設定やサイトヘルスなど別機能で再発する可能性があるため、回避策と根本修正を分けて考えてください。
エラーが出ても記事が保存されているのはなぜですか？
サーバー側の保存処理は完了したものの、その後の応答へ警告やHTMLが混ざった、通信が切れた、ブラウザが解析できなかった可能性があります。別タブで更新時刻とリビジョンを確認し、保存ボタンを連打しないでください。
REST APIを無効にすれば安全ですか？
無効化するとブロックエディターなどWordPress管理機能が壊れます。安全性は、認証・権限・WAFを適切に設定し、非公開データを保護することで確保します。エラーを消すための全面無効化は行わないでください。
特定の記事だけ失敗するときは削除すべきですか？
削除する前に内容を退避し、複製した下書きで特定ブロック、埋め込み、メタ情報を外して比較します。記事自体ではなく、特定URLに対するWAF・転送規則が原因の場合もあります。
まとめ
「返答が正しいJSONレスポンスではありません」は、WordPressの保存要求に対して、エディターが期待したJSONを受け取れなかった結果です。最初に本文を退避し、保存結果と再現範囲を確認してから、サイトヘルスとNetworkで実際のURL・ステータス・応答内容を調べます。
301・302なら転送、403なら防御、404なら経路、500ならPHP・サーバーというように分岐すれば、不要な一括変更を避けられます。復旧後は下書き保存だけでなく、画像、公開、予約投稿、REST API、ログまで確認して完了です。