WordPressのサイトヘルスの見方｜「重大な問題」が出たときの直し方

WordPressのサイトヘルスは、管理画面の「ツール」→「サイトヘルス」で開ける自己診断の画面で、「ステータス」タブに出る「重大な問題」から先に直します。重大な問題は、古いPHPのまま動いている、エラーの内容が訪問者に表示される設定になっている、といったセキュリティや表示に直結する項目です。「おすすめの改善」には運用の方針で残してよいものも混ざるので、全部を消すことを目標にする必要はありません。

この記事は、取引先のWordPressをいくつも預かっている制作会社や保守担当者が、サイトヘルスの結果をどう読んで、どこから手を付けるかを決めるためのものです。

サイトヘルスの開き方と画面の見方

サイトヘルスはWordPress 5.2で本体に入った機能で、プラグインを足さなくても管理者権限があれば誰でも開けます。開き方は2つあります。

• 左メニューの「ツール」→「サイトヘルス」
• ダッシュボードの「サイトヘルスステータス」ウィジェットにあるリンク

画面には「ステータス」と「情報」の2つのタブがあります。「ステータス」タブは問題の一覧で、上から「重大な問題」「おすすめの改善」の順に並び、問題がなかった項目は一番下の「合格したテスト」を開くと見られます。各項目は行をクリックすると説明が開き、何が起きているのかと、直すための操作が書かれています。「情報」タブはWordPress、テーマ、プラグイン、サーバー、データベースなどの設定値を並べた画面で、ここで設定を変えることはできません。

画面上部には「良好」や「改善が必要です」といった全体の判定が出ます。この判定は重大な問題とおすすめの改善の件数から決まるもので、数字が少し動いただけで一喜一憂するものではありません。見るべきなのは、一覧に何が並んでいるかです。

サイトヘルスの結果はいつ更新されるか

サイトヘルスの画面を開くと、その場でテストが走って一覧が作り直されます。それとは別に、WordPress 5.4からは週に1回、WP-Cron（WordPressの予約実行の仕組み）で裏でもテストが実行され、ダッシュボードのウィジェットにはこの最後の結果が表示されます。

保守で気をつけたいのは、ダッシュボードのウィジェットだけを見て判断することです。アクセスがほとんどないサイトや、WP-Cronを止めてサーバー側のcronで動かしているサイトでは、週1回のテストが走っていないことがあり、ウィジェットが何週間も前の結果のままになっている場合があります。気になったら、サイトヘルスの画面を一度開いて最新の結果を出し直すのが確実です。

「重大な問題」と「おすすめの改善」の違い

WordPress公式のドキュメントでは、重大な問題を「セキュリティ上の弱点や深刻な性能問題になりうる部分」、おすすめの改善を「重大ではないが、セキュリティと性能のために直したほうがよい項目」と説明しています。

制作会社の保守としては、次のように扱いを分けると判断しやすくなります。

区分	扱い	例
重大な問題	見つけた週のうちに直すか、直せない理由を記録する	古いPHP、エラーの画面表示、更新待ちのプラグイン、WordPress.orgに接続できない
おすすめの改善のうち、直せば済むもの	次の保守作業でまとめて直す	HTTPSになっていない、使っていないプラグインが停止したまま残っている
おすすめの改善のうち、運用の方針で残すもの	残す理由を顧客ごとの記録に書いておく	予備として残している停止中のテーマ、サーバーの都合で使えない機能

3つ目のように、サイトヘルスの指摘をあえて残す場面はあります。たとえば、子テーマを使っているサイトで親テーマを消すことはできませんし、サーバー会社の仕様で入れられないPHPの拡張モジュールを、制作会社側で解決することもできません。残すと決めた項目は、次に別の担当者が見たときに同じことを調べ直さないよう、理由と一緒に残しておくと引き継ぎが楽になります。

よく出る「重大な問題」と直し方

公式ドキュメントが重大な問題の例として挙げている項目のうち、保守の現場でよく見かけるものを、直し方と一緒にまとめます。

PHPのバージョンが古い

サイトが動いているPHPのバージョンが古く、セキュリティ更新が終わっている、または終わりが近いときに出ます。PHPのバージョンはサーバー会社の管理画面で切り替えますが、いきなり本番で上げると、古いテーマやプラグインがエラーになることがあります。切り替える前に、テーマとプラグインが新しいPHPに対応しているかを確認し、できればステージング環境で一度動かしてから本番を変えます。手順は次の記事で詳しく説明しています。

WordPressのPHPバージョンを確認・更新する方法｜変更前に見る互換性と推奨環境関連記事

