セキュリティ用のプラグインには SiteGuard WP Plugin をよく使っていますが、エックスサーバーで WordPress をインストールすると、CloudSecure WP Security も一緒にインストールできるようになりました。どちらを使うのがよいのか、公式の情報で比べました。
結論から書くと、管理しているサイトは SiteGuard に統一しました。また、調べている途中で、ログインの URL を変えたときに起きる問題が 2 つ見つかったので、直し方もまとめます。数字は 2026-10-12 に公式のページで確認したものです。
2 つのプラグイン
| SiteGuard WP Plugin ／ CloudSecure WP Security | |
|---|---|
| 作っているところ | SiteGuard WP Plugin：JP-SecureCloudSecure WP Security：エックスサーバー（WordPress.org の作者もエックスサーバー） |
| 料金 | SiteGuard WP Plugin：無料（WordPress.org からインストールできる）CloudSecure WP Security：無料（WordPress.org からインストールできる） |
| 主な役目 | SiteGuard WP Plugin：ログインの守り・管理画面の守りCloudSecure WP Security：ログインの守り・管理画面の守り・通知 |
どちらも、有料の段階があるとは公式のページに書かれていません。
機能の比べ
| 機能 | SiteGuard | CloudSecure |
|---|---|---|
| ログインの URL の変更 | あり | あり |
| 画像認証 | あり | あり |
| ログインのロック（何度も失敗したら止める） | あり | あり |
| ログインの通知（メール） | あり | あり |
| 2 段階認証 | なし | あり（認証アプリかメール・予備のコード） |
| ログインのエラー文をまとめる | あり | あり |
| フェールワンス（最初の正しいログインをわざと失敗させる） | あり | なし |
| XML-RPC | ピンバックだけ止める／全部止める、を選べる | 止める |
| REST API を止める | あり | あり |
?author= でユーザー名を漏らさない |
あり | あり |
| 管理画面の制限 | ログインできた IP だけ通す | 24 時間ログインのない IP に 404 |
| WAF | SiteGuard Server Edition の入ったサーバーで、誤検知の除外を書くだけ | プラグインの中の簡易 WAF（最初は切ってある） |
| 設定ファイルへのアクセスを止める | なし | あり |
| 500 エラーの通知 | なし | あり |
| 改ざんの検知 | どちらも公式のページには書かれていない | |
いちばん大きな違いは、2 段階認証です。CloudSecure にはあり、SiteGuard にはありません。反対に、フェールワンスは SiteGuard だけの機能です。
フェールワンスは、正しい ID とパスワードを入力しても、1 回目は必ず失敗にする機能です。人なら「もう一度入力すればよい」と知っていますが、パスワードを総当たりで試す仕組みは、正しいパスワードを試したときに失敗と受け取ってしまいます。
手入れの状況
WordPress.org のプラグインのページで見ました。
| SiteGuard ／ CloudSecure | |
|---|---|
| 今のバージョン | SiteGuard：1.8.9CloudSecure：1.4.17 |
| 最終更新 | SiteGuard：2026-08-19CloudSecure：2026-09-29 |
| 有効なインストール | SiteGuard：50 万以上CloudSecure：10 万以上 |
| 評価 | SiteGuard：4.3（15 件）CloudSecure：5.0（2 件） |
| フォーラムの未解決 | SiteGuard：30 件をこえるCloudSecure：0 件 |
| 試験済みの WordPress | SiteGuard：7.1.3CloudSecure：7.1.3 |
使っている人の数は SiteGuard のほうがずっと多いです。フォーラムの返事の早さは、CloudSecure のほうがよく見えます。評価は、CloudSecure は 2 件しかないので、まだ比べにくいです。
最近の脆弱性
| プラグイン | 中身 ／ 直ったバージョン |
|---|---|
| SiteGuard | 中身：CVE-2026-61982 など。ログインの URL を変えたときの、ログアウトの URL の XSS直ったバージョン：1.8.7 |
| CloudSecure | 中身：CVE-2026-42411 など。XML-RPC からのログインで、2 段階認証を飛ばせた直ったバージョン：1.4.8 |
どちらも、今のバージョンでは直っています。セキュリティのプラグインにも脆弱性は出るので、どちらを使う場合も、更新を止めないことが大事です。
エックスサーバーとの関係
CloudSecure は、エックスサーバーのグループが作っています。
- 2025-03-25 から、エックスサーバーの「WordPress 簡単インストール」で、CloudSecure を一緒にインストールできるようになりました
- 2025-11-12 から、XServer for WordPress で標準で使えるようになりました
簡単インストールの画面には、CloudSecure を一緒にインストールする項目があります。有効のまま進めると、CloudSecure が入った状態で WordPress ができます。
管理しているサイトは SiteGuard に統一した
フェールワンスや、管理画面の制限などの細かい設定も気に入っているので、SiteGuard に統一することにしました。弱いところは、2 段階認証がないことです。その分、ログインの URL の変更・画像認証・ログインのロック・フェールワンスを重ねて守ります。
2 つを同時にインストールしない
どちらも、ログインの URL を変えるときに、.htaccess とログインの処理を書き換えます。2 つとも有効にすると、ログインの URL が 2 つ使えてしまったり、ログインの画面が出なくなったりします。SiteGuard の WordPress.org のページにも、ほかのプラグインのログインの URL の変更と一緒に使わず、どちらか 1 つだけで有効にするように書かれています。
切り替えるなら、何が要るか
今回は切り替えていませんが、もし切り替えるなら、次のことが要ります。
- ログインの URL が変わる。ブックマークや、ログインの URL を知っている人に知らせる
- 設定は引き継がれない。ロックの回数・通知・管理画面の制限などを、新しいプラグインで設定し直す
- 前のプラグインを止めたあと、.htaccess にルールが残っていないかを見る
- 切り替える前に、.htaccess とデータベースのバックアップを取る
見つかったこと 1：/wp-admin/ を開くと、変えたログインの URL へ転送されていた
比べている途中で、管理しているサイトの /wp-admin/ を、ログインしていない状態で開いてみました。すると、多くのサイトで、変えたログインの URL へ 302 で転送されていました。
これでは、/wp-admin/ を開くだけで、変えたログインの URL が分かってしまいます。ログインの URL を変えた意味が薄れます。
確認の方法
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://example.com/wp-admin/
| 書き方 | 役目 |
|---|---|
-s |
途中の表示を出さない |
-o /dev/null |
ページの中身は捨てる |
-w "%{http_code} %{redirect_url}" |
返ってきた番号と、転送先の URL だけを出す |
転送先が、変えたログインの URL になっていたら、直す必要があります。
# 直す前 302 https://example.com/（変えたログインの URL）?redirect_to=...&reauth=1 # 直したあと 302 https://example.com/
なぜ転送されるのか
WordPress は、ログインしていない人が管理画面を開くと、ログインの画面へ転送します（auth_redirect()）。SiteGuard でログインの URL を変えていると、この転送先も、変えたログインの URL になります。
SiteGuard には、この転送を止める設定があります。「ログインページ変更」の画面にある「管理画面 (/wp-admin/) からログイン画面にリダイレクトしない。」です（設定の名前は redirect_enable）。これらのサイトは、ここにチェックが入っていませんでした。
// SiteGuard（1.8.9）の classes/siteguard-rename-login.php から
add_filter( 'auth_redirect_scheme', array( $this, 'handler_stop_redirect' ), 9999 );
function handler_stop_redirect( $scheme ) {
global $siteguard_config;
$redirect_enable = $siteguard_config->get( 'redirect_enable' );
if ( $redirect_enable == 1 ) {
if ( $user_id = wp_validate_auth_cookie( '', $scheme ) ) {
return $scheme;
}
wp_safe_redirect( home_url() );
exit;
}
}
| 書き方 | 役目 |
|---|---|
auth_redirect_scheme |
WordPress が管理画面でログインを確認する前に通るフィルター |
redirect_enable == 1 |
「リダイレクトしない」にチェックが入っているとき |
wp_validate_auth_cookie() |
ログインしている人なら、ふつうに管理画面を出す |
wp_safe_redirect( home_url() ) |
ログインしていない人は、ログインの画面ではなくトップへ送る |
直した結果
チェックを付けたら、/wp-admin/ から変えたログインの URL へは転送されなくなりました。どのサイトも、ログインしていない人は、上のコードのとおりトップへ 302 で送られるようになりました。ほかのサイトは、もとから変えたログインの URL へは転送されていませんでした。
なお、SiteGuard の「管理ページアクセス制限」を有効にしていると、ログインしたことのない IP からの /wp-admin/ は 404 になると、公式のページに書かれています。
作業環境でも確認した
作業環境の 2 サイトで、データベースの SiteGuard の設定（siteguard_config）の値をメモしてから、redirect_enable を 0 と 1 に変え、/wp-admin/ を 2 回ずつ開きました。
| redirect_enable | サイト A ／ サイト B |
|---|---|
| 0（チェックなし） | サイト A：302・変えたログインの URL へ（2 回とも）サイト B：302・変えたログインの URL へ（2 回とも） |
| 1（チェックあり） | サイト A：302・トップへ（2 回とも）サイト B：302・トップへ（2 回とも） |
試したあとは、メモした設定に戻し、戻した値がメモと同じことを確認しました。
見つかったこと 2：ログインの画面がキャッシュされて、認証画像が出なかった
あるサイトで、ログインの画面の画像認証の画像が出ず、ログインできなくなりました。
回り道：パーミッションを疑った
SiteGuard の画像認証は、wp-content/siteguard/ に画像を作ります。最初は、このフォルダに書き込めないのだと思い、パーミッションを見ました。でも、問題はなく、画像のファイルもちゃんと作られていました。
原因：キャッシュのプラグインが、ログインの画面を丸ごと保存していた
ログインの画面のソースを見ると、いちばん最後に次の 1 行がありました。
<!-- Cached by WP-Optimize - https://teamupdraft.com/wp-optimize/ - Last modified: （キャッシュを作った日時） -->
日時は前日のままでした。キャッシュのプラグイン（WP-Optimize）が、変えたログインの URL のページを、ふつうのページと同じように保存していたのです。
SiteGuard の画像認証は、ページを開くたびに新しい画像を作り、使い終わった画像や古い画像は消します。
// SiteGuard（1.8.9）の画像認証の一部
// ページを開くたびに、新しい画像を作る
function put_captcha() {
$this->word = $this->captcha->generate_random_word();
$this->prefix = siteguard_rand();
$this->captcha->generate_image( $this->prefix, $this->word );
echo $this->get_captcha();
}
// 画像の場所は wp-content/siteguard/（番号）.png
$result .= '<img src="' . WP_CONTENT_URL . '/siteguard/' . $this->prefix . '.png" alt="CAPTCHA">';
// 画像を作るときに、60 分より古い画像と答えのファイルを消す
public function cleanup( $minutes = 60 ) { ... }
保存されたページには、前日に作った画像の URL が書かれたままです。その画像はもう消えているので、画像の URL は 404 になります（そのサイトでは、ない URL はトップへ転送していたので、画像の代わりにトップのページが返っていました）。これで、画像が出ず、答えも合わないので、ログインできなくなっていました。
なぜ wp-login.php は大丈夫で、変えた URL はだめなのか
WP-Optimize は、最後が .php の URL はキャッシュしません。
// WP-Optimize（4.7.0）の cache/file-based-page-cache-functions.php から
$request_uri = isset($_SERVER['REQUEST_URI']) ? strval(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)) : '';
$file_extension = strtolower(pathinfo($request_uri, PATHINFO_EXTENSION));
// Don't cache disallowed extensions. Prevents wp-cron.php, xmlrpc.php, etc.
if (!preg_match('#index\.php$#i', $request_uri) && !wpo_is_cacheable_sitemap_request() && in_array($file_extension, array('php', 'xml', 'xsl'))) {
$no_cache_because[] = 'The request extension is not suitable for caching';
}
| 書き方 | 役目 |
|---|---|
pathinfo( ..., PATHINFO_EXTENSION ) |
URL の最後の拡張子（php など）を取り出す |
array('php', 'xml', 'xsl') |
この拡張子の URL はキャッシュしない（index.php とサイトマップは別） |
$no_cache_because[] |
キャッシュしない理由を足す。理由が 1 つでもあれば保存しない |
wp-login.php は最後が .php なので、最初からキャッシュされません。でも、変えたログインの URL は、ふつうのページの URL と同じ形なので、WP-Optimize にはログインの画面だと分かりません。そのため、自分で「キャッシュしない URL」に足す必要があります。
直し方
- その場では、ログインの URL の最後に
?nc=1を付けて開きました。WP-Optimize は、知らないクエリの付いた URL はキャッシュから出さないので、新しい画像のページが出て、ログインできました - ログインしてから、WP-Optimize の設定の「キャッシュしない URL」（設定の名前は
cache_exception_urls）に、変えたログインの URL を足しました
もう 1 サイトでも、同じようにログインの画面がキャッシュされていたので、同じように足しました。
確認の方法
curl -s "https://example.com/（変えたログインの URL）" | grep -c "Cached by WP-Optimize"
| 書き方 | 役目 |
|---|---|
curl -s |
ログインしていない人として、ログインの画面を取ってくる |
grep -c "Cached by WP-Optimize" |
キャッシュの目じるしが何行あるかを数える |
1 が出たらキャッシュされています。0 なら大丈夫です。
作業環境でも確認した
作業環境の 2 サイト（どちらも、本番から複製したままの設定）で、ログインの画面を取ってきました。
| 開き方 | キャッシュの目じるし ／ 認証画像の番号 |
|---|---|
| そのまま（1 回目・2 回目） | キャッシュの印：2 サイトと目じるし 1認証画像の番号：2 回とも同じ番号 |
?nc=乱数 を付ける（1 回目・2 回目） |
キャッシュの印：2 サイトと目じるし 0認証画像の番号：毎回ちがう番号 |
そのまま開くと、保存されたページが返り、画像の番号が変わりません。作業環境では、保存したばかりで画像がまだ残っていたので、画像は 200 で出ました。画像が消えて 404 になるところ（60 分たったあと）は、作業環境では試していません。
気をつけること
この 2 つは、SiteGuard だけの話ではありません。ログインの URL を変えるプラグインなら、どれでも起こりえます。
まとめ
作業環境で試していない、ログインの画面の画像が消えて 404 になるところ（60 分たったあと）を試します。「キャッシュしない URL」に足したあとは、時間がたってもログインの画面が新しく作られることを確認します。
参考
- SiteGuard WP Plugin（WordPress.org のプラグインのページ）
- SiteGuard WP Plugin（JP-Secure）
- CloudSecure WP Security（WordPress.org のプラグインのページ）
- CloudSecure WP Security の使い方（エックスサーバー）
- WordPress 簡単インストールで CloudSecure WP Security を一緒にインストールできるように（エックスサーバーのお知らせ）
- XServer for WordPress での標準提供のお知らせ（CloudSecure WP Security）
- auth_redirect()（developer.wordpress.org）
- auth_redirect_scheme（developer.wordpress.org）
- WP-Optimize（WordPress.org のプラグインのページ）
