ホームページが表示されない時の初動｜社内で確認する順番と連絡メモ
自社ホームページが突然開けなくなった時、最初にすることは設定変更ではありません。同じURLを別の端末と回線で開き、誰に・どの範囲で起きているかを確かめます。そのうえで、影響URL、発見時刻、最後に正常だった時刻、画面の表示、直前変更を一組の記録にし、管理担当へ渡します。原因が分からないままDNS、サーバー、WordPress、バックアップを触ると、状況を複雑にしたり、調査に必要な記録を失ったりするためです。
この記事で扱う「表示されない」は、ブラウザへURLを入れてもページが開かない、警告やエラーが出る、白い画面になるといった状態です。「検索しても自社サイトが見つからない」「修正した内容が古いまま見える」という問題とは確認する場所が異なります。まず、いま困っているのがサイトへの接続障害なのか、検索結果や更新反映の問題なのかを分けてください。
社内の一次受付に高度な診断は要りません。必要なのは、利用者側の一時的な問題とサイト全体の問題を切り分け、事実を同じ形式で残し、変更権限を持つ人へ早くつなぐことです。以下では、発見から連絡、復旧確認までを、非技術担当でも実行できる順番で整理します。
最初の10分で決めるのは「直す人」ではなく「事実を集める人」
障害に気づいた人が複数いると、それぞれがブラウザを再読み込みし、サーバー会社へ連絡し、管理画面を触り始めることがあります。ところが、確認方法と時刻がばらばらでは、「いつから」「誰に」「どのURLで」「何を試した後に」変化したのかを追えません。最初に一次受付を一人決め、情報をその人へ集めるだけで、重複連絡と無断変更を抑えられます。技術担当が不在でも、受付役は決められます。
次に、技術的な原因ではなく事業への影響で優先度を判断します。トップページだけでなく問い合わせ、予約、購入、採用応募など重要な導線が使えないか、外部の利用者にも再現するか、営業中かどうかで緊急度は変わります。社内の一台だけで開けない段階から「サイト全体が停止」と断定せず、反対に売上や受付へ直結する機能が止まっているのに通常の修正依頼へ混ぜないことが大切です。
| 一次判断 | 見えている状態 | 最初の扱い |
|---|---|---|
| 優先度が高い | 外部の複数環境で主要ページや受付機能が使えず、業務への影響が出ている | 一次受付を一本化し、保守・制作・サーバー担当へ障害連絡として渡す |
| 範囲を確認中 | 一部URL、一部地域、一部端末だけで再現する | 再現条件と正常な条件を並べ、対象を狭めてから連絡する |
| 利用環境の可能性 | 別端末や別回線では正常で、特定の端末・社内回線だけで起きる | 端末・ブラウザ・社内ネットワーク側の担当へ条件を渡す |
この表は原因を決めるものではありません。連絡の速さと、誰へ渡すかを決めるための仮分類です。確認途中で影響範囲が広がったら、優先度も更新します。
同じURLを端末と回線を変えて確認する
最初の切り分けでは、検索結果から入り直すのではなく、問題が起きたURLをそのまま使います。URLの末尾、httpとhttps、wwwの有無、特定の下層ページかトップページかが違うと、別の症状を見てしまうからです。チャットやメールにURLを貼り、確認する人全員が同じ場所を開けるようにします。
- 問題を見つけた端末で、URLと画面全体を記録する。再読み込みを何度も繰り返す前に、時刻とエラー文を残す。
- 同じ端末で別の一般的なサイトが開くか確認する。ほかのサイトも開かなければ、端末や回線の問題を先に疑う。
- スマートフォンのモバイル回線など、社内Wi-Fiとは別の回線で同じURLを開く。Wi-Fiを切ったかどうかも記録する。
- 可能なら別の人、別の端末、別のブラウザでも確認する。正常に開く条件と開かない条件を対にして残す。
シークレットウィンドウや別ブラウザでの確認は、保存済みデータや拡張機能の影響を見分ける手掛かりになります。ただし、最初の画面を残す前にCookieやキャッシュをすべて消す必要はありません。削除するとログイン状態や入力途中の情報が消え、元の条件を再現しにくくなることがあります。まず別環境で比較し、それでも利用者側の問題が濃い場合に、社内ルールへ沿って端末側の対処へ進みます。
表示障害の初動は、切り分け、記録、担当への受け渡しを分けると混乱しにくくなります。
社内だけで開けず、モバイル回線では開ける場合は、会社のネットワーク、DNS、プロキシ、セキュリティ製品などが関係する可能性があります。反対に、社内でも社外でも開けない場合は、サイト側の確認を優先します。どちらも一次受付の段階では「原因」ではなく「再現条件」として記録してください。
連絡に使える記録は、URL・時刻・画面・影響を一組にする
「ホームページが見られません」だけでは、担当者が同じ状況を再現できません。連絡前に、最低限の情報を一つのメモへまとめます。特に重要なのは発見時刻と、最後に正常だったことを確認できる時刻です。発見時刻は障害開始時刻とは限らないため、二つを分けます。たとえば朝9時に発見しても、前日の18時までは正常だった、という記録なら、調査対象の時間帯を絞れます。
- 影響URL：トップだけでなく、問い合わせや予約など確認した具体的なURL
- 時刻：発見時刻、最後に正常だった時刻、各確認を行った時刻
- 環境：端末、OS、ブラウザ、社内Wi-Fiかモバイル回線か
- 画面：アドレスバーを含むスクリーンショット、表示されたエラー文やコード
- 範囲：自分だけ、一部社員、社外の複数環境、特定ページだけ、サイト全体など
- 事業影響：問い合わせ不可、予約不可、購入不可、会社情報を閲覧できないなど
- 直前変更：公開作業、更新、移行、契約更新、外部サービス変更の有無と実施時刻
スクリーンショットには、URLと時刻が分かる情報を残します。一方、管理画面の個人情報、顧客情報、アクセストークン、パスワード、決済情報が映る場合は、その部分を隠して共有します。エラー文は要約せず、可能ならコピーした原文も添えます。「サーバーエラーだったと思う」より、「画面に503 Service Unavailableと表示」と伝える方が、確認先を早く絞れます。
記録の目的は、一次受付の人が原因を当てることではありません。正常な条件と異常な条件、起きた時刻、直前に変えた事実を、担当者が追える形で残すことです。
原因を断定せず、確認先を「入口」から分ける
ホームページが表示されるまでには、URLを名前として扱う仕組み、通信を安全にする証明書、ページを配信する基盤、WordPressなどのサイト本体、フォームや予約の外部サービスが順に関わります。どこか一つだけを見るのではなく、入口から層を分けると、連絡先と確認資料を整理しやすくなります。
確認先を層に分け、管理画面や状態ページで見えた事実を担当者へ渡します。
| 確認する層 | 一次受付で見られる事実 | 主な受け渡し先 |
|---|---|---|
| アドレス | 正しいURLか、ドメインやSSLの期限通知がないか、証明書警告が出るか | ドメイン管理者、SSL・インフラ担当 |
| 配信基盤 | サーバーやCDNの障害・メンテナンス情報、契約・請求通知、管理画面の稼働表示 | サーバー会社、インフラ・保守担当 |
| サイト本体 | 管理画面へ入れるか、直前のCMS・テーマ・プラグイン・公開作業、WordPressの通知 | 制作会社、保守担当、社内Web管理者 |
| 外部連携 | ページは開くがフォーム、予約、決済、地図、動画など特定機能だけ止まるか | 各サービス管理者、制作・連携担当 |
ステータスページや管理画面は、設定を変えずに見られる範囲だけ確認します。ログイン情報が分からない場合は、無理に再設定せず、誰が契約者・管理者かを探します。ドメイン、サーバー、SSL、外部サービスは契約名義や請求先が別になっていることもあるため、制作会社へ連絡するだけでなく、契約管理者を把握しておくと連絡が止まりません。
エラー表示は原因の断定ではなく、確認先を選ぶ手掛かり
ブラウザに出る言葉やHTTPの番号は、どの段階で応答が止まったかを示す手掛かりです。同じ番号でも、実際の原因は設定、負荷、プログラム、上流サービスなど複数あります。一次受付では次のように読み、担当者へ原文を渡します。
| 画面の例 | 読み取れること | 一次受付での行動 |
|---|---|---|
| サーバーが見つからない、名前を解決できない | URLの名前を接続先へ結び付けられていない可能性 | 別回線でも再現するか確認し、ドメイン・DNSの管理先へ状況を渡す |
| 証明書・プライバシーの警告 | SSL証明書、有効期限、対象ドメイン、端末時刻などの確認が必要 | 警告を無理に越えず、画面とURLを記録して管理担当へ連絡する |
| 403 | サーバーは応答したが、閲覧を許可していない状態 | 対象URL、接続元、直前のアクセス制限変更を記録する |
| 404 | そのURLに現在のページが見つからない状態 | トップは開くか、URL変更・削除・公開漏れがないかを確認する |
| 500 | サーバーが予期しない状態で処理を完了できない | 直前更新と発生時刻を添え、サイト・サーバー担当へ渡す |
| 502・503・504 | 中継先の応答、混雑・メンテナンス、上流の待ち時間などを確認する必要がある | 再読み込みを連打せず、状態ページと発生範囲を確認する |
| 白い画面、一部だけ欠ける | サイト本体、表示用ファイル、外部読み込みなど複数の可能性 | 画面全体と開発者向け情報を扱える担当へ、再現条件を渡す |
404が一つの下層ページだけで出る場合と、どのURLでも接続できない場合では、優先する確認先が違います。また、トップページが開いても問い合わせフォームだけ送れないなら、表示障害ではなく機能障害として扱います。ページを開く確認と、重要機能を実際に完了できる確認を分けてください。
直前変更と契約・期限は「いつ何を変えたか」で照合する
障害の直前に作業があったとしても、その作業が原因とは限りません。ただし、調査対象の時間帯を絞る重要な情報です。公開担当、制作会社、サーバー担当、総務・経理の通知を確認し、変更内容と時刻を並べます。担当者名だけでなく、作業した対象と完了時刻を残すと、必要なログやバックアップを探しやすくなります。
- ページ、テーマ、プラグイン、CMS本体、PHPなどの更新や公開
- ドメイン、DNS、サーバー、CDN、SSLの設定変更や移行
- フォーム、予約、決済、地図、動画、計測など外部サービスの変更
- 契約更新、クレジットカード変更、請求失敗、管理メールアドレス変更
- アクセス制限、セキュリティ製品、社内ネットワーク、プロキシの設定変更
ここで確認するのは「変更した事実」です。「更新したからプラグインが原因」「請求メールが来たからドメイン失効」と決めつけないでください。担当者が管理画面、ログ、契約状態を照合して初めて原因を判断できます。とくに期限や支払いはサービスごとに停止条件が違うため、通知の件名、契約番号、対象サービスを正確に共有します。
一次受付が避けたい復旧操作
緊急時ほど、元へ戻せるか分からない変更を重ねないことが重要です。DNSを書き換える、プラグインをまとめて停止する、サーバー内のファイルを削除する、古いかどうか分からないバックアップを上書き復元する、といった操作は、別の機能を止めたり、調査に必要な差分を消したりします。DNSの変更は端末やネットワークの設定にも影響するため、設定に習熟した担当者が現状を控え、戻し方を決めてから行います。
WordPressには致命的なエラーが起きた時に管理者へ案内されるリカバリーモードがありますが、届いたメールや管理画面の通知を確認しただけで、原因となる機能を推測して停止しないでください。管理権限を持つ担当者が、変更履歴、ログ、バックアップ方針と合わせて使うものです。一次受付は、通知が届いた時刻と宛先、記載された情報を安全に共有すれば十分です。
改ざん、不審な管理者追加、見覚えのない転送、情報漏えいが疑われる場合は、通常の表示不具合よりも証拠保全を優先します。ファイル削除や一括更新をせず、セキュリティ対応者へ別経路で連絡してください。パスワードや秘密鍵を通常のチャットへ貼ることも避けます。
担当へは「事実→影響→依頼」の順で連絡する
連絡文の先頭に、確認できた事実と事業影響を置きます。原因の推測や長い経緯から始めると、担当者が緊急度を読み取りにくくなります。件名に発見時刻と影響範囲を入れ、本文では同じ順番で情報を並べます。電話で連絡した場合も、後から同じ内容を文章で残すと、引き継ぎと時系列確認に使えます。
件名：［優先度］ホームページ表示不具合／発見 ○月○日 9:05 対象URL： 発見時刻： 最後に正常だった時刻： 再現した環境： 正常だった環境： 画面の表示・エラー： 影響範囲と事業影響： 直前変更・通知： すでに行った確認： 行っていない操作： 依頼したいこと：一次切り分けと次回連絡時刻の共有 当日の連絡先：
「行っていない操作」も有用です。たとえば「DNS変更なし」「復元なし」「プラグイン停止なし」と書けば、担当者は現状が保たれていると分かります。反対に、すでに操作した場合は隠さず、誰が、何時に、何を、どの画面で行ったかを記録します。
依頼先が分からない場合は、症状の層に近い窓口から始めます。ドメインや証明書の警告なら契約管理者とインフラ担当、サーバーの状態表示や5xxエラーなら保守・サーバー担当、WordPressのエラー通知や直前更新なら制作・保守担当、フォームだけの停止ならサイト担当と外部サービス担当です。複数社へ同時に連絡する時は、誰が全体の窓口かを明記し、同じ操作を別々に実行しないようにします。
緊急度は大きな言葉ではなく、影響で示します。「至急」だけでなく、「社外の複数回線で全ページが開かない」「営業時間中で問い合わせを受け付けられない」「次回状況共有を10時までに希望」のように書くと、受け手が優先順位を判断できます。復旧時刻を確約できない段階では、まず一次回答や次回更新時刻を依頼します。
暫定案内・復旧確認・事後記録を同じ作業にしない
サイトが開かない間に顧客対応が必要なら、復旧作業とは別に暫定案内を決めます。SNS、店舗掲示、電話案内、別ドメインのステータスページなど、サイト障害の影響を受けない経路を使います。案内には、確認済みの発生時刻、影響範囲、利用できる代替手段、次に情報を更新する時刻を載せます。原因が確定していない段階で「サーバー障害です」「攻撃を受けました」と断定しません。
復旧の連絡を受けても、一台でトップページが開いただけでは完了にしません。初動で使った複数端末・複数回線から同じURLを確認し、影響を受けていた主要ページと機能を順に試します。問い合わせ、予約、購入などは、画面が開くことと送信・完了できることを分け、通知メールや管理側の受信まで必要に応じて確認します。キャッシュやDNSの反映差がある場合は、正常な環境と異常が残る環境を継続して記録します。
- 復旧確認：誰が、どの端末・回線・URL・機能を、何時に確認したか
- 利用者向け更新：復旧時刻、現在使える範囲、残っている制限、次回案内
- 技術記録：原因、実施した変更、戻し方、参照したログ・バックアップ
- 業務記録：問い合わせや注文への影響、個別フォローが必要な相手
- 再発防止：監視、更新手順、期限通知、連絡網、権限管理の改善と担当期限
事後記録では、発見から復旧までの時系列を一つにします。「誰が悪かったか」ではなく、検知が遅れた理由、連絡が止まった場所、必要な権限や契約情報が見つからなかった場所を確認します。監視通知があっても受信者が退職者のまま、ドメインの更新通知が経理だけに届く、フォームの送信確認を公開後にしていない、といった運用上の空白は、技術修正とは別に直す必要があります。
平時に一枚の初動表を用意すると、連絡の迷いが減る
表示障害が起きてから、契約者、管理画面、保守範囲、緊急連絡先を探すと、確認より連絡先探しに時間を使います。平時に一枚の初動表を作り、アクセス権限そのものではなく、保管場所と責任者を記載しておきます。パスワードを表へ直接書かず、社内の認められた保管方法へつなぎます。
- 一次受付、技術判断、対外案内、最終承認を担当する人と代行者
- 制作・保守会社、サーバー会社、ドメイン管理、外部サービスの窓口
- 対象URL、管理画面、公式ステータスページ、契約・請求情報の保管場所
- ドメイン・SSL・サーバー・有料機能の更新時期と通知先
- バックアップの対象、取得時刻、復元を決める人、復元後に確認する機能
- 障害時に使う社外案内経路と、案内文を承認する人
保守契約がある場合も、「何かあれば連絡する」だけでは初動が止まります。受付時間、緊急連絡の条件、一次切り分けの範囲、サーバー・ドメイン・CMSの担当境界、復旧作業の承認者を確認します。契約範囲を見直す時は、ホームページの保守契約とは？必要性・種類と契約範囲の決め方も、担当境界を整理する材料になります。
初動表は作成後に一度だけ机上で試します。仮に「トップページと問い合わせが社外から開かない」と置き、担当者がURL、時刻、画面、影響、直前変更を集め、正しい窓口へ送れるか確認します。連絡先が不通、管理者メールが不明、ステータスページが分からない、といった不足は、障害がない時に直す方が安全です。
まとめ｜直す前の切り分けが、復旧を早める
ホームページが表示されない時は、まず同じURLを複数端末・複数回線で確認し、正常な条件と異常な条件を分けます。次に、URL、発見時刻、最後に正常だった時刻、画面、影響範囲、直前変更を一つのメモへ集めます。ドメイン・SSL、サーバー・CDN、CMS、外部サービスの順に確認先を分け、設定を変えずに見えた事実を担当者へ渡してください。
初動の役割は、原因を当てて一人で復旧することではありません。無断変更を増やさず、事業影響を伝え、変更権限と技術判断を持つ人が動ける状態を作ることです。暫定案内、復旧確認、事後記録も分けて行えば、同じ障害が起きた時の判断を速くできます。
