WordPressサイトヘルスの改善方法｜重大な問題・警告別の原因と対処手順│Webクラス

WordPressサイトヘルスの警告と改善を表現した診断ダッシュボードのイメージ

WordPressのサイトヘルスに「重大な問題」や「おすすめの改善」が表示されると、サイトの安全性や動作に問題がないか気になるものです。警告には早めに対応すべきものもあれば、現在の利用環境を確認してから判断できるものもあります。

サイトヘルスを改善するには、警告の種類を確認し、実際に影響している機能から優先的に対処することが大切です。この記事では、管理画面での確認方法と、代表的な警告ごとの原因・対処手順を解説します。

1 WordPressのサイトヘルスとは？改善前に知っておきたいこと
2 サイトヘルスの確認方法と改善の優先順位
- 2.1 管理画面で診断結果を確認する
- 2.2 警告の内容から優先順位を決める
3 サイトヘルスを改善する前にバックアップを取る
4 REST APIでエラーが発生する場合の改善方法
- 4.1 エラーメッセージと応答コードを確認する
- 4.2 セキュリティ設定やプラグインを確認する
5 ループバックリクエストが失敗する場合の改善方法
- 5.1 まず通信エラーの種類を確認する
- 5.2 サーバー会社へ相談する場合の伝え方
6 予約イベントが遅延・失敗する場合の改善方法
- 6.1 予約投稿と定期処理の状態を確認する
- 6.2 サーバー側の定期実行を利用する場合
7 PHPのバージョンが古い場合の改善方法
- 7.1 現在のPHPバージョンを確認する
- 7.2 PHPを安全に更新する手順
8 WordPress本体・プラグイン・テーマの更新に関する警告
9 ページキャッシュやオブジェクトキャッシュの改善方法
- 9.1 ページキャッシュの警告
- 9.2 永続オブジェクトキャッシュの警告
10 自動読み込みオプションの容量に関する警告
11 サイトヘルスの警告が消えない場合の確認事項
12 WordPressサイトヘルスのよくある疑問
13 まとめ｜サイトヘルスは原因を確認してから改善する

WordPressのサイトヘルスとは？改善前に知っておきたいこと

サイトヘルスは、WordPress本体・プラグイン・サーバー環境などの状態を診断する標準機能です。WordPress 5.2で導入され、管理画面の「ツール」→「サイトヘルス」から利用できます。

診断結果は主に次の3種類に分けられます。

重大な問題：セキュリティや動作性能に大きく影響する可能性がある項目です。優先的に確認します。
おすすめの改善：安全性や性能の向上につながる改善候補です。環境や必要性に応じて対応します。
問題のない項目：診断に合格した項目です。基本的に追加対応は不要です。

サイトヘルスは、サイトのすべての不具合を発見できる仕組みではありません。警告がない場合でも、表示速度、記事の表示、問い合わせフォーム、予約投稿などが正常に動作しているかは別途確認する必要があります。

サイトヘルスの確認方法と改善の優先順位

管理画面で診断結果を確認する

WordPressの管理画面にログインします。
左側の「ツール」から「サイトヘルス」を選択します。
「ステータス」タブで重大な問題とおすすめの改善を確認します。
警告項目を展開し、詳細なメッセージと対象機能を読みます。
必要に応じて「情報」タブからWordPressやサーバーの構成情報を確認します。

「情報」タブには、WordPressのバージョン、PHP、データベース、プラグインなどの技術情報が表示されます。サーバー会社やプラグイン開発元へ相談する場合にも役立ちます。

ただし、情報のコピー機能で取得した内容には、サイト構成やサーバー環境に関する情報が含まれます。公開掲示板などへ貼り付ける場合は、URLや環境情報などの公開範囲を確認してください。

WordPressのサイトヘルスで重大な問題とおすすめの改善を確認するステータス画面

警告の内容から優先順位を決める

警告が複数ある場合は、表示順だけでなく、実際の不具合やセキュリティへの影響を確認します。

