WordPressにログインできない原因と今すぐ試せる復旧方法

 

WordPressにログインできなくなったという相談は定期的に寄せられます。
特に多いのは、更新作業直前やキャンペーン公開直前など「今すぐ入らなければならない」状況です。

私自身も、緊急で記事を修正する必要があった日に管理画面へ入れなくなり、原因の切り分けに想定以上の時間を使った経験があります。

そのときはパスワードエラーだと決めつけ、何度も再発行を繰り返しましたが、実際の原因は別の場所にありました。今振り返ると、焦りが判断を狭めていたと思います。

この記事では、私が現場で実際に確認している順番と具体的な復旧方法を、経験を踏まえて紹介します。

WordPressにログインできない原因は以下の7点が考えられます。

原因①　ログインURLの正誤

経験上、最初に確認すべきはログインURLそのものです。

私は担当変更直後のサイトで、標準の「/wp-admin/」にアクセスして入れず、サーバー障害を疑ったことがあります。
WordPressの標準ログインURLは以下のいずれかになります。

• https://ドメイン/wp-admin/
• https://ドメイン/wp-login.php

しかし、セキュリティ強化のためにログインURLを変更しているケースがあります。

その場合、上記URLではアクセスできません。
特に「WPS Hide Login」などのプラグインを使用していると、独自URLになります。

ログインURLの正誤の確認方法

ログインURLの正誤の確認方法として以下の方法があります。

• 過去のメールや資料で変更URLを確認する
• 前任者や制作会社へヒアリングする
• .htaccessにリダイレクト設定がないか確認する

私は当時、サーバーメンテナンス通知を見た直後だったため、障害だと判断しました。
なぜその判断をしたかというと、直前情報に引きずられていたからです。

しかし実際はURL変更が原因でした。

その経験から、私は最初にURLの仕様を確認することを習慣にしています。
思い込みではなく、仕様確認から始めることが基本だと学びました。

原因②　パスワードエラーとユーザー情報の整合性

次に多いのは、認証情報の不一致です。
私は一度、クライアントから「正しいパスワードなのに入れない」と連絡を受け、システム不具合を疑いました。

しかし事実として、WordPressのユーザー情報はデータベースの「wp_users」テーブルに保存されています。
つまり、登録メールアドレスやユーザー名が一致していなければ再発行も届きません。

データベースでの確認手順

• サーバー管理画面からphpMyAdminへログイン
• 該当データベースを選択
• wp_usersテーブルを開く
• user_email・user_loginを確認

 

パスワードを直接変更する場合は、以下のようにMD5形式で保存します。

UPDATE wp_users SET user_pass = MD5('新しいパスワード') WHERE user_login = 'admin';

私は当初、ユーザーが削除された可能性を疑いました。
なぜなら、管理画面上で表示されなかったからです。

しかし実際は単にメールアドレスの相違でした。

この経験から、私は削除を疑う前にデータの存在を確認するという順序を守っています。
削除や新規作成は最後の手段にすべきだと実感しました。

原因③　プラグイン・テーマの競合によるログイン不能

アップデート後にログインできなくなるケースも少なくありません。
私はテーマ更新直後に管理画面が真っ白になり、コア破損を疑ったことがあります。

事実として、WordPressではプラグインやテーマの競合でログイン不能になることがあります。
特にPHPバージョン変更後に発生しやすい傾向があります。

FTPでプラグインを停止する方法

• FTPソフトでサーバーへ接続
• /wp-content/plugins/ を開く
• 問題が疑われるフォルダ名を変更

例：contact-form → contact-form_old

フォルダ名を変更すると自動的に無効化されます。
私は以前、全プラグインを一括停止しました。

なぜそうしたかというと、早期復旧を優先したからです。
しかし原因特定に余計な時間がかかりました。

今は一つずつ無効化し検証する方法を徹底しています。
急ぐほど検証手順を守ることが重要だと学びました。

原因④　サーバー側のWAF・IP制限によるブロック

ログイン試行回数が多い場合、IPアドレスが自動的に制限されることがあります。
私は深夜対応時に何度も再入力し、IPブロックを受けたことがあります。

事実として、多くのレンタルサーバーではWAFが標準で有効になっています。
403エラーが表示される場合はこの可能性があります。

確認ポイント

• サーバー管理画面でWAFログを確認
• アクセスログに403がないか確認
• 一時的にWAFを無効化して検証

私は当初、パスワード誤りだと判断しました。
なぜならエラーメッセージが認証失敗だったからです。
しかし実際はIP制限でした。

