SiteGuard WP Pluginを使っていて管理画面が404になる場合は、最初に変更後のログインURLから再ログインします。404だけで原因を決めつけたり、.htaccessの設定をすべて消したりしないでください。
管理ページとログインページを分けて確認する
「管理ページアクセス制限」は、ログインしていない接続元から/wp-admin/へのアクセスを404にします。Wi-Fiや接続元IPが変わったときは、管理ページではなくログインページへ移動してログインし直します。ログインページ変更を使っている場合は、変更後のURLを開きます。
以前の本文には「24時間後に解決する」とありましたが誤りです。公式説明の24時間は、ログイン済み接続元の扱いに関する時間であり、待つだけで復旧する保証ではありません。公式の管理ページアクセス制限で条件を確認してください。
ログインURLが分からない場合
保存したブックマークや、設定変更時に管理者へ届いた「ログインページURLが変更されました」というメールを確認します。対応版ではログインURLレスキュー機能もあります。機能の有効状態と利用中の版を確認し、公式のログインページ変更マニュアルに沿って進めます。
再ログインでも直らない場合
発生URL、時刻、接続環境、プラグインの版を控え、管理者またはサーバー担当者に確認します。Webサーバー、別のセキュリティ機能、URLの誤りでも404になるため、SiteGuardだけを原因と断定しません。認証情報を公開の相談欄へ貼らないでください。
公式FAQには、通常の復旧手順を試してもプラグインが原因と考えられる場合の復旧方法があります。.htaccessを編集する場合は、現在のファイルを復元できる形で保存し、対象のSiteGuard設定と他のWordPress・サーバー設定を区別します。Nginxなど.htaccessを使わない環境には同じ手順を適用できません。
設定を外すと保護機能が無効になる場合があります。
ログインが戻った時点で終了せず、必要な保護設定を復旧し、ログアウト状態でのログインと管理ページへのアクセスを確認してください。
本番環境の設定変更や障害復旧は行っていません。
SiteGuard公式FAQを参照してください。
管理ページアクセス制限の確認結果
| 接続状態 | 隔離環境での結果 |
|---|---|
| 未ログイン・成功記録のない接続元IP | /wp-admin/は404、通常のログインURLは200 |
| 同じIPでログイン成功後、Cookieなしで管理ページへアクセス | ログイン画面へ302転送 |
| 成功記録を24時間より古くした後、Cookieなしでアクセス | 管理ページは再び404 |
| ログイン済みのCookieが有効 | IP記録が古くても管理画面を表示 |
2026年10月3日、SiteGuard WP Plugin 1.8.9の管理ページアクセス制限のPHP処理を、隔離したWordPress 7.1.2でHTTP検証しました。
ローカル接続を外部IPとして扱う検証用の条件を置き、プラグインの判定処理と専用のログイン記録テーブルを使用しています。
この結果は、24時間待つことが復旧策にならない点を確認するものです。
ログインページ変更、Apacheの.htaccessによる処理、実サーバーの接続元IP判定は今回の試験に含みません。
変更後のログインURLは自分の設定記録から確認してください。
Apache経由でも管理ページとログインを分ける
2026年10月3日、隔離したApache 2.4.69・PHP CGI 8.2.29からWordPress 7.1.2へ接続し、SiteGuard 1.8.9の管理ページアクセス制限の判定処理を追加確認しました。
成功記録のない試験用IPでは管理ページが404、通常のログインURLは200でした。
その判定処理を読み込まない試験用リクエストでは、管理ページからログイン画面へ302転送されました。
本番の保護設定は変更していません。
ローカル接続を試験用の外部IPとして扱い、所有する記録テーブルを使った確認です。
プラグイン全体の有効化、ログインURL変更の生成・保存、サーバーが実際に認識する接続元IP、設定画面からの復旧は含みません。
404が同じでも、管理ページアクセス制限とログインURL変更は分けて調べます。