警告・症状	最初に確認すること	対処手順
更新やセキュリティに関する重大な問題	現在のバージョンと更新状況	更新関連の対処
REST APIのエラー	エラーコードと管理画面の動作	REST APIの対処
ループバックリクエストの失敗	サーバーから自サイトへの通信	ループバックの対処
予約イベントの遅延	予約投稿と定期処理の動作	予約イベントの対処
PHPのバージョンが古い	利用中のPHPと推奨要件	PHPの対処
ページキャッシュの警告	既存のキャッシュ機能	キャッシュの対処
自動読み込みオプションの問題	設定データの容量と発生元	自動読み込みの対処

サイトの表示停止、管理画面へのアクセス障害、重要な更新の失敗などが発生している場合は、通常の性能改善よりも復旧を優先してください。

サイトヘルスを改善する前にバックアップを取る

プラグインの更新、PHPの切り替え、データベースの変更などを行う前には、復元可能なバックアップを確保してください。

WordPressのファイルとデータベースの両方を保存する。
サーバー会社のバックアップ機能や復元手順を確認する。
可能であればステージング環境（本番サイトとは別の検証環境）で変更を試す。
変更前の設定値、警告文、発生日時を記録する。
複数の設定を同時に変更せず、1項目ずつ結果を確認する。

バックアップを取得しただけで、正常に復元できるとは限りません。保存先、対象範囲、復元方法も確認しておくことが重要です。

REST APIでエラーが発生する場合の改善方法

REST API（WordPressと外部プログラムなどがデータをやり取りするための仕組み）は、ブロックエディターをはじめとする各種機能で使用されます。

サイトヘルスでREST APIのエラーが表示された場合は、通信の失敗原因を確認してください。

エラーメッセージと応答コードを確認する

「サイトヘルス」→「ステータス」を開きます。
REST APIに関する警告を展開します。
表示されたエラーコードや通信先を記録します。
記事編集画面で保存や読み込みが正常にできるか確認します。

代表的なHTTPステータスコード（通信結果を示す番号）には、403（アクセス拒否）、404（対象が見つからない）、500（サーバー内部のエラー）などがあります。タイムアウト（指定時間内に応答が得られない状態）は、これらのHTTP応答とは区別して調べます。

ブラウザーから「https://自サイトのドメイン/wp-json/」へアクセスすると、公開されているREST APIの基本的な応答を確認できる場合があります。ただし、公開エンドポイントが表示されても、認証が必要な編集用APIやサーバー内部からの通信まで正常とは限りません。

セキュリティ設定やプラグインを確認する

403エラーの場合は、セキュリティプラグイン、WAF（不審な通信を遮断するWebアプリケーションファイアウォール）、サーバー側のアクセス制限などを確認します。

404エラーの場合は、対象URLやパーマリンク設定、サーバーのURL書き換え設定などを調べます。

500エラーの場合は、サーバーのエラーログ（障害内容を記録した履歴）やPHPエラーを確認します。

プラグインとの競合が疑われる場合は、バックアップと検証環境を用意し、影響が考えられるプラグインを個別に検証してください。本番環境で一括停止すると、問い合わせフォームや決済機能などに影響するおそれがあります。

対処後はサイトヘルスを再確認し、記事の保存や編集も正常に行えるか確認します。

ループバックリクエストが失敗する場合の改善方法

ループバックリクエストとは、サーバーが自分自身のWordPressサイトへHTTP通信を行う仕組みです。WordPressでは予約イベントなどの処理に関係します。

サイトヘルスに「サイトがループバックリクエストを完了できませんでした」などの警告が表示された場合は、通信を妨げている原因を調べます。

まず通信エラーの種類を確認する

サイトヘルスの警告を展開し、エラー内容を確認します。
タイムアウト、接続拒否、HTTPエラー、SSL証明書の検証失敗など、どの種類の問題か記録します。
WordPressの「設定」→「一般」にあるサイトURLを確認します。
サーバー側のWAF、アクセス制限、DNS（ドメイン名から接続先を調べる仕組み）、SSL証明書などを必要に応じて確認します。

外部ブラウザーからサイトが正常に表示されても、サーバー自身から同じURLへ接続できるとは限りません。

サーバー会社へ相談する場合の伝え方

原因が特定できない場合は、次の情報を整理してサーバー会社へ問い合わせます。

サイトヘルスに表示された警告文
発生日時とエラーコード
WordPress・PHPのバージョン
直前に変更した設定や導入したプラグイン
予約投稿や自動更新に実際の不具合があるか

