WordPressのサイトヘルスで「改善が必要」と出た時の見方と対処法

WordPressのサイトヘルスに「致命的な問題」や「おすすめの改善」と表示され、すぐ直さないとサイトが止まるのか不安になっていませんか。警告は、サイトの現在状態を調べる入口です。表示された項目を上から全部消すことが目的ではありません。

結論は、最初に警告文と発生時刻を保存し、売上・問い合わせ・ログイン・公開表示への影響を確認してから、危険度の高い原因を一つずつ切り分けることです。改善作業の前にはバックアップと復元方法を確認し、変更後は同じ条件で再テストします。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。サイトヘルスでは点数よりも、警告が実際の機能停止やセキュリティへつながっているかを優先して確認します。

この記事では、WordPress管理画面の「ツール」から開くサイトヘルスを対象にします。サーバー会社独自の診断、セキュリティプラグインのスキャン、Google Search Consoleの警告とは別の仕組みです。表示名が似ていても、確認元と対象範囲を混同しないでください。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressのサイトヘルスで表示される問題の見方

WordPressのサイトヘルスは、赤や黄の表示数をゼロにするのではなく、警告の種類と実害を読んで優先順位を決めるために使います。同じ警告でも、本番サイトの構成や利用機能によって緊急度は変わります。

致命的な問題は機能停止と安全性から確認する

「致命的な問題」は、サイトの動作やセキュリティへ大きく影響する可能性がある項目です。ただし、表示された瞬間に公開ページが必ず停止しているとは限りません。警告文だけで判断せず、トップページ、主要な下層ページ、管理画面、問い合わせ、決済や予約など重要機能を確認します。

たとえばREST APIやループバックリクエストの失敗は、ブロックエディター、予約処理、プラグインの定期処理へ影響することがあります。一方、Basic認証をかけた検証環境では意図した制限が警告の原因になる場合もあります。環境の目的まで含めて判断してください。

おすすめの改善は放置せず計画的に整理する

「おすすめの改善」は、直ちにサイトが止まるとは限らないものの、速度、更新性、安全性、将来の互換性を改善するための項目です。古いPHP、停止中のテーマ、ページキャッシュ、永続オブジェクトキャッシュ、HTTPSなどが表示されることがあります。

緊急性が低いからと長期間放置すると、次の更新で不具合が起きたり、復旧時に作業量が増えたりします。今すぐ変更する項目、検証環境で試す項目、契約サーバーへ相談する項目に分け、期限と担当を決めるのが安全です。

点数や件数だけでサイト品質を判断しない

サイトヘルスの表示が良好でも、フォームが届かない、決済が止まっている、改ざんされているといった問題を完全には検出できません。反対に、キャッシュやサーバー構成の都合で警告が残っていても、運用上の理由を説明できる場合があります。

評価は診断の一部であり、監視、バックアップ、更新記録、アクセスログ、PHPエラーログ、実際の操作試験を代替しません。警告の件数より、事業に必要な機能が正常で、異常時に戻せる状態かを確認することが重要です。

WordPressのサイトヘルス情報を作業前に記録する方法

WordPressのサイトヘルスを改善する前は、現在の警告、発生時刻、サイト情報、直前の変更を保存します。作業後に警告が消えても、原因と変更内容が分からなければ再発時に同じ調査を繰り返すからです。

ステータス画面の警告文を省略せず保存する

「サイトヘルスステータス」で各項目を開き、見出し、説明、推奨される操作、関連するテスト名を保存します。見出しだけでは、REST APIのどの応答が失敗したのか、予約イベントがどの程度遅れたのか、どのPHP拡張が不足しているのか分かりません。

スクリーンショットに加え、文章を作業メモへコピーすると検索や比較がしやすくなります。利用者名、サーバーパス、IPアドレス、データベース名などが含まれる場合は、外部へ共有する前に伏せてください。

情報タブは共有前に機密情報を確認する

「情報」タブには、WordPress、テーマ、プラグイン、サーバー、データベース、ファイル権限、定数、メディア処理などの詳細が表示されます。原因調査に役立ちますが、環境の内部情報が含まれるため、公開掲示板やSNSへそのまま貼ってはいけません。

専門家やサーバー会社へ送る場合も、相談に必要な範囲だけを共有します。パスワードや秘密鍵が直接表示されなくても、構成情報の組み合わせは攻撃者の手掛かりになります。保存ファイルの保管先と閲覧権限も決めてください。

直前の変更と正常だった時点を時系列にする

警告を見つけた日時だけでなく、WordPress・テーマ・プラグイン・PHPの更新、DNSやSSL、WAF、CDN、Basic認証、バックアップ、サーバー移転など直前の変更を並べます。予約投稿やフォームなど、初めて症状が出た時刻も記録します。

「いつからか分からない」場合は、監視履歴、メール通知、アクセスログ、更新履歴、担当者の作業記録から正常だった最後の時点を探します。変更と発生時刻が近い項目から確認すれば、無関係な設定を触る範囲を減らせます。

