メインコンテンツへスキップ
← ブログ一覧

ホームページは公開後が本番|WordPressを保守しない5つのリスク

ホームページは公開後が本番

WordPressを保守しない場合に起こり得る5つのリスク

ホームページを公開した日は、ひとまず肩の荷が下ります。

文章や写真を何度も確認し、ようやく公開までたどり着いたのですから
「これで完成した」
と感じるのは自然なことです。

しかし、WordPressで作られたホームページは、完成したパンフレットとは異なります。

WordPress本体、テーマ、プラグイン、サーバー、ドメインなどが組み合わさって動くシステムであり、公開後も周囲の環境は変わり続けます。

ホームページを何も変更していなくても、安全性まで公開時のままとは限りません。

ホームページの公開日は、制作の終わりではなく、運用の始まりです。


リスク1 古いWordPressが攻撃の入口になる

WordPress本体、テーマ、プラグインには、不具合やセキュリティ上の問題を修正する更新が配信されます。

更新を長期間放置すると、既に修正方法が公開されている弱点を残したまま、ホームページをインターネットへ公開し続けることになります。

標準構成でも影響したwp2shell

2026年7月17日、WordPress本体に関する重大な脆弱性が公表されました。

この問題はwp2shellと呼ばれ、WordPress 6.9.0から6.9.4および7.0.0から7.0.1では、二つの脆弱性を組み合わせることで、ログインしていない外部の攻撃者がサーバー上で不正なコードを実行できる可能性がありました。

特に怖いのは、怪しいプラグインやテーマを追加していない、標準的なWordPress環境でも攻撃対象になり得たことです。

悪用された場合は、ホームページの改ざん、情報の窃取、不正なプログラムの設置などにつながる可能性が指摘されています。

管理者が危険な操作をしたわけではありません。

昨日まで普通に表示されていたWordPress本体に問題が見つかり、更新しないまま使い続けること自体がリスクになった事例です。

WordPress公式は修正版を公開し、重大性を考慮して、影響を受けるサイトへの強制自動更新も有効化しました。

ただし、自動更新を有効にしているから確認不要とは限りません。

更新が正常に完了したか、使用中のバージョンが修正版になっているか、不審な管理者やファイルが追加されていないかを確認する必要があります。

「最近ホームページを触っていないから問題ない」

wp2shellは、その考え方が通用しないことを示しました。


リスク2 更新後の不具合に気付けない

セキュリティのために更新は必要です。

一方、WordPress本体、テーマ、プラグイン、サーバー側のPHPなどの組み合わせによっては、更新後に表示や機能へ影響が出る場合があります。

例えば、次のような不具合です。

  • レイアウトが崩れる
  • 画像やメニューが表示されない
  • スマートフォンだけ表示がおかしい
  • 問い合わせフォームを送信できない
  • 管理画面へ入れない

WordPress公式も、プラグインやテーマを最新状態に保つことを推奨していますが、更新前の定期的なバックアップも案内しています。

必要なのは、更新しないことでも、確認せずに一斉更新することでもありません。

更新前に戻せる状態を作り、更新後に主要ページと機能を確認することです。


リスク3 バックアップがなく、元へ戻せない

更新、操作ミス、不正アクセスなどで問題が起きたとき、正常な状態のバックアップがあれば復旧できる可能性があります。

WordPressのデータは、一つの場所だけに保存されているわけではありません。

画像、テーマ、プラグインなどのファイルに加え、記事、固定ページ、設定などを保存するデータベースがあります。完全に復元するには、原則として両方のバックアップが必要です。

確認すべき点は次のとおりです。

  • ファイルとデータベースの両方が対象か
  • 定期的に取得されているか
  • 複数世代が残っているか
  • サーバーとは別の場所にも保存しているか
  • 実際に復元できるか

バックアップファイルが存在することと、業務で使える状態まで復旧できることは別です。

一度も復元方法を確認していなければ、事故が起きた日に初めて手順を調べることになります。


リスク4 問い合わせを受け取れない

問い合わせフォームは、画面に表示されているだけでは正常と判断できません。

