WordPressで「更新に失敗しました。オフラインのようです」と出る原因と保存確認

WordPressのブロックエディターで「更新に失敗しました。オフラインのようです」と表示されたら、最初に行うべきことは再読み込みではありません。編集中の内容を別の場所へ退避し、保存通信がどこで止まったのかを順番に確認するのが正解です。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。保存エラーの対応では、原因探しより先に未保存の原稿を守ることを徹底しています。

この表示は、必ずしもパソコン全体がインターネットから切断されたという意味ではありません。WordPressが投稿を保存するために送った通信へ正常な応答が戻らず、エディターがオフライン相当と判断した時にも表示されます。

そのため、Wi-Fiだけを確認して終わると原因を見落とします。一方で、いきなりプラグインを停止したりサーバー設定を変更したりすると、別の不具合を増やす恐れがあります。この記事では、編集内容を守りながら影響の小さい確認から進めます。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPress「オフラインのようです」の意味

「オフラインのようです」は、ブロックエディターからWordPressへの保存リクエストが正常に完了しなかったことを示す通知です。原因は端末の回線断だけでなく、REST APIの拒否、応答の破損、タイムアウト、ブラウザ側の遮断まで含まれます。

サイトが見えていても保存通信だけ失敗する

公開ページを開けるのに投稿だけ保存できないことは珍しくありません。公開ページの閲覧は主にGET通信ですが、投稿の更新ではログインCookieやNonceを使い、REST APIへ内容を送信するためです。

この保存通信だけをWAFやセキュリティプラグインが拒否すると、サイト閲覧は正常でもエディターは更新に失敗します。通信が401・403なら認証や権限、500系ならサーバー処理、応答なしなら回線や遮断の可能性を優先して見ます。

WordPressでREST APIの401・403エラーが出る原因｜投稿保存までの切り分け手順

エラー表示だけでは未保存と確定できない

保存ボタンを押した直後に通信が途切れると、サーバーでは保存済みなのに、ブラウザが成功応答を受け取れない場合があります。反対に、ブラウザ内の自動保存表示だけ進み、サーバーには届いていないこともあります。

つまり、画面上の表示だけで「保存された」「全部消えた」と判断してはいけません。現在のタブを残したまま内容を退避し、復旧後に別タブやREST応答で保存結果を読み戻す必要があります。

WordPress更新失敗時は編集内容の退避を優先

更新に失敗した直後は、原因調査よりも現在の編集内容を守ることが最優先です。タブを閉じる、再読み込みする、ログアウトする、ブラウザを再起動する操作は、退避が終わるまで行わないでください。

全ブロックをコピーして端末へ残す

エディター右上のオプションから「すべてのブロックをコピー」を選び、テキストエディターなどへ貼り付けます。メニューを操作できない場合は、コードエディターへ切り替えて本文全体を選択し、ローカルファイルへ保存します。

通常の文章だけをドラッグしてコピーすると、画像ID、ブロック属性、装飾、内部リンクなどが失われることがあります。見た目の文章だけでなく、ブロックコメントを含む構造を残すと復元しやすくなります。

WordPressブロックエディタの使い方・全部わかる簡単そうさ方法

タイトルと投稿設定も別に記録する

本文以外に、タイトル、抜粋、カテゴリー、タグ、アイキャッチ、パーマリンクも記録します。本文を復元できても、投稿設定の変更だけ失われるケースがあるためです。

画面を撮影する場合は、パスワード、個人情報、限定公開URLが写らないように注意してください。必要な項目をメモへ転記し、保存時刻と最後に行った操作も残すと、その後の切り分けが正確になります。

現在のタブを証拠として残す

内容を退避した後も、エラーが出たタブはすぐ閉じません。別タブで管理画面や公開ページを開き、元のタブは通信記録と未保存内容を保持するために残します。

ブラウザの開発者ツールを使える場合は、Networkを開いて保存操作に失敗したリクエストのURL、Status、Responseを確認します。ただし、調査のために保存ボタンを何度も連打する必要はありません。一度の再現で十分です。

WordPressがオフライン表示になる主な原因

原因は「端末とブラウザ」「WordPressのREST API」「サーバーや保護機能」の三層へ分けると整理できます。最初から一つに決めつけず、同じ症状がどの端末・どの投稿・どの利用者で起きるかを比較してください。

Wi-Fi・VPN・端末の一時的な通信断

Wi-Fiの切り替え、スリープ復帰、VPNの再接続、テザリングの電波低下などで、保存の瞬間だけ通信が切れることがあります。他のWebページが開けても、数秒前のキャッシュを表示しているだけの場合があるため、別の新しいページで確認します。

同じネットワークの別端末でも新しいページを開けないなら、まず回線やルーターを疑います。一台だけなら、端末のネットワーク設定、VPN、プロキシ、セキュリティソフトの通信監視を確認する方が近道です。

ブラウザ拡張・Cookie・タブの長時間放置