WordPress修正の依頼前チェックリスト｜原因を切り分ける方法

WordPressのサイトヘルスで致命的な問題が出た時の対処

WordPressのサイトヘルスで致命的な問題が出た時は、証拠保存、バックアップ確認、重要機能の応急対応、原因の切り分け、再テストの順で進めます。警告を消すために複数設定を同時変更すると、何が効いたか分からなくなります。

バックアップと復元方法を確認してから変更する

最初にファイルとデータベースのバックアップを確認します。自動バックアップがあっても、日時、容量、対象、保存先、復元に必要な認証情報を確認し、作業直前の変更を含むか見てください。可能ならステージングや別環境で復元試験を行います。

バックアップの成功表示だけでは戻せる保証になりません。データベースが含まれない、保存先の容量が不足している、暗号化パスワードが不明、同じサーバー内にしか保存されていないといった問題があります。変更前に復元経路を説明できる状態へ整えます。

WordPressバックアップの完全解説｜UpdraftPlus / BackWPup / all-in-one-wp-migrationを図解

REST API・ループバック・Cronは通信経路を分けて調べる

REST APIはWordPressとブラウザーや外部機能のデータ通信に使われ、ループバックはサイトが自分自身へHTTP通信できるかを確認します。Cronは予約投稿や定期処理に関係します。似た警告が同時に出ても、同じ設定だけが原因とは限りません。

HTTPSのURL統一、DNS、証明書、WAF、CDN、IP制限、Basic認証、国外アクセス遮断、セキュリティプラグインを確認します。まず警告に表示されたURLとHTTP状態を保存し、遮断ルールを一つずつ検証します。本番の防御を一括無効化してはいけません。

SSHとWP-CLIを安全に扱える場合は、次のような読み取り中心の確認で更新状況や予約イベントを把握できます。コマンド実行前に対象ディレクトリとサイトURLを確認し、結果を保存してください。

wp core verify-checksums
wp plugin list --update=available
wp cron event list --fields=hook,next_run_relative

HTTPS・更新・PHPの問題は検証環境で先に試す

PHPの古さや拡張不足、WordPress本体・テーマ・プラグインの更新不足が表示された場合、いきなり本番で大きく版を上げないでください。古いテーマや独自PHPがあると、警告は消えても公開ページが真っ白になることがあります。

本番と同じPHP・データベース・Webサーバー構成のステージングで、バックアップ復元後に更新します。トップページだけでなく、ログイン、投稿編集、画像、検索、フォーム、会員、予約、決済、メール通知を確認し、問題があれば本番反映前に修正します。

WordPressのアップデート・保守をしないと危険｜放置で起こる深刻なリスクとは

WordPressのサイトヘルスにあるおすすめ改善の優先順位

WordPressのサイトヘルスにあるおすすめ改善は、セキュリティとサポート期限、更新失敗の可能性、速度への効果、作業リスクの順で並べます。簡単に消せそうな警告から着手すると、重要な古い環境が後回しになることがあります。

古いPHP・WordPress・プラグインは互換性調査を先にする

サポートが終わったPHPや古いWordPressは、脆弱性修正を受けられず、新しいプラグインの動作条件も満たせなくなるため優先度が高い項目です。ただし、最新版へ変更する前に、テーマ、独自コード、PHP拡張、データベース要件を確認します。

長期未更新サイトは段階更新が必要な場合があります。更新対象と順番、テスト項目、切り戻し条件を決め、ステージングで再現します。「推奨PHPへ変更したら警告が消えた」だけでなく、業務機能が同じように動くかまで確認してください。

停止中テーマやプラグインは用途を確認してから削除する

不要なテーマやプラグインは攻撃面と保守対象を増やすため、削除候補になります。しかし、停止中でも復旧時の切り替え先、子テーマの親、データ移行、過去データの表示、季節機能などで必要な場合があります。名前だけで不要と決めないでください。

利用箇所、依存関係、最終更新、配布元、保存データ、削除後の戻し方を確認します。バックアップ後に一つずつ削除し、表示、管理画面、フォーム、Cron、ログを確認します。複数をまとめて消すと、障害が出た時に原因を特定しづらくなります。

キャッシュの提案はサーバー構成と実測で判断する

ページキャッシュや永続オブジェクトキャッシュの提案は、サイト規模やサーバー機能によって効果が変わります。共有サーバー側ですでにキャッシュされている場合、プラグインを追加すると二重化やログイン状態の誤配信を招くことがあります。

導入前後で、未ログインの表示速度、管理画面、投稿更新後の反映、フォーム、会員・カート、Cron、サーバー負荷を同じ条件で測ります。体感だけで採用せず、除外URLと削除方法を記録し、問題があればすぐ元へ戻せるようにします。

WordPressエラーのトラブル解決ガイド10選【初心者向け】

WordPressのサイトヘルス改善でやってはいけないこと

