WordPressの安全点検は何を見る？更新通知・管理者・バックアップの確認方法

点検するサイト・時点・担当の範囲を決める

まず、自社のどのWordPressを、いつの状態として確かめるかを決めます。公開サイトと試験用サイト、別店舗のサイトを混ぜないよう、対象名とURLを照合します。管理画面の見え方や項目名は、版・追加機能・自分の権限によって変わることがあります。

会社のWeb担当は、商品案内、注文受付、問い合わせなど、止まると困る仕事を挙げます。管理する担当は、今回見られる管理画面と保存資料、確認できない範囲を示します。画面へ入れない場合は、権限のある担当へ項目の確認を依頼します。点検のためだけに管理者権限を広げたり、他人の認証情報を共有したりする必要はありません。

記録では、観測と判断を分けます。「更新通知が見える」は観測、「その対象を更新する」は作業の判断です。「管理者の用途が分からない」は未確認であって、不正な利用者と確定した結果ではありません。画面を見た時点と、通知・保存物そのものの日時も区別してください。

WordPress公式の安全性を高めるための説明も、完全な安全の保証ではなくリスクを減らす考え方を示しています。ホスティング側とサイト側の担当範囲を確かめ、個別の疑問はその環境を把握する担当へ戻します。

更新通知とサイトヘルスを、項目ごとに読む

更新通知は、対象の名前と現在の状態を確認する入口

管理画面の「ダッシュボード → 更新」や、テーマ・プラグインの管理画面で、どの対象に通知があるかを確かめます。本体の通知と、商品表示や受付を支える追加機能の通知を一つにまとめず、対象名、表示された文、確認時点を残します。版の情報を取得できるなら、現在の版と更新候補も制作担当と照合します。

本体の通知が見えなくても、プラグインに通知がある場合があります。通知がどちらにも見えないという記録でも、他の弱点や管理上の不足まで否定できません。表示されている通知を読む点検と、構成・提供元の案内を照合する調査は区別します。

通知を見たら、その場で一括更新するのではなく、対象の役割、更新内容、戻す備え、試す場所を確認します。作業順を決める具体的方法は、本体・テーマ・プラグインの更新対象と確認順で説明しています。本稿では、通知を見た後に何を調べれば実施の判断へ進めるかを整理します。

サイトヘルスは、分類と指摘の本文を読む

「ツール → サイトヘルス」を開き、「ステータス」で指摘の分類と項目を読みます。critical、recommended、passedなどの分類名だけで終えず、どの項目にどの文が出ているかを確かめてください。日本語表示は環境によって異なるため、見えた文を自分の記録に残します。

passedは、その道具が調べた項目で問題が示されていないという範囲で読みます。管理者の用途、保存物で復元できるか、顧客の注文が受け付けられるかまで、一つの表示で確認できたとは扱いません。「情報」タブは構成情報を見る場所で、そこを開くこと自体が設定を修正する作業でもありません。

分類と二つのタブの役割は、WordPress公式のサイトヘルス画面を参照しています。以下の架空例にある「背景更新の確認が必要」は例の原票の文であり、実サイトの原因や、現行画面の正確な翻訳を示すものではありません。

管理者の用途と、ファイル・DBの保存記録を確かめる

管理者は、人数だけでなく誰のどの仕事かを照合する

権限のある担当が「ユーザー」の一覧で、管理者の役割が付いた利用者を確認します。表示対象や絞り込みも確かめ、会社側の担当・制作委託先・必要な運用との対応を読み合わせます。実名・メールアドレス・パスワードなどを、公開用の点検資料へ貼る必要はありません。

覚えのない利用者が見えたら、サイト責任者へ作成の経緯、利用する人、現在の用途を確認します。分からないことだけで侵入者と決めつけず、用途が分かるまで削除や役割変更を先走らないようにします。人数が二人だから適切、三人だから不適切、という一律の基準にもできません。

仕事に対して権限が広すぎる・足りない可能性がある場合は、必要な操作と現在の設定を照合します。WordPressの仕事と役割から権限を決める方法がその判断に対応します。利用者一覧の列や役割の表示は、WordPress公式のユーザー画面で確認できます。

ファイルの保存記録と、DB・復元の記録を別々に見る

