WordPressにログインできない時の対処｜原因別の復旧手順

WordPressの管理画面にログインできないときは、むやみに再インストールせず、表示される症状から原因を切り分けます。パスワードエラー、画面の再読み込み、404・403、リダイレクト、真っ白な画面では、直す場所が異なるためです。

本記事は、レンタルサーバーなどへ設置するWordPress.org版を対象に、2026年9月25日時点の公式情報を基に復旧手順を解説します。WordPress.comのアカウント復旧とは手順が異なります。正常にログインできた後の初期設定や投稿方法は、LUFTMEDIAのWordPressの使い方を参照してください。本記事ではログイン障害の診断と復旧だけに範囲を絞ります。

ログイン画面の症状から最初に何を確認する？

最初にサイトのトップページとログインURLを別々に開き、症状を記録します。標準的なログインURLは、ルートに設置したサイトならhttps://example.com/wp-login.phpまたはhttps://example.com/wp-admin/です。サブディレクトリへ設置している場合は、https://example.com/wordpress/wp-login.phpのように設置先を含めます。

2026年9月25日時点の標準画面では、「ユーザー名またはメールアドレス」「パスワード」「ログイン状態を保存する」「ログイン」と「パスワードをお忘れですか？」が表示されます。ただし、セキュリティ系プラグインやレンタルサーバーの機能でログインURLを変更している場合、標準URLが404になることがあります。その場合は、ブックマーク、契約サーバーの「WordPress管理」「サイト管理」などの画面、導入したプラグインの設定記録を確認してください。

症状と優先確認先は次のように分けられます。

• 「ユーザー名またはパスワードが正しくありません」：入力内容かユーザー情報
• ログインを押すと同じ画面へ戻る：Cookie、キャッシュ、URL設定
• 404：ログインURLの変更、設置ディレクトリ、転送設定
• 403またはアクセス拒否：WAF、IP制限、Basic認証、権限設定
• 「重大なエラー」、500、真っ白：プラグイン、テーマ、PHPエラー
• 別ドメインへ飛ぶ、転送が繰り返される：home・siteurl、HTTPS、CDNの転送

スマートフォンだけで判断せず、可能ならPCでも確認します。WindowsとmacOSでWordPress側の復旧方法は同じですが、ファイル名を変更するときは、Windowsのエクスプローラーで拡張子が非表示になっていないか、macOSのFinderで先頭がドットのファイルを見落としていないかに注意します。また、サーバー管理画面へ入れるか、SFTPまたはファイルマネージャーを使えるか、データベース管理画面へ入れるかも確認しておくと、その後の分岐を選べます。

表示文、URL、発生直前の更新内容を先にメモすると、原因を戻す作業が早くなります。

パスワードを忘れた場合はどの順番で再設定する？

ログイン画面が表示され、認証情報だけが通らない場合は、最初に入力ミスを除外します。ユーザー名とパスワードは大文字・小文字が区別されます。日本語入力、Caps Lock、末尾の空白、パスワード管理ソフトに保存された古い情報を確認し、ユーザー名の代わりに登録メールアドレスでも試します。何度も連続入力するとログイン制限が働く構成もあるため、回数を重ねるより再設定へ進みます。

メールで再設定する

1. /wp-login.phpを開き、「パスワードをお忘れですか？」を選択します。
2. ユーザー名または登録メールアドレスを入力し、「新しいパスワードを取得」を選択します。
3. 受信したメールのリンクを開き、新しいパスワードを設定します。
4. ブラウザやパスワード管理ソフトに残る旧パスワードを更新してからログインします。

WordPress公式のパスワード再設定手順でも、通常はログイン画面の再設定リンクが最も簡単な方法として案内されています。メールが来ない場合は、迷惑メール、メールアドレスの入力違い、送信元ドメインの拒否、サーバーのメール送信失敗を確認します。「メールが届かない」こと自体は、ユーザーが存在しない証拠にはなりません。

WP-CLIで再設定する

SSHとWP-CLIを利用できる場合は、WordPress設置ディレクトリへ移動し、まずwp user list --fields=ID,user_login,user_email,rolesで対象を確認します。その後、対話履歴や共有画面にパスワードを残さない運用を前提にwp user update ユーザーID --user_pass='新しい強いパスワード'を実行します。公式のWP-CLI「wp user」コマンド資料にはユーザー一覧、更新、パスワード再設定用サブコマンドが掲載されています。サーバー会社によってSSH・WP-CLIの提供条件や画面名が違うため、2026年9月25日時点の契約プランの公式マニュアルも確認してください。

