ホームページが表示されないときの対処法｜症状別の原因と復旧手順

ホームページが表示されないときは、設定を変える前に「画面のエラー」と「誰に・どのURLで起きるか」を記録しよう。 DNS、SSL、403、500、真っ白な画面では、最初に調べる場所が違う。キャッシュ削除や再起動を片っ端から試すより、止まっている段階を一つずつ絞る方が、元へ戻しやすいよ。

この記事は、自分や担当先のサイトを公開・運用する人向けの実務ガイド。最初はブラウザだけで確認できる。後半のコマンドは自分が管理する公開URLの読み取りに使い、DNS・公開権限・本番ファイルを自動で変更しない。

急いでいる人へ： 次の表で症状を選び、該当する見出しへ進もう。判断に迷う場合は、症状別チェックを開くと、確認の順序と問い合わせメモを作れるよ。このチェックは実サイトを自動診断せず、選んだ条件から確認候補を示すもの。

まず結論：症状で最初の確認先を分ける

この表は原因の断定ではなく、確認の入口だよ。同じ番号でも、CDN、WAF、Webサーバー、アプリのどこが返したかで調べる先は変わる。CDNは配信を中継する仕組み、WAFはWebへのアクセスを検査・制御する仕組みの一つ。

最初の5分：変更せずに集める六つの情報

1．エラーの文字と発生時刻を控える

「見られない」だけでなく、表示された文字、番号、発生時刻とタイムゾーンを残す。スクリーンショットは役立つけれど、氏名、管理画面、トークン付きURLなどが写っていないか確認してから共有しよう。

ブラウザのエラー文字とHTTPステータスは別の場合がある。DNSや接続の問題では、サイトのHTTP応答に到達していないこともあるよ。

2．URLを一文字ずつ確認する

HTTPかHTTPSか、wwwの有無、ドメインの綴り、パスを確認する。メールに届いた管理用URLや、期限付きの共有URLを、公開トップの確認と混ぜないようにしよう。

比較するなら、同じサービスの公式案内にある正規URLを使う。見覚えのないサイトへ転送されたり、改ざんが疑われたりする場合は、ログインや個人情報の入力を止め、管理者へ連絡する。

3．トップと、問題のページを分けて開く

トップだけ、記事だけ、管理画面だけ、画像だけなど、範囲を分ける。トップが開くなら「ドメイン全体が利用できない」とは限らない。一つのURLしか確認していないなら、その点も記録しよう。

4．別の端末・回線で比較する

同じURLを、利用を許された別端末や、Wi-Fiと携帯回線などで一度ずつ比べる。回線だけを変えたつもりでも、ログイン状態や端末も変わっていないか意識することが大切。

シークレットモードも、保存状態を分ける手掛かりにはなる。ただし匿名になる機能ではなく、ブラウザ条件をすべて同じにするものでもないよ。

5．直前の変更と提供元の障害情報を見る

ドメイン移管、DNS変更、証明書更新、デプロイ、PHP変更、プラグイン更新、WAFやIP制限の変更などを、時刻と一緒に書き出す。同時刻のサーバー・CDN・回線などの公式障害情報も見る。

告知に自分のサービスや対象サーバーが含まれるか、現在も継続中か、利用者側の作業が必要かを確認しよう。障害情報がないことだけで、個別障害を否定しない。

6．戻し方が分かるまで変更を増やさない

変更する場合は、一度に一つに絞り、元の値・対象・時刻・戻し方を残す。元の設定が分からないまま、別の解説から複数の対処を同時に入れると、原因も復元手順も追いにくくなるよ。

DNS・サーバーが見つからない：名前と接続先を確認する

DNSは、ドメイン名から接続先などの情報を調べる仕組み。名前を解決できない問題と、解決した先が応答しない問題を分けよう。

たとえばERR_NAME_NOT_RESOLVEDやServer not foundは、名前解決を調べる手掛かり。一方、タイムアウトには接続先の停止や経路・制御など複数の可能性がある。エラー名だけで、契約切れやDNSの誤設定と決めつけないことが大切だよ。

確認は次の順番で進める。

1. ドメインの綴りと、正規URLを確認する。
2. 契約者が、ドメイン・サーバーの契約状態と通知を確認する。
3. ドメイン側のネームサーバーと、現在の公開先の案内を照合する。
4. 移転直後なら、変更前後のDNSレコードと変更時刻を読む。
5. 必要に応じてA・AAAAなどの回答を、管理者が確認する。