広告遮断、プライバシー保護、スクリプト制御の拡張機能がREST API通信を止めることがあります。また、編集タブを長時間開いたままにすると、ログインCookieやNonceの期限が変わり、保存だけ失敗することがあります。

シークレットウィンドウや別ブラウザで新しいテスト投稿を保存できるなら、元ブラウザ側の影響が濃厚です。ただし、元タブの原稿を退避せずにCookieを削除するとログアウトし、未保存内容へ戻れなくなるため順序を守ってください。

REST API・WAF・セキュリティ機能の遮断

ブロックエディターはREST APIを使って投稿を保存します。WAF、CDN、Basic認証、セキュリティプラグイン、サーバーのアクセス制限が、投稿本文に含まれる文字列や送信サイズを危険と判定すると保存できません。

短いテスト投稿は保存できるのに特定の記事だけ失敗するなら、本文の一部、カスタムHTML、埋め込みコード、容量が条件になっている可能性があります。記事を削る前に複製し、問題が起きるブロックを半分ずつ分けて確認します。

URL・HTTPS・キャッシュの不整合

WordPressアドレスとサイトアドレスのhttp・httpsが一致していない、管理画面だけ別ドメインを経由している、CDNが古い応答を返す、といった不整合でも保存通信は失敗します。ブラウザのアドレスとREST APIの接続先を比較してください。

保存は成功しているのに公開画面だけ古い場合は、オフライン問題ではなくキャッシュの可能性があります。保存通信と表示更新を分け、管理画面で最終更新時刻やリビジョンを確認してからキャッシュを削除します。

WordPressのキャッシュを削除しても表示が変わらない原因｜CDN・サーバー別に確認

サーバーの一時停止とPHP処理の遅延

アクセス集中、PHPワーカー不足、データベース遅延、メンテナンスによって、保存処理の応答がブラウザの待ち時間を超えることがあります。この場合は、同じ時間帯に管理画面全体が遅い、ほかの利用者も保存できないといった共通症状が出やすくなります。

何度も保存すると、処理待ちのリクエストが重なり、さらに応答を遅くする恐れがあります。サーバーのCPU・メモリ・PHPエラーログと、WordPressの更新操作を行った時刻を照合し、一時的な負荷か継続的な設定問題かを分けてください。

ホスティング側に障害が出ている時は、WordPress内の設定を変更しても直りません。公式の障害情報を確認し、原稿を退避した状態で復旧を待ち、サービス回復後に保存内容を別タブから確認する方が安全です。

WordPress更新失敗を安全に切り分ける手順

切り分けは、変更の影響が小さい順に「原稿退避→端末回線→別タブ→ブラウザ→REST API→WAF・サーバー」で進めます。一つ確認するたびに結果を記録すると、途中で状態が変わっても原因を見失いません。

手順1：回線とログイン状態を別タブで確認する

まず別タブで、キャッシュされていない新しいWebページとWordPress管理画面を開きます。両方とも開かなければ回線を確認し、一般サイトだけ開くならWordPress側の障害や接続制限を疑います。

管理画面がログイン画面へ戻る場合は、セッション切れの可能性があります。原稿退避済みであることを確認してから再ログインし、元の投稿を別タブで開いて保存済み内容と比較してください。

手順2：REST APIの基本応答を確認する

サイトのREST API入口が表示できるか確認します。次の例ではexample.comを自分のドメインへ置き換えます。画面にJSON形式の情報が返れば入口には到達していますが、それだけで投稿更新権限まで正常とは限りません。

https://example.com/wp-json/
https://example.com/wp-json/wp/v2/types/post

404ならパーマリンクやサーバー設定、401・403なら認証・権限・WAF、500系ならPHPエラーやサーバー障害を確認します。JSONではなくログイン画面、HTMLの警告、CDNのエラーページが返る場合も、正常なREST応答ではありません。

手順3：サイトヘルスとブラウザの通信記録を見る

WordPressの「ツール」から「サイトヘルス」を開き、REST APIやループバックリクエストの警告を確認します。ここで共通エラーが出るなら、投稿固有ではなくサイト全体の通信設定に原因がある可能性が高まります。

WordPressのサイトヘルスで「改善が必要」と出た時の見方と対処法

開発者ツールのNetworkでは、保存操作に対応するリクエストを一度だけ確認します。Statusが0やfailedなら端末・ブラウザ・CORS・通信断、401・403なら認証や遮断、413なら送信サイズ、5xxならサーバー処理を優先します。

手順4：別ブラウザと短いテスト下書きで比較する

同じアカウントで別ブラウザを使い、個人情報を含まない短いテスト下書きを作ります。保存できれば元ブラウザや元投稿固有、保存できなければアカウント・サイト・サーバー側の問題と考えやすくなります。

次に、元投稿を複製できる環境なら複製側で確認します。特定ブロックを外した時だけ保存できる場合は、そのブロックのHTML、埋め込み、ショートコード、入力文字列がWAFや検証エラーへ影響していないか調べます。