WordPressのサイトヘルス改善では、警告を消すことを優先して防御や機能をまとめて無効化しないでください。診断結果が良くなっても、問い合わせ、予約、キャッシュ、防御、更新処理が壊れれば改善ではありません。

複数のプラグインと設定を同時に変更しない

キャッシュ、セキュリティ、バックアップ、WAF、CDNを同時に停止すると、一時的に警告が消えても原因が分かりません。さらに本番サイトの防御や速度が変わり、利用者のアクセス条件まで変化します。一回の検証では一つの変数だけを変えます。

変更前の値、変更時刻、実施者、対象、結果、元へ戻した時刻を記録してください。無効化が必要なら低アクセス時間に短く実施し、確認後はすぐ復元します。再現できない場合はログと監視を追加し、推測で設定を触り続けないことが重要です。

本番で直接PHPやデータベースを更新しない

PHP版の変更、データベース更新、Webサーバー設定の変更は、サイト全体へ影響します。管理画面でボタン一つに見えても、古いテーマやプラグインが対応していなければ致命的エラーになります。ステージングと直前バックアップなしに進めないでください。

サーバー会社が自動切り戻しを提供していても、データベースの新規注文や投稿がどこまで戻るかを確認します。復元によって別のデータを失う可能性があるため、技術的に戻せることと業務上戻してよいことは別に判断します。

情報タブの内容を公開場所へ貼らない

原因を質問するためにサイトヘルス情報を公開掲示板へ貼ると、プラグイン構成、サーバー情報、ファイル権限などが第三者へ見えることがあります。相談先が本当に必要とする部分を確認し、安全な送付方法を選んでください。

公開してしまった場合は、投稿を削除するだけでなく、キャッシュや検索結果の残存を確認し、漏れた情報に応じて認証情報の変更やアクセスログ確認を行います。機密性が分からない時は、専門家へ相談して影響範囲を整理します。

WordPressのFatal errorの原因と今すぐできる解決策とは【緊急対応】

WordPressのサイトヘルスを再テストして運用へつなげる方法

WordPressのサイトヘルスは、変更後に再テストし、重要機能・ログ・速度・警告文を変更前と比較して初めて改善を確認できます。警告が消えたことだけを完了条件にせず、利用者に必要な機能が正常であることを確認します。

キャッシュを考慮して同じ条件で再確認する

サイトヘルスの再テストを実行し、ブラウザー、WordPress、サーバー、CDNのキャッシュが結果へ影響していないか確認します。変更直後だけ正常でも、Cronやキャッシュ更新後に再発することがあります。時間を置いた確認も計画してください。

未ログインとログイン中、パソコンとスマートフォン、主要ブラウザーで公開ページを見ます。フォームは実際に送信し、受信、完了画面、自動返信まで確認します。予約や決済はテスト手段を使い、管理側データと通知も点検します。

警告が残る場合は理由と代替策を記録する

環境の仕様上、サイトヘルス警告を完全に消せない場合があります。たとえば検証環境のBasic認証、外部Cronの運用、ホスティング側キャッシュなどです。その場合は、意図した構成、確認した影響、代替監視、見直し期限を記録します。

「問題なし」とだけ書くのではなく、なぜ許容できるかを説明できる記録にします。担当者や制作会社が変わっても判断を再現でき、後の環境変更で警告の意味が変わった時にも再評価できます。

月次点検で警告と実機能を一緒に確認する

月次または更新後の定期点検に、サイトヘルス、WordPress・PHP・プラグインの版、バックアップ、復元試験、ログ容量、Cron、フォーム、主要ページを含めます。項目ごとに前回値と今回値を並べ、急な変化を見つけます。

警告が新しく出た日と直前の変更を結び付けられるよう、更新作業の記録を残します。異常がなくても確認日を記録すれば、次回の障害時に正常だった最後の時点を特定できます。サイトヘルスを一度きりの掃除ではなく保守の入口として使ってください。

WordPressのサイトヘルスに関するよくある質問

WordPressのサイトヘルスでよくある疑問を、緊急度、削除、キャッシュ、共有方法の観点からまとめます。

WordPressのサイトヘルス改善は優先順位と再テストが重要

WordPressのサイトヘルスで「改善が必要」と出たら、最初に警告全文、発生時刻、直前の変更、重要機能の状態を記録してください。赤や黄の件数をゼロにすることより、サイト停止・売上・問い合わせ・ログイン・セキュリティへの影響を優先して判断します。

作業前はファイルとデータベースのバックアップ、保存日時、復元方法を確認します。REST API、ループバック、Cron、HTTPS、PHP、更新、キャッシュは関係し合いますが、複数設定を同時に変更せず、一つずつ検証して原因を切り分けるのが安全です。

よこやま良平が実務で重視するのは、警告が消えた後の確認です。公開ページだけでなく、フォーム、予約、決済、メール、ログ、Cronを再テストし、残る警告には理由と代替策を記録します。定期点検へ組み込めば、次のトラブルにも早く対応できます。

WordPressのサイトヘルス問題を自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で