AはIPv4、AAAAはIPv6の接続先に関わるレコード。片方だけ古いなどの状態では、利用環境によって結果が変わることもある。だからといって、確認せずAAAAを消す対処には進まないでね。

変更後の見え方には、キャッシュやTTL、委任先の状態などが関係する。「必ず数分」「必ず72時間待つ」と一律には決められない。待つだけでよいのか、元の設定が誤っているのかを分ける必要があるよ。

コマンドで確認できる人は、利用できる環境で次のように読む。example.comは説明用なので、実作業では自分の公開ホスト名へ置き換える。

nslookup -type=A example.com
nslookup -type=AAAA example.com

表示されたIPアドレスの存在だけで、正しいサーバーだとは判断しない。サーバー会社から案内された公開先と照合しよう。詳しい役割はDNSのA・AAAA・CNAMEで確認できるよ。

SSL・証明書の警告：警告を消す前に名前と期限を見る

HTTPSの証明書では、接続先の名前、有効期限、信頼できる経路などを確認する。端末の日時のずれでも警告が出る場合があるよ。

• URLのホスト名に対して使える証明書か。
• 証明書の有効期間内か、更新処理に問題がないか。
• www付きと、wwwなしの両方を使うなら、それぞれ正しく接続できるか。
• 特定端末だけなら、日時・ブラウザ・組織の通信制御などに差がないか。
• 移転直後なら、新しい接続先に証明書と公開設定がそろっているか。

HTTPSへの転送を入れただけでは、証明書は正しくならない。 証明書の検証は、HTTPの転送先や本文を受け取る前の段階に関わる。wwwなしだけ正常でも、www付きの接続を安全に転送できるとは限らないんだ。

原因が分からない状態で、ブラウザの警告を無視してログインしたり、curlの検証を無効にしたりしない。具体的な見方はHTTPS証明書で分かることへ。

403・404：拒否と、URLがない状態を分ける

403 Forbiddenなら、制限した場所と対象範囲を見る

403は、要求を理解した上で処理を拒否したことを示す。IP制限、WAF、Webサーバーの設定、公開先、権限などが確認候補になるけれど、番号だけでは原因を確定できない。

全ページか一部だけか、公開ページか管理画面か、特定回線だけかを分ける。直前にアクセス制限を変えたなら、その変更とログを優先して照合しよう。

ファイルの権限は、サーバー会社や構成によって条件がある。「表示されないから777」と一律に広げたり、WAFを全部止めたりしない。現在値と必要な権限を確認する。数字の意味はchmodの基本へ。

404なら、公開状態と正規URLを確かめる

URLの入力ミス、記事の削除・移転、予約公開前、公開先のパスなどを確認する。トップが見えるのに記事だけ404なら、まずそのURLの状態から調べる。

すべての404をトップへ転送しても、なくなった内容が復旧するわけではない。代わりの記事があるなら適切な案内を検討し、存在しないURLは正しい404を返す設計にする。見た目のエラー画面と番号の違いは404ページの確認を参考にしてね。

500・503：更新を重ねず、ログと依存先を確認する

500はサーバー内の予期しない問題、503は一時的に処理を提供できない状態などを示す。500だからPHP、503だからアクセス集中と、一対一では決められないよ。

1. 発生時刻と、対象URLを控える。
2. 直前のデプロイ・設定・実行環境の変更を確認する。
3. 同時刻のWebサーバー、アプリ、必要な依存先のログを見る。
4. データベースや外部API、容量など、処理の前提を調べる。
5. 戻す場合は、どの変更を、どのデータと組み合わせて戻すかを確認する。

古いコードだけ戻しても、新しいデータ形式と合わない場合がある。バックアップがあることと、今の構成へ復元できることも別だよ。

503の応答にRetry-Afterがあれば、待ち時間などの案内の一つになる。ただし待てば必ず直る約束ではない。再読み込みや送信を連打せず、処理の状態を確認しよう。基礎は500と503へ。

WordPressの「重大なエラー」が出る場合

WordPressなら、管理者向けメールや公式のリカバリーモードの案内が手掛かりになる。通常のログインとは異なる復旧用の入口を含む場合があるので、そのURLを公開しない。

