WordPress安心診断 by MozCheck

【2025年版】WordPressにログインできないときの完全ガイド｜原因別エラー対処と最短復旧フローチャート

Written by

Yudai Tsuyuzaki

in

WordPressの管理画面に入れなくなると、更新や修正が止まり、広告や受注にも影響します。焦る気持ちを抑えて、最短で復旧する道筋をたどりましょう。

本ガイドは「とりあえず全部試す」ではなく、症状→原因→対処の順に迷いを減らすための最短復旧フローチャートと、深掘りの手順をセットで提示します。

ホスティングやテーマに依存しない 環境非依存のやり方（FTP/SFTP・ファイルマネージャ・WP-CLI） を採用し、初心者から運用担当者まで同じ地図で解決できます。

本ガイドではまず「いま直せる最短手当て」を提示し、ダメなら一段深い切り分けに進みます。

作業の各段階では「戻せる」ことが安全の鍵です。変更前の状態を把握し、ファイルやDBに触る際は必ずバックアップを確保してから取り掛かってください。

目次

はじめに：ログイン障害の原因を一望できる「症状 × 主な原因」早見表

WordPressにログインできない理由は、URLの取り違えからサーバー設定、プラグイン衝突まで幅広く、最初の切り分けで迷いがちです。

そこで本セクションでは、よくある症状と主な原因だけを2列でまとめた早見表を最初に掲載しています。
トラブルシューティングを始める前に、まずは下の表で自分の症状がどの原因に当てはまるかをサッと確認してください。

症状 / エラー主な原因
404 / ログインURLが見つからないログインURLの取り違え、サブディレクトリ／サブドメイン誤認、セキュリティ系プラグイン等によるログインURL変更
403 ForbiddenWAFやIP制限、Basic認証、ファイル／ディレクトリのパーミッション不正
500 Internal Server ErrorPHP致命的エラー、バージョン不整合、メモリ不足
データベース接続確立エラーDB資格情報（DB_NAME／USER／PASSWORD／HOST）の不一致、DB停止や高負荷、接続先ホスト名の相違
無限リダイレクト／https化後に入れないsiteurl と home の不一致、.htaccess やリダイレクト設定の二重化
正しいはずのパスワードで弾かれる／同じ画面に戻るCookie・キャッシュ衝突、ブラウザ拡張の干渉
プラグイン衝突が疑わしい更新直後の不整合、複数プラグインの競合
テーマ起因が疑わしいfunctions.php によるリダイレクト、古いテンプレートの不整合
ユーザー自体の問題ユーザー削除・欠落、権限不備、パスワード再発行不可
wp-login.php が破損コアファイルの欠損・破損
パスワードリセットメールが届かないSMTP未設定、SPF／DKIM／DMARC不備、送信制限
  • 左列の「症状 / エラー」を探す
  • 右列の「主な原因」を確認して当たりをつける
  • 詳細の解説や検証ポイントは本文で順に確認

※ この早見表は「原因の切り分け」に特化しています。対処手順は本文の該当箇所でご案内します。

最短5分で復旧：症状から始めるフローチャート

まず確認：正しいURL・サブディレクトリ・/wp-login.php（/wp-adminも試す）

ログイン不能の多くは入口の取り違えです。

まずは運用中のURL構造を思い出し、トップ直下なのか／サブディレクトリ設置なのかを確認します。

  • 例1：https://example.com/wp-login.php
    （または https://example.com/wp-admin）
  • 例2：https://example.com/blog/wp-login.php
    （サブディレクトリ設置）
  • 例3：https://sub.example.com/wp-login.php
    （サブドメイン）

URL入力時はwww あり/なしやhttp/httpsの混在でも弾かれます。

ブックマークに頼らずアドレス欄から手入力し、/wp-admin も併せて試しましょう。

セキュリティ系プラグインでログインURLを変更している場合は、制作・運用メモや引き継ぎ資料を確認します（覚えがなければ後述のプラグイン一時停止で戻せます）。

ブラウザ側の即効策：Cookie/キャッシュ削除・別ブラウザ/シークレットで再試行

