WordPressにログインできないときの対処|症状別の確認と安全な復旧
※本記事にはPRを含む場合があります。
こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。
WordPressにログインできなくなると、記事が消えたのではないかと焦るかもしれません。しかし、ログイン画面が開かない、入力が拒否される、入力後に同じ画面へ戻る、サイト全体でエラーが出るという状態では、確認する順番が違います。最初からパスワード変更やプラグイン停止を繰り返すより、症状を分けることが復旧への近道です。
本記事は、自分が管理するサイト、または管理を正式に任されたサイトへ戻るための確認ガイドです。安全に読める情報と通常の再設定手順から進み、ファイルやデータベースの変更が必要な場面は管理担当・サーバー会社へ相談する境界も示します。例文とケースは架空の説明例、図版は説明用の生成イメージです。個別サイトの復旧を実演した記事ではありません。
WordPressにログインできない症状を、入口・認証・環境に分ける

ログイン画面が開く前か、入力した後かを確認する
最初に、どこで止まっているかを書き出します。アドレスを開いた瞬間に404になるのか、ログインフォームは出るが入力を受け付けないのか、認証後に画面が戻るのかを区別してください。同じ「入れない」でも、入口の問題と認証の問題では次の行動が変わります。
ログインフォームが見えない段階なら、パスワードを変えても改善しない可能性があります。反対にフォームが表示され、パスワードに関する明確な案内が出ているなら、URLやサーバーを何度も変更するより、入力内容と通常の再設定を確認する方が適切です。
エラーが出たときは、文字列を正確に控えます。「何か英語が出た」ではなく、表示された番号や見出し、発生した時刻を記録しましょう。画面を保存する場合は、メールアドレス、認証コード、復旧用リンクなどが写り込んでいないかを確認してから共有します。
公開ページが見えるかどうかも別に確かめる
管理画面へ入れなくても、読者向けのページが通常どおり見える場合があります。この場合、記事や画像が消えたと直ちに判断する必要はありません。自分のサイトのトップと代表記事を一つずつ開き、公開側の状態を確認します。
公開側も真っ白、重大なエラー、接続不能になっているなら、認証だけでなくサイトやサーバー側の問題を考えます。表示できるページとできないページがある場合は、その違いも記録してください。どの範囲に影響しているかが分かれば、相談先が優先して調べる場所を絞りやすくなります。
公開ページが見えるから完全に正常、と断定することも避けます。キャッシュされたページだけが表示されている可能性や、一部機能だけが止まっている可能性もあります。ここでの確認は原因を確定する試験ではなく、影響範囲を把握するための最初の整理です。
※表は横にスクロールできます。
| 止まる場所 | 見える状態の例 | まず確認すること | 急いで変えないこと |
|---|---|---|---|
| 入口の前 | 404・接続不能 | 正しいURL、設置先、公開側 | WordPressの再インストール |
| 入力後の認証 | 入力情報への警告 | 入力状態と通常の再設定 | 連続した試行 |
| 入力後の遷移 | 同じ画面へ戻る | Cookie、URL、直前の変更 | 複数の転送設定 |
| アクセス拒否 | 403・制限の案内 | ホストの制限と契約状態 | 保護機能の全面停止 |
| サイト側の障害 | 白画面・重大なエラー | 管理者通知、更新履歴 | データを確認しない復元 |
直前の変更と、最後に正常だった時点を残す
「昨日は入れた」より、「昨夜の記事保存までは正常で、今朝プラグイン更新の通知後に入れなくなった」の方が、調査の手がかりになります。更新、移行、SSL設定、ログインURL変更、パスワード変更、端末変更など、心当たりを時系列で並べます。
ただし、直前に行ったことが必ず原因とは限りません。「更新したから壊れた」と断定せず、「更新後に初めて気づいた」と事実で書きましょう。自動更新があるサイトでは、自分が操作していなくても変更が入っている場合があります。通知や管理記録が読めるなら確認します。
分からない項目は「不明」と残して構いません。記憶を埋めるために推測を事実のように書くより、最後に確認した正常状態と、現在の表示を分ける方が役立ちます。複数人で管理しているなら、同じ時間帯に誰かが設定を変えていないかも連絡して確かめます。
復旧を急いでも、最初に止めてよい操作を決める
状況が分からない段階で避けたいのは、WordPressの再インストール、データベースの直接編集、全プラグインの無計画な削除、セキュリティ機能の全面停止です。ログインの原因とは別の問題を増やすと、元の状態へ戻す判断が難しくなります。
特に受注、予約、会員登録が動くサイトでは、昔のバックアップへ戻すことで新しいデータを失う可能性があります。復元の前には、どの時点へ戻り、どのデータが変わるかを管理担当と確認してください。「入れるようになれば何でもよい」という目標にしないことが大切です。
この記事で安全に確認できる範囲を試しても解決しないなら、作業を止めて情報をまとめることも前進です。操作を増やさない間に、問い合わせの材料やバックアップの所在を整理できます。復旧の完了条件は、管理画面へ入れることに加え、必要な機能と安全な設定が保たれることです。
正しいログイン先・入力内容・ブラウザーを順に確認する

