When wp-admin Stops Working
"wp-admin is broken" is four unrelated faults wearing the same URL. The symptom you see — blank, redirect, 403 or 404 — tells you which one you have before you change anything.
Quick fix: name the symptom before you change anything. A blank /wp-admin/ is a PHP fatal error. A bounce straight back to the login form is cookies or a wrong site URL. A 403 is the server or a security plugin. A 404 is permalinks or a missing directory. The symptom decides which check is worth your time.
The trap is treating this as one fault. It is at least four unrelated faults that happen to share a URL, and the fixes for them have nothing in common. Work from the cheapest test upward.
Read the symptom first
Load /wp-admin/ in a private window and write down exactly what comes back.
| What you see | Layer at fault |
|---|---|
| Blank white page | PHP fatal in a plugin, theme or core |
| Login form reloads with no error | Cookies, session or site URL mismatch |
| 403 Forbidden | Server rules, firewall, file permissions |
| 404 Not Found | Permalinks, wrong site URL, missing files |
| 500 Internal Server Error | .htaccess, PHP configuration, fatal error |
| Loads but unstyled and half-dead | Admin CSS/JS blocked or failing |
| "Briefly unavailable for scheduled maintenance" | An interrupted update |
Then load the public homepage. If the frontend is healthy and only the admin is dead, suspect admin-only code or a security rule. If both are dead, suspect plugins, PHP or the server itself.
Rule out cookies and cached redirects
This costs thirty seconds and explains a surprising share of login loops.
- Test in a private window. A fresh profile has no stale authentication cookie and no cached 301.
- Clear cookies for the domain, not the whole browser. WordPress authentication cookies are domain- and path-scoped, and an old one from a previous URL will be rejected on every attempt.
- Try a second browser or device. If wp-admin works there, the fault is local and nothing on the server needs touching.
- Check the clock. A device whose time is badly wrong can invalidate cookies immediately.
If the login form reloads without an error message, that is the signature of a cookie WordPress set and then refused. Fixing the WordPress login redirect loop covers that specific case in detail.
Confirm the address WordPress thinks it has
WordPress builds every admin redirect from the stored Site Address and WordPress Address. If either points somewhere you are not — the wrong protocol, a stale staging hostname, a missing or extra www — the admin will redirect you away from yourself forever.
Confirm the stored values without wp-admin by querying the siteurl and home rows in the wp_options table, or with WP-CLI:
wp option get siteurl
wp option get home
To override them temporarily while you work, define them in wp-config.php:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );
These constants win over the database, which makes them a safe way to prove the theory. If the admin returns, the stored values were wrong — correct them, then remove the constants. What each wp-config.php setting does explains why hard-coding them permanently causes trouble later.
Separate a server block from a PHP fatal
A 403 never comes from WordPress code — it comes from the web server, a firewall or a security plugin. Look for a rate-limit or country block that caught your own IP, a login-lockout rule you triggered, or file permissions that were changed by a restore.
A blank page or a 500, by contrast, means PHP stopped. Get the actual error rather than guessing: enable logging as described in the WordPress debug mode guide, reload /wp-admin/ once, and read the last fatal in wp-content/debug.log. The file path in that line usually names the guilty plugin or theme outright, and the white screen walkthrough covers what to do with it.
Rename .htaccess to .htaccess.bak if you suspect the rewrite rules. WordPress regenerates a clean one once you resave permalinks; if the admin loads immediately, the old file contained a bad directive.
Isolate the plugin, theme or core file
If the log names nothing useful, isolate by hand. Rename wp-content/plugins to plugins-off — every plugin deactivates at once, settings intact — and reload. If the admin returns, rename it back and disable plugins individually until the fault reappears. Disabling plugins without admin access covers the safe sequence.
Two more causes worth checking once plugins are ruled out:
- Memory. The admin is heavier than the frontend, so it exhausts memory first. An "Allowed memory size exhausted" line in the log is definitive; see raising the WordPress memory limit.
- Incomplete core files. An interrupted update can leave
wp-adminpartially written. A.maintenancefile left in the site root produces the maintenance message and is safe to delete.
Once you are back in
Do not stop at "it works now." Note which layer failed, because that decides what to change: a plugin that fatals on your PHP version needs updating or replacing, a firewall that locked you out needs an allowlist entry, and a wrong site URL usually means a migration was left half-finished. Then take a fresh backup — you now have a known-good state worth keeping.
Frequently asked
- The frontend and the admin load different code, so admin-only plugin code, an admin AJAX call or a firewall rule can fail while public pages render fine. Cookie and site URL problems also affect only authenticated requests, because the frontend does not need a valid login cookie.
- You still have SFTP or the hosting file manager, phpMyAdmin and, on many hosts, WP-CLI over SSH. Those three cover almost every recovery task: disabling plugins, switching themes, correcting the site URL and resetting a password.
- No, and it breaks WordPress. Core code refers to that path in hundreds of places, and plugins that hide the login URL do it with rewrite rules instead. If someone renamed the directory, restoring the original name is part of the fix.