ECサイトが突然表示されなくなった時の対処法｜機会損失を防ぐバックアップ体制の作り方

ECサイト 表示されない 対処法を調べている読者の多くは、いままさに自社のネットショップが開けない、あるいは管理画面にログインできず商品もセールも触れない状態に直面しています。落ち着いて対処するための手順と、二度と焦らないための備えの両方を求めているはずです。

先に前提を一つ明確にしておきます。本記事が扱うのは、ShopifyのようなSaaS型ECではなく、WordPress＋WooCommerceやEC-CUBEなど「自社サーバー・自社構築」で運営しているネットショップ特有の障害です。ShopifyはShopify社が全体のインフラとアプリケーション層を管理しているため、プラグイン更新の失敗でサイト全体がロックアウトされる、FTPで手動対応が必要になる、といった障害モードはそもそも存在しません。一方で自社構築型は、テーマやプラグインの更新、サーバー環境のバージョン変更、日々の運用作業そのものが障害の引き金になり得ます。この違いを理解しないまま一般論のトラブル対応記事を読んでも、実際の初動には結びつきません。

本記事では、特定のプラグインや特定の障害事例だけに限定せず、自社構築型ネットショップで実際によく起きる「表示不能」「管理画面ロックアウト」を一般化し、初動対応の標準化と、そもそも機会損失を発生させないための予防的バックアップ体制まで、2026年8月5日時点の実務観点で整理しました。今後もサーバー環境やプラグインのアップデート方針は変わり得るため、自社の契約しているレンタルサーバーやホスティング事業者の最新のドキュメントも合わせて確認することをおすすめします。

このテーマが重要になる理由

ECサイトは「見えなくなった瞬間から売上が止まる」という性質を持つ点が、一般的なコーポレートサイトと決定的に違います。問い合わせフォームが多少遅れても業務は続きますが、ネットショップはトップページが開かない、カートに進めない、決済画面が表示されないだけで、その瞬間の購入意欲がそのまま離脱に変わります。

特に自社構築型のネットショップでは、プラグインやテーマの更新、サーバー移行、PHPバージョンの変更といった「良かれと思って行った作業」が障害の引き金になりやすいという特徴があります。SaaS型ECにはない自由度の高さは大きなメリットですが、同時に運用側が復旧手順を自分たちで押さえておく必要があるということでもあります。

• 表示不能の原因は「攻撃」より「自社の更新作業」であることの方が多い
• 管理画面に入れない状態でも、多くの場合FTP/SFTPからは対応できる
• 初動の型を知っているかどうかで、復旧までの時間が数十分にも数時間にもなる

参考テーマから抽出した主要論点

この領域では、特定のバックアッププラグインのアップデートが引き金となり、PHPの関数不足でサイトと管理画面の両方にアクセスできなくなる、という個別の障害事例がしばしば話題になります。リカバリーモードの活用や、FTP経由でのプラグイン手動無効化といった対処自体は有効な手段ですが、特定プラグイン名にひもづく解説だけでは、別の原因・別の環境で同じ状況に陥った読者の役には立ちません。

本記事では、個別事例のノウハウを「原因を問わない初動対応の型」まで抽象化し、さらに検索意図を「対処法」から「予防的なバックアップ体制の設計」まで広げて再構成しています。似たテーマとして自社サイトには既にSaaS型EC（Shopify）の障害確認手順を扱った記事がありますが、あちらは外部サービス側の障害切り分けが主眼です。本記事はそれとは逆に、自社側の作業・環境起因で発生する障害に焦点を当てている点で検索意図が異なります。

• プラグイン・テーマ更新の互換性問題という共通原因
• 管理画面に入れない状態での代替アクセス手段(FTP/SFTP)
• 復旧して終わりにせず、原因記録と再発防止まで含める視点
• 個別プラグイン名に依存しない、汎用的な初動フローへの再構成

こんな状況の小売事業者に向いている

検索意図が近く見えても、実際に置かれている状況によって必要な情報は変わります。自社の状況と照らし合わせながら読むと、優先して手を打つべき箇所が見えてきます。

• WordPress＋WooCommerceやEC-CUBEなど、自社サーバーでネットショップを構築・運営している
• プラグインやテーマの更新を担当者の判断でその都度行っている
• バックアップを取っているつもりだが、最後に復元を試したのがいつか覚えていない
• セールや繁忙期の直前にアップデート作業を行うことがある
• 障害発生時に誰が何を確認するかのルールが明文化されていない

いずれか一つでも当てはまるなら、対処法そのものより先に、次章の「着手前に整理すべき前提条件」から確認することをおすすめします。