正しいURLでも弾かれるなら、Cookie とキャッシュを疑います。

  • 現在のブラウザで「このサイトのみ」キャッシュとCookieを削除
  • シークレットウィンドウで同URLへアクセス
  • 別ブラウザ（Chrome/Firefox/Edge/Safariなど）で再試行
  • 広告ブロッカーやパスワード管理拡張を一時無効化

特にhttps 化直後やドメイン切替直後は旧Cookieが残り衝突します。

ログインフォームが送信されても同じ画面に戻る／無限ループはCookie要因の典型。ここで解消しなければ、アプリ側（プラグイン・テーマ）へ切り分けます。

これでもダメなら：一時的に全プラグイン停止→デフォルトテーマへ（方法は後述）

アプリ要因の切り分けは衝突を除去する順番がポイント。

  1. プラグインを全停止：wp-content/plugins を plugins._off に一時リネーム（FTP/ファイルマネージャでOK）。これで入れればプラグイン起因。
  2. テーマの切替：ログイン不可が続く場合は、現在のテーマフォルダを一時リネームしてTwenty Twenty-Five等のデフォルトにフォールバックさせます。
  3. どちらでも改善しなければ、URL整合（siteurl/home）や .htaccess を疑い、次章へ。

上記はいつでも元に戻せる操作です。

手を付ける前に作業メモを残し、改善したら犯人特定のために段階的に戻す前提で進めましょう。

症状別に直す：エラー画面・挙動で分岐

404 Not Found：URLの取り違え・配置ミス・ログインURL変更の可能性

/wp-login.php や /wp-admin が404なら、まずURLの整合を疑います。

サブディレクトリ設置（/blog/ 等）やサブドメイン運用、www あり/なしの差、http/https の混在があると404が出ます。制作時にセキュリティ系プラグインでログインURLを変更していれば、/login や /signin などに書き換わっていることも。

運用メモが無ければ、プラグインを一時停止すれば元の wp-login.php に戻せます。

ファイル配置が原因の場合、誤って上位ディレクトリへ移動・削除したケースもあるため、SFTP/ファイルマネージャでWordPressコアの構成（wp-admin/ wp-includes/ wp-content/ 直下に wp-login.php がある）を点検し、欠損時は同一バージョンのコアファイルを再配置。

Nginx/Apache のリライトが壊れている場合は、/.htaccess を一時リネーム→固定リンク再設定で再生成します（ログイン不可なら後述のURL整合修復を先に）。

403 Forbidden：WAF・アクセス制限・権限/パーミッションの問題

403 はアクセスが拒否されている状態。

代表的なものには
（1）WAF/セキュリティ機能がログイン試行を攻撃と誤検知、
（2）Basic認証やIP制限の存在、
（3）ファイル/ディレクトリ権限の異常（例：wp-login.phpが600で実行不可）。

対処は次の順で進めます。

  • 別回線/別IPで試し、WAFのIPブロックを切り分け。サーバーパネルのWAFログやアクセス解析でブロック有無を確認。
  • .htaccess に Deny from all 等がないか、ベーシック認証 .htpasswd の設定漏れ/誤りを点検。
  • wp-content 配下のセキュリティ系プラグインを一時停止（フォルダリネーム）し、誤検知が解けるか確認。
  • パーミッションは、ファイル 644、ディレクトリ 755 が目安（環境により異なる）。一括変更の前に、対象を限定して試すのが安全です。

500 Internal Server Error：PHP致命的エラー・メモリ不足・バージョン不整合

500 はアプリ側の致命的エラー。更新直後に増えやすく、プラグイン/テーマのコードやPHPバージョン不整合、メモリ不足が典型です。

  • wp-config.php に define('WP_DEBUG', true); を暫定追加し、error_log を確認（本番では復旧後に戻す）。
  • 全プラグイン停止→デフォルトテーマへの順に衝突を除去。改善したら犯人特定のため一つずつ戻す。
  • PHPバージョンを直前の安定版へ戻す/上げる（ホスティングの切替画面から）。拡張モジュールの不足（intl, mbstring 等）にも注意。
  • メモリ不足の疑いがあれば define('WP_MEMORY_LIMIT', '256M'); を一時設定（許容上限は契約プランに依存）。
  • コアファイル破損時は同一メジャーの公式パッケージで再配置（wp-content と wp-config.php は上書きしない）。