その経験以降、ログを確認するまで再試行しないという判断基準を設けました。
ログは感覚よりも正確な判断材料になります。

原因⑤　データベース接続エラーとwp-config.phpの確認

ログイン画面以前に「データベース接続確立エラー」が表示される場合は、認証以前の問題です。
私はサーバー移転直後の案件でこの表示が出たとき、データ破損を疑いました。

事実として、WordPressはwp-config.phpに記載された情報をもとにデータベースへ接続しています。
ここに誤りがあると、ログインどころかサイト全体が表示されません。

確認すべき設定項目

define('DB_NAME', 'データベース名');
define('DB_USER', 'ユーザー名');
define('DB_PASSWORD', 'パスワード');
define('DB_HOST', 'localhost');

特に注意すべきはDB_HOSTです。
サーバーによっては「localhost」ではなく、専用ホスト名が指定されます。

私は当時、直前にデータ移行を行っていたため、インポートミスだと判断しました。
なぜその判断をしたかというと、自分の作業を原因だと想定したほうが説明がつくと思ったからです。

しかし実際はホスト名の誤りでした。

その経験から、私は作業履歴に関係なく設定値を客観的に照合することを徹底しています。
設定値の確認は、推測ではなく照合で行うべきだと学びました。

原因⑥　PHPバージョンとメモリ不足の影響

ログイン時に500エラーや真っ白な画面になる場合、PHP環境の影響も考えられます。
私は一度、PHPバージョンを更新した直後に管理画面へ入れなくなりました。

事実として、WordPressは推奨PHPバージョンが定められており、古いテーマやプラグインが新バージョンに対応していないことがあります。
また、メモリ不足でも同様の症状が出ます。

wp-config.phpでのメモリ増設例

define('WP_MEMORY_LIMIT', '256M');

エラーログに「Allowed memory size exhausted」とあれば、メモリ不足の可能性が高いです。

私は当初、テーマ破損を疑い再アップロードしました。
なぜなら直前にテーマを更新していたからです。

しかし実際はメモリ不足でした。

この経験から、エラーログを確認してから再アップロードを行うという順序を守っています。
ログを見ずに上書きするのは、遠回りになることが多いです。

原因⑦　改ざん・不正アクセスの可能性

可能性は低いものの、改ざんが原因でログインできないケースもあります。
私は一度、ログインURLが外部サイトへリダイレクトされる案件を担当しました。

事実として、改ざんがある場合は不審なPHPコードや未知の管理者ユーザーが存在します。
サーバーの最終更新日時を確認すると、不自然な変更が見つかることがあります。

確認ポイント

• wp-admin内に不審なファイルがないか確認
• wp_usersテーブルに見覚えのない管理者がいないか確認
• コアファイルを公式版で上書きする

私は当初、キャッシュ不具合を疑いました。
なぜなら表示崩れが同時に起きていたからです。

しかし実際はindex.phpへの不正コード挿入でした。
今振り返ると、変更履歴と無関係な場所も確認すべきでした。

この経験は、想定外の可能性を切り捨てない判断基準につながっています。
関連性が薄く見えても、調査対象から外さない姿勢が重要です。

よくある質問（FAQ）

Q. パスワード再発行メールが届きません。
登録メールアドレスの確認と迷惑メールフォルダを確認してください。
届かない場合は、データベースから直接変更が可能です。

Q. 何度入力しても弾かれます。
IP制限やWAFブロックの可能性があります。
ログ確認を優先してください。

Q. 真っ白な画面になります。
プラグイン停止とPHPバージョン確認を行います。
エラーログの確認が重要です。

まとめ

WordPressにログインできない状況は、原因が一つとは限りません。
私が現場で常に意識している判断軸は、「仕様」「認証」「環境」「制限」「改ざん」の順で切り分けることです。

焦って復元や再インストールを行うと、状況を悪化させることがあります。
実際に私は以前、IP制限が原因だったにもかかわらず、バックアップを上書き復元してしまいました。

なぜその判断をしたかというと、早く復旧しなければならないという焦りがあったからです。
その結果、最新の投稿データを失いました。何を見落としていたかというと、サーバーログの確認です。

この失敗以降、私は必ずログ確認→設定確認→最小変更の順で対応しています。
感覚ではなく、事実を一つずつ積み上げることが最短ルートです。

焦りは判断を鈍らせますが、順番を守れば必ず原因に近づけます。
私の経験が、同じ状況で困っている方の判断材料になれば幸いです。