ホームページが​表示されない​原因。​ドメイン・DNS・証明書の​止まり方と、​自分で​確かめる​方法

画面に​出る​言葉で、​どこが​止まったかの​見当を​つける

ホームページが​見られなくなった​とき、​私が​最初に​確かめるのは、​画面に​何と​出ているかです。
ページが​真っ白なのか、​警告が​出るのか、​「サイトに​アクセスできません」と​出るのかで、​疑う​場所が​変わります。

ブラウザが​「サーバーの​IPアドレスが​見つかりませんでした」のように​言う​ときは、​名前から​サーバーの​場所を​引く​段階、​つまり​ドメインか​DNSで​止まっています。
「この​接続では​プライバシーが​保護されません」のような​警告なら、​サーバーまでは​届いていて、​証明書に​問題が​あります。
「500」​「503」のような​数字や、​サーバー会社の​案内ページが​出るなら、​サーバーか​その​契約の​側です。
ページは​出るのに​問い合わせだけが​届かないなら、​フォームと​メールの​側を​見ます。

もう​1つ、​wwwありの​アドレスと、​wwwなしの​アドレスの​両方で​開いてみてください。
片方だけが​開かない​ことは​珍しくなく、​その​理由は​後で​書きます。
スマホの​回線と​パソコンの​回線で​結果が​違う​ときは、​DNSの​書き換えが​まだ​行き​渡っていない​途中かもしれません。

止まり方と、​症状・​確かめ方・防ぎ方

小さな​会社の​サイトが​止まる​場面を、​私たちの​経験と​公開されている​決まりから、​次の​表に​まとめました。
細かい​手順は、​それぞれ詳しく​書いた​記事に​任せています。

表の​後半は、​技術よりも​「誰の​名義か」の​話に​なります。
ドメインも​サーバーも、​名義と​支払いが​自社に​あれば、​困った​ときに​自分で​管理画面に​入って​直せます。

ドメインの​期限切れは、​サイトと​メールが​一緒に​止まる

ドメインが​失効すると、​その​ドメインを​使っている​ものが​まとめて​使えなくなります。
ホームページだけでなく、​info@ のような​会社の​メールアドレスも​同じ​ドメインの​上に​あるからです。
サイトが​見られない​ことより​先に、​取引先からの​「メールが​戻ってくる」という​連絡で​気づく​こともあると​思います。

JPドメインを​管理する​JPRSは、​登録の​期限を​過ぎて​意図せず​廃止に​なった​場合でも、​廃止から​20日以内なら​登録の​回復を​申し込めると​案内しています。
手続きは​契約している​事業者に​相談し、​通常は​手数料が​かかります。
一定の​期間が​過ぎると、​第三者が​その​ドメイン名を​登録できるようになる、とも​書かれています​（⁠JPRS：ドメイン名の​廃止に​関する​注意、​2026年10月5日確認）。
つまり、​気づくのが​遅れる​ほど、​取り戻せなくなる​道に​近づきます。

自動更新に​して​あっても​安心は​できません。
更新の​代金を​引き落とすクレジットカードの​有効期限が​切れていた、​登録した​メールアドレスが​辞めた​担当者の​もので​更新の​案内を​誰も​読んでいなかった、という​形で​止まる​ことが​あるからです。
JPドメインならJPRS WHOISで​ドメイン名を​引くと、​状態と​日付が​表示されます。
2026年10月5日に​自社の​ドメインを​引くと、​状態の​欄は​「Connected (2027/04/30)」でした。
一度​引いてみて、​表示された​期限と、​自社が​把握している​期限が​合っているかを​見ておくと​安心です。
名義を​制作会社から​自社へ​移す手続きは、ドメイン移管の​記事に​書いています。

DNSの​書き換えは、​間違いが​行き渡ってから​気づく

DNSは、​ドメイン名から​「サイトは​この​サーバー、​メールは​この​サーバー」と​行き先を​引く​ための​表です。
サーバーを​変える​ときや​メールの​サービスを​変える​ときに、​この​表を​書き換えます。
止まるのは、​たいていこの​書き換えの​ときです。

