ホームページが表示されない・更新が反映されないときの確認手順

自社ホームページが表示されない、または更新した内容が本番サイトに反映されないときは、急いで設定を変更すると状況や調査に必要な記録が分かりにくくなることがあります。この記事は、閲覧者個人の端末を直すためではなく、自社サイトの運営・発注・調整を担う担当者が、事業影響を抑えながら対応するための手順です。

表示不能、スマホだけ古い表示、証明書警告、不審な転送といった状況ごとに、記録すべき事実、緊急共有の目安、最初の連絡先を整理します。緊急度と最初の連絡先を判断し、安全な一次確認を進められるようになります。

設定を変える前に、再現範囲と事業影響を記録し、緊急性の有無で対応を分けます。

01Sectionまず確認したい対象：この記事は自社サイトの運営者向け

対象は、自社が管理・運営するホームページで発生した表示不能や更新未反映です。ドメイン、サーバー、CMS、証明書、CDNなどの管理先が分かれている場合でも、運営者は「どこに原因があるか」をその場で決める必要はありません。まず、再現範囲と事業影響を記録し、確認領域と連絡先を絞ります。

一方、自社とは無関係のサイトが自分の端末だけで閲覧できない場合は、サイト運営側の障害とは限りません。本記事の手順は、自社サイトの公開・保守に関わる担当者が、社内外の関係者へ必要な情報を渡し、復旧判断を進めるためのものです。

02Section設定を変える前に行う初動確認と緊急度の判定

初動では変更作業より先に記録と再現範囲の比較を行い、緊急兆候があれば関係者への共有を優先します。

表示エラーの画面や更新未反映を見つけたら、最初に行うことは設定変更ではなく事実の記録です。特に複数人・複数事業者で対応する場合、誰が、どの環境で、いつ確認したかが復旧の優先順位と調査範囲を決める材料になります。

最初に残すべき記録

PCとスマホ、通常・プライベートブラウズ、Wi-Fi・モバイル回線で比較し、可能なら社外ネットワークでも再現を確認します。比較結果を記録してから、設定変更の要否を判断します。証明書警告や不審な転送がある場合は、確認を繰り返さず後述の緊急共有へ進みます。

緊急対応へ切り替える事業影響の目安

緊急度は、エラーコードだけでは決めません。停止している導線、利用者保護の必要性、複数環境での再現範囲を合わせて判断します。次の状態では、保守担当、ホスティングやサーバーの管理先、社内責任者への共有を優先します。

初動判断は、次の順番で進めると整理しやすくなります。

自社サイトの運営・発注担当として確認しているか
  └─ はい
       └─ URL、時刻、画面、再現環境、直前変更、事業影響を記録する
            └─ PC/スマホ、通常/プライベート、Wi-Fi/モバイル回線、可能なら社外環境で比較する
                 └─ 全ページ停止、主要フォーム停止、TLS警告、不審な転送、顧客情報機能の異常があるか
                      ├─ ある：設定変更を止め、保守・インフラ管理先と社内責任者へ緊急共有する
                      └─ ない：画面症状から確認領域と第一連絡先を絞る
                           ├─ 更新内容が古い：更新未反映の判断表へ進む
                           └─ それ以外：症状別連絡先マトリクスへ進む

03Section画面の症状から確認領域と最初の連絡先を絞る

ドメイン、DNS、サーバー、証明書、CMS保守は役割が異なります。ただし、画面に出た文言だけで、どの管理先の問題か、誰に責任があるかを決めることはできません。ブラウザ、ネットワーク、配信基盤によって表示文言が異なることもあります。

NXDOMAINは、DNSにおける名前の不存在に関する応答です。RFC 8020を参照しつつ、ブラウザの表示とDNS応答を同一視せず、ドメイン登録・DNS・ネームサーバーを優先確認します。ドメイン契約や権限を整理する際は、独自ドメインの基礎と管理方法も確認してください。

500、502、503、504はHTTPステータスコードの分類（MDN Web Docs）でサーバーエラーに分類されます。しかし、サーバー本体だけでなく、アプリケーション、ゲートウェイ、配信経路も確認候補です。TLS警告では、警告を無視して利用するよう案内せず、証明書、対象ホスト名、接続先設定を確認します。TLSの仕組みはTLSの概要（MDN Web Docs）で確認できます。