着手前に整理すべき前提条件

障害はいつ起きるか選べません。だからこそ、障害が起きた「その瞬間」に何を確認すればよいかを、平時のうちに整理しておく必要があります。

• サーバーの管理画面(コントロールパネル)へのログイン情報を担当者以外も参照できる場所に保管しているか
• FTP/SFTPのアカウント情報とツール(FileZilla等)の使い方を、担当者交代時にも引き継げる状態にしているか
• 直近のバックアップがどこに、いつの時点のものが保存されているか把握しているか
• 契約しているレンタルサーバーに「リカバリーモード」やそれに相当する緊急復旧機能があるか確認済みか
• 障害発生時に誰が第一報を受け、誰が判断し、誰が制作会社・保守会社に連絡するかが決まっているか

この前提が整理されていないままだと、対処法の手順を読んでも「そもそもログイン情報がどこにあるか分からない」という一番手前の段階でつまずきます。

障害発生時の初動対応ステップ

影響範囲を切り分ける

「サイトが表示されない」と一言でいっても、実際の状態は様々です。まずは次の観点で切り分けます。

• フロント(お客様が見る画面)だけが表示されないのか、管理画面(wp-admin)にも入れないのか
• 特定のページだけがエラーになるのか、サイト全体が真っ白(いわゆるホワイトスクリーン)なのか
• 特定の端末・ブラウザだけの現象か、複数の環境で再現するのか
• 直前に何か作業(プラグイン更新、テーマ変更、サーバー側の設定変更)を行っていないか

この段階で「直前の作業」が特定できれば、原因の当たりをつけやすくなります。自社構築型のトラブルの多くは、外部からの攻撃よりも、直近の更新作業がきっかけであるケースの方が多いというのが実務上の実感です。

レンタルサーバーのリカバリーモードを確認する

多くのレンタルサーバー・ホスティングサービスには、プラグインやテーマの致命的エラーによってサイトが表示できなくなった場合に、管理画面だけを安全な状態で開けるようにする「リカバリーモード」または類似の緊急アクセス機能が用意されています。これはWordPress自体が持つ機能に加え、サーバー事業者側が独自に用意している場合もあります。

• 致命的エラー発生時にWordPressから管理者宛にリカバリーモードのリンクが自動送信される仕組みがあるか確認する
• 契約しているサーバーのコントロールパネルに「セーフモード」「緊急ログイン」に相当する機能がないか確認する
• リカバリーモードで管理画面に入れた場合は、直前に更新・有効化したプラグインやテーマから順に無効化し、原因を切り分ける

リカバリーモードが使えれば、次に説明するFTP作業を行わずに済むケースも多く、復旧までの時間を大きく短縮できます。

FTP/SFTP経由で原因プラグイン・テーマを無効化する

管理画面にもリカバリーモードにも入れない場合は、FTP/SFTPで直接サーバー上のファイルを操作して復旧を試みます。

• FTP/SFTPクライアントでサーバーに接続し、`wp-content/plugins`フォルダを確認する
• 直前に更新・有効化したプラグインのフォルダ名を変更する(例: `plugin-name` → `plugin-name-disabled`)。WordPressはフォルダ名が変わると該当プラグインを自動的に無効化した状態として扱う
• フォルダ名変更後、フロントと管理画面が復旧するか確認する
• プラグインではなくテーマが原因と考えられる場合は、`wp-content/themes`内で同様に処置し、標準テーマに切り替えて復旧するか確認する
• 復旧を確認できたら、当該プラグイン・テーマの提供元に不具合報告や最新版の有無を確認してから再導入する

この手順は、原因となっているプラグインやテーマの種類を問わず有効な、汎用性の高い初動対応です。慌てて複数のフォルダ名を一度に変更すると原因の特定が難しくなるため、一つずつ確認しながら進めることが重要です。

エラーログを確認する

ホワイトスクリーンや管理画面ロックアウトの背後には、多くの場合PHPのエラーが記録されています。原因の当たりをつけるうえで、エラーログの確認は欠かせません。

• サーバーのコントロールパネルから`error_log`やPHPエラーログの場所を確認する
• WordPressの`wp-config.php`で`WP_DEBUG`と`WP_DEBUG_LOG`を一時的に有効化し、`wp-content/debug.log`にエラー内容を出力させる(本番環境で有効化する場合は、画面表示への出力`WP_DEBUG_DISPLAY`はオフにし、ログ出力のみに限定する)
• 「Fatal error」「関数が見つからない」といった文言と、どのプラグイン・テーマのファイルで発生しているかを確認する