エラーを訪問者に表示する設定になっている

wp-config.php で WP_DEBUG_DISPLAY が有効になっていて、PHPのエラーがページにそのまま出る設定のときに出ます。エラーの文面にはサーバー上のファイルの場所などが含まれるため、公開中のサイトでは表示を止めます。不具合を調べるためにデバッグを有効にしたまま、戻し忘れているケースがほとんどです。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

調査を続けたいときは、上のように画面への表示だけを止めて、ログファイルに記録する形にします。ただし、ログの保存先が外から読める場所にあると、それも重大な問題として指摘されます。調査が終わったら WP_DEBUG 自体を false に戻しておくのが一番確実です。

更新待ちのプラグインがある

更新が出ているのに適用されていないプラグインがあると出ます。サイトヘルスはプラグインごとの互換性までは見ていないので、ここで指摘されたからといって全部をその場で更新するより、いつもの更新手順（バックアップを取ってから更新し、表示を確認する）に乗せて片付けるほうが安全です。

WordPress.orgに接続できない、ループバックリクエストが失敗する

サイトから WordPress.org の更新情報を取りに行けない、またはサイトが自分自身にリクエストを送れない（ループバックリクエスト）ときに出ます。どちらも、本体やプラグインの更新、予約投稿、管理画面でのテーマ・プラグインのファイル編集といった機能に影響します。

原因として多いのは、セキュリティプラグインやサーバーのWAFが通信を止めている、ステージング環境にBasic認証をかけている、サーバー側で外向きの通信が制限されている、のいずれかです。直前に入れたプラグインや変えた設定があればそれを疑い、心当たりがなければサーバー会社に「サイトからWordPress.orgとサイト自身への通信が止まっていないか」を問い合わせます。

バックグラウンド更新が動いていない

自動更新が設定どおりに動かない状態のときに出ます。ファイルの書き込み権限、wp-config.php の自動更新を止める定数、バージョン管理のフォルダ（.git など）の有無などが原因になります。自動更新をどこまで使うかの考え方は次の記事にまとめています。

WordPressの自動更新は有効にすべき？設定・無効化の方法と壊れにくくする条件関連記事

「情報」タブはサポートへの問い合わせに使う

「情報」タブは、WordPressのバージョン、使っているテーマとプラグインの一覧、PHPのバージョンやメモリの上限、データベースのサイズなどを1つの画面にまとめたものです。上部の「サイト情報をクリップボードにコピー」を押すと、この内容をテキストでまとめてコピーできます。

プラグインの作者やサーバー会社に不具合を問い合わせるとき、最初に聞かれるのはほとんどがここに載っている情報です。問い合わせの最初にこのテキストを添えておくと、「PHPのバージョンは？」「ほかに何のプラグインが入っていますか？」というやり取りを1往復減らせます。

ただし、コピーした内容にはサーバー上のディレクトリの場所やWordPressの定数の値なども入ります。相手を確認して送るぶんには問題ありませんが、サポートフォーラムのように誰でも読める場所には、必要な部分だけを抜き出して貼るほうが安全です。

預かっているサイトが多いときの見方

サイトヘルスは、そのサイトの管理画面にログインしないと見られません。10サイト、20サイトと預かっていると、毎週全サイトのサイトヘルスを開いて回るのは現実的ではなく、気づいたときには重大な問題が何週間も放置されていた、ということが起こりがちです。

NexraOneでは、サイトヘルスと同じ方向の情報を、複数サイトの一覧から確認できます。PHPのサポート終了、SSL証明書の期限、WP-Cronやメール送信の失敗、Fatal Errorなどを0〜100点のヘルススコアにまとめ、サイトごとの詳細画面ではデバッグ表示や検索エンジンへの公開設定といったWordPressの設定も確認できます。サイトヘルスの項目をそのまま取り込んでいるわけではないので、細かい指摘は各サイトのサイトヘルスで見る、という使い分けになります。点数の計算方法と、設定診断で見ている項目は次のページで公開しています。

• ヘルススコアの計算方法
• WordPress設定診断の見方

複数サイトの更新をまとめて回す方法は、次の記事で整理しています。

複数のWordPressサイトをまとめて更新する方法｜管理画面、WP-CLI、管理ツールの違い関連記事

参考にした公式情報

• Site Health Screen（WordPress.org Documentation）
• wp_dashboard_site_health()（WordPress Developer Resources）
• WP_Site_Health::maybe_create_scheduled_event()（WordPress Developer Resources）

※2026年10月21日時点の情報です。サイトヘルスのテスト項目はWordPressのバージョンによって増えたり変わったりします。