契約先や管理権限が不明な場合の確認順

管理先が不明なときも、公開情報だけを頼りに設定を変更してはいけません。契約名義と正規権限を確認できる資料を優先します。

1. 1契約書、発注書、保守契約書から、ドメイン、サーバー、CMS、証明書の契約先を確認します。
2. 2請求書、カード明細、更新案内の共有メールから、契約名義と更新時期を照合します。
3. 3情報システム、経理、過去担当者、制作会社が保有する管理一覧を確認します。
4. 4ICANN Lookup FAQを補助手段として使い、公開範囲でレジストラやネームサーバーを確認します。
5. 5公開情報だけでは契約名義や設定変更権限まで確定できないため、正規の契約者確認を経て管理先へ相談します。

04Section更新したのに反映されない、スマホだけ古いときの切り分け

更新未反映では、端末のキャッシュを疑う前に、更新した対象が正しい本番URLか、保存だけでなく公開済みか、公開日時が意図どおりかを確認します。CMSによって名称は異なりますが、公開・下書き・予約公開・限定公開などの状態があり、閲覧可否に影響するためです。

本番URLと公開状態を先に確認する理由

テスト環境や下書きを更新していた、予約公開の日時が未来だった、別URLを確認していた場合、キャッシュ対応をしても本番表示は変わりません。更新対象、正しい本番URL、公開状態、公開日時を確認してから環境差を比較します。

確認結果ごとの次の行動

更新未反映は、表示結果の差から確認領域を絞ります。スマホだけ古い場合も、原因を一つに決めつけず比較結果を残します。

HTTPキャッシュには、ブラウザ以外の共有キャッシュも含まれ得ます。RFC 9111（HTTP Caching）が示すように、保存済みの応答の再利用や再検証には仕組みがあります。そのため、スマホだけ古いという事実だけで、端末、社内ネットワーク、CMS、サーバー、CDNのいずれかに原因を断定しません。

画像・CSS・JavaScriptだけ古い場合の確認観点

本文は新しいのに画像やデザインだけ古い場合は、HTMLと静的ファイルを分けて記録します。古いファイルURL、新旧の画面差、再現環境を添えると、制作保守や配信基盤の管理先が確認しやすくなります。

個別サービスのキャッシュ削除やパージ、デプロイは、対象範囲を誤ると影響が広がることがあります。利用中サービスの公式手順、契約条件、正規権限を確認してから実施してください。

05Section不審な転送や改ざんが疑われる場合は保全と連絡を優先する

TLS証明書の警告と不審な転送は、どちらも優先度が高い現象ですが、同じ原因とは限りません。TLS警告では証明書・対象ホスト名・接続先設定を優先確認し、不審な転送では改ざん、DNS、外部スクリプトなどを含むセキュリティ確認へ切り替えます。

通常の表示障害と分けるべき兆候

意図しない外部サイトへの転送、未知のページや広告、身に覚えのない管理者・設定変更、認証異常、顧客情報を扱う機能の異常は、通常の更新不具合として扱わないほうが安全です。Googleが検出したハッキングや不正なコンテンツの確認補助として、Google Search Centralのセキュリティ情報を確認する方法もあります。ただし、問題表示がないことだけで安全性は判断できません。

初動で避ける操作と連絡順

画面、URL、転送先、発見時刻、影響範囲、直前変更を保全したうえで、保守またはセキュリティ担当とホスティング管理先へ連絡します。社内の情報システム、サイト責任者、必要に応じて法務にも共有し、公開停止、機能停止、認証情報の変更、通知の要否を権限者が判断します。

IPA「中小企業のためのセキュリティインシデント対応の手引き」付録8では、初動、証拠保全、復旧、再発防止を段階的に検討する考え方が示されています。保全、権限管理、再発防止の観点は、Webサイトのセキュリティ対策でも確認できます。

06Section外部へ復旧を依頼するときの伝え方と復旧完了の確認

依頼時は復旧だけか、原因調査や再発防止まで含めるかを分け、復旧後は主要導線まで確認します。

外部への依頼では、症状から原因者を決めつけず、何を依頼したいかを作業単位で伝えます。初動記録がそろっていれば、複数の管理先に同じ説明を繰り返す負担も抑えられます。