よく​あるのは、​ネームサーバー​（その​表を​どこで​管理するか）を​新しい​事業者に​切り替えたのに、​新しい​側に​元の​記録を​移していなかった、という​形です。
サイトの​記録だけ移して、​メールの​記録​（MX）を​移し忘れると、​サイトは​見られるのに​メールだけ届かなくなります。
入力欄に​ドメイン名が​自動で​付く​管理画面で、​ドメイン名まで​打ち込んでしまい、​名前が​二重に​なることもあります。

DNSの​値は、​すぐには​全員に​行き渡りません。
それぞれの​記録には、​ほかの​DNSが​覚えておいて​よい​時間​（TTL）が​付いていて、​その​時間が​過ぎるまでは​古い​値を​返す​場所が​残ります。
私たちが​自社ドメインの​記録を​書き換えた​ときも、​同じ​ドメインを​受け持つ3台の​DNSサーバーの​うち1台だけ、​新しい​値を​返すまでに​約10分​遅れました。
間​違えた​値も​同じように​行き渡り、​直した​値も​同じように​遅れて​届きます。
その​ため、​書き換える​前に​今の​記録を​すべて​書き出し、​TTLを​先に​短くしておきます。
手順はサーバーを​移すときの​確認表に、​作業の​時刻も​含めて​書いています。

今の​値は、​パソコンの​ dig や​ nslookup で​引ける​ほか、​公開されている​DNSを​調べる​道具でも​見られます。
引いた​値を、​控えておいた​値と​並べて​見るのが、​いちばん早い​確かめ方です。

wwwなしの​アドレスは、​CNAMEで​向けられない​ことが​多い

www.example.co.jp と​ example.co.jp は、​利用者には​同じに​見えても、​DNSの​上では​別の​名前です。
wwwなしの​方は、​ドメインの​いちばん上​（apex、​ゾーンの​頂点とも​呼びます）に​あたり、​ここには​特別な​事情が​あります。

wwwありの​名前は、​CNAMEという​記録で​「この​名前は、​あちらの​名前の​別名です」と​書けます。
クラウドの​サービスが​用意した​名前に​向けて​おけば、​サービス側で​サーバーの​住所が​変わっても、​こちらは​何もしなくて​済みます。
私たちの​ www.bundlyze.co.jp も、​配信に​使っている​ Firebase Hosting の​名前​（bundlyze-hp2.web.app）への​CNAMEです​（2026年10月5日に​確認）。

ところが、​DNSの​基本を​定めた​ RFC 1034 は、​CNAMEが​ある​名前には、​ほかの​記録を​置かないよう定めています。
一方で、​ゾーンの​いちばん上には、​その​ゾーンを​受け持つDNSサーバーの​一覧​（NS）と、​管理の​ための​記録​（SOA）が​必ずあります​（⁠RFC 1034 3.6.2節・4.2.1節、​2026年10月5日確認）。
この​2つの​決まりが​ぶつかるので、​多くの​DNSの​管理画面では、​wwwなしの​名前に​CNAMEを​置けません。
置けるように​見える​サービスは、​裏で​行き先の​IPアドレスを​引いて返す、​独自の​仕組みを​持っています。
たとえば​ Cloudflare は​「CNAME flattening」という​名前で、​ゾーンの​いちばん上で​CNAMEを​使えるように​する​機能を​説明しています​（⁠Cloudflare：CNAME flattening、​2026年10月5日確認）。

そうした​機能が​ない​DNSでは、​wwwなしの​名前は​IPアドレスを​直接書く​A（と​AAAA）の​記録で​向ける​ことになります。
その​結果、​wwwありは​クラウドへ、​wwwなしは​前から​使っている​レンタルサーバーへ、と​向き先が​分かれたまま、​何年も​気づかれない​ことがあります。
片方だけが​止まるのは、​この​分かれ目からです。

私たちの​wwwなしの​アドレスで​起きかけた​こと