送信操作は完了しても、通知メールが会社へ届いていない場合があります。

送信先アドレスの変更、迷惑メール判定、フォームの不具合など、原因はさまざまです。

反対に、大量の営業メールやスパムによって、本来の問い合わせが埋もれることもあります。

問い合わせが少ないのではなく、届いていない。

その状態に自社だけが気付いていない可能性があります。

定期的にテスト送信を行い、次の点を確認します。

  • フォームから送信できるか
  • 管理者へ通知が届くか
  • 自動返信が届くか
  • 送信先が現担当者になっているか
  • スパム対策が正常な問い合わせを妨げていないか

月に一度でも、自分で問い合わせを送ってみることには意味があります。


リスク5 契約や掲載情報が古くなる

ホームページには、WordPress以外にも管理が必要なものがあります。

代表的なのがドメインとサーバーです。

契約者のメールアドレスが退職者のものになっている、支払い用カードが古い、更新案内を誰も確認していないといった状態では、契約を継続できない可能性があります。

掲載内容も少しずつ現状とずれていきます。

  • 退職者の名前が残っている
  • 営業時間や住所が古い
  • 終了したサービスを掲載している
  • 料金や対応範囲が実態と異なる
  • プライバシーポリシーが現在の運用と合っていない

古い情報を掲載し続けることは、顧客へ誤った案内をすることでもあります。

保守では、システムだけでなく、契約情報と掲載内容も確認する必要があります。


保守は、毎月作り直す契約ではない

ホームページ保守の中心は、毎月大きな変更を加えることではありません。

何も問題が起きていないように見える状態を維持することです。

主な作業には、次のようなものがあります。

  • 更新情報の確認
  • 更新前のバックアップ
  • WordPress、テーマ、プラグインの更新
  • 更新後の表示確認
  • 問い合わせフォームのテスト
  • 不要なアカウントやプラグインの整理
  • ドメインやサーバー契約の確認
  • 不具合発生時の初動対応

何も起きなかった月にも価値があります。

問題が表面化する前に状態を確認することが、保守の役割です。


自社管理と外部保守を使い分ける

すべてのホームページに、同じ内容の保守契約が必要なわけではありません。

社内にWordPressを管理できる担当者がいれば、自社で更新や確認を行う方法もあります。

通常は自社で管理し、問題が起きたときだけ外部へ依頼する方法もあります。

社内に担当者がおらず、更新やバックアップが後回しになる場合は、定期保守を外部へ任せる方が現実的です。

重要なのは、誰が管理するのかを曖昧にしないことです。


TrusKiteが支援できること

TrusKiteでは、契約内容に応じて次の保守を行います。

  • WordPress本体、テーマ、プラグインの更新
  • 更新前のバックアップ
  • 更新後の表示確認
  • 問い合わせフォームの動作確認
  • スパムや営業メールへの対策
  • 軽微な文章や画像の修正
  • ドメインやサーバー契約の確認
  • 不具合やセキュリティ問題の初動調査
  • 必要に応じた復元や修正

普段の記事投稿はお客様が行い、システム部分だけをTrusKiteが管理する方法も可能です。

保守範囲を曖昧にせず、月額料金に含む作業と、別途見積もりになる作業を事前に整理します。


公開後も使い続けられてこそ、ホームページになる

ホームページを作った目的は、公開することだけではなかったはずです。

会社を知ってもらうこと。

サービスを正しく伝えること。

問い合わせを受け取ること。

その目的を果たし続けるには、公開後の管理が必要です。

派手な変更を毎月行う必要はありません。

更新し、確認し、問題が起きたときに戻せる状態を保つ。

ホームページは公開後が本番です。

TrusKiteでは、制作だけでなく、公開後も安心して使い続けられるよう、企業の運用体制に合わせた保守をご提案します。


※保守内容、対応頻度、軽微修正の範囲、緊急対応および復旧作業は、個別の見積もりと契約内容に基づいて定めます。

※更新や保守を行っても、すべての不正アクセス、不具合、データ消失またはサービス停止を防止できるものではありません。