障害連絡に必要な情報

以下はメールやチケットへ転記できる短い形式です。分からない項目は空欄にせず、「確認中」と記載すると、調査対象と未確認事項を区別できます。

件名：［緊急／通常］サイト表示・更新不具合の調査依頼
対象URL：
発生確認日時：
影響範囲・事業影響：全ページ／特定URL、フォーム・資料請求・広告LP等
表示内容・エラー文言：
再現環境：PC・スマホ／ブラウザ／Wi-Fi・モバイル回線／社外環境
通常・プライベートブラウズの比較結果：
直前の変更：更新／DNS／証明書／サーバー／CMS・CDN／不明
実施済み確認：本番URL／公開状態／別端末／別回線／社外環境
不審兆候：転送・未知ページ・認証異常の有無
依頼内容：一次切り分け／復旧／原因調査／証跡保全／再発防止
連絡担当者・連絡可能時間：
画面キャプチャ・記録の添付：

依頼範囲と見積もりで確認する条件

復旧だけか、原因調査・保全・再発防止まで含めるかで、依頼範囲は異なります。契約内外、対応時間帯、バックアップの状態、複数事業者の調整によって、費用や対応時期も変わります。契約条件または個別見積もりで、対象範囲と完了条件を確認してください。

復旧後の検収で確認すること

トップページだけでは、復旧完了と判断できないことがあります。事業上重要な導線まで確認し、結果・確認者・確認日時・証跡を障害記録に残します。暫定復旧の場合は、恒久対策の担当者、期限、監視方法も決めます。

07Section次の障害で止まらないためのサイト運営管理台帳

緊急時に契約先や権限者が分からない状態では、技術的な障害そのものより連絡・承認・権限確認に時間がかかります。管理台帳は単なるログイン先の一覧ではなく、誰が、いつ、何を確認し、異常時に誰へ連絡するかを整理する運用表として維持します。

台帳に残すべき最小項目

パスワードそのものを台帳に平文で記載せず、承認済みの保管手段と、その管理責任者を記録します。初動対応を担当者任せにしないための規定・周知は、IPA「従業員の初動対応の規定」も参考になります。

内製継続と外部保守を分ける判断軸

内製が適合しやすいのは、複数人で公開・権限・障害対応の手順を維持し、定めた確認や一次切り分けを自社の許容停止時間の範囲で行える場合です。一方、次の条件が続く場合は、保守範囲と責任分界の見直しが必要になることがあります。

• ドメイン、DNS、サーバー、CDN、セキュリティなど、複数の管理先を継続して調整する必要がある。
• 契約先、正規権限、バックアップ、復元手順のいずれかが担当者に依存している。
• 時間外の一次対応、監視、主要フォームや計測の確認を自社の体制だけでは維持しにくい。
• 障害後の原因調査、再発防止、変更記録の管理まで継続できていない。
• 期待する対応範囲、連絡方法、責任分界を契約で確認できていない。

継続的な点検や保守体制を整える際は、ホームページ保守の進め方も参考にしてください。点検周期は一律に決めるのではなく、契約更新日、担当者変更、構成変更、主要導線の事業影響、監視アラートを契機として自社で定め、実施記録を残します。

08Section状況別に次に取る行動

• 緊急障害の場合：全ページ停止、主要フォーム停止、TLS警告、不審な転送、顧客情報機能の異常があれば、URL・時刻・画面・影響・再現環境を記録し、設定変更より先に管理先、保守担当、社内責任者へ緊急共有します。
• 通常の更新不具合の場合：本番URL、公開状態、公開日時を確認し、端末・ブラウザ・回線・社外環境の比較結果を添えて、CMS/制作保守または該当する管理先へ依頼します。
• 契約・権限が不明な場合：契約書、請求情報、更新通知、社内関係者、過去の管理一覧を確認し、契約・権限・バックアップ・緊急連絡網を管理台帳へ整理します。正規権限が確認できるまで、DNSや証明書などの設定変更を急がないことが重要です。

ホームページの保守体制を見直したい場合

契約先や権限、更新手順、障害時の連絡網を継続的に整備したい場合は、対応範囲と責任分界を整理したうえで、ホームページ保守を依頼できる会社を比較できます。

WordPress制作・保守2949社掲載

ホームページ保守を依頼できる会社を見る