手順5：WAFと直前の変更を一つずつ戻す

直前に有効化したプラグイン、CDNルール、WAF設定、Basic認証、リバースプロキシ設定があれば、一度に一つだけ切り戻して再テストします。複数を同時に変更すると、直っても原因が分からず再発防止につながりません。

WAFログに該当リクエストが記録されている場合は、遮断されたURL、時刻、ルールを確認します。WAF全体を長時間無効にするのではなく、原因を特定し、必要最小限の例外や入力修正で対応するべきです。

WordPress修正の基本｜表示崩れ・エラーを直す前に見るべきポイント

WordPressの保存結果を復旧後に確認する方法

エラーが消えただけでは作業完了ではありません。退避した内容とサーバー上の下書きを比較し、再読み込み後も同じ本文が残り、プレビューへ反映されるところまで確認します。

別タブで投稿を開いて読み戻す

元タブを残したまま、別タブで投稿一覧から対象記事を開きます。本文の末尾、直前に変更した見出し、画像、カテゴリーなど、見分けやすい箇所を退避データと比較してください。

別タブに最新内容があれば、サーバー保存は成功しています。古い内容なら、元タブのコピーを使って不足分だけ戻し、下書き保存を一度実行します。全体を無条件に上書きすると、共同編集者の変更を消す恐れがあります。

保存時刻・リビジョン・自動保存を比較する

投稿一覧の更新日時とリビジョンを確認し、エラーが出た時刻の変更が残っているか見ます。自動保存が見つかった場合も、すぐ置き換えず、現在の下書きと差分を比較して必要な部分だけ採用します。

時刻が合っていても、本文の一部だけ欠けることがあります。特に大きな投稿、埋め込み、再利用ブロック、プラグイン独自ブロックは、末尾だけでなく中間の変更箇所も確認してください。

下書き保存後にプレビューまで確認する

保存ボタンが完了表示になったら、別タブでプレビューを開きます。タイトル、見出し、画像、リンク、装飾が表示され、再度エディターを開いても変更が残ることを確認します。

管理画面では保存済みでも、プレビューが古い場合はキャッシュを分けて確認します。キャッシュ削除は保存確認の代わりではありません。まず投稿の更新日時と内容を確認し、その後で表示側のキャッシュを処理します。

WordPress更新失敗が直らない時の切り分け

基本確認で直らない場合は、症状が発生する範囲を狭めます。「一台だけ」「一人だけ」「一つの記事だけ」「サイト全体」のどこまで共通するかで、調べる場所が変わります。

一台・一ブラウザだけで発生する場合

別端末では保存できるなら、元端末のVPN、プロキシ、拡張機能、セキュリティソフト、ブラウザプロファイルを確認します。シークレットウィンドウで直る場合は、拡張機能や保存済みサイトデータの影響が有力です。

Cookie削除を試す時は、原稿退避とログイン情報の確認後に対象ドメインだけを削除します。全サイトのデータを一括削除する必要はなく、他サービスのログイン状態まで失う操作は避けます。

一つの記事だけで発生する場合

特定記事だけなら、本文サイズ、カスタムHTML、埋め込み、ショートコード、特殊文字、プラグイン独自ブロックを疑います。複製した下書きでブロックを半分ずつ分けると、問題範囲を少ない試行で絞れます。

原因候補を見つけても、元記事を直接削りながら試さないでください。退避データと複製を残し、問題ブロックだけを標準ブロックで再作成する方が安全です。

全利用者・全投稿で発生する場合

複数の利用者が複数端末で保存できないなら、WordPress本体、REST API、サーバー、WAF、CDNの共通障害を優先します。サイトヘルス、サーバーログ、WAFログ、ホスティングの障害情報を同じ時刻で照合します。

本番環境で闇雲に設定を変えず、バックアップとステージング環境を用意します。原因が分からないままWAFや保護機能を停止し続けると、保存できても別のリスクが高まります。

WordPressオフライン表示でよくある質問

最後に、「更新に失敗しました。オフラインのようです」と表示された時によくある疑問へ回答します。

WordPress更新失敗時の保存確認まとめ

「更新に失敗しました。オフラインのようです」と表示された時は、再読み込みや設定変更を急がず、未保存の内容を先に退避します。その後、端末、ブラウザ、REST API、WAF・サーバーの順で切り分けると、安全に原因へ近づけます。

重要なのは、エラー表示が消えたことではなく、サーバー上の下書きへ最新内容が保存され、別タブで読み戻せることです。更新時刻、リビジョン、プレビューまで確認して初めて復旧完了と判断します。

保存エラーは、焦って操作を重ねるほど原稿消失や原因の複雑化につながります。退避、切り分け、読み戻しの順序を守り、自分で判断できない変更は実施前に専門家へ相談してください。

WordPressの投稿保存エラーが自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で