ホームページが突然表示されないと、担当者はサーバーやWordPressの設定を急いで変更しがちです。しかし、原因が端末、通信、DNS、SSL、サーバー、アプリケーションのどこにあるか分からないまま操作すると、状況を悪化させる可能性があります。
最初に影響範囲と発生時刻を確認し、証拠を残しながら切り分けることが重要です。中小企業の担当者が行う初動を順に解説します。
まず確認する4項目
1. どのURLが表示できないか
トップページだけか、全ページか、管理画面だけか、フォームだけかを確認します。URLを正確に記録します。
2. 誰に起きているか
一人の端末だけか、社内全体か、社外からも起きるかを確認します。スマートフォン回線など別の通信環境でも試します。
3. いつからか
最後に正常表示を確認した時刻と、最初に異常を確認した時刻を記録します。更新、公開、DNS変更、請求、サーバーメンテナンスとの関連を調べます。
4. 何と表示されるか
真っ白、接続できない、証明書警告、404、403、500、メンテナンス中など、画面とエラー文をスクリーンショットで残します。
最初にしてはいけないこと
- バックアップなしで更新する
- 複数の設定を同時に変える
- 原因不明のままプラグインを削除する
- DNSを何度も書き換える
- エラーログや画面を消す
- 出所不明の修復ツールを実行する
- パスワードを不特定多数へ送る
一つずつ変更し、変更前後を記録します。
原因1：自分の端末・通信
ブラウザーキャッシュ、拡張機能、VPN、社内ネットワーク、DNSキャッシュが原因の場合があります。別ブラウザー、シークレット表示、別端末、スマートフォン回線で確認します。
ほかの人は見られる場合、サーバー設定を変える前に端末側を切り分けます。
原因2：ドメインの期限切れ・DNS
ドメイン更新失敗、ネームサーバー変更、DNSレコード誤りでサイトへ到達できなくなります。会社メールも同じドメインなら、メール障害を伴う可能性があります。
登録事業者の管理画面、契約メール、更新期限、DNS変更履歴を確認します。闇雲に元へ戻さず、正しい設定の記録と照合します。
原因3：SSL証明書
証明書の期限切れ、ドメイン不一致、中間証明書、DNS変更などでブラウザーに警告が出ます。警告を無視して利用を続けず、サーバー会社または管理者へ連絡します。
自動更新が有効でも、認証やDNSの問題で失敗することがあります。
原因4：サーバー障害・契約
サーバー会社の障害、メンテナンス、容量超過、支払い失敗、アカウント停止が考えられます。公式の障害情報と管理画面通知を確認します。
同じサーバー上のほかのサイトやメールにも影響があるかを調べます。
原因5：WordPress更新・プラグイン競合
更新直後に表示不能になった場合、WordPress本体、テーマ、プラグイン、PHPの互換性が原因かもしれません。直前の更新履歴と自動更新メールを確認します。
本番で無差別に無効化せず、バックアップと検証環境を確保して切り分けます。
原因6：容量・データベース
ディスク容量やデータベース容量が上限に達すると、書き込み失敗、更新停止、500エラーが起こる場合があります。バックアップの増加、ログ、キャッシュ、大きな画像を確認します。
不要ファイルを慌てて削除せず、何が容量を使っているか特定します。
原因7：アクセス集中・攻撃
広告、報道、キャンペーンによる正常なアクセス集中のほか、ボット、不正ログイン、DDoSなどで負荷が上がる場合があります。
アクセスログ、サーバー負荷、WAF通知を確認し、サーバー会社や保守会社へ連絡します。
原因8：改ざん・マルウェア
見覚えのない転送、広告、管理者、ファイル、検索結果の異常がある場合は、改ざんの可能性があります。感染中のサイトを安易に公開し続けず、影響範囲を調査します。
侵害後のバックアップを上書きしないよう、証拠と複数世代を保全します。
原因9：URL・リダイレクト設定
WordPressアドレス、サイトアドレス、https化、www有無、リダイレクト設定の誤りで、無限転送や別URLへの移動が起こります。
最近の設定変更、プラグイン、サーバー設定、CDNを確認します。
原因10：公開作業・ファイル変更
テーマ編集、ファイル移動、権限変更、デプロイ失敗で表示できなくなる場合があります。誰が何をいつ変更したかを確認します。
変更履歴がない場合は、ログとファイル更新時刻から調べます。
初動対応の順番
- 発生時刻、URL、画面、報告者を記録する
- 別端末・別回線で再現を確認する
- 影響範囲を確認する
- 直前変更と契約通知を確認する
- サーバー・ドメインの公式障害情報を見る
- ログとバックアップを保全する
- 管理者・保守会社へ連絡する
- 顧客・社内への案内を判断する
- 復旧後に表示・フォーム・メール・計測を確認する
- 原因と再発防止を記録する
制作会社へ伝える情報
- サイトURL
- 発生時刻と最終正常時刻
- エラー画面
- 再現する端末・回線
- 影響するページ・機能
- 直前の更新・設定変更
- ドメイン・サーバー通知
- 会社メールへの影響
- 緊急度と事業影響
「見られません」だけでなく、切り分け情報を渡すと調査が早くなります。
顧客への案内
問い合わせや予約が止まる場合は、SNS、Googleビジネスプロフィール、電話案内、臨時ページなど代替手段を検討します。原因が確定していない段階で断定せず、利用できない機能と代替連絡先を案内します。
復旧見込みは、根拠がある場合だけ伝えます。
復旧後に確認すること
- パソコン・スマートフォンの主要ページ
- 管理画面ログイン
- 問い合わせフォームと受信
- 予約・決済・会員機能
- 会社メール
- SSLとリダイレクト
- GA4・GTMの発火
- Search Consoleの警告
- 不審ユーザー・ファイル
- バックアップの再設定
表示できただけで完了にせず、業務機能まで確認します。
再発防止
原因に応じて、稼働監視、容量通知、契約期限管理、検証環境、変更手順、権限管理、バックアップ、WAFなどを見直します。
障害記録には、影響、原因、復旧、判断、連絡、改善、担当期限を残します。
平時に準備する障害対応表
- 自社責任者と代行者
- 制作会社・サーバー会社・ドメイン会社の連絡先
- 契約番号と管理URL
- 稼働監視の通知先
- 最新バックアップの場所
- 緊急アカウントの保管方法
- 顧客への代替案内手段
- 優先復旧ページ・機能
- 復旧後テスト項目
障害発生後に契約情報を探さない体制を作ります。
まとめ
ホームページが表示されないときは、まずURL、影響範囲、発生時刻、エラー画面を記録し、別端末・別回線で再現を確認します。
DNS、SSL、サーバー、WordPress、容量、攻撃、変更履歴を一つずつ切り分け、証拠とバックアップを保全しましょう。復旧後はフォーム、メール、計測まで確認し、再発防止を記録することが重要です。