サイトヘルスとは何を教えてくれる機能か
WordPress の「サイトヘルス」は、その名の通り
「このサイトはいま健康か？どこか具合が悪いところはないか？」
を自動でチェックしてくれる診断ツールです。
PHP のバージョン、HTTPS の設定、REST API の動作、プラグインやテーマの状態、バックグラウンド処理、モジュールの有無など、
普段は意識しづらい“裏側の状態”をまとめて点検し、「良い」「改善が必要」「重大な問題」といった形で教えてくれます。
プログラミングでたとえると、
アプリケーションに対して定期的に healthcheck() を叩いて、
レスポンス内容から「どこが怪しいか」を教えてくれる仕組みです。
これを人間が全部手作業で確認するのはかなり大変なので、WordPress が標準機能として用意してくれているわけです。
どこからサイトヘルスを開くのか
ダッシュボードからの入り方
WordPress にログインしたら、左メニューの「ツール → サイトヘルス」を開きます。
ここに、「ステータス」と「情報」という 2 つのタブがあります。
ステータスでは、
「サイトに重大な問題があります」「おすすめの改善があります」
といった形で、今の状態が評価されます。
情報では、
サーバー情報、PHP 情報、データベース、テーマ、プラグイン、メディア、REST API など、
かなり細かい技術情報が一覧で確認できます。
初心者のうちは、まず「ステータス」タブだけ見れば十分です。
ここに出てくるメッセージを一つずつ読み解いていく感覚で使います。
なぜ「定期チェック」が重要なのか
問題は「ある日突然」ではなく「じわじわ」溜まる
サイトの不調は、
ある日いきなり爆発するというより、
小さな問題が少しずつ積み重なって、ある日限界を超える、というパターンが多いです。
例えば、
古い PHP バージョンのまま放置
HTTPS 設定が中途半端
REST API がブロックされている
バックグラウンド処理が失敗している
プラグインの自動更新が止まっている
こうした「今すぐは致命傷ではないけれど、放置すると危ない」問題は、
普段の画面操作だけでは気づきにくいです。
サイトヘルスを定期的に見ることで、
「まだ動いているけど、ここはそろそろ手を入れた方がいい」
というサインを早めに拾えるようになります。
セキュリティとパフォーマンスの“前兆”を掴める
サイトヘルスは、
「セキュリティ的に弱い設定」や
「パフォーマンスを悪くしそうな要因」
も指摘してくれます。
例えば、
古い PHP バージョンの使用
REST API やループバックリクエストの失敗
必要なモジュールが有効化されていない
などです。
これらは、
今すぐサイトが真っ白になるわけではないけれど、
攻撃に弱くなったり、特定の機能が動かなくなったりする“予兆”です。
天才プログラマー視点で言えば、
「障害が起きてから直す」のではなく、
「障害の芽を潰しておく」ためのチェックポイントとして、
サイトヘルスを使うイメージです。
チームやクライアントに「状態」を説明しやすくなる
サイトヘルスは、
「良好」「改善が必要」「重大な問題」
というラベル付きで状態を見せてくれます。
これは、非エンジニアのメンバーやクライアントに対して、
「今のサイトはどんな状態か」を説明するときにも役立ちます。
例えば、
「重大な問題はないですが、PHP バージョンの更新が推奨されています」
「バックグラウンド処理に失敗が出ているので、スケジュール系の機能に影響が出るかもしれません」
といった形で、
“感覚”ではなく“根拠”を持って話ができるようになります。
サイトヘルスがチェックしてくれる主なポイント
※細かい項目はバージョンや環境によって変わりますが、よく出てくる代表的なものをイメージで押さえましょう。
PHP バージョンやモジュール
「推奨より古い PHP を使っています」
「必要なモジュールが有効になっていません」
といった指摘が出ることがあります。
これは、
セキュリティリスク
パフォーマンス低下
将来の互換性問題
につながる部分です。
PHP バージョンは、
レンタルサーバーの管理画面から切り替えることが多いので、
サイトヘルスで警告を見たら、サーバー側の設定も確認する、という流れになります。
HTTPS（SSL）の状態
「サイトが完全に HTTPS 化されていません」
「アドレスが混在コンテンツになっています」
といった指摘が出ることがあります。
これは、
一部の画像やスクリプトがまだ http:// で読み込まれている
URL 設定が中途半端
といった状態を意味します。
ブラウザの「保護されていない通信」警告や、
SEO の評価にも関わる部分なので、
サイトヘルスで指摘されたら優先度高めで対応したいポイントです。
ループバックリクエストや REST API
「ループバックリクエストが失敗しています」
「REST API にアクセスできません」
というメッセージが出ることもあります。
これは、
WordPress 自身が自分のサイトに対して行う内部リクエストがうまくいっていない、
という意味です。
スケジュールされたタスク（cron）、自動更新、ブロックエディタ、
一部のプラグイン機能などが、REST API やループバックに依存しています。
ここに問題があると、
「なぜか予約投稿が動かない」
「なぜか自動更新が走らない」
といった“謎の不具合”の原因になります。
サイトヘルスは、その「謎」を言語化してくれる存在です。
プログラミングの感覚で「サイトヘルス定期チェック」を捉える
本番環境のヘルスチェックエンドポイントを定期監視するイメージ
Web アプリケーションを本番運用するとき、
多くのチームは /health や /status のようなエンドポイントを用意し、
監視ツールから定期的に叩いて状態を確認します。
WordPress のサイトヘルスは、
それを GUI でやってくれているようなものです。
違いは、
単に「200 OK かどうか」ではなく、
「中の設定やバージョン、モジュールの状態まで含めて診断してくれる」
という点です。
天才プログラマー的には、
「本番環境のヘルスチェックを、ダッシュボードから手動で覗きに行く」
という感覚で、サイトヘルスを定期的に見るとしっくりきます。
「エラーが出てから見る」のでは遅い
多くの人は、
サイトに不具合が出てからサイトヘルスを開きます。
でも、本来の使い方は逆で、
「不具合が出る前に、定期的に状態を確認しておく」
ことに意味があります。
コードでも、
テストを書かずに本番で落ちてから原因を探すのはしんどいですよね。
サイトヘルスは、“本番環境に対する簡易テスト”のようなものです。
月に一度でも、
大きなアップデートの前後でもいいので、
「サイトヘルスを開いて、警告が増えていないかを見る」
という習慣を持つだけで、トラブルの早期発見率はかなり変わります。
具体的な運用イメージ
例1：個人ブログの場合
あなたが個人でブログを運営していて、
プラグインもそこまで多くないとします。
この場合の現実的な運用は、こんな感じです。
月に一度くらい、WordPress にログインしたタイミングで
「ツール → サイトヘルス」を開く
「重大な問題」がないかを見る
「おすすめの改善」があれば、内容を読み、対応できそうなものから手を付ける
これだけでも、
「何年も PHP が古いまま」
「HTTPS が中途半端なまま」
といった放置状態を避けられます。
例2：クライアントサイトを複数管理している場合
フリーランスや制作会社として、
複数の WordPress サイトを管理しているなら、
サイトヘルスは「保守レポート」の材料にもなります。
例えば、
月次レポートで
「今月のサイトヘルス：重大な問題なし、改善提案 2 件（PHP バージョン更新、REST API 設定見直し）」
のようにまとめておけば、
クライアントにも「ちゃんと裏側まで見ている」ことが伝わります。
また、
サイトヘルスの「情報」タブは、
サーバー情報や PHP 設定を共有するときにも便利です。
サポートやトラブルシューティングの際に、
この画面の情報をコピーして渡す、という使い方もできます。
まとめ：サイトヘルスは「プロっぽい運用」への入り口
「サイトヘルスを定期チェックする」というのは、
単にエラーを見つけるためだけではなく、
設定の老朽化を防ぐ
セキュリティとパフォーマンスの前兆を掴む
チームやクライアントに状態を説明できる
“なんとなく運用”から一歩抜け出す
ための習慣です。
プログラミングで言えば、
ログを見ずにコードを書き続けるのではなく、
定期的にログとメトリクスを眺めて、
「今のシステムは本当に健康か？」を確認するのと同じです。
WordPress の左メニューにある「ツール → サイトヘルス」は、
そのための入り口が、最初から用意されている状態です。
もしまだ一度も開いたことがないなら、
まずは一回、今すぐ開いてみてください。
そこに出ているメッセージを一つずつ読み解くこと自体が、
“本番環境を意識したエンジニアの目線”の練習になります。