phpMyAdminを使う場合

メールもSSHも使えない場合は、バックアップ取得後にphpMyAdminで対象データベースを開きます。wp_usersを探し、user_loginとuser_emailから自分の行を特定し、user_passを編集します。接頭辞のwp_は環境ごとに異なります。公式資料にはMD5を指定する復旧方法がありますが、誤った行やデータベースを編集すると別アカウントを変更するため、対象のIDを確認してください。ログイン後は「ユーザー」→「プロフィール」でWordPressが生成する強いパスワードへ更新します。

メールで直せるならデータベースを触らず、使える権限の中で最も小さい操作を選びましょう。

ログイン後に同じ画面へ戻るときCookieをどう直す？

正しい情報を入力してもログイン画面へ戻る場合は、認証Cookieが保存されていないか、異なるURL向けに発行されている可能性があります。WordPressは認証にCookieを使用し、ログイン時には確認用のwordpress_test_cookieも設定します。仕組みはWordPress公式のCookie資料で確認できます。

Chrome、Edge、Firefoxでは、アドレスバー左側のサイト情報から対象ドメインのCookieとサイトデータを削除し、ブラウザを閉じて開き直します。SafariではmacOS版の「Safari」→「設定」→「プライバシー」→「Webサイトデータを管理」、iPhone・iPadでは「設定」→「アプリ」→「Safari」の履歴とWebサイトデータ関連項目を確認します。ブラウザの名称や配置は更新で変わるため、これらは2026年9月25日時点の代表的な順路です。全サイトのデータを消すと他サービスからもログアウトするので、可能なら対象ドメインだけを削除します。

続いてプライベートブラウズまたはシークレットウィンドウで試します。ここでログインできれば、通常ウィンドウのCookie、キャッシュ、拡張機能が原因候補です。広告ブロック、Cookie制御、パスワード入力、VPN・プロキシ系の拡張機能を一時停止し、対象サイトだけで再確認します。別ブラウザや別端末でも同じなら、端末よりWordPress側のURL・プラグイン・サーバー設定を優先します。

「Cookieがブロックされている」と表示される場合は、ブラウザで対象サイトのCookieを許可します。会社や学校の管理端末ではポリシーによって変更できないことがあるため、管理外の端末での確認または管理者への相談が必要です。CDNやキャッシュプラグインを使っている場合は、/wp-admin/と/wp-login.phpをページキャッシュ対象から外します。キャッシュ削除後も、wwwあり・なし、HTTP・HTTPSを混在させず、実際に設定されたURLで試してください。

同じ画面へ戻る症状は、まず対象ドメインのCookie削除とプライベートウィンドウで切り分けます。

404・403でwp-adminを開けない場合はどこを調べる？

404はページが見つからない状態、403は要求が拒否された状態です。ただし、セキュリティ対策がログインページを意図的に404として見せる場合もあるため、ステータスコードだけで断定しません。

404の場合

最初に/wp-admin/ではなく/wp-login.phpを直接開きます。WordPressが/blog/などへ設置されていれば、そのパスを含めます。ログインURL変更プラグインを使っていた場合は設定済みURLを確認し、不明ならSFTPまたはサーバーのファイルマネージャーで通常プラグインを一時停止する手順へ進みます。

トップページは開くがログインURLだけ404になる場合は、Apacheの.htaccess、Nginxのリライトルール、CDNの転送ルールも候補です。変更直前の.htaccessを別名で保管してから、カスタム転送を確認します。単にファイルを消すのではなく、復元できるコピーを残してください。管理画面へ戻れた後は「設定」→「パーマリンク」を開き、現在の構造を変えずに「変更を保存」してリライトルールを再生成できる場合があります。

403の場合

レンタルサーバーの管理画面で、WAF、国外IP制限、WordPressセキュリティ、アクセス制限、Basic認証の履歴を確認します。画面名や解除方法、料金・提供条件は事業者とプランによって異なり、2026年9月25日時点の契約先公式情報で確認が必要です。自分のIPアドレスだけが拒否されているか調べるには、スマートフォンのWi-Fiを切ってモバイル回線から試します。別回線で開けるなら、サーバー側のIP制限、WAF、ネットワーク側フィルターが有力です。

