Your site is white. Or it says "There has been a critical error on this website." Or you can see the front end but wp-admin won't let you in.
Whatever the symptom, the next ten minutes matter, and the instinct — start changing things until something works — is the one that turns a twenty-minute fix into a lost weekend.
WordPress breaks for a small number of reasons. The error message usually tells you which one, if you know how to make it talk. Here's the order that finds it fastest, and the one rule that stops you making it worse.
The short version
Rule zero: take a backup before you touch anything. Even a broken site. You need a restore point for the state you're in now, because the fix might make things worse and you'll want the option to go back.
Then work down:
- Read the actual error — check email, then enable debugging
- Symptom lookup — the table below routes you
- Plugin conflict test — the cause maybe half the time
- Theme check — switch to a default theme
- Memory limit — a common quiet cause of white screens
- Host-side — sometimes it was never WordPress
Rule zero: back up first, even now
Yes, the site is already broken. Back it up anyway.
Files and database, both. If your host offers one-click backups, use that. If you have FTP access, download wp-content and export the database via phpMyAdmin.
Two reasons this isn't optional. First, a troubleshooting step can make things genuinely worse — a partial rollback, a corrupted table, a deleted plugin that held settings. Second, you may need to prove what state the site was in.
The one-minute version if you're panicking: download wp-config.php and the wp-content folder via FTP. That's your themes, plugins, and uploads. Combined with a database export, it's a full recovery kit.
Check your email before anything else
Since WordPress 5.2, when a fatal error occurs the site emails the admin address with a recovery mode link — a special login URL that loads wp-admin with the offending plugin or theme paused.
Check that inbox, including spam. It frequently names the exact file and line that caused the crash, which skips most of the diagnostic below.
If the email never arrives, that's informative too: your site probably can't send mail at all, which is its own problem. That one's here.
Symptom-to-cause lookup
Find your symptom, check the likely cause first.
| Symptom | Most likely cause | Start at |
|---|---|---|
| Completely white page, no text | PHP fatal error, or memory exhausted | Enable debugging |
| "There has been a critical error" | PHP fatal error — check the recovery email | Recovery mode link |
| "Error establishing a database connection" | Credentials, database down, or corrupt tables | S11.3 |
| Front end fine, wp-admin white | Admin-side plugin conflict | Plugin test |
| Login redirects in a loop | URL mismatch, cookies, or a security plugin | S11.4 |
| Broke immediately after an update | The update, obviously — roll it back | S11.1 |
| Layout mangled, content present | Theme or CSS, not a fatal error | Theme check |
| 500 Internal Server Error | Server config, .htaccess, or PHP |
Host-side |
| Site loads but very slowly | Not an error — a performance problem | P12 |
| Random redirects to unknown sites | Likely compromised | P14 |
That last row deserves emphasis. Unexplained redirects, unknown admin users, or content you didn't write is a security incident, not a bug. Don't troubleshoot it as one.
Stop guessing: turn on error reporting
A white screen is WordPress hiding an error from you. Make it show you.
Edit wp-config.php via FTP or your host's file manager. Find the line that says /* That's all, stop editing! */ and above it, add:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
If WP_DEBUG is already defined as false, change it rather than adding a second line.
Reload the broken page, then open /wp-content/debug.log via FTP. The last entries are your error, usually naming a specific file:
PHP Fatal error: Uncaught Error: Call to undefined function ...
in /wp-content/plugins/some-plugin/includes/thing.php on line 214
That path tells you which plugin to disable. You've just skipped the entire trial-and-error process.
Why WP_DEBUG_DISPLAY is false: it logs errors without printing them on your live site, where visitors — and anyone probing for vulnerabilities — would see your file paths.
Turn debugging off when you're done. A debug.log left running grows indefinitely and leaks information about your setup.
The plugin conflict test
If the log points at a plugin, disable that one. If it doesn't, test properly.
With admin access: use Health Check & Troubleshooting, which disables plugins for your session only. Visitors keep seeing the working site while you test. This is the method to use on anything with traffic — the classic "deactivate everything" approach takes your site down while you work.
Without admin access: via FTP, rename /wp-content/plugins to plugins-off. WordPress can't find them and deactivates all of them. If the site returns, rename it back, then rename individual plugin folders one at a time until it breaks again.
The two-plugin problem: occasionally no single plugin is at fault — two work fine alone and conflict together. If disabling everything fixes it but no individual plugin reproduces it, reactivate in pairs.
The full method, including staging.
The theme check
If plugins are clear, the theme is next.
Switch to a default theme — Twenty Twenty-Four or similar. If the problem vanishes, it's your theme.
Without admin access: rename your active theme's folder via FTP. WordPress falls back to a default theme automatically, provided one is installed. Worth checking you have one installed before you need it.
Important: if you're using a child theme, test by switching to a default theme, not to the parent. The parent may share the fault.
Memory limits
An underrated cause of white screens, especially on shared hosting or after installing something heavy.
PHP allocates a fixed amount of memory per process. Exceed it and the script dies — often with no message at all, which is exactly what a white screen is.
The debug log will say so plainly: Allowed memory size of X bytes exhausted.
The fix, in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
Some hosts cap this at the server level and ignore your setting, in which case you'll need to ask them.
Worth noting: needing to keep raising the limit is a symptom rather than a solution. Something is consuming more than it should — usually a bloated plugin or an inefficient query. Auditing plugins.
When it's the host, not WordPress
Some failures aren't WordPress at all, and you can waste hours before realising.
500 Internal Server Error is a server-level failure. Common causes: a corrupted .htaccess, a PHP version incompatibility, or exhausted server resources. Try renaming .htaccess to .htaccess-old and reloading — if the site returns, regenerate permalinks in Settings → Permalinks.
503 or connection timeouts usually mean the server is overloaded or down. Check your host's status page before touching your site.
A PHP version change breaks older plugins abruptly. Hosts sometimes upgrade PHP without much warning, and a plugin that hasn't been updated in three years stops working overnight. Your debug log will show it.
The check that saves time: does the host's status page report an incident, and does a plain HTML file on the same server load? If a static file also fails, WordPress was never the problem.
Stopping it happening again
Most WordPress emergencies are preventable, and the prevention is unglamorous.
Have a staging site. Most decent hosts offer one free. Update there first, check the site, then push. This alone prevents the large majority of update disasters.
Have backups you've actually restored. An untested backup is a hypothesis. Restore one to staging once, so you know it works and how long it takes.
Update deliberately, not automatically — for major things. Security patches should apply fast. Major plugin versions, and especially page builders and anything touching commerce, deserve a staging test first.
Audit your plugins. Every plugin is a potential point of failure. Abandoned ones — no update in a year or more — are both a break risk and a security risk. How to audit.
Keep PHP current rather than letting it drift until your host forces it.
Frequently asked questions
What causes the WordPress white screen of death?
Almost always a PHP fatal error or exhausted memory. A fatal error stops the script mid-execution, and if error display is off, you get a blank page instead of a message. The fastest route is enabling WP_DEBUG_LOG in wp-config.php and reading /wp-content/debug.log, which usually names the exact file and line responsible. Check the admin email first, though — since WordPress 5.2, fatal errors trigger a recovery-mode email that often identifies the culprit outright.
How do I fix a critical error without admin access?
Use FTP or your host's file manager. Rename /wp-content/plugins to plugins-off, which deactivates every plugin at once — if the site returns, rename it back and disable plugins individually until you find the offender. If that doesn't help, rename your active theme's folder so WordPress falls back to a default. Enable WP_DEBUG_LOG in wp-config.php first, so you're reading the error rather than guessing.
Can I roll back a WordPress update?
Yes. The WP Rollback plugin reverts a plugin or theme to a previous version from the repository, and most managed hosts keep automatic restore points you can roll back to. For core updates, restoring a full backup is the reliable route. Whichever method you use, take a backup of the current broken state first — you may need to recover content added since the last good backup.
Why did my site break after an update?
Usually an incompatibility rather than a bad update. A plugin update assumes a newer WordPress core version, or a core update removes a function an old plugin still calls, or two plugins that coexisted now conflict. PHP version changes cause the same symptom. This is why staging exists — testing an update against your specific combination of plugins catches it before your visitors do.
What to do next
Take the backup first. Even now, even broken.
Then check the admin email for a recovery link before doing anything else. It's the fastest path back, and it frequently names the exact file that crashed — which turns an afternoon of guessing into a five-minute fix.
If there's no email, enable WP_DEBUG_LOG and read the log. Stop guessing.
Free: The WordPress maintenance checklist.
Related guides
- Blank page after an update — rolling back safely
- Find a plugin conflict safely — without taking the site down
- Error establishing a database connection — the four causes
- Locked out of wp-admin — six routes back in
- WordPress security — if you suspect a compromise
- WordPress speed — if it's slow rather than broken
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
Transactional Email Services Compared for WordPress
Every one of these services will deliver your password resets. That's not the differentiator. What differs is setup difficulty, what the free tier covers, how good the logs are when something goes wrong, and — the one people never consider until it bites them — whether the service also handles marketing mail, and whether you […]
Contact Form Notifications Not Arriving: Every Cause
Here's the version of this problem that costs the most: it's been happening for months and you don't know. The form says "thank you." The visitor believes they've reached you. You believe nobody's been in touch. There's no error, no bounce, no alert — just an absence, and absences are invisible. Most of the time […]
WooCommerce Order Emails Going to Spam: The Fix
"I never got a confirmation. Did my order go through?" Every store owner gets this message. And when it arrives often enough, you stop treating it as customer confusion and start realising your receipts genuinely aren't landing. This costs more than most email problems, because a missing order confirmation doesn't just annoy someone — it […]