データベース接続確立エラー：資格情報・DB稼働・修復の確認

「データベース接続確立エラー」はDBに繋がらない状態。

  • wp-config.php の DB_NAME/DB_USER/DB_PASSWORD/DB_HOST を確認。最近の移行やパスワード変更の影響を疑います。
  • ホスティングのDB管理画面で接続先ホスト名（localhost 固定でない場合あり）とユーザー権限を点検。
  • サーバー側のリソース逼迫（プロセス上限、ストレージ満杯）やメンテナンスを確認。
  • 破損の可能性があるときは define('WP_ALLOW_REPAIR', true); を追加して /wp-admin/maint/repair.php を実行（復旧後は必ず無効化）。
  • WP-CLI が使えれば wp db check / wp db repair で迅速に検査・修復。

無限リダイレクト／https化後に入れない：siteurl/home と .htaccess を整合

ログイン後に同画面へ戻る、/wp-login.php から行ったり来たりする、http→https でぐるぐる回る——これらはURL整合性の崩れが濃厚です。

  • siteurl と home が一致しているか（https か／www あり/なしが揃っているか）をDBで点検。ダッシュボードに入れない場合は phpMyAdmin で wp_options を直接修正。
  • .htaccess のリダイレクト記述（常時SSL化・www統一・セキュリティ対策）が二重適用になっていないか。一時リネームでループが止まるか検証。
  • キャッシュ/リバースプロキシ/CDN（Cloudflare等）を利用中なら一時バイパスして origin 直で確認。
  • セキュリティ系プラグインの「管理画面を常時SSL」強制と、サーバー側のリダイレクト設定がぶつかることもあるため、どちらか一方を一時停止して切り分けます。

いずれの症状でも、「まずは再現条件を最小化→一手ずつ戻せる形で変更→改善したら段階的に復元」の原則を守ると、短時間で原因点に到達しやすくなります。

原因別に直す：ブラウザ / URL / サーバ / プラグイン・テーマ

ブラウザ・Cookie：ログインCookieの受け入れとキャッシュの衝突を解消

WordPressはログイン時にファーストパーティCookieを発行し、これが拒否・上書き・期限切れだと正しい資格情報でも弾かれます。

まずは対象サイトのみのCookieとキャッシュを削除し、シークレットウィンドウや別ブラウザで再試行します。

パスワードマネージャや広告ブロッカー、トラッキング防止機能がフォーム送信やCookie保存を妨げることがあるため、拡張機能を一時停止して切り分けるのが早道です。

プロキシ・VPNを常用している場合は自宅回線へ切り替え、IPv6/IPv4や企業プロキシの影響を排除します。

ブラウザ側で改善しない場合でも、ここで得た「何を無効にしたら動いたか」は後工程のヒントになります。たとえば、拡張機能停止で入れるならスクリプト注入・トラッキング防止が原因候補、別ブラウザで入れるならプロファイル破損やキャッシュの取りこぼしが疑わしい。

モバイル端末からのログインでも再現しないかを確かめると、端末依存かサーバ依存かの切り分けが進みます。

URL/配置：siteurl/home の不一致、設置場所や .htaccess の齟齬を正す

ログイン不可の定番は、WordPressアドレス（siteurl）とサイトアドレス（home）の不一致です。

https 化や www 有無の統一を途中で変えた、サブディレクトリ設置に切り替えた、移行でドメインを替えた――こうした変更で無限リダイレクトやフォームに戻る症状が起きます。

ダッシュボードに入れない場合は、phpMyAdmin などで wp_options を開き、siteurl と home を同じスキーム・同じホスト名に修正します。

あわせて .htaccess の常時SSL化やリダイレクト記述が二重化していないか確認し、一時リネームで挙動が落ち着くか検証しましょう。

配置ミスも意外と多い原因です。