2026年9月8日、​wwwなしの​ bundlyze.co.jp を​置いていた​レンタルサーバーから、​無料の​証明書の​更新が​終わっていない、という​知らせが​届きました。
有効期限は​9月27日の​朝6時8分でした。

調べると、​更新の​操作を​何度しても​直らない​状態でした。
その​サーバーの​無料の​証明書は、​wwwなしと​wwwありの​2つの​名前を​1枚に​載せる​決まりに​なっていました。
証明書は、​載っている​名前すべてに​ついて、​管理しているのが​自分だと​示せないと​発行されません。
ところが、​wwwありの​名前は​すでに​CNAMEで​ Firebase Hosting に​向いていて、​レンタルサーバーからは​示せませんでした。
前の​節の、​向き先が​分かれた​状態​その​ものです。

もし期限を​過ぎていたら、​https://bundlyze.co.jp/ で​来た​人だけが、​証明書の​警告を​見ることになっていました。
wwwありの​アドレスは​無事なので、​自分たちが​普段開く​ページでは​気づけません。
しかも、​私たちの​名刺には、​wwwなしの​アドレスが​刷ってありました。
名刺を​見て​打ち込んでくれた​人ほど、​警告の​画面に​行き着く​形です。

直し方として、​wwwなしの​名前も​wwwありと​同じ​ Firebase Hosting に​移し、​wwwありへ​転送する​形に​しました。
証明書は​ Firebase Hosting が​自動で​発行し直すと​説明している​仕組みです​（⁠Firebase：カスタム ドメインを​接続する、​2026年10月5日確認）。
DNSを​書き換えたのは​9月14日から​15日に​かけてで、​期限の​12日前に​切り替えを​終えました。
移した​理由と​手順はSSL証明書の​期限切れを​防ぐ​記事に​詳しく​書いています。

振り返ると、​知らせの​メールが​届いたのは​幸運でした。
届かなかったら、​あるいは​誰も​読まない​宛先に​届いていたら、​期限の​朝まで​気づかなかったはずです。

証明書の​期限は、​知らせの​メールを​待たずに​自分で​見る

証明書の​更新の​知らせは、​これからも​届くとは​限りません。
無料の​証明書を​発行している​ Let's Encrypt は、​期限が​近づいた​ことを​知らせる​メールを、​2025年6月4日で​やめると​告知しました。
多くの​利用者が​更新を​自動に​している​ことなどを​理由に​挙げ、​期限を​見張るには、​ほかの​事業者の​見張りの​仕組みを​使うよう​案内しています​（⁠Let's Encrypt：期限の​通知メールの​終了、​2026年10月5日確認）。

期限は、​ブラウザで​アドレス欄の​左に​ある​鍵の​マーク​（または​サイト情報の​マーク）から、​証明書の​詳細を​開けば​見られます。
wwwありと​wwwなしの​両方で​開いて、​それぞれの​有効期限と、​証明書に​載っている​名前を​見てください。
私たちの​ bundlyze.co.jp の​証明書は、​10月5日に​見ると​9月16日に​発行し直されていて、​12月15日までの​期限に​なっていました。
切り替えの​準備で​9月14日に​発行された​証明書とは​別の​もので、​私たちが​何もしないうちに​替わっていました。
自動で​更新される​仕組みでも、​こうして​期限が​動いているかを、​ときどき外から​見ておくつもりです。

サーバー契約と、​作った​会社の​手元に​ある​アカウント

サーバーの​契約が​切れた​ときに​止まるのは、​多くの​場合、​支払いが​止まった​日ではなく、​事業者が​決めた​猶予が​過ぎた​日です。
その​ため、​止まった​時点では、​なぜ​止まったのか社内の​誰にも​分からない​ことがあります。
契約の​名義と​請求の​宛先が、​ホームページを​作った​会社に​なっている​場合は、​な​おさらです。