セキュリティ機能が原因と疑われても、WAFや認証機能を恒久的に無効化するのは避けてください。 必要な通信だけを許可できるか、提供元の案内に従って確認する方が安全です。

予約イベントが遅延・失敗する場合の改善方法

WordPressにはWP-Cron（予約投稿や定期処理を実行するための仕組み）があります。予約投稿、自動更新、プラグインの定期処理などに関係します。

WP-Cronは標準構成ではサイトへのアクセスを契機として実行されるため、アクセスが少ないサイトでは予定時刻から処理が遅れることがあります。ただし、予約イベントの警告が出たからといって、原因がアクセス数だけとは限りません。

予約投稿と定期処理の状態を確認する

サイトヘルスで予約イベントの警告内容を確認します。
対象イベント名が表示されていれば記録します。
投稿一覧で予約投稿が予定どおり公開されているか確認します。
ループバックリクエストにもエラーがないか調べます。
サーバーのアクセス制限やWP-Cron関連の設定を確認します。

特定のプラグインが登録したイベントだけが遅延している場合は、そのプラグインの処理や実行条件も確認する必要があります。

予約投稿そのものが失敗している場合は、WordPressの予約投稿が失敗する原因と対処法も参考にしてください。

サーバー側の定期実行を利用する場合

アクセス数が少ないサイトや、定期処理の実行時刻をより安定させたいサイトでは、サーバーのcron（指定時刻に処理を実行する仕組み）を利用する方法があります。

ただし、サーバー側のcronを設定する場合は、実行方法、実行間隔、WordPress側の設定、既存の定期処理との重複を確認してください。

WP-Cronを無効化する設定だけを先に行うと、予約処理が動かなくなる可能性があります。代替の実行方法を確保してから切り替える必要があります。

改善後は、警告の再確認だけでなく、実際の予約投稿や定期処理が正常に動作するかを検証してください。

PHPのバージョンが古い場合の改善方法

PHPはWordPressを動作させるプログラミング言語です。古いPHPには、セキュリティ更新の終了や、プラグインとの互換性などの問題が生じる場合があります。

現在のPHPバージョンを確認する

「ツール」→「サイトヘルス」→「情報」を開きます。
「サーバー」の項目を展開します。
表示されたPHPバージョンを記録します。
WordPress公式の推奨要件と、使用中のテーマ・プラグインの対応条件を確認します。

PHPの推奨バージョンは更新されるため、固定された古い数値を参考にせず、WordPress公式の動作要件を確認してください。

PHPを安全に更新する手順

ファイルとデータベースをバックアップします。
使用中のテーマ・プラグインが変更先のPHPに対応しているか確認します。
可能であれば検証環境で切り替えます。
サーバーの管理画面からPHPバージョンを変更します。
サイト表示、管理画面、記事保存、問い合わせフォームなどを確認します。
不具合が発生した場合は、サーバーの案内に従って以前の設定へ戻し、原因を調査します。

PHPの切り替え方法や利用できるバージョンは、レンタルサーバーによって異なります。

WordPress本体・プラグイン・テーマの更新に関する警告

WordPress本体やプラグイン、テーマの更新に関する警告が出た場合は、利用中のバージョンと更新内容を確認します。

更新にはセキュリティ修正が含まれることもありますが、互換性の問題が発生する可能性もあります。

「ダッシュボード」→「更新」を開きます。
更新対象と現在のバージョンを確認します。
公式の更新情報や互換性を確認します。
バックアップを取得します。
可能であれば検証環境で動作を確認してから更新します。
更新後にサイトヘルスと主要機能を再確認します。

自動更新に関する警告では、WordPress.orgへの通信、ファイルの書き込み権限、サーバー側の制限などが関係する場合があります。

単純に自動更新を有効化するだけで解決するとは限らないため、警告の詳細に応じて原因を切り分けてください。

ページキャッシュやオブジェクトキャッシュの改善方法

サイトヘルスには、キャッシュに関する改善提案が表示される場合があります。

キャッシュとは、生成済みのページや処理結果を再利用して、サーバーの負荷を減らす仕組みです。

ページキャッシュの警告

