WordPress管理画面に「サイトに重大な問題があります」「おすすめの改善」と表示されると、すぐに直さなければ危険なのか、何から確認すればよいのか迷います。
警告を見て、検索で見つけたコードを貼る、キャッシュプラグインを追加する、PHPやデータベースをいきなり変更するのは安全ではありません。環境によって原因と担当範囲が違うためです。
結論から言うと、サイトヘルスは点数や警告数をゼロにする画面ではなく、今のWordPressで優先して確認する場所を見つける診断画面です。
この記事では、サイトヘルスの「重大な問題」「おすすめの改善」「問題なし」の見方と、情報タブの使い方、警告を安全に直す順番を初心者向けに整理します。
先に結論：警告は3段階で優先順位を決める
サイトヘルスを開いたら、表示された項目を上から機械的に直すのではなく、次の順番で見ます。
| 優先 | 見ること | 最初の行動 |
|---|---|---|
| 1 | 公開ページ、ログイン、フォーム、予約投稿に実害が出ている | 変更を止め、状態を記録してバックアップを確認 |
| 2 | 「重大な問題」にセキュリティ・更新・通信・サーバー関連の警告がある | 説明文を保存し、原因の担当を切り分ける |
| 3 | 「おすすめの改善」に速度・保守性の提案がある | 必要性を確認し、低リスクの項目から検討 |
| 確認済み | 「問題なし」に入っている | 基本的に変更せず、記録として使う |
「重大な問題」と表示されても、すぐにサイトが攻撃されている、壊れていると決めつけないでください。警告の本文、現在の不具合、直前の変更をセットで確認します。
WordPressサイトヘルスで分かること
サイトヘルスは、WordPress管理画面の「ツール」→「サイトヘルス」から開きます。画面は主に「ステータス」と「情報」に分かれます。
| 画面 | 役割 | 使いどころ |
|---|---|---|
| ステータス | セキュリティ、更新、通信、速度などの診断結果を表示 | 優先して確認する問題を探す |
| 情報 | WordPress、テーマ、プラグイン、サーバー、データベース等の構成を表示 | 変更前の記録、サポート相談、環境比較に使う |
WordPress本体のテストには、バージョン、PHP、データベース、HTTPS、REST API、ループバック、予約処理、更新、ページキャッシュなどがあります。テーマやプラグインが独自のテストを追加することもあるため、すべてのサイトに同じ項目が出るとは限りません。
サイトヘルスだけでは分からないこと
サイトヘルスが「良好」でも、サイト運営のすべてが正常とは限りません。次の項目は別に確認します。
- すべてのページの表示崩れや誤字
- 問い合わせフォームが実際に届くか
- 広告リンクや計測タグが正しく動くか
- 検索順位やインデックス登録の状態
- 実際の読者環境での表示速度
- バックアップから本当に復元できるか
- 未知の脆弱性や不正アクセスがないこと
表示速度の原因は画像、広告、テーマ、プラグイン、サーバーなどが重なるため、サイトヘルスだけで判断せず、WordPressが重い原因と改善順も使って切り分けます。
警告を直す前に行う4つの準備
1. 警告全文と現在時刻を記録する
警告の見出しだけでなく、展開した説明文、推奨される操作、表示日時をスクリーンショットまたはメモで残します。直前に更新や設定変更をした場合は、その内容も一緒に記録します。
2. 公開サイトで実害を確認する
トップページ、代表記事、管理画面、フォーム、予約投稿などを確認します。警告が出ていても公開サイトは正常な場合があり、逆にサイトヘルスに目立つ警告がなくてもフォームだけ止まっている場合があります。
3. ファイルとデータベースをバックアップする
PHP、データベース、テーマ、プラグイン、キャッシュ、権限を変更する前に、戻せる状態を作ります。WordPressサイトはファイルとデータベースの両方で成り立つため、片方だけで十分とは限りません。
確認範囲はWordPressバックアップの取り方で整理しています。
4. 影響が大きい変更はテスト環境で試す
PHP変更、テーマ切り替え、主要プラグイン停止、データベース操作は、本番サイトへ直接行うと復旧が難しくなることがあります。可能ならWordPressテスト環境の作り方を先に確認してください。
「重大な問題」で先に確認したい項目
重大な問題は、セキュリティやサイト機能へ大きく影響する可能性がある項目です。ただし、表示される内容は環境によって異なります。次は代表的な分類と最初の対応です。
| 表示される項目の例 | 何に関係するか | 最初の対応 |
|---|---|---|
| WordPress・テーマ・プラグインの更新 | 不具合修正、互換性、セキュリティ | バックアップと更新内容を確認して順番に更新 |
| 古いPHP・データベース | サーバー環境、互換性、保守 | 利用中テーマ・プラグインの対応とサーバー手順を確認 |
| REST APIの問題 | ブロックエディターやプラグインの通信 | 直前のセキュリティ・キャッシュ・プラグイン変更を確認 |
| ループバックの失敗 | 予約投稿、定期処理、自己接続 | プラグイン・テーマ・サーバー制限を切り分ける |
| WordPress.orgへ接続できない | 更新情報や公式サービスとの通信 | 一時障害、外向き通信、セキュリティ設定を確認 |
| デバッグ情報が訪問者に表示される | エラー情報やサーバー情報の公開 | 公開画面を確認し、サーバー・設定担当へ相談 |
更新通知への対応は、複数を同時に更新せず、WordPress更新のやり方の順番で進めます。セキュリティ全体を確認する場合は、WordPressセキュリティ設定の基本も参考になります。
REST APIとループバックは何を意味する？
REST API
REST APIは、WordPressの管理画面や外部機能がデータをやり取りする仕組みの一つです。ブロックエディター、サイト編集、プラグインなどが利用します。
警告が出た場合、REST APIそのものを無理に有効化するコードを探すのではなく、直前に変更したセキュリティ設定、キャッシュ、プラグイン、Basic認証、サーバーの通信制限を確認します。
ループバック
ループバックは、WordPressサイトが自分自身へ接続する処理です。WordPress公式では、予約投稿や定期イベント、テーマ・プラグイン編集時の確認などに使われると説明されています。
失敗している場合は、予約投稿が遅れるなどの現象があるかを確認します。いきなり本番で全プラグインを停止せず、テスト環境で競合を確認するか、サーバーサポートへ警告全文を伝えます。
「おすすめの改善」は必要性を見て判断する
おすすめの改善は、セキュリティやパフォーマンスを良くする提案ですが、すべてを即日対応する必要があるとは限りません。サイトの規模、サーバー機能、動的ページの有無、現在の不具合を見て判断します。
| 項目の例 | 注意点 | 相談先 |
|---|---|---|
| ページキャッシュ | すでにサーバー側で動作している場合や、会員・決済ページがある場合は設定確認が必要 | サーバー、キャッシュ機能の公式情報 |
| 永続オブジェクトキャッシュ | プラグインだけで完結せず、Redis等のサーバー機能が必要な場合がある | サーバー会社 |
| 自動読み込みオプション | データベースから直接削除すると設定を壊す可能性がある | 原因プラグイン・テーマの提供元、保守担当 |
| 未使用のテーマ・プラグイン | 本当に不要か、復旧・検証用に残す方針があるか確認 | WordPress管理者 |
| PHPモジュール・データベース | 契約サーバーで利用者が変更できない場合がある | サーバー会社 |
キャッシュの基本と表示確認は、WordPressキャッシュ設定の基本で確認できます。警告を消すためだけに、役割が重なるキャッシュプラグインを追加しないようにしましょう。
「情報」タブは変更前の記録と相談に使う
情報タブには、WordPressのバージョン、サイト設定、ディレクトリ容量、使用中のテーマとプラグイン、サーバー、データベース、WordPress定数、ファイル権限などが表示されます。
- 更新前後でPHPやWordPressのバージョンを比べる
- 有効なテーマとプラグインを確認する
- サーバーやデータベース環境をサポートへ伝える
- 本番とテスト環境の違いを探す
- サイト容量やアップロード上限の手がかりを確認する
「サイト情報をクリップボードにコピー」を使うと相談しやすくなりますが、貼り付け先には注意が必要です。
サイト情報、サーバーパス、利用プラグインなどを、不特定多数が見られるSNSや公開コメント欄へそのまま貼らないでください。
- パスワード
- 二段階認証コード
- APIキーや秘密鍵
- データベースのログイン情報
- 個人情報を含むエラーログ
- バックアップファイルそのもの
これらは送らず、相談先が公式サポートであることを確認します。サイト情報に不明な項目がある場合は、公開前に伏せてよい範囲を相手へ確認してください。
サイトヘルスの警告を安全に直す順番
警告を直すときは、次の7ステップで進めます。
- 警告全文、表示日時、直前の変更を記録する
- 公開ページ、管理画面、フォーム、予約投稿の実害を確認する
- ファイルとデータベースの最新バックアップを確認する
- WordPress管理、テーマ・プラグイン、サーバーのどこが担当か分ける
- 影響の大きい変更はテスト環境で試す
- 変更を1つだけ反映し、キャッシュを確認して再診断する
- 公開ページと必要機能をもう一度確認し、結果を記録する
一度に複数の警告へ対応すると、何を変えたことで直ったのか、何が原因で不具合が出たのか分からなくなります。1回の変更を小さくしてください。
自分で直すか、サポートへ相談するかの基準
| 状況 | 推奨する対応 |
|---|---|
| 更新待ちのプラグインがあり、公式更新情報とバックアップを確認できる | 安全な更新手順に沿って自分で対応を検討 |
| 使っていないプラグインが明確 | 設定や依存関係を確認して整理 |
| PHP、データベース、モジュール、ファイル権限の警告 | サーバー公式マニュアルとサポートを優先 |
| REST API、ループバック、予約投稿の問題が続く | 警告全文とサイト情報を整理してサーバー・提供元へ相談 |
| 管理画面へ入れない、公開ページが表示されない | 追加変更を止め、復元方法を確認して早めに専門家へ相談 |
| 自動読み込みデータを直接削除する必要がありそう | データベースを触らず、原因調査を専門家へ依頼 |
プラグインを整理するときは、WordPressプラグインを減らす方法に沿い、停止と削除を分けて判断します。サーバー関連の問題が複数続く場合は、WordPressのレンタルサーバーを見直すべきタイミングも判断材料になります。
サポートへ送ると解決しやすい情報
- サイトヘルスの警告全文
- 警告を確認した日時
- 問題が起きるページと操作
- いつから起きたか
- 直前に行った更新・設定変更
- 公開画面、フォーム、予約投稿などへの影響
- 必要部分だけに絞ったサイト情報
- すでに試したことと、その結果
「サイトヘルスが赤いです」だけでは原因を絞りにくくなります。正確な警告文と、実際に困っている現象をセットで伝えましょう。
サイトヘルスを確認するタイミング
- WordPress本体、テーマ、主要プラグインの更新前後
- PHPやサーバー設定を変更する前後
- サーバー移行やテーマ変更の前後
- 予約投稿、フォーム、ブロックエディターに問題が出たとき
- 定期保守日を決めてサイト状態を記録するとき
毎回すべてを変更するのではなく、前回の記録と違う項目がないかを見る使い方が安全です。
WordPressサイトヘルスのよくある質問
サイトヘルスは100点を目指すべきですか？
点数や警告数を目的にせず、実害と重大度で判断します。サイトの用途やサーバー環境によって、提案された機能を使わない合理的な場合もあります。警告を隠すのではなく、理由を確認して対応方針を記録することが大切です。
「おすすめの改善」は無視してもよいですか？
一律に無視はしません。内容、現在の不具合、変更リスク、サーバー機能を確認し、必要なら保守計画へ入れます。緊急性が低くても、理由を確認しないまま放置しないようにします。
サイトヘルス用のプラグインは必要ですか？
基本のサイトヘルスはWordPressに含まれています。追加プラグインが独自チェックやトラブルシューティング機能を提供する場合はありますが、警告を消す目的だけで新しいプラグインを増やさない方が安全です。
サイトヘルスが良好なら表示速度も問題ありませんか？
保証されません。サイトヘルスはページキャッシュなどを確認しますが、実際の速度は画像、広告タグ、テーマ、プラグイン、通信環境、サーバー負荷などにも影響されます。実ページを別途測定してください。
まとめ：警告を消すより、原因と担当を見極める
WordPressサイトヘルスは、重大な問題、おすすめの改善、問題なしを整理し、サイトの保守で確認すべき場所を教えてくれる機能です。
警告が出たら、まず全文と現在の現象を記録し、バックアップを確認します。そのうえで、WordPress管理画面で直す項目、テーマ・プラグイン提供元へ確認する項目、サーバーへ相談する項目に分けます。
サイトヘルスの目的は、緑色にすることではなく、WordPressを安全に保守できる状態へ近づけることです。
まずは「ツール」→「サイトヘルス」を開き、重大な問題の全文と、情報タブのWordPress・PHP・テーマ・プラグインの状態を記録するところから始めましょう。