自分のWordPressと、別サービスのアカウントを取り違えない
WordPress.orgのサポート用アカウント、WordPress.comのサービスアカウント、自分のサーバーへ設置したWordPressの管理者は、同じものとは限りません。サーバー会社の契約画面へ入るIDも別の場合があります。どのサービスへ入ろうとしているかを先に確認しましょう。
自分で設置したサイトなら、通常はそのサイト自身のログインページへ入ります。公式のWordPress認証ガイドでは、標準のログイン場所や、ユーザー名または登録メールアドレスで認証する仕組みが説明されています。ただし、設置場所やセキュリティ設定で入口が変更されている場合があります。
検索エンジンで「WordPress ログイン」と検索して出た画面が、自分のサイトの入口とは限りません。以前確認して保存したブックマーク、契約時の案内、管理担当から正式に渡されたURLを照合します。知らないサイトへ、手元のIDとパスワードを試しに入力しないでください。
URLはドメイン・設置場所・HTTPSを見直す
標準構成の説明例では、ログインファイルはサイトの設置場所にあるwp-login.phpです。WordPressを別のフォルダへ置いている、ログインURLを変更する機能を使っている、といった場合は入口が異なります。例にあるURLをそのまま使うのではなく、自分の環境に対応する場所を確認します。
URLの前後に不要な文字がないか、似た綴りの別ドメインではないかも見ます。メールのリンクから開いた場合は、送信元名だけで信頼せず、実際の移動先を確かめてください。久しぶりのログインであれば、ドメイン変更や制作会社からの引き継ぎがなかったかも確認します。
ブラウザーが証明書や安全な接続に関する警告を出している場合は、警告を無視して認証情報を入れないようにします。HTTPへ戻して入力することも、安易な解決策にはなりません。管理担当やサーバー会社へ、URLと警告内容を伝えてHTTPSの状態を確認してもらいます。
入力の問題は、試行回数を増やす前に点検する
パスワードは大文字・小文字、全角・半角、前後の空白を確認します。日本語入力が有効になっていたり、Caps Lockの状態が意図と違っていたりすることがあります。見た目が似た文字を何パターンも連続して試すより、保存していた情報と入力状態を照合してください。
パスワード管理ツールを使っているなら、その項目が正しいサイトのものか、古いパスワードが残っていないかを見ます。複数サイトで同じような名前を付けていると、別の登録情報を選んでしまう場合があります。URLとアカウントの対応を確かめることが先です。
パスワードを見える状態にする機能を使う場合は、周囲から見られない場所で行います。確認のためにチャットや共有メモへ貼り付ける必要はありません。入力が正しいか判断できなければ、思い出すまで総当たりするのではなく、通常の再設定手順へ進みます。
※表は横にスクロールできます。
| 確認箇所 | 具体的な点検 | 結果から分かること | 注意 |
|---|---|---|---|
| ログイン先 | ドメイン・設置場所・サービス名 | 別アカウントとの混同 | 検索で出た画面をそのまま信頼しない |
| 入力 | 大文字・全角・空白・保存項目 | 単純な入力違い | 秘密情報を共有メモへ貼らない |
| Cookie | 対象サイトでの許可と保存情報 | 認証状態の不整合の可能性 | 削除でログアウト等の影響 |
| ブラウザー | 正規URLでの表示差 | 環境側の問題の手がかり | 保護機能を一斉に切らない |
| HTTPS | URLと警告の内容 | 証明書等の確認が必要か | 警告を無視して入力しない |
Cookieやキャッシュは、対象サイトを意識して確認する
WordPressはログイン状態の管理にCookieを利用します。対象サイトのCookieが禁止されている場合や、古い情報との不整合がある場合、認証後に元の画面へ戻ることがあります。公式のログイントラブル案内にも、Cookieやキャッシュの確認が含まれています。
まず、未保存の作業があるタブを整理し、対象サイトでCookieが使える設定かを確認します。Cookieを削除すると、そのサイトからログアウトされるなどの影響があります。ブラウザー全体の履歴や保存情報を一括で消す前に、対象サイトだけを扱う方法があるか、利用ブラウザーの公式案内を見ましょう。
別のブラウザーで正規のログインページの表示を確認すると、ブラウザー側の違いを切り分ける材料になります。ただし、アクセス制限を回避する目的で接続元を次々変える必要はありません。別環境で何が変わったかを記録し、サイト管理上の制限がある場合は担当者へ確認します。
ブラウザーだけの問題かを、範囲を限定して調べる
拡張機能、管理された端末の設定、セキュリティソフトなどが動作へ関係する場合もあります。しかし、ログインできないという理由だけで、端末全体の保護を切ってしまうのは避けます。業務用端末なら、会社の管理担当へ相談してください。
個人の端末でも、一度にすべての拡張機能を変更するより、どのブラウザーで再現し、どの画面まで進むかを整理します。変更する場合は現在値と戻し方を控え、一つの条件だけを変えて比較します。設定の変更に自信がなければ、表示確認までにとどめても構いません。
認証が拒否されるのか、ボタンを押しても反応しないのか、入力フォーム自体が欠けるのかでも手がかりが違います。「ブラウザーを変えたら直った」という結果だけで終わらせず、普段使う環境で何を点検すべきかを残しておくと、同じ問題の再発に備えられます。
パスワードの再設定と追加認証は、公式の入口から進める