エラーログを確認せずに手当たり次第プラグインを無効化していくと、復旧までの時間が余計にかかります。原因の見当をつけてから対処する方が、結果的に早く復旧できます。

復旧後の原因記録を残す

サイトが表示されるようになった時点で「解決した」と考えて終わらせてしまうと、同じ障害を繰り返しやすくなります。

• 何が起きたか(現象)
• 何が原因だったか(直前の作業・更新内容)
• どう対処して復旧したか
• 再発防止のために何を変えるか(更新手順の見直し、事前検証の追加など)

この記録を残す習慣があるチームとないチームでは、同種の障害が起きたときの復旧時間に大きな差が出ます。

予防的バックアップ体制の設計

バックアップ頻度と保管先を決める

ネットショップは商品・注文・顧客データが日々更新されるため、コーポレートサイト以上にバックアップ頻度の設計が重要になります。

• データベース(注文・会員情報など変化が速い部分)は毎日、可能であれば1日複数回のバックアップを検討する
• ファイル一式(テーマ・プラグイン・アップロード画像など)は週次を基本とし、大きな更新作業の前には都度取得する
• バックアップの保管先は、サーバー内だけでなく外部ストレージ(クラウドストレージ等)にも分散させ、サーバー自体に障害が起きた場合にも復元できるようにする

復元テストを定期的に行う

バックアップは「取得しているか」より「復元できることを確認しているか」の方が重要です。取得だけして一度も復元を試していないバックアップは、いざという時に使えない可能性があります。

• 四半期に一度など、頻度を決めて検証環境への復元テストを実施する
• 復元にかかった時間を記録し、実際の障害時にどの程度の時間で復旧できるかの目安にする
• 復元テストの結果を担当者間で共有し、手順書として残す

更新作業前のバックアップを徹底する

プラグイン・テーマ・WordPress本体の更新は、障害の最大の引き金です。更新作業そのものをなくすことはできませんが、更新の直前に必ずバックアップを取る運用を徹底することで、万一の際の復旧を格段に容易にできます。

• 更新前に手動でバックアップを取得するルールを明文化する
• 自動バックアップに頼る場合も、更新直前のタイミングで確実に取得されているか確認する
• セールや繁忙期の直前・最中は、緊急性の高いセキュリティ更新を除き、大きな更新作業を避ける

ステージング環境を活用する

可能であれば、本番環境と同じ構成の検証用環境(ステージング環境)を用意し、更新作業は必ずそこで検証してから本番に反映する運用が理想的です。

• 契約しているレンタルサーバーにステージング機能があるか確認する
• ステージング機能がない場合は、ローカル環境や別サブドメインでの検証環境構築を検討する
• 検証環境で問題がないことを確認してから本番へ反映する運用を定着させる

ダウンタイムが小売ECに与える経営インパクト

ダウンタイムのコストは「見えにくいが確実に発生している」という点が厄介です。1時間の停止であっても、平常時の平均時間当たり売上に加えて、セール中・広告配信中であれば機会損失はさらに拡大します。

• 平常時のダウンタイム: その時間帯の平均売上分がそのまま損失になる
• セール・キャンペーン中のダウンタイム: 広告費をかけて集めた流入が購入に至らず、広告費だけが失われる
• SNSや口コミで話題化しているタイミングでのダウンタイム: 一時的な検索・アクセス増加を取りこぼす
• 離脱した顧客の一部は、復旧後も戻らずに競合サイトで購入を完了させてしまう

バックアップ体制への投資は「守りのコスト」に見えますが、実際には機会損失という将来の売上を守るための投資だと捉えると、経営判断として位置づけやすくなります。

具体的な試算で考えてみます。月商300万円のネットショップであれば、1日あたりの平均売上はおよそ10万円、1時間あたりではおよそ4,000円程度になります。平常時であれば数時間のダウンタイムは数万円規模の損失に留まるかもしれませんが、これがセール当日や広告出稿中であれば話は変わります。セール当日は平常時の3〜5倍の流入・売上が見込めるため、同じ1時間の停止でも損失額は数倍に膨らみますし、その時間帯にクリックされた広告費はコンバージョンにつながらないまま消化されてしまいます。復旧に半日かかれば、広告費と機会損失を合わせて数十万円規模の影響になるケースも珍しくありません。

この試算からも分かる通り、バックアップ体制と初動対応の型に投資することで短縮できる「復旧までの時間」そのものが、そのまま守れる売上に直結します。

失敗しやすいポイント

