WordPressサイトヘルスの「重大な問題」の意味と対処法

管理画面の ツール > サイトヘルス に「重大な問題」が出ている。 でもサイトは普通に動いている。直すべきなのか、放っていいのか分からない。

サイトヘルスの項目には、環境によって必ず赤くなるものがあります。 各検査が実際に何を見ているかを、1 つずつ壊して確かめました。

検査は 2 種類ある

WordPress の検査は 26 項目あり、動き方が 2 つに分かれます。

async の 5 つは、実際にこの URL を叩いています。

/wp-json/wp-site-health/v1/tests/dotorg-communication
/wp-json/wp-site-health/v1/tests/background-updates
/wp-json/wp-site-health/v1/tests/loopback-requests
/wp-json/wp-site-health/v1/tests/https-status
/wp-json/wp-site-health/v1/tests/authorization-header

ここが偽陽性の最大の原因です。サイト自身への通信（ループバック）が 通らない環境では、中身が正常でも 5 つ全部が失敗します。

実測: 正常なサイトでも critical が 2 件出た

検証環境（サイトは正常に動作、REST API も外から見れば 200 で正常な JSON を返す）で 検査を走らせた結果です。

rest_availability    [critical]   REST API でエラーが発生しました
loopback_requests    [critical]   サイトでループバックリクエストが完了できませんでした

しかし外から REST API を叩くと正常です。

$ curl -s -o /dev/null -D - http://localhost:8080/wp-json/ | grep -iE '^HTTP|^content-type'
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8

同じ環境をブラウザで開いた画面（2026-09-16 撮影）。このときは「バックグラウンド更新が想定通りに動作していません」を含む 3 件が並んだ。バックグラウンド更新も async の検査で、ループバックが通らないと失敗する 5 つのうちの 1 つ

「REST API でエラーが発生しました」は、REST API が壊れていることを 意味しません。サイト自身から自分の URL に到達できないだけです。

ループバックが通らない実際の原因

この状態では予約投稿も自動更新も止まります。 サイトヘルスの警告は無視できませんが、「REST が壊れている」と読むのは誤りです。 → 予約投稿されない

見分け方

# 外から REST を叩く
curl -s -o /dev/null -D - https://example.com/wp-json/ | grep -i content-type

後者なら記事の内容が変わります。 → 「返答が正しい JSON レスポンスではありません」

実測: 全 21 項目の判定

同じ環境での direct 検査の結果です。赤や黄色が並ぶのが普通の状態だと 分かります。

放っていい recommended と、放ってはいけないもの

放ってはいけないもの

debug_enabled の実害は別記事で実測しています。 → サイトが死んでいるのに監視は 200 を返す

優先度が低いもの

autoload のサイズは WordPress 自身が見ている

autoloaded_options は、起動時に読み込まれるオプションの合計サイズを 検査します。しきい値を実測で挟み込みました。

約 800 KB が境目です。critical のときのメッセージには 実際の数値が入ります。

このサイトには options テーブル内に 139 個の自動読み込みオプション
(サイズ: 11 MB) があります。

これは実際に速度とメモリに効きます。別記事で測った値です。

→ WordPress が重い

この項目が critical なら、実害があるので対応します。

偽陽性になる項目

コマンドラインから検査を走らせた場合

WP-CLI から検査を実行すると、Web とは別の環境で判定されるため 結果がずれます。実測した例です。

Web では有効なのに、コマンドラインからは無効と判定されました。 オペコードキャッシュはコマンドライン実行では既定で働かないためです。

同じ理由で、タイムゾーン、メモリ上限、アップロードサイズなども コマンドラインと Web で違う値になります。

サイトヘルスはブラウザから見るのが正しい、ということになります。

HTTPS を使っていない環境

https_status は async なので、ループバックが通らないと判定できません。 また HTTP のみの検証環境では当然 recommended になります。

「情報」タブのほうが役に立つ

「ステータス」タブより、「情報」タブが実務では有用です。 ここには判定ではなく生の値が並びます。

max_input_vars と PHP のエラーログの場所は、ここで確認するのが最短です。 どちらも障害調査で必要になり、他の場所からは探しにくい値です。 → 保存したのに一部だけ消える → ログはどこにあり、何を見るのか

まとめ: 読む順番

1. critical を見る。ただし rest_availability と loopback_requests は 外から REST を叩いて確認する（偽陽性の可能性）
2. autoloaded_options が critical なら実害あり。対応する
3. debug_enabled が出ていたら本番設定を直す
4. search_engine_visibility が出ていたら公開サイトかどうか確認する
5. scheduled_events が出ていたらループバックを疑う
6. plugin_version / php_version は「いつかやる」に分類してよい

「重大な問題」という表示は、必ずしも「今すぐ直す」を意味しません。 逆に recommended（debug_enabled）のほうが実害が大きいことがあります。

# ブラウザを使わずに検査を走らせる(ただし CLI 実行は一部偽陽性になる)
wp eval '
require_once ABSPATH . "wp-admin/includes/class-wp-site-health.php";
$h = WP_Site_Health::get_instance();
foreach ( WP_Site_Health::get_tests()["direct"] as $key => $t ) {
  $m = "get_test_" . $t["test"];
  if ( ! is_string( $t["test"] ) || ! method_exists( $h, $m ) ) continue;
  $r = $h->$m();
  printf( "%-26s [%s] %s
", $key, $r["status"], wp_strip_all_tags( $r["label"] ) );
}'

# REST が本当に壊れているか(サイトヘルスとは別に確認する)
curl -s -o /dev/null -D - https://example.com/wp-json/ | grep -i content-type