再設定は、自分のサイトのログインページから申請する
パスワードを忘れた、保存情報が古い可能性があるという場合は、正しいログインページの「パスワードをお忘れですか」などの再設定リンクを確認します。自分のユーザー名または登録メールアドレスを入力し、案内に従って申請します。
現行のWordPress認証ガイドでは、標準の復旧手順として、登録先へパスワード再設定用リンクを送る方法が説明されています。メールに現在のパスワードがそのまま届くと思い込まないようにしましょう。リンクを開く前に、申請したサイトのドメインと一致するか、身に覚えのある申請かを確認します。
再設定画面では、ほかのサービスで使っていない十分に強いパスワードを設定します。変更後は、パスワード管理ツールの保存内容を正しい項目で更新し、新しい情報でログインできるかを確認してください。パスワードそのものを相談メールへ書く必要はありません。
再設定メールが届かないときの確認順序
届かない場合は、最初にどのメールアドレスを登録していたかを確認します。ブログの連絡先として表示しているメールと、ユーザーアカウントの登録先が同じとは限りません。制作会社や別の管理者が設定した場合は、正式な連絡経路で確認しましょう。
次に迷惑メール、振り分け、受信容量、メールサービス側の受信状況を見ます。短時間に何度も再申請すると、複数のメールが届いた際に古いリンクを開くなど、状況を複雑にしがちです。最新の申請時刻を控え、届いたメールがどの申請に対応するかを整理します。
登録先が正しくても、サイトの送信処理やサーバー側のメール配信に問題がある場合があります。「送信しました」と画面に出たことは、受信箱への到達を保証しません。自分の受信設定で説明できなければ、申請時刻と送信先を伏せた状態の情報をまとめ、管理担当やサーバー会社へ相談します。
リンクが無効・期限切れなら、最新の申請と照合する
再設定リンクが開けないときは、古いメールを使っていないか、URLが途中で切れていないかを確認します。メール本文の折り返しやコピーの欠けによって、意図したリンクになっていないこともあります。ブラウザーへ手作業でつぎ足すより、元のメールの正式なリンクを確認します。
身に覚えのない再設定メールが届いた場合は、そのまま操作を続けないでください。まず自分のサイトへ、普段確認している正規の入口からアクセスし、アカウントの状態を管理担当と確認します。届いたという事実だけで、第三者に侵入されたと断定することも避けます。
再申請が必要なら、以前のメールと新しいメールを区別して扱います。復旧リンクは認証に関わる情報なので、掲示板へ貼ったり、スクリーンショットに残したまま広く共有したりしないようにします。相談ではリンク本体を省き、エラーの文言と時刻を伝えます。
※表は横にスクロールできます。
| 再設定で困ること | 確認する情報 | 次の相談先・行動 | 共有しない情報 |
|---|---|---|---|
| メールが来ない | 登録先・迷惑メール・申請時刻 | 受信側確認後にサイト送信を相談 | パスワード |
| リンクが無効 | 最新申請か・URLが欠けていないか | 正規の入口から再申請 | 復旧リンク本体 |
| 登録先を使えない | 契約と引き継ぎ記録 | 所有確認のうえ管理担当へ | 不要な本人確認情報 |
| 追加認証が通らない | 機能の提供元・端末変更 | 提供元の公式復旧手順 | 認証コード・バックアップコード |
| 知らない再設定通知 | 自分が申請したか | 普段の正規入口で状態確認 | メールのリンクを広く転送しない |
二要素認証や独自のログイン機能は、設定元を確認する
パスワードが合っていても、追加のコードや認証アプリが必要なサイトがあります。WordPressの追加機能、サーバー会社の仕組み、外部ID連携など、どこが追加認証を提供しているかを確認してください。サーバー契約画面の認証と、WordPress自体の認証が別々の場合もあります。
端末を買い替えた、認証アプリを消した、登録先メールを使えなくなった場合は、その機能の公式復旧手順に従います。事前に発行していたバックアップコードがあるなら、所有者本人が安全な場所で確認します。コードを第三者へ送って代わりに突破してもらうような対応は避けます。
会社や共同管理のサイトなら、別の正当な管理者へ本人確認を依頼する方法も考えられます。ただし、他人のアカウントを借りる、共有パスワードを使い続けるといった運用に置き換えないことが大切です。復旧できた後も、本人の権限で利用できる状態へ戻します。
登録メールも使えない場合は、所有確認から相談する
登録先のメールを失った場合、画面からの通常の再設定だけでは戻れないことがあります。自分が正当な管理者であることを確認できる契約情報や引き継ぎ記録を用意し、サーバー会社または制作・保守担当へ相談します。
データベースを書き換える方法を見つけても、対象サイト、対象ユーザー、バックアップ、変更後の影響が分からないまま実行しないでください。公式資料にも技術者向けの方法はありますが、初心者の最初の確認と同じ扱いにはできません。特に似た名前のデータベースが複数ある環境では、別サイトを変更する危険があります。
相談先から本人確認資料の提出を求められたら、正規の窓口か、何の情報が必要かを確認して送ります。パスワードや復旧コードをメール本文へ書いてほしいと言われた場合も、より安全な対応手段がないかを相談してください。復旧を急ぐときほど、相手と送信先の確認を省かないようにします。
403・404・転送ループ・重大なエラーを環境側から切り分ける

