When /wp-admin/ stops working, the single most useful thing you can do is find out what the server returns. A blank 200, a 500, a redirect loop, a 403 and a 404 are five different problems with five different fixes, and the guides that tell you to start by renaming the plugins folder are making you do the most invasive step first.
Run this before touching anything:
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://example.com/wp-admin/
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://example.com/wp-login.php
What comes back narrows it to one of five cases.
What each status code means
200 with an empty body is a PHP fatal error that WordPress caught too late or did not catch at all. The front end is usually broken too.
This is the case where Recovery Mode is involved, which is the next section.
500 is a fatal error the server reported itself, usually in a mu-plugin, wp-config.php, or a plugin that fatals before WordPress installs its error handler. Check the PHP error log, not debug.log, because the handler that writes debug.log may not have loaded yet.
302 pointing back at wp-login.php, forever, is a cookie or URL problem, not a plugin problem. See the siteurl section below.
403 is almost never WordPress. It is the web server, a host-level rule, a WAF or a security plugin's IP block, and the fix lives wherever that rule lives.
404 on /wp-admin/ while the front end works means rewrite rules or .htaccess, or the admin directory is genuinely not there after a failed update.
Separating those five takes one command. Renaming the plugins folder fixes exactly one of them and makes the other four harder to read.
Recovery Mode has probably already tried, and it only tries once a day
WordPress has shipped a fatal-error handler since 5.2, and when a plugin or theme fatals it emails a one-click recovery link to the address in admin_email. Neither of the two biggest guides ranking for this problem mentions it at all.
If you are locked out and have not checked that inbox, check it first.
The part that catches people is the rate limit. WP_Recovery_Mode::get_email_rate_limit() returns DAY_IN_SECONDS through the recovery_mode_email_rate_limit filter, so core sends at most one recovery email per day (wp-includes/class-wp-recovery-mode.php line 307, read 2026-10-20).
Worse, the clock starts whether or not the mail goes out. WP_Recovery_Mode_Email_Service::maybe_send_recovery_mode_email() writes recovery_mode_email_last_sent before it calls the send, and returns early if that write fails (class-wp-recovery-mode-email-service.php lines 55 to 62, read 2026-10-20).
A site whose mail is misconfigured, which is a common reason the site is broken in the first place, will silently burn its daily attempt.
If you have database access, clearing that option arms it again on the next request:
wp option delete recovery_mode_email_last_sent
Two more numbers are worth knowing.
The recovery link is valid for the same period as the rate limit, because get_link_ttl() returns max( $valid_for, $rate_limit ), so a link from yesterday's email is expired. Once you are in, the recovery session cookie lasts WEEK_IN_SECONDS by default, via the recovery_mode_cookie_length filter.
The redirect loop is usually siteurl, not a plugin
If wp-login.php keeps bouncing you back to wp-login.php after a correct password, WordPress is setting an auth cookie on one host and reading it on another. That happens when siteurl and home disagree with the URL you are actually browsing, most often after a migration, an http-to-https move, or a www change.
Check what the database thinks:
wp option get siteurl
wp option get home
Pinning both in wp-config.php takes the database out of the loop while you work:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );
A hardcoded COOKIE_DOMAIN in wp-config.php does the same damage from the other direction. If one is defined and does not match the host you are on, the browser will not send the cookie back, and the login looks like it failed when it actually succeeded.
We covered the surrounding mechanics in changing a WordPress site URL.
Use WP-CLI instead of renaming folders
Every ranking guide for this phrase reaches for FTP and tells you to rename wp-content/plugins. That works, but it deactivates everything at once, loses which plugins were active, and on some setups leaves orphaned options behind.
If you have SSH, WP-CLI does the same job reversibly and tells you what it did:
wp plugin list --status=active --field=name # write this down first
wp plugin deactivate --all
wp theme list --field=name # pick a default theme
wp theme activate <a-default-theme>
wp user list --role=administrator --fields=ID,user_login,user_email
WP-CLI loads WordPress without going through wp-admin, so it keeps working when the dashboard does not, and it keeps working through a redirect loop because there is no cookie involved. If a plugin fatals hard enough to break WP-CLI too, wp --skip-plugins --skip-themes plugin deactivate <name> gets you past it.
That also gives you the one thing folder-renaming never does: a list you can replay, one plugin at a time, to find which one it was.
Reproduce it on a copy, not on the live site
Bisecting plugins on a production site means your visitors watch you do it. The faster loop is to take a copy, break it on purpose, and fix the real site once you know the answer.
SandyWP's Cloner pulls a running site into a sandbox with its database and files, and the sandbox has SSH and WP-CLI, so the commands above run against the copy. Turn on Debug mode there and the fatal that produced your blank page is written to debug.log where you can read it, rather than being swallowed on a production site with WP_DEBUG_DISPLAY off.
The copy is also where you can test the fix. Reactivating twelve plugins one at a time is fine on a sandbox you can throw away, and resetting it is faster than undoing the mess if you get it wrong.
When a sandbox is the wrong tool
If the status code was 403, stop. That rule lives in your host's edge, your web server config, or a WAF, and none of those come with the site when you clone it.
A sandbox will happily serve you a working /wp-admin/ and tell you nothing, because the thing that blocked you is not in the copy.
The same goes for "error establishing a database connection" and for a host suspending the account. Both are infrastructure, and the answer is a support ticket, not a test install.
Clone it when the problem is in the code or the database. Call the host when the problem is in front of PHP.
The short version
Run the two curl commands first and write the status codes down. Check the admin_email inbox for a recovery link, and remember you get one email a day whether it arrived or not.
If it loops, look at siteurl, home and COOKIE_DOMAIN before you look at plugins. If it is a fatal, use WP-CLI rather than FTP, so you keep the list of what was active.
And if it is a 403, the fix is not in WordPress at all.