ファイル権限を変更した直後なら、サーバー会社の推奨値と所有者を確認します。環境を問わず一律に広い書き込み権限を付ける方法は避けます。会社ネットワークだけで失敗する場合はプロキシやファイアウォールも候補ですが、防御機能を恒久的に無効化せず、テスト時間と対象IPを限定してください。

404はURLと転送、403はアクセス制御という順で調べ、解除した防御設定は検証後に戻します。

URL変更後のリダイレクトループをどう復旧する？

「設定」→「一般」で「WordPress アドレス（URL）」または「サイトアドレス（URL）」を変更した直後に入れなくなった場合は、データベースのsiteurlとhome、実際の設置場所、SSL・転送設定が一致しているか確認します。前者はWordPress本体がある場所、後者は訪問者がサイトを開く場所です。公式のWordPress移行・サイトURL変更資料では、URLにhttps://を含め、末尾へスラッシュを付けない形が案内されています。

SFTPまたはファイルマネージャーでWordPress直下のwp-config.phpをダウンロードして保管し、/* That's all, stop editing! Happy publishing. */より前へ次のように正しい値を追加すると、管理画面へ戻れる場合があります。

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

WordPress本体が/wordpressにあり、公開URLがルートなら、WP_HOMEとWP_SITEURLが同じとは限りません。推測せず、サーバー上でwp-admin、wp-includes、wp-config.phpが存在する位置を確かめます。上記定数を設定すると「設定」→「一般」のURL欄が編集できなくなるため、恒久設定にするか、データベースを修正して定数を削除するかを決めます。

phpMyAdminを使う場合は、対象データベースのwp_optionsにあるsiteurlとhomeを編集します。テーブル接頭辞はwp_とは限りません。マルチサイトは値が複数テーブルにまたがるため、この単一サイト向け手順をそのまま適用せず、ネットワーク管理者または保守会社へ確認します。

HTTPS化後のループでは、WordPress、Webサーバー、CDNの複数箇所でHTTPからHTTPSへの転送を重ねていないか調べます。ブラウザの開発者ツール「Network」で301・302の遷移先を確認すると、wwwあり・なしやHTTP・HTTPSの往復を特定できます。URL修正前にはWordPressをバックアップする方法に沿って、ファイルとデータベースの両方を保存してください。

URL設定は実際の設置場所を確認してから直し、マルチサイトでは単一サイト用の変更を流用しないでください。

プラグインが原因で管理画面に入れないときどう停止する？

更新や設定変更の直後に500エラー、重大なエラー、リダイレクト、ログイン制限が発生した場合は、プラグインを疑います。管理画面へ入れない状態でも、ファイル側から通常プラグインをまとめて停止できます。作業前にwp-contentとデータベースをバックアップし、変更前後の名前を記録します。

1. SFTPまたはサーバーのファイルマネージャーでWordPress設置先を開きます。
2. wp-content/pluginsをplugins.holdへ変更します。
3. /wp-admin/plugins.phpまたはログイン画面を開きます。
4. 入れるようになったら、フォルダー名をpluginsへ戻します。
5. 「プラグイン」→「インストール済みプラグイン」で一つずつ有効化し、各回でログアウトと再ログインを確認します。

この方法はプラグインの設定データを直ちに削除するものではありません。WordPress公式のFAQ Troubleshootingでも、管理画面へ入れない場合にpluginsフォルダーを改名する方法が案内されています。原因が特定できたら、そのプラグインだけのフォルダー名を変更して停止し、開発元の公式更新履歴、対応WordPress・PHPバージョン、復旧手順を確認します。

wp-content/mu-pluginsに置かれるMust-Useプラグインは、通常の「プラグイン」一覧から停止できず、pluginsフォルダーの改名でも停止しません。レンタルサーバーが管理機能として配置している場合もあるため、内容が不明なら削除せずサーバー会社へ確認します。また、ログイン回数制限や二要素認証のプラグインでは、単なるパスワード再設定では解除できない場合があります。リカバリーコード、登録済み認証器、管理者による解除という製品固有の順番に従います。

復旧後に別テーマへ乗り換える場合の比較はWordPressテーマおすすめ比較へ分けています。本記事の目的はテーマ選定ではなく、ログイン障害を起こした拡張機能を特定して元の管理権限を回復することです。

全停止で直ったら一括で戻さず、一つずつ有効化して再発するプラグインを特定します。