wp-login.php がルート直下に存在するか、wp-admin/ wp-includes/ の位置が正しいか、上位階層へ誤移動していないかをSFTPで点検します。

サブディレクトリ設置（例：/blog）なのに /wp-admin へアクセスしている、逆にルート設置なのにサブディレクトリを付けているといった単純ミスも404の典型。

修正後はブラウザキャッシュを消して改めてログインURLを手打ちしましょう。

プラグイン衝突：一括停止→段階的再有効化で“犯人”を最短特定

フォーム送信後に弾かれる、403が出たりCAPTCHAが常に失敗する、ログインURLが別パスに書き換わる……これらはセキュリティ系・キャッシュ系・リダイレクト系プラグインが原因であることが多く、最短の切り分けは全停止です。

SFTP/ファイルマネージャで wp-content/plugins を plugins._off 等に一時リネームし、ログインを試します。

入れるようになったらフォルダ名を元に戻し、半分ずつ有効化（バイナリサーチ）で範囲を絞ると短時間で特定できます。

特に怪しいのは、ログインURL変更・WAF連携・Bot対策・ページキャッシュを行うプラグイン群。CDNやリバースプロキシと組み合わせると、管理画面だけキャッシュしてしまう設定事故も起きがちです。

犯人を特定したら、最新版に更新、設定を見直し、問題が再発するなら同系統の代替プラグインへ切り替える判断も視野に入れましょう。

テーマ起因：functions.php のリダイレクト・フック・古いテンプレの不整合

テーマの functions.php によるlogin_redirect/template_redirect フックや、独自のメンテナンスモードがログインを妨げるケースがあります。

切り分けはシンプルで、現在のテーマフォルダを一時リネーム（例：mytheme._off）してTwenty Twenty-Five等のデフォルトテーマにフォールバックさせます。

改善したら、子テーマ→親テーマの順に戻し、functions.php の最近の追記（会員制プラグイン連携、特定URLへの強制遷移、Cookie チェック等）を中心に差分を確認します。

古いテーマほどPHPバージョンやブロックエディタ対応の齟齬が起きやすく、ログイン直後のダッシュボード描画で500が出て“入れたようで入れない”状態になることも。

アップデートで直る場合が多い一方、商用テーマでは子テーマのカスタマイズが追従できずカスタムフックがエラーになることもあるため、ステージング環境での検証→本番反映を徹底しましょう。

URLとHTTPSの整合性を修復（ダッシュボードに入れない場合）

phpMyAdminで wp_options の siteurl/home を正す（www/httpsの統一）

ダッシュボードに入れないときの定石は、DBからURLを直接修正する方法です。

phpMyAdmin で該当サイトのDBを開き、wp_options テーブル（接頭辞が異なる場合あり）を表示します。option_name が siteurl と home のレコードを探し、同一のスキーム（http/https）・同一のホスト（www有無）に統一して保存します。

誤った値にすると再ログインできなくなるため、現在表示できるフロントURLを基準に合わせるのが安全です。

緊急回避として wp-config.php に

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

の一時追記で上書きする方法もあります（復旧後はコメントアウトしてダッシュボード側の設定管理に戻すのが基本）。

ドメイン変更・パス変更を伴う移行では、検索置換（シリアライズ対応）が必要になるため、WP-CLI の wp search-replace や実績あるプラグインで配列・オブジェクト内のURLも含めて一括変換しましょう。

.htaccess / リダイレクト設定の一時停止でループを断つ（検証→元戻し）

URLを正してもループが収まらない場合、.htaccess の記述やホスティング側の常時SSL/ドメイン統一設定が二重適用になっている恐れがあります。

/.htaccess を .htaccess._off に一時リネームし、ログインを再試行して挙動を比較します。

WordPress既定の書式は以下のような最小構成です（復旧後に固定リンク設定を保存すると再生成されます）。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

CDN/リバースプロキシを併用中なら、オリジン直での動作確認（CDN無効化またはバイパス）が有効です。

サーバーパネルの「アクセスリダイレクト」「セキュリティ設定」で似た設定が有効化されていないかも併せて点検し、片側のみに寄せてシンプルに保つと安定します。

