検証用のWordPressでサイトヘルスを開くと、「致命的な問題」が1件、「おすすめの改善」が9件表示されていました。
同じ警告でも、公開サイトと検証サイトでは対応が変わります。検索に載せない設定を意図している場合もあれば、予約処理やメール送信に支障が出ている場合もあります。表示を消すことより、何が起きていて、利用者に影響があるかを確認することが先です。
この記事では、掲載した検証画面の10件を例に、警告の意味と対処の考え方を整理します。サイトヘルスの項目や判定は、WordPressのバージョン、環境設定、プラグインによって異なります。ここで紹介する警告が、すべてのサイトに出るわけではありません。
まず、影響の大きい項目から確認する
サイトヘルスは「ツール」→「サイトヘルス」で開きます。各項目を展開して、原因の説明と対象機能を確認してください。
画像の①が「致命的な問題」、②が「おすすめの改善」です。右側のラベルは、セキュリティやパフォーマンスなどの分類を示しています。「WP Mail SMTP」の項目は、プラグインが追加したものです。
| 確認の優先度 | 項目の例 | まず確かめること |
|---|---|---|
| 情報の公開や通信の保護 | エラーの画面表示、公開され得るログ、HTTPS | 外部に情報が見えていないか。通信が正しく保護されているか |
| 必要な機能への影響 | 予約イベント、メール送信、検索除外 | 予約投稿や通知が動くか。検索掲載の方針と設定が一致するか |
| 保守・性能の改善 | 停止中のプラグイン・テーマ、キャッシュ | 不要なファイルや未更新がないか。実際の負荷・応答に問題があるか |
分類だけで緊急度は決まりません。たとえばメールが届かず購入者対応に支障がある場合は、キャッシュの提案より先に確認します。
WordPressサイトのメンテナンスを行いたいなら、まずはサイトヘルス機能を使うのがおすすめです。 定期検診のようなイメージで、サイトの健康状態をチェックできます。問題があればすぐに対策できるので、安心して運営できます。 当記事では、サイトヘルスの見方や活用方法についてご紹介します。 ...
エラーを訪問者へ表示する設定になっている
検証画面では「サイト訪問者へエラー表示を行う設定になっています」が、致命的な問題として表示されていました。
WP_DEBUGが有効で、画面表示を制御するWP_DEBUG_DISPLAYも有効な場合に関係する警告です。エラーの文面に、サーバー上のパスなどが含まれることがあります。公開サイトで不要なデバッグが残っていれば、設定を見直します。
調査を終えている場合は、wp-config.phpの既存のWP_DEBUG定義を確認し、falseに変更します。
define( 'WP_DEBUG', false );調査中でログを残す必要がある場合は、画面表示を止め、公開されない場所へ記録します。次は設定の形を示す例です。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/path/outside-public/debug.log' );パスはそのまま貼らず、実際の公開フォルダの外にある、書き込み可能な保存先へ置き換えます。既存の定義を書き換え、同じ定数を重複して追加しないでください。変更前にバックアップを取り、不明なら保守担当者へ依頼します。
サイトヘルスの判定は、設定やログのパスなどから行われます。警告が下がったり消えたりしても、実際の公開範囲やサーバー側のエラー表示まで、すべて確認できたわけではありません。
参考：WordPress公式デバッグガイド、デバッグ状態の判定コード
停止中のプラグイン・テーマを削除するよう表示される
停止中のプラグイン
停止しているプラグインも、ファイルはサーバーに残ります。使う予定がなく、必要なデータへの影響も確認できたものは、バックアップを取って削除します。更新待ちのプラグインがある場合は、有効・無効を問わず扱いを確認しましょう。
単に停止していることと、実際に悪用可能な脆弱性があることは別です。ただし、不要なファイルを古いまま残さないことは保守上の基本になります。
停止中のテーマ
検証画面では、有効なGLUEとデフォルトテーマのTwenty Twenty-Fiveを除き、停止中のテーマが1つあると表示されていました。予備のデフォルトテーマを残す場合も、更新を続けます。
子テーマを使用している場合、その親テーマは必要です。「停止中」と表示されているものを一括で削除せず、使用関係とカスタマイズの保存先を確認してください。
使っていないテーマを安全に消す手順は、こちらで紹介しています。
「不要なWordPressテーマを削除したい」 「でも本当に削除しても大丈夫かな？」 WordPress初心者の方は、そう思う方もいらっしゃるかもしれません。 そこで当記事では、WordPressテーマを安全に削除（アンインストール）する方法と、知っておきたいポイントをご紹介します。 ...
予約したイベントの実行に失敗したと表示される
画面に出ていたaction_scheduler_run_queueは、WooCommerceなどでも使われるAction Schedulerに関係するイベントです。
サイトヘルスは、予定時刻を過ぎたイベントが残っていないかを確認しています。「失敗しました」という表示だけで、処理の失敗原因や、すべての予約処理が止まったことまでは断定できません。
アクセスの少ない検証サイトでは、アクセスをきっかけに動くWP-Cronの実行が遅れる場合があります。ただし、アクセスが少ないから必ず問題ない、と判断することも避けます。
- 一時的な遅れか、再確認しても継続しているかを見る
- 予約投稿や自動更新など、必要な機能が動いているか確認する
- Action Schedulerの管理画面がある場合は、対象アクションの状態とログを確認する
- サーバー側cronを使う場合は、設定と実行記録を確認する
DISABLE_WP_CRONをtrueにする設定は、通常のWP-Cron起動を止めるためのものです。サーバー側のcronを自動で登録する設定ではありません。手動実行や変更は、対象処理の内容と影響を確認してから行います。
予約処理が止まる原因と、サーバーのcronに切り替える方法はこちらです。action_scheduler_run_queue を使うプラグインの仕組みは、2本目の記事で解説しています。
WordPressで予約投稿を設定したのに、時間になっても記事が公開されていない。投稿一覧を見ると、日付の欄に赤字で「予約投稿の失敗」と表示されている。そんな経験はありませんか？ この「予約投稿の失敗」の多くは、WordPressの予約処理を担う「WP-Cron」という仕組みがうまく動いていな...
WordPressの管理画面に、ある日突然「予約済みアクション」というメニューが追加されたり、「action_scheduler/migration_hook failed」といった英語のエラーメッセージが表示されて、驚いたことはありませんか？ 結論から言うと、これはAction Schedu...
検索エンジンのインデックス作成を推奨しない設定になっている
「設定」→「表示設定」の「検索エンジンがサイトをインデックスしないようにする」が有効な場合に関係する表示です。
検索に載せたい公開サイトなら、意図せず有効になっていないか確認します。公開前や検証用など、検索掲載を避けたいサイトでは、設定の意図を確認して維持します。
検索除外の設定は、サイトを非公開にするアクセス制限ではありません。URLを知っている人からも見られないようにしたい場合は、認証やアクセス制限を別に設けます。
チェックを外すことも、検索結果への掲載を保証する操作ではありません。サイトを公開するときは、他のnoindex設定やアクセス制限が残っていないかも確認してください。
永続オブジェクトキャッシュを推奨される
データベースから取得した結果などを、リクエストをまたいで再利用する仕組みです。検証画面では、利用可能な候補としてAPCuが表示されていました。
WordPressはサイト規模などの条件から導入を提案しますが、マルチサイトやプラグインによる判定変更もあります。警告が出たことだけで、必ず導入すべきとは限りません。
契約サーバーが対応する方式と導入手順を確認し、既存のキャッシュ構成との重複、動的な機能への影響、導入前後の効果を確かめます。Redisなどの名前が表示されたからといって、プラグインを入れるだけで使えるとは限りません。
参考：永続オブジェクトキャッシュを提案する条件（WordPress公式）
自動読み込みオプションが多すぎるときの減らし方は、こちらにまとめています。
WordPressのサイトが、なんとなく重くなってきた。画像を圧縮したり、キャッシュを入れたりしても、管理画面の動きまで遅い。そんなときに見直したいのが「autoload（自動読み込み）」です。 autoloadは、プラグインやテーマの設定をページの表示のたびにまとめて読み込む仕組みです。長く...
WP Mail SMTPの設定・テストに関する項目が出る
掲載画面では「WP Mail SMTPメーラーの設定が不完全です」と、送信元ドメインの確認を促す「Send a test email to check your email domain」が表示されていました。どちらもWP Mail SMTPが追加した項目です。
使用するメール送信方式の設定を確認し、テスト送信と実際の通知の到達を確かめます。送信成功の表示だけで、受信箱への到着まで保証されるわけではありません。通知が届かない場合は、迷惑メールや送信サービス側の記録も確認します。
本番サイトで問い合わせ通知や購入メールが届いていない場合は、後回しにしないでください。別の送信方式へ切り替えたなど、プラグインが不要な場合も、影響を確認して整理します。
WP Mail SMTPの設定手順は、こちらの記事で紹介しています。
問い合わせフォームから送ったはずの通知メールが、どこにも届いていない。迷惑メールフォルダにも見当たらない。 WordPressは、初期設定のままだとサーバーのPHPから直接メールを送ります。送信元のアドレスは「wordpress@サイトのドメイン」。実在しないこともあるこのアドレスから、送信の認証...
HTTPSを使用していないと表示される
検証画面では、HTTPSでアクセスできる一方、WordPressアドレス・サイトアドレスがHTTPになっているという説明でした。証明書が使えない場合など、同じ見出しでも原因は異なるため、展開した説明を読みます。
サイトヘルスにHTTPSへ更新するボタンがある場合も、次の点を確認してから変更します。
- バックアップと、管理画面に入れなくなった場合の復旧方法を用意する
- HTTPSのURLで証明書エラーなくアクセスできるか確認する
- サーバーやCDNの案内に沿って、サイトURLと転送設定を整える
- 変更後にログイン、画像、フォームなどを確認する
記事内などにHTTPのURLが残っている場合は、混在コンテンツの有無を確認します。データベースの直接置換は、保存形式を壊さない方法で行ってください。
サイトをHTTPSに切り替えるときは、こちらのプラグインも使えます。
あなたのWEBサイトは、SSL化（暗号化）されていますか？ 今や多くのサイトでSSL化は当たり前となっており、SSL化されていないサイトは、それでだけで評価が下がることがあります。Chromeで非SSL化のサイトへ接続すると、下記のように警告の文言が表示されます。 上記のような文...
ページキャッシュは未検出でも、応答が良好と表示される
掲載した検証では、トップページへのリクエストの応答時間の中央値が201ミリ秒で、画面の基準600ミリ秒を下回っていました。一方、ページキャッシュは検出されませんでした。
この計測は、訪問者の画面表示がすべて完了するまでの時間ではありません。画像やJavaScriptの読み込み、端末・回線の違いなどは別に考えます。
確認した公式コードでは、応答時間が基準未満なら、キャッシュの検出状況に応じて「テスト通過」または「おすすめの改善」となります。基準以上などの場合は「致命的な問題」になりますが、判定値は変更される可能性があります。
警告の有無だけを目的にキャッシュを追加せず、実際の負荷や表示速度、サーバー側のキャッシュも確認しましょう。会員向けページや購入画面など、キャッシュしてはいけない内容の扱いにも注意します。
参考：ページキャッシュの判定コード（WordPress公式）
「ページキャッシュが検出されませんでした」と出たときの対処は、こちらで解説しています。
WordPressのサイトヘルスに「ページキャッシュが検出されず、サーバーのレスポンスが遅くなっています」と表示されることがあります。 「致命的な問題」として表示されるので、早く解決したいですよね。 この問題は、シンプルに解決できる上にサイトの表示速度に関わるものなので、早めに対...
「テスト通過」や、表示されない項目の意味
問題が見つからなかった項目は、「テスト通過」にまとまります。PHPやデータベースのバージョン、REST API、ループバック、ディスク容量など、今回の10件以外にもチェックがあります。
ただし、環境によって実施されないテストもあります。Localなどの検証環境と本番サイトでは、環境タイプや利用機能が違うため、同じ警告一覧になるとは限りません。
サイトヘルスは既知の設定・接続状態などを点検する機能です。すべての脆弱性や侵害、通知の未達を検出するものではありません。
まとめ
最初に見るのは、外部へのエラー表示やログの公開、通信の保護などです。続いて、予約処理・メール・検索掲載が、サイトの目的どおり動いているかを確認します。
不要なプラグインやテーマの整理、キャッシュの導入は、使用状況と効果を確認して進めます。設定を変更した後は、サイトヘルスの再確認と、関係する機能の動作確認を行いましょう。
警告をゼロにすることより、必要な機能を保ち、実際の問題を解消することを優先してください。
WordPressテーマ集
コメント