メールの正当性と対象サイトを確かめ、公式手順に沿って原因の候補を調べる。プラグインを何本も同時に更新・削除したり、テーマやPHPを一度に切り替えたりしない。ファイルや設定を変える前に、控えと戻し方を用意しよう。

この記事は特定のWordPress環境の復旧を実機で保証するものではない。ホスティングの固有手順は、利用中のサービスの案内も確認してね。

真っ白・CSSだけ崩れる：200でも本文と必要な通信を見る

200 OKはHTTP要求の成功を示すけれど、画面の内容が目的どおりと保証する番号ではない。空のHTML、JavaScriptの失敗、CSSや画像の取得失敗などを分ける必要があるよ。

パソコンのChromeなら、開発者ツールのNetworkを開いてページを読み直し、次を見る。

エラーの文字をそのまま検索へ貼る前に、秘密情報が含まれないか見る。HARなどの通信記録には認証情報が含まれる場合もあるので、第三者へ丸ごと渡す前に内容を確認しよう。

キャッシュの影響が疑われても、最初からCookieやパスワードを含めて全部削除しない。開発者ツールでの一時的なキャッシュ無効化など、目的に合う確認を選ぶ。区別はキャッシュとCookie、通信上の指定はno-cacheとno-storeへ。

転送がループする：www・HTTPS・設定箇所を並べて見る

HTTPからHTTPS、www付きからwwwなし、古いドメインから新しいドメイン。複数の転送が別々の場所で動くと、元へ戻る循環が起きることがある。

たとえば、AがBへ、BがAへ返すなら、ルールを一つ増やしても根本の整理にならない。サーバー、CDN、アプリのどこがどのURLへ転送しているかを、時系列に並べよう。

このときも証明書の問題と混ぜない。HTTPSへ安全に接続できること、転送先が正しいこと、最後に期待する本文があることは別の確認だよ。canonicalと301リダイレクトは役割の違いも整理している。

curlで読み取る：終了コードとHTTP番号は別

コマンドを使える人向けの確認例。認証や操作用のURLではなく、自分が管理する公開ページを対象にする。example.comは説明用なので、実際の対象へ置き換えてね。

curl -sS --connect-timeout 5 --max-time 15 -o /dev/null \
  -w 'http=%{http_code} total=%{time_total}s\n' \
  https://example.com/
printf 'curl_exit=%s\n' "$?"

この例は本文を保存せずGETを行い、HTTP番号と所要時間を出す。すぐ次の$?でcurlの終了状態を見る。間へ別のコマンドを入れると、確認対象が変わるよ。

この指定では、HTTPが404や500でも、通信が完了すればcurlの終了コードは0になり得る。 HTTPの成功・失敗と、curlが通信を完了できたかを混同しないようにしよう。

ヘッダーだけを見る-IはHEADを使うため、GETで本文を確認したことにはならない。読み分けはHEADとGETへ。

転送先も確認したいなら、公開URLに限り、上限を付けて次のように読む。-D -は応答ヘッダーを表示する指定で、認証情報やCookieを含む記録はそのまま共有しない。

curl -sS -L --max-redirs 5 --connect-timeout 5 --max-time 15 \
  -D - -o /dev/null https://example.com/

-Lは転送をたどる。この例のように上限を設け、URLとLocationの移動を読む。接続の検証を省略する-kは付けないよ。

編集部の再現例：番号だけで決めない三つのケース

以下はローカルの練習HTTPサーバーで作った架空のケース。実際のサーバー会社の障害や、特定サイトの復旧事例ではないよ。

ケースA：200なのに、画面の材料が空

HTMLの本文を空にして200を返すと、通信の成功と、読めるページがあることは一致しない。curlは通常のGETで0を返しても、本文の確認は別に必要になる。

次の確認はDocumentの本文と必要なファイル。最初からDNSを変更する場面ではない、という切り分けの例だよ。

ケースB：500が返っても、curlは0

練習サーバーで500を返すと、上の-fを付けない確認では、HTTP番号500とcurlの終了コード0を並べて確認できた。

サイト監視でcurlの終了コードだけを見ると、この違いを見落とす場合がある。監視の目的に合う番号と内容を確認しよう。

