WordPressの管理画面にある「サイトヘルス」は、サイトのセキュリティとパフォーマンスの状態を自己診断してくれる機能です。「改善が必要」「致命的な問題」といった表示が出て不安になった方も多いはずです。ただ、表示される項目の多くは、意味と対処法さえ分かれば自分で解消できます。サイトヘルスは、管理画面の「ツール → サイトヘルス」にあります。
この記事では、サイトヘルスのステータスに表示される項目を重要度別に網羅し、それぞれの原因と対処方法を解説します。あわせて、自分で直せるもの・サーバー会社に相談すべきもの・制作会社に任せたほうがよいものを切り分けて示します。上から読めば、自分のサイトに出ている問題をひとつずつ対応できる対処リファレンスとして使えます。
サイトヘルスとは
サイトヘルスは、WordPress 5.2から標準搭載された自己診断機能です。サイトの環境を自動でチェックし、セキュリティやパフォーマンス上の問題点を教えてくれます。画面は2つのタブに分かれています。
- ステータス: セキュリティ・パフォーマンスの問題を「致命的な問題」「おすすめの改善」「問題のない項目」に分けて表示します
- 情報: WordPressのバージョン、サーバー、データベース、テーマ、プラグインなど、サイトの構成情報を一覧で確認できます
定期健診のようなもので、問題があれば早めに気づいて対応できます。
サイトヘルスの確認方法
管理画面の左メニューから「ツール → サイトヘルス」をクリックすると、サイトヘルスの画面が表示されます。開いた画面の上部にある「ステータス」と「情報」のタブを切り替えて確認します。また、管理画面にログインした直後のダッシュボードにも「サイトヘルスステータス」のウィジェットが表示され、問題の件数をすぐに確認できます。ウィジェットの内容をクリックすると、サイトヘルスの詳細画面に移動します。なお、この画面の表示には管理者権限が必要です。編集者や投稿者の権限ではサイトヘルスは表示されません。
ステータスの3つの区分
ステータスタブの項目は、重要度で3つに分かれます。
- 致命的な問題: セキュリティ上の脆弱性や、深刻なパフォーマンス低下につながる問題。優先して対応します
- おすすめの改善: 必須ではないものの、セキュリティやパフォーマンス向上のために直したほうがよい項目
- 問題のない項目: テスト済みで問題なしと判定された項目
「致命的」という強い言葉が出ても、必ずしもサイトがすでに攻撃されているわけではありません。落ち着いて内容を確認してください。
「致命的な問題」の項目と対処方法
まず優先して対応する項目です。
REST API でエラーが発生（利用できない）
REST APIはWordPressの内部機能が使う仕組みで、止まると管理画面の一部が正常に動きません。原因の多くはプラグインの競合や、セキュリティプラグイン（SiteGuard WP Pluginなど）の制限、サーバー側の設定です。プラグインを一時的にすべて停止し、ひとつずつ有効化して原因を特定します。SiteGuardを使っている場合は、除外設定を見直します。
スケジュールされたイベント（WP-Cron）が機能していない
WordPressは予約投稿や自動更新などを「WP-Cron」という仕組みで実行します。これが動かないと、更新やバックアップの自動処理が止まります。プラグインの競合や、wp-config.phpでWP-Cronを無効化している設定が原因になります。サーバー側の本物のcronに切り替えている場合は、その設定が正しいかを確認します。
1つ以上の必須モジュールが存在しません
WordPressの動作に必要なPHPモジュールがサーバーに入っていない状態です。これはサーバー環境の問題なので、自分では解決できません。利用しているレンタルサーバー（ホスティング会社）に問い合わせて、必要なモジュールを有効化してもらいます。
誰もが参照可能なファイルにエラーを書き出します
デバッグ用のエラーログ（debug.log）が、誰でもアクセスできる場所に出力されている状態です。エラー内容からサイトの構造が推測される恐れがあります。wp-config.phpのデバッグ設定（WP_DEBUG_LOG）を見直し、本番環境ではログの公開を止めます。
非常に古いバージョンのPHPで動作しています
サポートの切れた古いPHPは、セキュリティ上の危険があります。レンタルサーバーの管理画面からPHPのバージョンを、WordPressが推奨する新しいもの（8系）に切り替えます。切り替え後は、サイトが正常に動くかを必ず確認します。
「おすすめの改善」の項目と対処方法
致命的ではないものの、直しておきたい項目です。数が多いので、系統ごとに整理します。
更新に関する項目
| 表示される項目 | 対処方法 |
|---|---|
| WordPressの更新が可能 | ダッシュボード → 更新から本体を更新する |
| 更新可能なプラグインがあります | 該当プラグインを更新する |
| 更新可能なテーマがあります | 該当テーマを更新する |
| 停止中のプラグインを削除してください | 使っていないプラグインを削除する |
| 停止中のテーマを削除してください | 使っていないテーマを削除する |
| デフォルトテーマを利用可能にしましょう | 公式のデフォルトテーマ（Twenty〜）を1つ残しておく |
更新系は自分で対応できる項目です。作業前にバックアップを取っておくと安心です。
PHP・データベース・モジュールに関する項目
- サイトが古いバージョンのPHPを実行しています: レンタルサーバーの管理画面でPHPを新しいバージョンに切り替えます
- 古いデータベースサーバー: MySQLやMariaDBのバージョンが古い状態です。ホスティング会社に相談します。実害が出ることは少ないため、優先度は高くありません
- 1つ以上の推奨モジュールが存在しません: imagickなどの推奨モジュールがない状態です。ホスティング会社に有効化を相談します
通信・エラーに関する項目
- HTTPリクエストがブロックされています: 外部との通信を止める設定（wp-config.phpのWP_HTTP_BLOCK_EXTERNAL）が入っています。必要な通信まで止めていないか確認します
- WordPress.orgに接続できませんでした: 更新情報の取得に必要な通信ができない状態です。サーバーの外部通信設定や、SiteGuardでsite-health.phpが除外されていないかを確認します
- サイト訪問者へエラー表示を行う設定になっています: デバッグ表示（WP_DEBUG_DISPLAY）が有効な状態です。本番環境ではオフにします
- ループバックリクエストが完了できませんでした: サイトが自分自身に通信できない状態です。プラグインの競合や、Basic認証、PHPセッションが原因になります
- PHPデフォルトタイムゾーンが無効です / アクティブなPHPセッションが検出されました: プラグインやテーマのコードでsession_start()が使われていることが原因の場合があります。REST APIやループバックの妨げにもなるため、該当プラグインを特定します
キャッシュに関する項目
キャッシュ系はパフォーマンス改善のための項目で、いずれも「必須」ではありません。対処法とあわせて、対応すべきかの判断も示します。
永続オブジェクトキャッシュを使用してください
データベースへの問い合わせ結果をメモリ上（APCu・Redis・Memcachedなど）に保存し、読み込みを速くする仕組みを促す項目です。項目の説明文に「次のオブジェクトキャッシュサービスをサポートしているようです」と、利用中のサーバーが対応している仕組み（APCuなど）が表示されます。対処方法は次のとおりです。
- まずレンタルサーバーの管理画面に、オブジェクトキャッシュをワンクリックで有効化する設定がないか確認します。あればそれが最も簡単です。
- サーバーがAPCuに対応している場合は、プラグイン「APCu Manager」をインストールして有効化します。これでキャッシュのドロップインが設置され、警告が消えます。
- サーバーがRedisに対応している場合は、「Redis Object Cache」プラグインを使い、サーバー側でRedisを有効化します。
- 有効化後、サイトヘルスを再読み込みし、警告が消えてサイトが正常に表示されるかを確認します。古い内容が表示される場合はキャッシュをクリアします。
小規模なサイトでは必須ではないため、対応しなくても問題はありません。ただしサーバーが対応している場合は、低リスクで管理画面やデータベース処理を速くできます。
ページキャッシュが検出されませんでした
ページの静的なコピーを保存して返すページキャッシュが検出されない状態です。この項目には「サーバーのレスポンスは良好です」と併記されることがあり、その場合はサーバーの応答速度自体は基準（中央値600ミリ秒）を下回っていて、優先度は高くありません。対処方法は次のとおりです。
- ページキャッシュプラグイン（WP Super Cache、W3 Total Cache、WP Fastest Cacheなど。サーバーがLiteSpeedならLiteSpeed Cache）を導入して有効化します。キャッシュのレスポンスヘッダーが付与され、警告が消えます。
- またはサーバー側やCDN（Cloudflareなど）のキャッシュ機能を有効化します。これでも同様にヘッダーが付きます。
- 有効化後、サイトヘルスを再読み込みして確認します。
応答速度がすでに良好で小規模なサイトなら、このままでも問題ありません。なお、ページキャッシュは問い合わせフォームやログイン中の表示など動的なページと競合することがあります。導入時は除外設定を行い、表示が崩れないかを確認してください。
HTTPSに関する項目
HTTPSを使用していません: 通信が暗号化されていない状態です。SSL証明書を設定し、サイトをhttps化します。証明書の設定はサーバー側、サイト内のURL置き換えは制作会社に相談すると確実です。
対処を「自分・サーバー会社・制作会社」で切り分ける
サイトヘルスの項目は、対応する相手が変わります。無理に自分で触るとサイトを壊しかねない項目もあるため、次の切り分けを目安にしてください。
| 対応先 | 主な項目 |
|---|---|
| 自分でできる | 本体・プラグイン・テーマの更新、停止中の削除、デフォルトテーマの確保、キャッシュプラグインの導入 |
| サーバー会社に相談 | PHPバージョンの切り替え、必須・推奨モジュール、古いデータベース、永続オブジェクトキャッシュ、HTTPリクエストの制限 |
| 制作会社に相談 | REST APIエラーやループバックの原因切り分け、WP-Cronの不具合、デバッグ設定の見直し、SSL化、プラグイン競合の調査 |
「どこに頼めばいいか分からない」項目が出たら、まずはサイトを制作・保守している会社に相談するのが確実です。
「情報」タブでわかること
情報タブでは、サイトの構成が一覧で確認できます。トラブル時に制作会社やサーバー会社へ状況を伝えるときにも役立ちます。主な内容は次のとおりです。
WordPress本体の情報、ディレクトリとサイズ、現在のテーマ、停止中のテーマ、使用中のプラグイン、停止中のプラグイン、メディア処理、サーバー、データベース、WordPress定数、ファイルシステムパーミッション。画面下部の「サイト情報をクリップボードにコピー」を使えば、これらの情報をまとめて相手に渡せます。
サイトヘルスが表示されないときの対処
「ツール」にサイトヘルスが見当たらない場合、次の原因が考えられます。
- 管理者権限がない: サイトヘルスは管理者のみ表示されます。権限を確認します
- WordPressのバージョンが古い: 5.2未満には機能がありません。本体を更新します
- プラグインやテーマが非表示にしている: メニューを制限するプラグインが原因の場合があります。一時的に停止して確認します
サイトヘルスを非表示にする方法
ダッシュボードのウィジェット表示が気になる場合は、消せます。ダッシュボード画面の右上「表示オプション」を開き、「サイトヘルスステータス」のチェックを外します。機能自体は残るため、必要なときは「ツール → サイトヘルス」から確認できます。
「良好」でも安心しきらない
覚えておきたいのは、サイトヘルスが「良好」でも、それは「サイトが安全」を意味しないという点です。サイトヘルスがチェックするのは主に環境や設定であり、既知の脆弱性のスキャンや、不正アクセス・改ざんの監視までは行いません。「良好」を確認したうえで、更新の徹底や外部ツールでの点検も欠かさないでください。自分でできる点検の手順はWordPressのセキュリティチェック方法 自分でサイトの安全を点検する手順にまとめています。
サイトヘルスを活用するポイント
サイトヘルスは、表示された問題に一度対応して終わりではなく、定期的に確認して使うことで効果を発揮します。運用のポイントを3つ挙げます。
定期的にチェックする習慣をつける
WordPress本体やプラグインの更新は頻繁に発生し、サーバー環境も変わります。昨日まで「良好」だった項目が、今日は「改善が必要」に変わることもあります。月に一度はサイトヘルスの画面を開き、新しい問題が出ていないかを確認してください。
対応に優先順位をつける
表示された項目すべてに一度に対応する必要はありません。まず「致命的な問題」から片づけ、次に「おすすめの改善」をセキュリティに関わるものから順に対応します。パフォーマンス系の項目は、サイトの規模や状況に応じて判断します。
改善したら再チェックする
項目に対応したら、サイトヘルスの画面を再読み込みして、問題が消えたか、サイトが正常に表示されるかを確認します。対応した結果、別の不具合が出ていないかもあわせてチェックします。