重大なエラーや真っ白な画面からどう復旧する？

「サイトに重大なエラーがありました」と表示される場合は、まず管理者メールアドレスに届く「サイトで技術的な問題が発生しています」という通知を探します。WordPressには、致命的なPHPエラーを検出したときに専用リンクから限定的にログインできるリカバリーモードがあります。WordPress公式のRecovery Mode資料によると、この機能は原因となったプラグインやテーマを一時停止して修正するためのものです。

メール内のリンクから入れたら、リカバリーモードの通知に示された拡張機能を確認し、「プラグイン」または「外観」→「テーマ」で停止・更新します。リンクには期限があるため、無効なら新しい障害通知を確認します。メールが届かず、直前にプラグインを更新したなら前節のフォルダー改名を試します。テーマ更新直後ならwp-content/themes/対象テーマの名前を変更しますが、利用可能な標準テーマがサーバーにないと切り替えられないため、先にテーマ一覧を確認してください。

debug.logで原因を確認する

原因が表示されない場合は、バックアップ後にwp-config.phpへ次を設定します。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

記述位置は終了コメントより前です。再度ログイン画面を開き、wp-content/debug.logの末尾に出るファイルパス、プラグイン名、テーマ名、PHPエラーを確認します。WordPress公式のデバッグ資料は、本番画面へエラーを表示しない構成と、調査後にデバッグを無効化する必要性を説明しています。ログにはサーバーパスなどが含まれ得るため、公開領域へ放置せず、調査後はWP_DEBUGをfalseへ戻してログを適切に保管または削除します。

PHPのバージョンを変更した直後なら、サーバー管理画面で元のバージョンへ戻して挙動を確認します。ただし、古いPHPを恒久利用する判断はせず、原因となるテーマやプラグインを対応版へ更新します。料金、利用可能なPHP、切り替え画面名はサーバー会社とプランで異なるため、2026年9月25日時点の公式仕様を確認してください。

画面を復活させるだけで終わらず、debug.logの原因ファイルを特定してからデバッグ設定を解除します。

復旧後に再発と不正ログインをどう確認する？

ログインできたら、最初に「ユーザー」→「プロフィール」で自分のメールアドレスと権限を確認し、必要なら強い固有パスワードへ変更します。次に「ユーザー」→「ユーザー一覧」で、覚えのない管理者、メールアドレス変更、不要なアカウントがないか調べます。ただし、正体不明の管理者を見つけても、投稿の所有者や外部サービス連携を確認せず即削除すると運用に影響するため、作成日時や関係者を確認します。

「ツール」→「サイトヘルス」では、重大な問題、推奨される改善、サーバー情報を確認できます。2026年9月25日時点でも、表示項目はWordPress本体、サーバー、プラグイン構成によって異なります。プラグインとテーマは公式配布元または正規購入元の対応版へ更新し、使用していないものはバックアップ後に整理します。コアファイルを非公式サイトから上書きしないでください。

ログイン障害が不正アクセスと関係する疑いがある場合は、WordPressだけでなく、レンタルサーバー、SFTP・SSH、データベース、管理用メール、DNS・CDNの認証情報も見直します。アクセスログでwp-login.phpへの大量試行、未知のIP、身に覚えのないファイル変更を確認し、保守会社またはサーバー会社へ調査を依頼します。二要素認証を導入するときは、管理者全員の登録、リカバリーコードのオフライン保管、端末紛失時の解除担当まで決めます。

最後に、復旧時に変更したフォルダー名、WAF、IP制限、キャッシュ除外、デバッグ定数を点検します。正常系の確認は、ログアウト後の再ログイン、別ブラウザ、PCとスマートフォン、トップページ、投稿編集画面の順で行います。バックアップから戻す必要がある場合は、障害発生前の世代を選び、現在の注文・問い合わせ・投稿が巻き戻らないか確認してから実施します。

参照した公式情報

• WordPress.org「Troubleshoot login issues」
• WordPress.org「Reset your password」
• WordPress Developer Resources「Cookies」
• WordPress Developer Resources「Migrating WordPress」
• WordPress Developer Resources「FAQ Troubleshooting」
• WordPress.org「Recovery Mode」
• WordPress Developer Resources「Debugging in WordPress」
• WordPress Developer Resources「wp user」

復旧後は認証情報、管理者一覧、バックアップ、停止した防御設定まで確認して作業を完了しましょう。