アクセス拒否は、制限の種類と契約状態を確認する
403などのアクセス拒否が出る場合、認証情報だけでなく、接続元の制限、ログイン試行回数、サーバー設定などが関係している可能性があります。番号だけで原因を一つに決めず、画面に書かれた説明と契約先の障害・制限案内を照合しましょう。
例として、エックスサーバーのWordPressセキュリティ設定には、IPアドレス、国外アクセス、ログイン試行回数などの制限が説明されています。これは同社の機能例であり、他社も同じ名称・条件・解除時間だと考えてはいけません。自分が契約しているサービスの案内を使います。
保護機能を一括で無効にすればよい、とは考えないでください。必要な制限まで外すと、第三者のアクセスへの備えが弱くなる可能性があります。正当な接続を許可する方法があるか、現在の設定を誰が管理しているかを確認し、変更が必要なら範囲と戻す条件を決めます。
404なら、入口の変更と設置場所を調べる
404は、指定した場所が見つからないことを示す表示ですが、ログインURLを隠す機能やアクセス制限の表示として使われる場合もあります。404を見ただけでWordPressのファイルが消えたと判断せず、ログイン入口の変更履歴を確認します。
以前のブックマーク、制作担当からの案内、サーバー管理画面に記録されている設置先を照合します。サイトを別フォルダへ移した、ドメインを変えた、セキュリティ機能を導入した直後なら、その作業記録が手がかりになります。思いつくURLを大量に試す方法は避けましょう。
通常の記事は表示されるのにログイン入口だけ見つからない場合と、全ページが404になる場合は、調べる範囲が異なります。パーマリンク設定をむやみに保存し直したり、ファイルを上書きしたりする前に、どのURLで何が出たかを整理して管理担当へ伝えます。
同じ画面へ戻るときは、URLとCookieの整合を確認する
入力後にログイン画面へ戻る、転送が多すぎると表示される場合、Cookieだけでなく、HTTPとHTTPS、ドメイン表記、WordPressのURL設定、サーバーやCDNの転送などが関係することがあります。ブラウザー側の確認で変わらなければ、直前の移行やSSL作業を振り返ります。
初心者が避けたいのは、複数の場所にあるURL設定を同時に変えることです。WordPress側を変更し、さらにサーバーの転送を追加すると、どちらが影響したか分からなくなります。現在の設定と期待するURLを一覧にし、管理担当が一段階ずつ検証できる状態を用意します。
移行後に起きている場合は、WordPressのサーバー引っ越しガイドにある新旧環境の確認項目も参考になります。ログインを戻すために、すぐ旧サーバーを解約したり、古いデータで本番を上書きしたりしないようにしてください。
※表は横にスクロールできます。
| 症状 | 調べる環境 | 相談時の材料 | 避けたい決めつけ |
|---|---|---|---|
| 403等の制限 | 接続元制限・試行回数・ホスト状態 | 正確な文言と発生時刻 | 必ずパスワード違いと考える |
| 404 | 入口変更・設置場所・制限仕様 | 以前の入口と変更履歴 | ファイル消失と断定する |
| 転送ループ | HTTPS・URL・CDN等の設定 | 現在URLと直前の作業 | 全部の設定を同時に直す |
| 重大なエラー | プラグイン・テーマ・追加コード | 管理者通知とエラー情報 | 原因不明の全削除 |
| 不審な変更 | アカウント・サイト・端末等 | 症状・時刻・通知・記録 | ログイン成功だけで終了する |
重大なエラーでは、管理者メールと復旧モードを確認する
白い画面や「重大なエラー」の案内が出る場合、プラグイン、テーマ、追加コードなどの問題が関係していることがあります。WordPressの復旧モードの公式ガイドでは、一部の致命的なエラーに対して、管理者メールへ専用リンクやエラー情報が届く仕組みが説明されています。
復旧モードの案内が届いたら、正規のサイトからの通知か確認し、原因として示された部品と直前の変更を照合します。復旧用リンクから管理画面を開けたことだけで、通常の訪問者向け表示が直ったと決めつけないことが重要です。管理者のセッションでの動作と、サイト全体の状態を分けて見ます。
メールが届かない場合や、影響する部品を判断できない場合は、サーバー会社や保守担当へ相談します。エラー情報に名前が出ているからといって、必要なデータを確認せず削除するのは避けます。修正後は通常の状態へ戻し、管理画面と公開側の必要機能を改めて確認してください。
不審な変更があるときは、通常の入力ミスと分ける
身に覚えのない管理者追加、見知らぬページへの転送、改ざんされた表示、サーバー会社からの不正利用通知などがある場合は、単なるパスワード忘れと同じ手順で進めないようにします。確認できた事実を残し、正規のサポートへ早めに連絡してください。
WordPressの不正アクセスが疑われる場合の公式案内では、症状や時刻、直前の変更を記録する重要性が示されています。焦ってファイルやログを消すと、何が起きたかを調べる材料がなくなる場合があります。何を保存し、どう保護するかも相談します。
このような場合は、ログインできるようになっただけで対応終了にはできません。サイト、端末、メール、関係する管理権限などの確認が必要になることがあります。一般的な記事だけで被害範囲を断定せず、利用している環境に詳しい担当者の助けを得ましょう。
相談に必要な情報をそろえ、復旧後の状態まで確認する