ページキャッシュは、生成済みのHTMLを再利用してページ表示時の処理を減らす仕組みです。

「ページキャッシュが検出されませんでした」などの警告が出た場合は、まずレンタルサーバー側にキャッシュ機能があるか確認します。

サーバー側ですでにキャッシュを利用している場合、追加のキャッシュプラグインが必ずしも必要とは限りません。また、診断で検出されないことだけを理由に、キャッシュが存在しないと断定することもできません。

会員サイト、ECサイト、ログイン状態によって内容が変わるページなどでは、キャッシュの対象や除外条件を慎重に設定してください。

永続オブジェクトキャッシュの警告

オブジェクトキャッシュは、データベースから取得した情報などを一時保存して再利用する仕組みです。永続オブジェクトキャッシュでは、リクエストをまたいでキャッシュを保持します。

Redisなどの仕組みを利用できるサーバーもありますが、対応状況は環境によって異なります。

警告が表示された場合は、サーバー会社の対応機能、現在のサイト負荷、既存のキャッシュ構成を確認してください。警告を消す目的だけで複数のキャッシュ機能を追加するのは避けましょう。

自動読み込みオプションの容量に関する警告

WordPressの自動読み込みオプションは、ページ処理時に読み込まれる設定データです。保存量が大きい場合、性能に影響する可能性があります。

サイトヘルスに自動読み込みオプションの容量に関する警告が表示された場合は、不要な設定データが残っていないか確認する必要があります。

サイトヘルスの警告で、対象となる設定データの情報を確認します。
最近削除したプラグインや、設定データが増加した可能性のある機能を整理します。
データベースのバックアップを取得します。
設定データの所有元や必要性を確認します。
不要であると確実に判断できたデータだけを、提供元の手順に従って整理します。

データベース内のオプションを名前や容量だけで判断して直接削除しないでください。プラグインの設定やサイトの動作に必要なデータが含まれている可能性があります。

サイトヘルスの警告が消えない場合の確認事項

対処後も同じ警告が残る場合は、原因が解消されていないか、診断条件が想定と異なっている可能性があります。

次の順番で確認してください。

警告文が変更前と同じか確認します。
実際のサイト機能に問題が残っているか確認します。
キャッシュやサーバー設定の反映状況を確認します。
直前に変更した項目を一つずつ見直します。
必要に応じてサーバー会社やプラグイン開発元へ相談します。

サイトヘルスの警告数だけで改善の成功を判断せず、関連する機能が正常に動作しているかも確認することが大切です。

WordPressサイトヘルスのよくある疑問

重大な問題が表示されてもサイトを使い続けられますか？

警告の内容によって異なります。サイトが表示できていても、セキュリティ上の問題や自動処理の不具合が残っている可能性があります。重大な問題は放置せず、影響範囲を確認して対応してください。

おすすめの改善はすべて対応する必要がありますか？

必ずしもすべてを直ちに実施する必要はありません。サーバーの構成や利用している機能によって必要性が異なります。変更による副作用も考慮して判断してください。

サイトヘルスを改善するとSEOの順位は上がりますか？

サイトヘルスの警告を解消するだけで、検索順位が上がるとは限りません。ただし、表示速度やセキュリティ、サイトの正常な動作に関係する問題を改善することには意味があります。検索順位はコンテンツや検索意図への適合性など、さまざまな要素に左右されます。

警告がなくなればサイトは完全に正常ですか？

いいえ。サイトヘルスは特定の診断項目を確認する仕組みであり、すべての機能を保証するものではありません。予約投稿、フォーム送信、ログイン、記事編集、スマートフォン表示なども定期的に確認しましょう。

まとめ｜サイトヘルスは原因を確認してから改善する

WordPressのサイトヘルスで警告が表示されたら、まず「ツール」→「サイトヘルス」で詳細を確認し、実際に問題が起きている機能を特定してください。

特にREST API、ループバック通信、予約イベントは関連する場合があるため、警告を個別に消そうとする前に、通信や実行環境を確認すると原因を整理しやすくなります。

PHPの更新やキャッシュの変更、データベースの整理などは、バックアップと復元手順を確保したうえで進めましょう。警告をゼロにすることよりも、安全で正常に動作するサイトを維持することが重要です。