サーバーパネル/FTPでできること（環境依存しない説明）

ファイルマネージャ or SFTPでの操作：plugins/themesの無効化、wp-login.phpの再配置

コントロールパネルのファイルマネージャまたは SFTP で直接ファイルに触れられるなら、ログイン復旧は一気に進みます。まずは戻せる単位での変更が原則。

  • 全プラグイン停止：wp-content/plugins を plugins._off に一時リネーム。ログインできたら、元名に戻し、半分ずつ再有効化（バイナリサーチ）で問題プラグインを特定。
  • テーマのフォールバック：wp-content/themes/現在のテーマ を一時リネームし、Twenty Twenty-Five などのデフォルトテーマに自動切替。入れたら functions.php のリダイレクト系フックや最近の編集差分を要確認。
  • wp-login.php の再配置：誤削除・破損時は、同一メジャーのWordPress公式パッケージから wp-login.php を上書き（バージョンを合わせる）。wp-admin/ wp-includes/ の構成も崩れていないか確認。
  • パーミッション：原則ファイル 644・ディレクトリ 755。ログインスクリプトが 600/700 などで実行不可になっていないか、所有者と合わせて点検。
  • .htaccess の一時停止：.htaccess を .htaccess._off にリネームして挙動比較。ループが止まるなら、常時SSL化やwww統一の二重リダイレクトが疑わしい。

作業前にフルバックアップ（少なくとも wp-content とDB）を取得し、変更点をメモ化。

改善後は段階的に元へ戻し、原因をピンポイントで押さえます。

エラーログの見方とサポート依頼テンプレ（必須情報）

500系や白画面はログに真相が残ります。

サーバーパネルに「エラーログ」ビューアがあればそこを確認、無ければサイト直下や wp-content/ にある error_log を探します。必要に応じて wp-config.php に以下を一時追加。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);   // wp-content/debug.log に出力
define('WP_DEBUG_DISPLAY', false);

再現後に wp-content/debug.log を開いて、日時・ファイルパス・エラーレベルを抽出。

サポートへ問い合わせる場合は、次のテンプレで情報を整理すると早く解決します。

  • 事象：ログインできない（症状：404/403/500/白画面/ループ など）
  • 発生日と作業履歴：直前の更新・移行・https化の有無
  • 切り分け状況：プラグイン全停止／テーマ切替／.htaccess 一時停止の結果
  • ログ抜粋：直近5–10行（フルは共有リンクで）
  • 望む状態：ログイン復旧が最優先、恒久対策は別途相談

調査後は WP_DEBUG を必ず false に戻し、ログファイルに機密情報が残っていないかも確認します。

WP-CLIが使えるなら最速（推奨）

全プラグイン停止：wp plugin deactivate --all と除外つき停止

SSH が使えるなら WP-CLI が最短ルートです。

まずは衝突を一掃。

# 全プラグイン停止
wp plugin deactivate --all

# 特定を除外して停止（例：ログインに必須のSMTPだけ残す）
wp plugin deactivate --all --exclude=wp-mail-smtp

# ページキャッシュやオブジェクトキャッシュを削除
wp cache flush

これで入れれば、一括停止 → 1つずつ再有効化（または半分ずつ）で犯人を特定します。

CLI は環境依存のパネル操作を回避でき、記録も取りやすいのが利点です。

ユーザーPW再発行：wp user update／管理者の緊急作成

パスワードリセットが詰まる場合は、CLIで即変更。

# 既存ユーザーのパスワードを対話で更新
wp user update admin --prompt=user_pass

# ユーザーIDが不明なら一覧
wp user list

# 管理者が消えている/ロック時は一時管理者を作成
wp user create rescue your@example.com --role=administrator --user_pass='強固な一時PW'

ログイン後は一時管理者を削除し、2FA を有効に。メールが出ない環境でも CLI なら復旧できます。

代表的な補助コマンド：--skip-plugins/--skip-themes・DB検査・検索置換

復旧中は、コマンド単位でプラグインやテーマを無効にできます。