障害対応でつまずくのは、手順を知らないことよりも、事前に決めておくべきことを決めていなかったケースがほとんどです。

• サーバーのログイン情報やFTPアカウントが、担当者一人にしか分からない状態になっている
• バックアップを取得してはいるが、復元方法を誰も知らない
• 更新作業を繁忙期直前に行い、検証を省略してしまう
• 障害発生時の連絡フローが決まっておらず、対応開始までに時間がかかる
• 復旧後に原因を記録せず、同じ障害を繰り返す

これらはどれも特別な失敗ではなく、担当者が少ない小売事業者ほど陥りやすい落とし穴です。事前に言語化しておくだけで、再発の多くは防げます。

見るべき指標と報告の作り方

バックアップ体制や障害対応の質は、感覚ではなく定点観測できる指標で管理すると、経営層への説明もしやすくなります。

指標は増やしすぎず、経営層へ共有するもの(売上損失額、復旧時間)と、現場改善に使うもの(取得成功率、テスト実施率)を分けて管理すると運用しやすくなります。

内製と外注の切り分け

バックアップ体制や障害対応は、全てを内製する必要はありませんが、全てを外注に丸投げして自社では何も把握していない、という状態も危険です。

• 社内で持つべきもの: サーバー・FTPの情報所在の把握、障害時の連絡フロー、バックアップ取得状況の定期確認
• 外注しやすいもの: 復旧作業そのもの、ステージング環境の構築、原因の技術的な切り分け、保守契約による定期監視
• 共同で決めるもの: バックアップ頻度、復元テストの実施計画、更新作業のスケジュール

「何かあったらすぐ連絡できる保守先」を平時から確保しておくことが、自社構築型ネットショップの障害対応において最も費用対効果の高い備えの一つです。

あわせて読みたい関連記事

• Shopifyで障害が起きたときの確認手順｜原因の切り分けと復旧フロー
• WordPressを安全にアップデートする手順｜本番事故を防ぐ事前確認とロールバック設計
• WordPressの更新履歴を残す方法｜保守レポートと監査に強い運用設計

よくある質問

管理画面にもFTPにも入れない場合はどうすればよいですか？

契約しているレンタルサーバーのサポート窓口に連絡し、サーバー側の障害の有無を確認してください。FTPアカウント自体が使えない場合は、コントロールパネルからFTP情報の再発行が可能なことが多いです。

バックアップを取っていなかった場合、復旧は不可能ですか？

不可能ではありませんが、原因の切り分けや復旧の難易度が大きく上がります。多くのレンタルサーバーはサーバー側で独自の世代管理バックアップを持っている場合があるため、まずサーバー事業者に確認してください。

どのくらいの頻度でバックアップを取ればよいですか？

データベースは毎日、ファイル一式は週次を基本とし、更新作業の直前には都度手動で取得することをおすすめします。取引量が多いネットショップほど、より高頻度な設計が望ましいです。

セール中に障害が起きないようにするにはどうすればよいですか？

セールや繁忙期の直前は、緊急性の高いセキュリティ更新を除き、プラグインやテーマの更新作業を避けるのが基本です。どうしても更新が必要な場合は、ステージング環境での事前検証を必ず行ってください。

リカバリーモードとはどのような機能ですか？

プラグインやテーマの致命的エラーでサイトが表示できなくなった際に、管理者宛のメールなどを通じて安全な状態で管理画面へアクセスできるようにする仕組みです。契約サーバーによっては類似の緊急アクセス機能が別途用意されている場合もあります。

Shopifyのようなカート型ECサービスなら、この種の障害は起きませんか？

SaaS型のためプラグイン更新によるサイト全体のロックアウトという障害モードは基本的に発生しませんが、Shopify自体のシステム障害は起こり得ます。その場合の確認手順は別記事で解説しています。

制作会社に丸投げしても大丈夫ですか？

実際の復旧作業やステージング環境の構築は任せられますが、サーバー情報の所在把握や障害時の連絡フローは発注側でも把握しておくべきです。

まとめ

ECサイト 表示されない 対処法に関する良い備えは、特定の障害事例を丸暗記することではなく、初動の型を持つことと、機会損失を未然に防ぐバックアップ体制を平時から設計しておくことから生まれます。

自社構築型のネットショップは自由度が高い分、運用側が備えを持つ必要があります。Okojoのような制作・保守支援の現場でも、障害が起きてから相談を受けるより、平時のバックアップ設計や更新運用の整備から関わる方が、結果的に売上を守ることにつながります。

WordPress・WooCommerce/EC-CUBEのネットショップの障害対応・バックアップ体制構築の相談はこちら