WordPressのログインURLを変える理由 — WPS Hide Loginの使い方

2026-02-15

読者が少ない時間帯でも、WordPressの応答が遅くなることはある。テーマやプラグインを疑う前に、アクセスログを見たい。既定のログイン先 /wp-login.php には、場所を知っている自動スキャンが集中しやすい。

自動スキャンでは、多数のサイトを調べ、WordPressのログイン画面を見つけると認証情報を繰り返し送ることがある。ログインが失敗しても、サーバーには処理が発生する。

ログインの処理に負荷がかかる理由

公開記事はページキャッシュから返せることがある。ログインの送信はアプリケーション側で処理するため、構成に応じて次のような作業が生じる。

  • PHPを実行する。
  • WordPress本体を読み込む。
  • アカウントを探す。
  • データベースに問い合わせる。
  • パスワードを照合する。
  • ログインに成功した場合、認証用のCookieを設定する。

短時間に試行が集中すると、PHPやデータベースの処理が積み重なる。小さなインスタンスではCPU使用率が上がり、応答が遅れることもある。ゲートウェイタイムアウトが出た場合も、原因はログで確かめる。

実際の読者が増えていなくても、ログインへのアクセスだけが増えることがある。

ログイン先を変えるとどうなるか

ログインフォームを、広範囲のスキャンがよく調べる場所から移す。新しいURLでも、ログインそのものを守る仕組みは必要だ。

WordPressの既定のパスは、たとえば次のとおり。

/wp-login.php

変更後のパスは、例としてこうなる。

/my-login

以前の /wp-login.php に認証情報を送り続けるボットには、旧URLに設定された応答が返る。たとえば404だ。WPS Hide Loginでは、そのリクエストを扱うためにWordPress自体は起動するが、旧パスで通常のログイン処理には進まない。

目的は、機械的なスキャンを認証フォームから遠ざけ、実際に使う人にはフォームを開けるようにすることだ。

Cloudflareが働く場所

Cloudflareは、ファイアウォールやレート制限の条件に合ったリクエストを、WordPressのサーバーに届く手前でブロックしたり、チャレンジを出したりできる。条件に当てはまらないものはオリジンに届く。

旧パスがまだログイン先なら、通過したリクエストは認証処理に進める。移したあともリクエスト自体はWordPressに届き得るが、旧フォームでは認証情報が処理されない。

二つの設定は、効く場所が違う。

  • Cloudflareは、条件に合うリクエストをオリジンの手前で処理する。
  • プラグインは、WordPressがログインフォームを受け付けるパスを変える。

両方を組み合わせることもできる。Cloudflareのイベントとオリジンのログを比べ、どのリクエストがサーバーまで届くかを確かめる。

WPS Hide Loginを設定する

WordPress本体のファイルに手を入れると、更新後の維持が難しくなる。WPS Hide Loginを使えば、管理画面からURLを変更できる。 公式資料

プラグインは本体を書き換えず、リクエストを受け取ってログインフォームの場所を切り替える。設定を保存したら、いま開いている管理画面を閉じる前に動作を試す。

管理画面で次の順に進む。

  1. WordPressの管理画面にログインする。
  2. 「プラグイン」から「新規プラグインを追加」を開く。
  3. WPS Hide Loginを探し、インストールして有効化する。
  4. 「設定」の「一般」を開く。
  5. ページ下部の「ログインURL」に新しいパスを入力し、保存する。

以下は説明用のパスだ。実際には推測されにくい文字列を選ぶ。

login

この例でのURL全体は、次のようになる。

https://example.com/login

別のプライベートウィンドウで新URLからログインできるか試す。旧 /wp-login.php と、ログアウト時の /wp-admin の挙動も確認する。

入れなくなったときに備える

ログアウトする前に、新しいURLをあとから参照できる場所に控える。分からなくなった場合は、プラグインの説明に、サーバーへのアクセスからパスを確認したり無効化したりする手順がある。

admin、login、wordpress などの一般的な語は推測されやすい。予測しにくいパスなら一部の自動スキャンを避けやすくなる。アカウントの保護にはパスワードやほかの認証手段も引き続き使う。

ログで何を見るか

Cloudflareのイベントやサーバーのログには、旧 /wp-login.php へのリクエストが残る場合がある。確認したいのは、実際のログインフォームに届く認証の試行が減ったかどうかだ。

条件の似た期間でログと稼働指標を見比べる。たとえば次の変化が考えられる。

  • 実際のログインフォームへの送信が減る。
  • 認証に伴うデータベースへの問い合わせが減る。
  • CPU使用率のばらつきが小さくなる。
  • 一時的な応答の遅れが減る。

ログイン試行に無視できない量の資源を使っていた小さなLightsailインスタンスでは、違いが表れやすいことがある。

変更後に確認しておきたいこと

フォームを移すと、既定パスを調べるボットによる認証処理を減らせる。旧URLへのアクセスは残り得る。ほかのWordPressの入り口にも通常の保護が必要だ。

Cloudflareで手前のリクエストを絞り、プラグインでフォームの場所を変える。組み合わせが自分のサイトで役に立ったかは、アクセスログで確かめられる。

記事を検索