Search results for WordPress errors nearly all assume the worst case, that nothing loads at all. But a large share of real faults are lopsided: the admin works and the public site does not, or the public site is fine and you cannot log in. People in that situation follow advice written for total failure, and the advice does not fit.
The half-broken cases are not a lighter version of the fully broken one. They point at different causes, and they have a different first step. This page is about telling them apart before you touch anything.
First, establish which half
Open two things in a private browsing window, so no cache and no logged-in session confuses the result:
- Your home page,
https://yoursite.com/ - Your login screen,
https://yoursite.com/wp-login.php
That gives you one of four outcomes.
Both load. Whatever you saw was probably cached, or specific to one browser or one page. Check a specific broken URL rather than the home page before concluding anything.
Neither loads. This is the full outage case. It is the situation the standard critical-error advice was written for, and our walkthrough of the critical error after an update is the right starting point if an update preceded it.
The front end is down, the admin works. Covered below as Case A.
The front end is fine, you cannot log in. Covered below as Case B.
The point of doing this first is that Cases A and B have almost no overlap in their likely causes, and treating them as the same problem is how people end up deactivating plugins that were never involved.
Case A: the public site is broken, the admin loads
This is the more common half-break and it is the better one to have, because you have a working control panel.
WordPress loads a different set of code for the front end than it does for the admin. A theme file, a front-end-only plugin feature, a widget, a shortcode or a caching layer can break one without touching the other. That is what makes this case diagnosable.
Work in this order.
Check whether it is one page or all pages. Try the home page, a single post, and a category archive. If only one page is broken, the fault is in that page's content, most likely a block or a shortcode from a plugin that has stopped working. If everything is broken, it is the theme, a global plugin feature, or caching.
Check whether it is cached. Purge the caching plugin, purge the host cache, purge the CDN if you use one, then check in a private window again. A stale cache serving a page built during a broken moment is a genuinely common cause of "the site is still down after I fixed it".
Switch the theme, briefly. Activate a default WordPress theme from Appearance. If the front end returns, the fault is in your theme or in something that hooks into it. Switch back and note it in your change log. This test is fast and it is reversible, which is why it comes before anything involving files.
Then, and only then, plugins. Deactivate in halves rather than one at a time. If the site returns, reactivate half of the deactivated set, check, and keep halving.
The advantage in Case A is that you can turn the debug log on from the admin side and read a real error message instead of guessing. That is nearly always faster than the theme and plugin dance, and it is worth doing first if you are comfortable editing wp-config.php with a backup in hand.
Case B: the site is fine, you cannot get into the admin
The public site being healthy tells you something useful straight away: WordPress is running, the database is connected, and PHP is working. Whatever is wrong is specific to the login or admin path, and the list of causes is short.
A redirect loop or a wrong site address. If wp-login.php bounces you repeatedly, the site URL and home URL settings, or an HTTPS setting, are usually the cause. This is the one case where a plugin that manages HTTPS or redirects is the first suspect.
A security plugin locking you out. Login-limiting and firewall plugins block by IP address, and they cannot tell you apart from an attacker. If your address changed, or you mistyped a password a few times, you may be blocked at the door rather than at the password.
A password or user problem. Use the password reset link before anything else. If the reset email never arrives, your site cannot send mail, which is a separate and very common fault that has nothing to do with your login.
A role or capability problem. If you can log in but the admin is empty or shows almost nothing, your account may have lost its administrator role rather than its access. That looks alarming and is usually recoverable. Our guide to how WordPress user roles work explains what each level can actually see, which is useful for recognizing the symptom.
A broken admin-side plugin. Rarer, but possible: something that only loads in the admin has thrown a fatal error. If WordPress detected it, the Recovery Mode email will have been sent to the site's administration address, and that link is the intended way back in.
The one thing not to do in either case
Do not start editing files because a search result told you to. In both cases above, the majority of causes are settings, plugins or caches, and file edits are the most likely step to turn a recoverable problem into an unrecoverable one.
If you reach a step you would be performing without understanding it, that is the point to stop and ask someone, not the point to try it and see.
Why this distinction is worth the two minutes
Most published WordPress troubleshooting collapses every fault into a single "site is broken" narrative, because that is the query people type. The result is that a reader whose admin works perfectly is told to rename their plugins folder over FTP, which is drastic advice for someone who could have clicked Deactivate.
Two minutes in a private window tells you which of the two problems you have, and the two problems barely share a cause list. That is worth more than any single fix on this page.
Version context. Written against WordPress 7.1, released 2026-08-19, the current major release on our record. The behavior described here, separate front-end and admin code paths, Recovery Mode notification by email, and the site address settings, is long-standing core behavior rather than a 7.1 feature. Release dates come from our own dated record of the WordPress.org release page, last read 2026-08-19.