# プラグイン・テーマを読み込まずにコマンド実行
wp option get home --skip-plugins --skip-themes

# DBチェックと修復
wp db check
wp db repair

# URL整合の一括修正（シリアライズ対応）
wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise --dry-run

--dry-run で影響を確認し、問題がなければ本実行へ。可逆性を重視して一手ずつ進めます。

それでも入れない時の「最後の手段」

wp_users を直接確認：アカウント存在・権限・緊急パスワード

phpMyAdmin で wp_users と wp_usermeta を開き、対象ユーザーの存在・メールアドレス・wp_capabilities（管理者なら administrator:1）を確認。

どうしてもPW変更が必要なら、user_pass を一時的に MD5 で更新してログイン（WordPressがログイン後に強固なハッシュへ再変換）。

ただし誤操作リスクが高いため、可能なら WP-CLI での更新を優先。アカウントが見当たらないなら、緊急の管理者を作成し、復旧後に最小権限へ整理します。

wp-login.php 破損時の置き換え／コア再配置（wp core download --force）

wp-login.php やコアファイル破損が疑われる場合、同一メジャーのパッケージで再配置します。

CLI が使えるなら、wp core download --force --skip-content でコアのみ上書き（wp-content と wp-config.php は保持）。SFTP でも同様に、該当ファイルを公式パッケージから上書き。

終わったらファイル整合とパーミッションを再点検し、固定リンク保存で .htaccess を再生成します。

相談・エスカレーションの要点：記録を添える

ホスティング／制作会社／公式フォーラムに相談する際は、再現手順・ログ抜粋・試した施策をセットで。

  • 影響範囲：管理画面のみか、フロントも巻き込むか
  • 発生日時と直前の変更：更新・移行・証明書の入替など
  • 切り分け表：プラグイン全停止／テーマ切替／URL整合／.htaccess 無効の結果
  • エラーログ抜粋：5–10行（時刻・ファイル・メッセージ）

再開目標（復旧の優先度）を明記すると、対応が最短化します。

予防策：再発させない設定と運用

二段階認証・ログイン試行制限・安全な運用フロー

ログイン周りは守りと回避経路の両立が重要です。

  • 2FA（TOTP）を管理者全員に必須化し、回復コードを安全保管。
  • ログイン試行制限やreCAPTCHAで総当たりを抑制（ただし管理者が自分でロックしない運用に）。
  • アプリケーションパスワードを活用し、外部連携で通常パスワードを使わない。
  • いざという時のために、WP-CLI／SFTP／DBアクセスの代替ルートを常に用意し、権限と手順をドキュメント化。

URL変更/https化の定石（検証→本番、リダイレクトは1系統に）

本番でのURL変更・https化はステージングでリハーサル→本番反映が鉄則。

変更時は

  1. siteurl/home を一致、
  2. .htaccess の常時SSL・www統一を片側のみに寄せる、
  3. wp search-replace で埋め込みURLを一括変換、
  4. CDN/キャッシュを一時停止して検証、
  5. 問題なければHSTS等の強制を段階導入。

設定の二重化が最も事故を生むため、どこで何を強制しているかを1枚の図で管理しましょう。

更新前のスナップショット＋ステージング：安全なアップデート習慣

プラグイン/テーマ/コアの更新前に

  • ファイル＋DBのスナップショットを取得（復元テストも年数回は実施）、
  • ステージングで更新→主要導線の動作確認→本番反映、
  • 本番反映後もログ監視＆アクセス監視を強化。

プラグインは役割が重複するものを整理し、更新停止の古いプラグインは代替へ移行。

更新後は変更履歴を残し、万一のロールバックの意思決定を速めます。

よくある質問（FAQ）

Q.「パスワードリセットメールが届かない」時の代替手順は？

迷惑メール・受信拒否・ドメイン認証（SPF/DKIM/DMARC）不備が典型です。

まずは別メールアドレスで試し、届かない場合は WP-CLIでパスワード更新→ログイン後にSMTPプラグインを適切に設定して送信テスト。

