この記事でわかること
- WordPressが狙われる本当の入口は、本体よりプラグインとテーマであること
- 効果の大きい順に並べた15の対策
- それぞれを、自分のサイトで外から（または管理画面から）確認する方法
- 2026年10月時点で使うべきPHPのバージョン
セキュリティ対策の記事には、「ログインURLを変える」と「プラグインを更新する」が同じ重さで並んでいることがよくあります。実際の効果は大きく違います。
この記事では、効果の大きい順に15項目を並べました。各項目には、自分のサイトで確認する方法を添えています。確認はすべて自分が管理するサイトで行ってください。他人のサイトでログインを試すような行為は、不正アクセスとみなされるおそれがあります。
WordPressが狙われる本当の理由
Patchstackのレポート「State of WordPress Security in 2026」によると、2025年に新たに見つかったWordPress関連の脆弱性は11,334件でした。前年から42%増えています。内訳はプラグインが91%、テーマが9%で、WordPress本体はわずか6件、いずれも低リスクでした。
日本の中小企業の被害も、同じ傾向です。IPAの「2024年度 中小企業における情報セキュリティ対策の実態調査」では、不正アクセスの原因の48.0%が「修正プログラムの未適用などの脆弱性」、36.8%が「ID・パスワードの窃取」でした。
つまり、守るべき順番ははっきりしています。まず更新、次にログインです。
最優先の5項目：更新・削除・PHP・バックアップ・監視
1. 本体・プラグイン・テーマを最新に保つ
脆弱性の多くは、修正版がすでに出ています。更新すれば塞がる穴を、開けたままにしないことが一番の対策です。
確認方法：管理画面の「ダッシュボード」→「更新」で、残っている更新がないかを見ます。外からは、ページのソースに表示されるバージョン番号が手がかりになります（項目11も参照）。
2. 使っていないプラグイン・テーマを削除する
停止しているだけのプラグインも、ファイルはサーバーに残っています。長期間更新されていない「放置プラグイン」は、脆弱性が見つかっても修正版が出ないことがあります。
確認方法：「プラグイン」一覧で停止中のものを削除し、残すものは「最終更新日」を公式ディレクトリで確認します。1年以上更新がないものは、代わりを探しましょう。
3. サポート中のPHPを使う（2026年10月時点は8.3以上）
PHPにはサポート期限があり、期限が切れるとセキュリティ修正が出なくなります。php.netの公開情報では、次のとおりです。
| PHP | セキュリティ修正の期限 |
|---|---|
| 7.4 / 8.0 / 8.1 | 終了済み |
| 8.2 | 2026年12月31日まで |
| 8.3 | 2027年12月31日まで |
| 8.4 | 2028年12月31日まで |
| 8.5 | 2029年12月31日まで |
WordPress公式の推奨も「PHP 8.3以上」です。8.2はあと2か月ほどで期限が切れるので、今から上げるなら8.3か8.4を選んでください。
確認方法：「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPのバージョンが分かります。切り替えはサーバーの管理画面から行います。手順はPHPバージョンアップの記事で解説します。
4. バックアップをサーバーの外にも置き、戻せるか試す
改ざんやサーバー障害のときに、最後に頼れるのはバックアップです。ただし、サーバー内だけのバックアップは、サーバーと一緒に失われることがあります。
確認方法：最新のバックアップの日付と保存先を確認します。年に1〜2回、ステージングなどに実際に戻してみるのが理想です。詳しくはバックアップの記事をどうぞ。
5. 使っているプラグインの脆弱性情報を追う
更新を待つだけでは、修正版が出ていない脆弱性に気づけません。
確認方法：JVN iPedia、WPScan、Patchstackなどのデータベースで、使っているプラグイン名を検索します。メール通知を出せるサービスもあります。
ログインを守る4項目
6. 推測されにくいパスワードと、人ごとのアカウント
アカウントを共有すると、誰が何をしたか追えず、退職者のアクセスも止められません。
確認方法：「ユーザー」一覧に、退職者や心当たりのない管理者がいないかを見ます。管理者の権限は、本当に必要な人だけに絞ります。
7. 2段階認証を入れる
パスワードが漏れても、2段階目がなければ入れません。IPAの調査でID・パスワードの窃取が36.8%を占めていることを考えると、効果の大きい対策です。
確認方法：ログアウトして入り直し、2段階目を求められるかを確かめます。
8. ログインの試行回数を制限する
パスワードを総当たりで試す攻撃は、今も毎日のように来ています。
確認方法：自分のサイトで、わざとパスワードを数回間違えてみます。一定回数でロックされれば機能しています。
9. ログイン画面を守る（URL変更は補助として）
ログインURLの変更は、機械的な攻撃を減らす効果はあります。ただし、URLを知られれば終わりなので、それだけに頼るものではありません。可能なら、IPアドレスによる制限や、ログイン画面の手前での認証を組み合わせます。
確認方法：シークレットウィンドウで、自分のサイトのログイン画面を開きます。誰でも開けるか、制限がかかっているかが分かります。
SiteGuardについて：日本で広く使われているSiteGuard WP Pluginは、項目8・9のようなログイン周りの対策に強いプラグインです。ただ、プラグインの更新、バックアップ、PHP、サーバー側の対策までは担いません。入れていれば安心、ではない点に注意してください。詳しくはSiteGuardの記事で解説します。
情報を漏らさない3項目
10. ログインに使うユーザー名を外に出さない
WordPressは初期状態だと、投稿者ページやREST APIからユーザー名が分かる場合があります。ユーザー名が分かれば、攻撃者はパスワードだけを当てればよくなります。
確認方法：自分のサイトの記事を開き、投稿者名と、そのリンク先のURLを見ます。表示名は「ユーザー」→「プロフィール」の「ブログ上の表示名」で変えられます。一方、URLの部分はログイン名から作られるため、プロフィール画面では変えられません。投稿者ページを使っていなければ無効にする、記事を書く用とログイン管理用のアカウントを分ける、といった対処をします。
11. バージョン情報と、不要な公開ファイルを隠す
バージョン番号が見えると、どの脆弱性が使えるかを相手に教えることになります。
確認方法：ブラウザでページのソースを表示し、「generator」で検索します。WordPressのバージョンが出ていれば、隠せます。また、自分のサイトの /readme.html を開いてみてください。WordPressの説明ページが表示されるなら、削除するかアクセスできないようにします。
12. ディレクトリの一覧表示を止める
フォルダの中身が一覧で見えると、アップロードしたファイルや、使っているプラグインの構成がまる見えになります。
確認方法：自分のサイトの /wp-content/uploads/ を開きます。ファイルの一覧が出るなら、サーバー側で一覧表示を無効にします。
サーバー側で守る3項目
13. HTTPSとHSTSを有効にする
通信の暗号化は今や前提です。さらにHSTSを設定すると、ブラウザが常にHTTPSで接続するようになります。
確認方法：http:// で始まるURLを入力し、https:// に転送されるかを見ます。HSTSは、次の項目のツールで確認できます。
14. セキュリティヘッダーを設定する
Content-Security-Policy（CSP）やX-Content-Type-Optionsなどのヘッダーは、改ざんされたときや、他のサイトに埋め込まれたときの被害を小さくします。JPCERT/CCの報告では、正規のサイトに偽のログインフォームが埋め込まれ、訪問者の情報が盗まれた事例もありました。
確認方法：securityheaders.com に自分のサイトのURLを入れると、設定されているヘッダーが一覧で分かります。ブラウザの開発者ツールの「ネットワーク」タブでも見られます。
15. WAFを使い、サーバー内の守りを固める
WAFは、攻撃と思われる通信を手前で止める仕組みです。多くのレンタルサーバーに無料の機能があり、Cloudflareのようなサービスを前に置く方法もあります。あわせて、次の2つの設定をしておくと、侵入されたときの被害を広げにくくなります。
- 管理画面からテーマやプラグインのファイルを編集する機能を無効にする
- 画像などのアップロード先で、プログラムが実行されないようにする
確認方法：サーバーの管理画面で、WAFが「有効」になっているかを確認します。ファイル編集の無効化は、管理画面の「外観」「ツール」に「ファイルエディター」が表示されなければ有効です。
15項目のチェック表
| # | 対策 | 外から確認できるか |
|---|---|---|
| 1 | 本体・プラグイン・テーマの更新 | 一部（バージョン表示） |
| 2 | 不要なプラグイン・テーマの削除 | いいえ（管理画面） |
| 3 | PHP 8.3以上 | いいえ（サイトヘルス） |
| 4 | サーバー外のバックアップと復元テスト | いいえ |
| 5 | 脆弱性情報の監視 | いいえ |
| 6 | 人ごとのアカウントと権限の整理 | いいえ（ユーザー一覧） |
| 7 | 2段階認証 | 自分でログインして確認 |
| 8 | ログイン試行回数の制限 | 自分のサイトで確認 |
| 9 | ログイン画面の保護 | はい |
| 10 | ユーザー名を外に出さない | はい |
| 11 | バージョン情報・readme.htmlを隠す | はい |
| 12 | ディレクトリ一覧の停止 | はい |
| 13 | HTTPSとHSTS | はい |
| 14 | セキュリティヘッダー | はい |
| 15 | WAFとサーバー内の設定 | 一部 |
迷ったら、1〜5と7から始めてください。この6つで、被害の原因の大部分に手が届きます。
このサイトで実際にやっている対策
wpexperts.jp自身もWordPressで動いていて、この記事の対策を実際に入れています。それぞれの対策と確認方法は「このサイトの守り方」のページで公開していますので、答え合わせに使ってください。
自分のサイトをまとめて確認したい方へ
外から確認できる項目（表で「はい」のもの）は、無料セキュリティチェックでまとめて確認できます。URLを入れるだけで、公開されている情報だけを見てスコアを出します。サイトに負荷をかけるような検査はしません。
結果の読み方が分からない、管理画面側の確認も含めて見てほしい、という場合は、お問い合わせフォームまたはLINEからご相談ください。