ケースC：二つのURLが互いへ転送

二つのパスが互いに302を返すケースでは、転送をたどる上限に達し、curlの終了コード47を確認した。転送があること自体と、正常な行き先へ到達できることは別なんだ。

これらの再現はHTTP応答と確認コマンドの検証。DNS障害、証明書、WordPressの本番復旧まで再現したという意味ではないよ。

相談するときのテンプレート：推測より、観察したことを渡す

原因が分からなくても、次の情報があると確認の出発点をそろえやすい。コピー用のテンプレートも用意したよ。ダウンロードだけでは問い合わせを送信しない。

発生日時・タイムゾーン：
対象の公開URL：
画面の文字・HTTP番号：
発生範囲：トップ／特定ページ／管理画面／その他
比較した端末・回線と結果：
直前に変えた内容と時刻：
公式障害情報で確認したこと：
試した操作・結果・元へ戻したか：
現在も継続しているか：

パスワード、秘密鍵、認証コード、復旧用リンクは書かない。個人情報を含む画面やURLは取り除き、契約者向けの正規の窓口へ必要な情報だけを渡そう。

復旧後のチェック：トップが一度開いても終わりにしない

• 正規のHTTPS URLで、期待する本文を読める。
• 問題があった個別ページ、画像、CSS、JavaScriptも確認できる。
• 存在しないURLは、正常ページを装わず適切な404になる。
• wwwやHTTPなど、運用上の入口から適切な場所へ到達する。
• 管理者は、必要な範囲でフォーム・ログインなどの機能も確認する。
• 一時的に変えた制限・保守設定を、意図した状態へ戻した。
• 変更内容、確認結果、残っている問題を記録した。

フォームの確認で、実際の申込や決済を何度も発生させない。許可されたテスト手順や確認先を使うよ。

検索公開も別に確認する。メンテナンスの案内を200で返し続けたり、保守用のnoindexを戻し忘れたりすると、意図しない検索上の状態につながることがある。GoogleのHTTP・ネットワークエラーの資料でも、応答の種類と継続する状態がクロールや登録へ影響すると説明している。

サイトマップを送り直すことだけで、ページの配信障害は直らない。まず公開状態を直し、必要ならSearch Consoleで対象URLを確認しよう。再発予防にはサイト公開チェックリストも使ってね。

よくある質問

自分だけ表示されないとき、Cookieを全部削除すればよい？

最初の対処にはしない。別ブラウザ・端末・回線で範囲を比べ、保存データが関係するかを確認する。Cookieなどの削除はログアウトや入力情報の消失につながる場合があるので、対象と影響を読んでから必要な範囲へ絞ろう。

スマホでは見えて、パソコンでは見えないのはサーバーの問題？

それだけでは決められない。回線、名前解決、保存データ、ログイン状態、表示するURL、ブラウザ機能などが異なる可能性がある。同じURL・同じ回線へそろえるなど、一つずつ比較する。

DNSを変更したので、待っていれば必ず直る？

正しい設定が前提なら、キャッシュなどで見え方に差が出る場合はある。ただし、元のレコードや委任先が誤っていれば、待つだけでは解決しない。変更前後の値と、利用中のサービスの案内を確認しよう。

SSLの警告があるけれど、表示だけなら無視してよい？

原因が確認できないまま進まない。対象の名前、期限、信頼、端末の日時などを調べる。とくにログインや個人情報の入力は、警告を消すことより接続の正当性の確認を優先しよう。

サーバーを再起動すれば直る？

必要な場面もあるけれど、最初の一律の対処ではない。原因や証拠が分かりにくくなり、別の利用者へ影響することもある。提供元の手順、ログ、対象と復旧方法を確認してから行う。

検証の範囲と公式資料

確認日：2026年10月24日。ブラウザの表示名や管理画面は、製品・OS・契約によって異なる。

編集部では、ローカルのHTTP再現サーバーで200・403・404・500・503・空の200・通常転送・転送ループを用意し、掲載したcurlのHTTP番号・終了状態・転送上限の関係を検証した。症状別チェックは実サイトへ通信せず、ブラウザ内で分岐とリセットを確認する。外部サービスの障害や実アカウントの復旧は、この検証の対象ではないよ。

公式資料は、この記事の末尾の「参考・出典」から確認できるよ。