バックアップは、必要になったときに戻すための保存物です。画像・テーマ・プラグインなどのファイルと、投稿・設定などを保存するDB（データベース）を、対象サイトと保存分が対応する組として確かめます。保存先、対象、取得した時点を資料と照合し、必要な担当が取り出せるかも確認してください。

ファイルを保存した記録があっても、対応するDBがあるかは別です。取得時刻が近いだけで整合した一組とせず、保存中の変更をどう扱ったかも管理担当に確認します。保存処理の完了表示、必要な部品がそろうこと、その保存物で実際に動くことは、それぞれ違う確認です。

復元を試した記録が見つからなければ、復元できないとも、問題なく戻せるとも補いません。保存物と検証先を決めた試験が必要なら、本番と分けた環境でのWordPress復元テストへ進みます。点検中に本番のDBやファイルを上書きして試す作業ではありません。

WordPress公式の更新案内は更新前のバックアップを案内しています。保存があることだけで、今回の更新を開始できることや、顧客の注文・受付まで戻せることを保証する説明にはしません。

通知がある例と、用途不明の管理者がある別の例を比べる

次の二つは、別々のサイトを点検した架空の記録です。小物販売サイトAには、本体の通知は見えず、商品表示プラグインの更新通知があります。ファイルの保存記録はありますが、DBの保存と復元試験は未確認です。通知の対象と、戻すための保存物の組が分かるまで、変更を保留しています。

別の相談受付サイトBには、サイトヘルスのpassed項目が見え、本体・プラグインの通知は見えていません。一方、管理者一覧には用途を確認したい利用者があります。担当はサイト責任者へ用途を照会中で、削除や権限変更をまだ進めないという記録です。BはAを修正した後のサイトではありません。

画面の表示がよくても、飛ばせない確認はどれ？

図では、Aの「プラグインの通知」と「ファイルの記録・DB未確認」、Bの「passed項目」と「管理者の用途確認」を、それぞれのサイト内で結び付けて読みます。線は確認する資料の関係を示し、更新や修復が成功した順番を示しません。

説明図の原画を開く

Aでは、制作担当に対象の更新内容と、対応するファイル・DBの保存分、復元確認の記録を尋ねます。Bでは、サイト責任者に利用者の用途と必要な仕事を確認します。どちらも、未確認の注文・受付の動作、侵害の有無、変更後の結果を、よい表示から埋め合わせることはできません。

変更する条件を決め、同じ項目と実ページを見直す

点検で得た情報から、何を変更する必要があり、何がまだ判断できないかを分けます。Web担当が「通知を消すこと」だけを完了条件にせず、管理する担当と、対象・理由・作業する時点・戻す備え・確認する機能を決めます。緊急の指摘があれば、表示された内容と対象を速やかに責任者へ伝え、必要な対応の優先度を確認してください。

1. 保留の理由を一つずつ明らかにする。Aなら、DBと復元試験の記録を取得できていません。担当に確認し、どの保存分と結果を根拠にするかを決めます。Bなら、利用者の用途と必要な操作が先です。未確認のまま、まとめて更新・削除を実行しません。
2. 作業する人と、判断し直す条件を決める。更新は制作・保守担当、利用者の用途はサイト責任者、保存物は管理担当など、実際の契約と体制に合わせて確認先を指定します。「連絡済み」と「回答を得て条件を確認済み」を分け、判断を行う時点も決めます。情報が来ないまま一定日数待てば安全、とはしません。
3. 承認した変更の後に、同じ項目を読み直す。実施した対象と版、通知・指摘の変化を、前と同じ場所で比較します。未実施の対象や見ていない項目は未確認のまま残します。点検表示が変わったことから、すべての弱点がなくなったとは判断しません。
4. 重要な実ページと必要な動作を確認する。商品案内や相談受付など、先に挙げた仕事のページで、表示・移動・入力を対象に応じて確かめます。注文や通知の送信は、許可された試験先と範囲が決まっている場合に別に確認します。画面の完了表示と、会社側の受付は同じ結果ではありません。

予想と違う状態があれば、対象、操作、期待した結果、実際の表示を残し、担当と次の調査を決めます。更新後に起きたことだけで原因を特定したり、用途不明の利用者がいたことだけで侵害と確定したりはしません。明らかな不審な変化や顧客への影響が疑われる場合は、通常の点検を完了扱いにせず、責任者と環境を管理する担当へ状況を伝え、調査・対応の範囲を決めます。