問い合わせは、事実・試したこと・希望を分ける
問い合わせでは、サイトURL、発生時刻、表示された文言、公開ページの状態、最後に正常だった時点を伝えます。加えて、入力確認や対象サイトのCookie確認など、既に試したことと、その結果を短く並べてください。何を変えていないかも分かると、調査しやすくなります。
架空の連絡例なら、「本日9時ごろから管理画面だけアクセス拒否になります。公開側のトップと記事は表示できます。昨夜はログインできました。入力は二回確認し、現在は再試行を止めています。直前の設定変更は把握していません。制限の種類と、確認すべき記録を教えてください」といった形です。
パスワード、認証コード、復旧用URLは通常の問い合わせ本文へ入れません。管理画面の画像を添えるときは、必要なエラー部分だけにして個人情報を隠します。「早く直してほしい」だけでなく、どの作業が止まっているか、公開側にも影響があるかを伝えると優先度を判断してもらいやすくなります。
※表は横にスクロールできます。
| 問い合わせ項目 | 書き方の例 | 役立つ理由 | 扱い方 |
|---|---|---|---|
| 影響範囲 | 管理画面のみ、公開側は表示可能 | 認証とサイト全体を分ける | 確認した事実のみ |
| 発生時刻 | 本日9時に初めて確認 | ログや通知と照合する | タイムゾーンも明確に |
| 直前の変更 | 昨夜更新通知あり、手動変更なし | 調査の順番を決める | 原因と断定しない |
| 試したこと | 入力二回確認、その後停止 | 同じ操作の重複を避ける | 結果も付ける |
| 復旧後の確認 | 下書き保存・公開ページ・必要機能 | 業務に戻れるか判断する | 一時設定の後始末も含める |
変更する前に、対象と戻し方を合意する
技術的な修正を依頼する場合は、対象のサイト、変更する設定、バックアップ、停止時間の可能性、復旧後の確認担当を整理します。ログインの復旧を頼んだつもりが、大規模なテーマ変更やサイト再構築まで進むと、目的や費用がずれる可能性があります。
サイトに新しい注文や申し込みが入るなら、バックアップ時点以降のデータをどう扱うかも確認します。自分には小さなブログに見えても、コメントや問い合わせなどの情報が増えている場合があります。戻す時点だけでなく、戻す対象がファイルかデータベースかも説明してもらいましょう。
作業後に残る一時設定も忘れず確認します。調査のために追加した権限や一時的な接続許可がある場合は、不要になった時点で適切に見直します。復旧手順を自分で理解しきれなくても、何を変更し何を元へ戻したかの記録は受け取っておくと役立ちます。
ログイン成功後は、編集と公開側の必要機能を試す
管理画面へ入れたら、まず意図したアカウントと権限で入っているかを確認します。見慣れた画面が出たことだけで完了にせず、必要な投稿があり、下書きを正常に保存できるかなど、通常業務に関係する範囲を点検します。
公開側では、代表ページ、画像、メニュー、必要なフォームなどを確認します。フォームの試験は、テスト送信であることを関係者が分かるようにし、不要な個人情報を入れない形で行います。今回の修正が何に影響したかに合わせて、確認対象を選んでください。
再発防止のために、原因が確定した点と未確定の点を分けます。「Cookieを消したら戻ったが、元の不整合の理由は未確認」といった記録でも意味があります。理由が分からない部分を無理に断定しない方が、同じ症状が出たときに別の原因も検討できます。
連絡先と認証情報の管理を、平常時に整える
復旧後は、正しいログインURL、アカウントの登録メール、サーバー会社の窓口、制作・保守担当、バックアップの所在を整理します。パスワードは共有文書へ直接並べず、適切な管理方法を使い、必要な人だけが使える状態にします。
端末変更や担当者交代のときには、メール受信と追加認証の引き継ぎを忘れないようにします。管理者が一人しかおらず、その人の個人メールにすべて依存していると、退職やメール停止時に困る場合があります。組織の方針に沿って責任者と復旧経路を決めておきましょう。
契約環境そのものを見直す必要がある場合は、副業ブログ向けレンタルサーバーの比較ガイドで、価格だけでなくバックアップとサポート条件を確認できます。目の前のログイン不具合を理由に急いで移転するより、まず復旧と記録を終え、必要な支援を整理してから検討します。
迷ったときは、試行回数より状況の整理を増やす
ログインできないときの第一歩は、パスワードの候補を増やすことではありません。正しいサイトか、画面は開くか、どの操作で止まるか、公開側はどうかを整理します。それだけで、認証の再設定、ブラウザーの確認、サーバー側の調査を分けやすくなります。
入力や通常のメール再設定で解決しない場合は、安全機能やサイトの設定を無差別に変えず、確認した事実を持って相談します。専門知識が必要なところで止まることは失敗ではありません。読者やサイトのデータを守りながら戻すための判断です。
最後に、復旧後の管理画面と公開側の状態を確かめ、変更履歴と連絡先を残してください。次に同じ問題が起きても、前回何を確認し、どこから支援を受けたかが分かれば、落ち着いて対応を始められます。