何もしていないのにWEBサイトが壊れました、は本当にあるのか？

WordPressサイトの構築や運用をしていると、この言葉に出会う機会がある。

「何もしていないのに壊れた。管理画面も触っていない」

「前回見たときは問題なかったはず」

うそをついているとは思わない。管理画面を開いた記録がないことも、実際にある。

ただ、体感では8割ぐらい、人の操作が原因になっている。

本人からすると「何もしていない」てしても…

別のスタッフが記事や画像を直していた。何年か前に入れた設定やプラグインが残っていた。通知から更新ボタンを押したこと自体を覚えていない。

だがしかし、本当に何もしていなくてもWEBサイトが壊れることはある。

この記事では、「何もしていないのに壊れた」がなぜ起きるのか、先に何を確認するか、日頃どう備えるかを、運用現場の感覚から整理する。

Webサイトは、一度作ったらそのまま止まっている物に見えやすい。

特に企業サイトは、公開した後に大きく手を入れないことも多い。会社概要、取り扱い先、ニュース、お問い合わせフォーム。これらが表示されていれば、「動いている」ように見える。

ただ、実際のサイトは、自分たちが書いたHTMLや画像だけで成り立っていない。

これらは、サイト所有者が何もしていなくても進む。

例えばPHPは、バージョンごとにサポート期限がある。よくあるのが、「何年も問題なく動いている」ことを理由に、古いPHPやWordPressをそのままにしているケース。

その状態でも、昨日までは表示できる。

しかし、ホスティング会社がPHPを上げたり、プラグインが新しいPHPに対応していなかったりすると、突然白画面になる。

この場合、確かにサイト所有者から見ると「何もしていない」。

何もしていないからこそ、壊れたとも言える。

「何もしていない」ケースで、先に疑うのはこの3つ。

WordPressは、本体、テーマ、プラグインを自動で更新できる。

セキュリティの観点だけ見ると、自動更新は非常に魅力的だ。

ただ、企業サイトで自動更新を信用していると、次のようなことが起きる。

私はクライアントサイトでは、自動更新をあまり信用しない。

理由は簡単で、「更新された時刻」と「壊れた原因」が追いにくくなるから。

夜中にプラグインが更新され、朝、お問い合わせが届かなくなっている。こうなると、当事者から見ると「何もしていない」になる。

自動更新そのものが悪いわけではない。

個人ブログで、バックアップが取れていて、崩れても戻せる状態なら使うこともある。

ただ、企業サイトでフォームや予約、外部連携がある場合、誰がいつ更新したかが追えない状態は避けたい。

SSL証明書も、「何もしていない」で壊れる典型だ。

ブラウザに「この接続はプライベートではありません」と出る。

サイト本体は死んでいないのに、訪問者から見ると壊れたのと同じになる。

現場で見るのは、大きく2通り。

「証明書を入れたから安心」と思っていると、有効期限が来た時点で突然警告が出る。

無料SSLは自動更新できるが、常に成功するとは限らない。

古いVPS、OSのサポート切れ、証明書発行用コンテナの停止。こうした環境では、「無料だし自動だし大丈夫」という話にならない。

サイトの一部は、自分たちのサーバーの外で動いている。

これらは、先方の仕様変更やAPIキーの無効化で止まる。

よくあるのは、トップページの一部だけが欠けるパターンだ。

サイト全体は見られる。しかし地図が出ない、投稿が出ない、フォントが崩れる。

こうなると、「サイトが壊れた」と報告される。

実際には、サイト本体より先方サービス側の変更であることが少なくない。

個人ブログでも同じことは起きる。

このブログはNotionから記事を取得しているので、Notion APIや画像URLの扱いが変わると、自分が記事を書いていなくても表示が壊れる。

運用をしていると、「何もしていない」の中身が少しずつ広がっていることが分かる。

先に確認したいのは、次のような操作がなかったかだ。

これらは、本人からすると「サイトを壊す操作」ではない。

ただ、システムから見ると十分に変更だ。

特に多いのが、自分ではなく、別の人が触っているケースだ。

営業、広告、宣伝、外注先。

管理画面のアカウントが複数あるサイトでは、「自分は何もしていない」が同時に成り立つ。

私が確認するときは、感想ではなく記録を見る。

ここでよく分かるのが、「本人は何もしていないが、誰かが何かをした」という状態だ。

そして、本当に誰も操作していない場合でも、自動更新や証明書、外部サービスが動いていることが多い。

だから私は、「何もしていない」を否定するための質問にはしない。

「意図して変えた人はいない」という前提で、周囲の変更を探すようにしている。

壊れ方によって、先に見る場所は変わる。

私がよく使う切り分けは、おおよそ次の通り。

ここで大切なのは、最初から全部を疑わないことだ。

白画面なのにデザインを直し始めたり、地図が出ないだけなのにWordPress本体を更新したりすると、原因が更に追いにくくなる。

私が最初にするのは、次の3つ。

これが分かると、見る場所が狭まる。

例えば、自分のブラウザだけ古い画面ならキャッシュを先に疑う。

誰の環境でもSSL警告なら証明書を先に見る。

トップだけ地図が欠けるなら、本体より埋め込みを先に見る。

WordPressなら、管理画面に入れるかどうかも大きな分かれ目。

エラーログが見られるなら、推測で直すより先に読む。

Fatal error や Allowed memory size 、プラグイン名が出ていれば、原因はそこにある。

逆に、ログも更新履歴もない場合は、サイト内部より外側を疑う。

証明書、DNS、ホスティング会社の障害情報、外部APIで解決することがある。

「何もしないこと」が安全な運用にはならない。

私が運用していて大切だと感じるのは、次の5つだ。

最低限バックアップさえあれば、なんとかなることが多い。

自動バックアップがあるなら、保持期間と復元方法まで確認する。

「バックアップがあるはず」と「今日戻せる」は違う。

復元テストをしたことがないバックアップは、必要なときに使えないことがある。

セキュリティ更新を後回ししていいわけではない。

ただ、ボタンを押す前に準備する。

企業サイトでは、自動更新よりこの方が安全だと思っている。

時間はかかるが、「いつ何が変わったか」が残る。

逆に、何年も更新しないのも危険だ。

古いWordPressやPHPは、今日は動いていても、攻撃面や後の更新難易度が上がる。

「動いているから触らない」と「自動更新に任せる」の間に、意図した更新を置きたい。

SSL証明書とドメインは、忘れやすい。

更新代行をしている場合でも、期限の1ヶ月前にリマインドを入れておく。

無料SSLなら、自動更新が成功しているかを定期的に確認する。

「入れたから大丈夫」になりやすいものほど、期限管理が必要だ。

管理画面のアカウントが増えるほど、「何もしていない」が起きやすい。

プラグイン更新の通知が複数部署に届くと、誰も判断できなくて放置される。

そのまま放置するか、誰かが独断で更新するか。

どちらも、後からの「何もしていない」につながりやすい。

「何もしていないのにWEBサイトが壊れました」は、本当にある。

ただ、サイトが自然に壊れたというより、周囲が変わったのに、サイト側だけ止まっていたというほうが近い。

こうしたものが重なると、本人が意図していなくても表示が壊れる。

だから、運用で大切なのは「何もしないこと」ではない。

サイトは、手を止めた瞬間から古くなり始める。

壊れないことより、壊れたときに追える状態を作っておくほうが、結局は安心だと思っている。