ホスティングのメール送信制限や、短時間に多数の試行で一時ブロックされることもあるため、インターバルを置き、ログにSMTP/PHPMailerのエラーが出ていないかを確認します。

Q.セキュリティプラグインでログインURLを変えた覚えがない…

制作時の設定や「推奨設定を一括適用」で自動変更されていることがあります。

思い当たらなければ、SFTPで該当プラグインのフォルダを一時リネームして無効化（例：wps-hide-login、rename-login 等）。

これで wp-login.php に戻れるかを確認。.htaccess に独自リライトルールが書き込まれている場合もあるため、一時無効で挙動を比較すると原因に近づけます。

Q.共有PCで“勝手にログアウト/再ログイン不可”が起きる

Cookie の有効期限・スコープや、キャッシュ系プラグインが管理画面を誤キャッシュしている可能性があります。

管理画面のキャッシュを明示的に除外し、home/siteurl とCookie ドメインの不一致を解消。セキュリティプラグインのセッション固定・同時ログイン制限が効いている場合もあるため、一時オフで比較。

共有PCではシークレットウィンドウ運用と自動保存パスワードの無効化も有効です。

参考・参照リンク

まとめ

WordPressにログインできないときは、やみくもに設定を触るのではなく、症状→原因→対処の順に“戻せる範囲で一手ずつ”進めるのが最短復旧への近道です。

本記事では、

  1. まず正しいURLとブラウザ側の衝突（Cookie/キャッシュ/拡張機能）を除去し、
  2. 改善しなければプラグイン全停止→デフォルトテーマというセオリーでアプリ要因を切り分け、
  3. 最終的にURL整合（siteurl/home）と .htaccess を正してリダイレクトや白画面を解消するフロー

を示しました。

SSHが使える環境では WP-CLI を用いれば、プラグイン停止・ユーザーPW再発行・DBチェック・URL一括置換までを短時間で実施できます。

要点を再確認しておきましょう。

  • 正しい入口（/wp-login.php／/wp-admin、http/https、www有無、設置場所）を確認する。
  • ブラウザのCookie/キャッシュや拡張機能を一時無効化し、別ブラウザ・シークレットで再試行。
  • 直らなければ plugins をリネームして全停止→入れたら段階的再有効化で“犯人”特定。
  • テーマも一時退避し、デフォルトテーマへフォールバックして functions.php の影響を切る。
  • ダッシュボードに入れない場合は DBで siteurl/home を一致させ、.htaccess の二重リダイレクトを排除。
  • WP-CLI があれば wp plugin deactivate --all、wp user update、wp db check/repair、wp search-replace を活用。
  • なおらない時は wp_users の権限/存在確認やコア再配置で破損を疑い、ログを添えて支援にエスカレーション。

復旧後は再発防止が本番です。

2FAの全管理者適用、ログイン試行制限、更新前スナップショット＋ステージング、そしてURL/SSL統一の一本化で“二重設定の地雷”をなくしましょう。

SFTP・WP-CLI・DBの“代替ルート”をいつでも使えるようにしておけば、万一のログイン障害でも短時間で業務を再開できます。

今回のフローを自社手順に落とし込み、チェックリスト化しておくことが、次のトラブル時の最大の保険になります。

関連記事

  1. 初心者向け！WordPressのバックアップと復元の基本ステップと注意点
  2. あれ、サイトの見た目が変…？WordPressの「表示が崩れた！」ときの原因と対処法
  3. WordPressが突然真っ白に…よくある原因とすぐできる対処法

投稿者

Yudai Tsuyuzaki

フリーランスのWeb系プログラマー。 長野県の北アルプス地方在住

🛠️ WordPressのトラブルでお困りですか？

ログインが出来ない・白画面・更新崩れなどの緊急トラブルは、
「WordPress保守サービス」で即対応いたします。

今すぐ依頼する（ランサーズページへ）

🧰 WordPress無料診断

サイト改善の第一歩をお届け

当サイト「MozCheck」は、WordPressサイトの不安をチェックできる無料診断サービスです。
URLを入力するだけ。登録不要、すぐに診断結果が表示されます。

無料で診断する

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA


More posts