There is a pattern to how a small WordPress problem becomes a large one. Something breaks. You deactivate a plugin. Nothing changes, so you deactivate another. You switch the theme. You clear a cache. You edit a file because a forum post said to. Twenty minutes later the original symptom is still there, four other things have changed, and you can no longer describe what state your site is in.
This page is the antidote, and it is deliberately not a fix. It is the ordered process for finding out what is actually wrong, so that the fix you eventually apply is the right one and the only one. It is the entry point for this site's troubleshooting cluster, and it links out to the individual procedures rather than repeating them.
Before anything: the one precondition
You need a backup you have restored at least once, or you need to accept that some of what follows is irreversible. Not a backup you have. A backup you have proven. Those are different things, and the difference only becomes visible on the day it matters.
If you have never tested a restore, treat everything from step 4 onward as a decision rather than a step, and do the smallest possible version of it. Diagnosis itself is mostly read-only, which is exactly why it goes first.
Rule zero: one change at a time, written down
Keep a text file open. Every time you change something, write one line: what you changed, the time, and what happened. It sounds like overhead. It is the single habit that separates a fifteen-minute diagnosis from a three-hour one, because it makes every change reversible in the exact order you made it.
If you change two things and the symptom clears, you have not learned anything. You have two suspects and no way to tell them apart, and next month the same thing will break again.
Step 1: Say what "broken" means, in one sentence
Almost every wrong diagnosis starts with a vague symptom. Force yourself to answer four questions before touching anything.
Who sees it? You while logged in, a logged-out visitor, or both? A problem only you can see is usually a cache or a browser issue. A problem only logged-out visitors see is usually a cache or a permission issue. A problem both see is usually real.
Where is it? The public site, the admin, or both? This is the most useful single split in WordPress troubleshooting, and it separates two entirely different problems. If the admin loads and the front end does not, you still have a working diagnostic surface and your situation is far better than it looks. Our guide to telling a lockout apart from a site outage covers that fork properly.
What exactly appears? A white page, a WordPress error message, a browser error, a server error code, or a page that loads but is wrong. Copy the exact text. "It's broken" is not a symptom. "There has been a critical error on this website" is.
What changed last? An update, a new plugin, a setting, a host notification, something expired. If the answer is an update, the suspect list is short and ordered, and what actually happens during a WordPress update explains why the errors take the shapes they do.
Step 2: Rule out the free explanations
Three things account for a large share of reported WordPress faults, and none of them requires touching the site.
Caching. Your host cache, a caching plugin, a CDN and your own browser are four separate layers, and any of them can serve you yesterday's page. Test in a private window, on a different device, or on mobile data. If the problem disappears in a private window, it was never a site problem.
Your own browser. An extension, a stale service worker or a blocked script produces symptoms that look exactly like a broken site. A second browser settles it in thirty seconds.
The host. Check your host's status page and your email before you conclude anything. A site that is down because the server is down cannot be fixed from inside WordPress, and every minute spent deactivating plugins is wasted.
If any of these three explains it, stop. You are done, and you changed nothing.
Step 3: Read what WordPress is already telling you
WordPress reports on itself, and most site owners never look.
Tools then Site Health. The Status tab lists issues WordPress has already detected. The Info tab is a full inventory: PHP version, database version, active theme, active plugins, memory limit, file permissions. When you ask for help anywhere, this is the information you will be asked for first. Not every warning here is urgent, and knowing which ones matter is its own subject.
The Recovery Mode email. When WordPress detects a fatal error in a plugin or theme, it emails the site's administration address a link that logs you in with the offending extension paused. Check that inbox, including spam. This is the intended door, and it is far safer than anything you would do by hand.
The debug log. WordPress can write PHP errors to a file instead of showing them to your visitors. It is off by default, and turning it on is the highest-value diagnostic step available to a non-developer, because the log usually names the guilty file outright. It is a wp-config.php edit, so it is covered separately in a separate guide on turning the debug log on without showing errors to your visitors, and reading the result is covered in a separate guide on reading the log and finding the guilty plugin.
Steps 1 to 3 are entirely read-only. If you have got this far without changing anything, you are doing it correctly.
Step 4: Isolate, and only then
Now you change something. One thing, with a written note.
The classic isolation test is to deactivate all plugins and switch to a default theme, then reintroduce them one at a time until the symptom returns. It works, and it is also blunt: on a live site it means turning off the shop, the forms and the caching for as long as the test takes. Do it deliberately, at a quiet hour, and do it as a test you intend to reverse rather than as a fix.
If you cannot reach the admin at all, "deactivate your plugins" is useless advice, and the way in is renaming the plugins folder through your host's file manager. If the recovery email never arrived, there is another way in.
The efficient version of the test is not one plugin at a time. It is halving: turn off half, check, then halve whichever half still shows the fault. On a site with thirty plugins that is roughly five checks instead of thirty. The full method is in our guide to the conflict test.
Step 5: Decide whether to fix, roll back, or stop
You now have a cause. There are only three honest options.
Fix in place when the cause is a setting, a cache, a permission, or a plugin you can update. This is the normal outcome and it should be the boring one.
Roll back when the cause is a change you can undo. Rolling back feels more dangerous than it is for files and less safe than it looks for data, because files revert cleanly and a database that has already been upgraded does not.
Stop and get help when the cause involves the database, the server, file permissions you do not understand, or anything where the next step is a command you would be copying without knowing what it does. Knowing where that line sits for you is a skill, not a failure.
What this page deliberately does not do
It does not fix the critical error, diagnose a specific error code, or tell you which plugin is the problem on your site. Those are separate pages because they are separate jobs, and one page trying to be all of them would be the generic troubleshooting guide that already exists in a hundred versions.
What this page does is stop you from becoming the second cause of your own outage. Read the symptom, rule out the free explanations, let WordPress tell you what it already knows, isolate one variable, and only then change something.
Version context. Written against WordPress 7.1, released 2026-08-19, which is the current major release on our record. The steps above describe core behavior rather than 7.1-specific features, but the menu paths reflect the redesigned 7.x admin. Release dates here come from our own dated record of the WordPress.org release page and have not been re-read since 2026-08-19, so treat the version numbers as accurate to that date rather than to today. If your admin does not match the screens described in guides you find online, that is worth reading about on its own.