作った​会社との​付き合いが​終わっても、​サイトは​しばらく​動き続けます。
止まるのは、​ドメインや​証明書、​サーバーの​次の​更新日です。
その​日までに、​ドメインの​管理画面、​DNSの​管理画面、​サーバー、​Search Console と​ Google アナリティクスに、​自社の​アカウントで​入れるかを​試しておきます。
入れない​ものが​あれば、​それが​止まる​候補です。
名義を​移す順番はドメイン移管の​記事に、​サイトと​一緒に​業務システムも​引き継ぐ​場合はシステムを​作った​会社と​連絡が​取れない​ときに​書いています。

移した​後に​止まりやすいのは、​フォームと​メール

サーバーや​DNSを​変えた後、​ページが​表示された​ことで​安心してしまいがちです。
ところが、​問い合わせフォームの​送信は、​古い​サーバーの​仕組みに​頼っていたり、​送信元を​許可する​DNSの​記録​（SPF）が​古いままだったりして、​ページとは​別に​止まります。
ページを​開くだけでは​分からないので、​フォームから​自分​宛てに​1通送り、​届くかどうか、​迷惑メールに​入らないかを​見ます。
届かない​ときの​直し方は問い合わせフォームの​メールが​届かない​ときに​書いています。

止まっている間、​検索は​どうなるか

サーバーが​「500」や​「503」のような​エラーを​返すと、​Googleの​クローラーは、​一時的に​サイトを​見に​来る​ペースを​落とします。
すでに​検索に​載っている​ページは​しばらく​残りますが、​エラーが​続けば、​最終的には​検索から​外れます。
サーバーが​正常に​返すようになれば、​見に​来る​ペースは​少し​ずつ​戻る、と​Googleは​説明しています​（⁠Google 検索セントラル：HTTP ステータス コードと​エラーの​扱い、​2026年10月5日確認）。

半日で​直れば、​検索への​影響を​心配するより、​その間に​来られなかった​人の​ことを​考える​ほうが​先だと​私は​思います。
止まった​日と​直った​日は、​Search Console の​ページの​登録の​状況や、​クロールの​統計情報でも、​後から​確かめられます。

止まらないように、​名義と​期限を​1枚に​しておく

ここまでの​止まり方は、​どれも​「更新の​日」と​「誰の​名義か」が​分かっていれば、​前もって​手を​打てる​ものでした。
まず、​ドメイン、​DNS、​証明書、​サーバー、​計測​（Search Console・Google アナリティクス・タグマネージャー）に​ついて、​どこの​事業者で、​誰の​名義で、​いつ​更新されるかを​書き出します。
私たちも、​自社の​ドメインの​DNSを​切り替える​前に、​全部の​記録を​書き出して​残しました。
DNSは​書き換えると、​元の​値が​どこにも​残らないからです。

そのうえで、​私が​勧めたい​備えは​次のような​ものです。
更新日は、​担当者個人ではなく、​会社で​共有している​予定表に​入れる。
管理画面の​アカウントは​自社名義で​作り、​外の​作業者には​招待で​入ってもらう。
DNSや​証明書を​触った​日は、​何を​どう​変えたかを​日付つきで​残す。
そして、​表示と​証明書の​期限を、​人の​記憶ではなく​仕組みで​見張る。
どれも​手間は​小さく、​止まってから​調べ直す​時間に​比べれば​ずっと​軽いと​感じています。
更新を​誰が​担うかの​決め方はホームページの​更新は​誰が​するかにも​書きました。

bundlyzeは、​大阪市北区の​グラングリーン大阪を​拠点に、​大阪・兵庫を​中心とした​関西の​会社からの​ご相談を​受けていて、​打ち合わせは​Web会議でも​対面でも​できます。
全国から​オンラインでも​ご相談いただけます。
この​記事を​書いた​津嘉山は、​業務システム開発と​AWSを​専門と​する​エンジニアで、​サーバーや​DNS、​証明書も​ふだんの​仕事の​範囲です。

今日の​うちに​できる​ことを​1つ挙げるなら、​自社の​ドメインを​WHOISで​引いて、​表示された​日付を​予定表に​入れておく​ことです。