Since WordPress 5.2, a fatal error is not supposed to produce a blank white page. It is supposed to show visitors a holding message and email you a secret recovery link that pauses the plugin or theme that broke.
So the first diagnostic question is not "what broke?" It is: did you get the email?
- You got it — click the link, and WordPress puts you into recovery mode with the offending extension paused. Most of this guide is then unnecessary.
- You did not get it — you have two problems. Something broke, and your site cannot send mail. The second one is why the first one is so much harder to fix than it needed to be.
That second problem is extremely common, and it is invisible until the exact moment you need it most. If your site cannot send a recovery email, it also cannot send password resets, order confirmations or contact form notifications — covered in WordPress email: why your site's emails never arrive.
What you see, and what it means
Start here. The screen names the category of fault.
| What you see | What it usually is | Where to go |
|---|---|---|
| "There has been a critical error on this website" | A PHP fatal error, handler working | Check your email for the recovery link |
| Completely blank white page | Fatal error where the handler could not run, or a memory exhaustion | Blank page after a WordPress update |
| "Error establishing a database connection" | Credentials, database server, or corrupted tables | Database connection error |
| HTTP 500 Internal Server Error | Corrupted .htaccess, memory limit, or a server-level fault |
See below |
| Redirect loop or "too many redirects" | Site URL mismatch, or an SSL plugin misconfiguration | Check WP_HOME and WP_SITEURL |
| Admin loads, front end broken | Theme fault | Switch to a default theme |
| Front end fine, admin broken | Plugin fault in an admin-only code path | Find a plugin conflict safely |
| Cannot log in at all | Credentials, cookies, or a plugin blocking access | Locked out of WordPress admin |
The last two rows are the most useful distinction on this page. Whether the break is on the front end, the back end, or both narrows the cause enormously, and it costs nothing to check.
Before you change anything
Take a backup. Files and database, both. Every step below is reversible if you have one and permanent if you do not.
Write down what changed. WordPress sites break after something happens: an update, a new plugin, a PHP version change at the host, an edit to a theme file. Almost every fault has a specific cause on a specific day, and the change log is usually a faster route to it than any diagnostic.
Do not make several changes at once. Fixing five things simultaneously means never learning which one was broken, and the next occurrence starts from zero.
Turning on the error log properly
This is the single highest-value skill in WordPress troubleshooting, and most people do it wrong on a live site by showing errors to visitors.
In wp-config.php, above the line that says /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
That combination is the one that matters. WP_DEBUG turns error reporting on, WP_DEBUG_LOG writes it to wp-content/debug.log, and WP_DEBUG_DISPLAY set to false keeps it out of the page your visitors see.
Then reproduce the error and read wp-content/debug.log. The last entries name the file and line number that failed — which is usually a plugin directory name, and therefore your answer.
WordPress's own guidance is that debug tools are meant for local and staging installs rather than live sites. The configuration above is the compromise when you have no choice: errors are captured and never displayed. Turn it off once you are done, because a growing debug log is both a disk-space problem and, if it is publicly reachable, an information leak.
The diagnostic order
Seven steps. Stop at the first thing that resolves it.
Step 1 — Check your email for the recovery link
Including spam. If it arrived, click it and WordPress will pause the failing plugin or theme for you.
Step 2 — Fix the date of the break, and what changed around it
An update, a new plugin, a PHP version bump, an edited file. Hosts keep logs of PHP version changes and updates.
Step 3 — Turn on logging and reproduce the error
The four lines above. The log names the file and line, which almost always names the plugin.
Step 4 — Deactivate all plugins
If you can reach the admin, deactivate them all and reactivate one at a time. If you cannot, rename wp-content/plugins to wp-content/plugins-off over FTP or the host's file manager — WordPress deactivates everything it cannot find.
Rename the folder back afterwards, then reactivate one plugin at a time. The method in full, including how to avoid losing settings, is in find a WordPress plugin conflict safely.
Step 5 — Switch to a default theme
Rename your active theme's folder and WordPress falls back to a default one. If the site returns, the fault is in the theme — most often a functions.php edit.
Step 6 — Rule out .htaccess and memory
For a 500 error, rename .htaccess to .htaccess-old and reload. If that fixes it, the file was corrupt — visit Settings → Permalinks and save to regenerate a clean one.
For memory exhaustion, raise WordPress's own limit in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
WordPress defaults to 40MB for single sites and 64MB for multisite, which modern plugin stacks exceed easily. Note that your host's PHP limit is a separate ceiling that this cannot exceed.
Step 7 — Escalate to the host
Server errors, PHP version mismatches and resource limits are theirs. Bring them the log entry rather than the symptom — "PHP Fatal error in this file at this line" gets a useful answer; "my site is down" gets a script.
The errors this cluster covers separately
Four faults are common enough to have their own diagnostic, because each has a distinct cause list:
- Blank page after a WordPress update — the true white screen, where even the error handler failed
- Find a WordPress plugin conflict safely — without losing settings or taking the site down
- Error establishing a database connection — credentials, server, or corruption
- Locked out of WordPress admin — every route back in, in order of risk
The email problem underneath all of this
Worth stating plainly, because it is the thread running through this whole cluster.
WordPress's recovery mechanism, its password reset, and its "your site had a critical error" notification are all email. A site that cannot send email cannot use any of them. And a WordPress site sending through PHP mail() — the default — frequently cannot, because that mail fails authentication checks and is rejected or filed as spam.
The consequence is that the safety net most people assume they have is not connected. You discover it at the worst possible moment, which is the moment you are locked out.
Fixing it is a twenty-minute job — SMTP configuration, covered in how to set up SMTP in WordPress properly — and it is worth doing before you need it rather than during an incident.
Why site email fails in the first place is a deliverability question rather than a WordPress one: authentication, sending domain, and the reputation of whatever is doing the sending. The Email Deliverability Playbook covers the setup end to end, including the exact records and the platform-by-platform paths. Available here.
Frequently asked questions
Why is my WordPress site showing a blank white page?
Since WordPress 5.2, a fatal error should show "There has been a critical error on this website" and email you a recovery link. A genuinely blank page means the error handler itself could not run — often memory exhaustion or an error occurring very early in loading. Enable logging to wp-content/debug.log and read the last entries.
What is WordPress recovery mode?
A feature added in WordPress 5.2 that catches fatal errors, shows visitors a holding message rather than a broken page, and emails the admin a secret link. Following that link sets a cookie enabling recovery mode on that device only, with the failing plugin or theme paused so you can deactivate it.
Why didn't I get the recovery mode email?
Almost always because your site cannot send email. WordPress uses PHP mail() by default, which frequently fails authentication and is rejected or spam-filtered. It is the same reason password resets and order confirmations go missing, and it is fixed by configuring SMTP properly.
How do I see WordPress errors?
Add WP_DEBUG and WP_DEBUG_LOG as true and WP_DEBUG_DISPLAY as false in wp-config.php. Errors are then written to wp-content/debug.log without being shown to visitors. WordPress recommends debug tools for local and staging installs, so turn them off once you have finished.
How do I deactivate plugins if I cannot log in?
Rename the wp-content/plugins folder to something else using FTP or your host's file manager. WordPress deactivates every plugin it cannot find. Rename the folder back afterwards, then reactivate one plugin at a time to identify the culprit.
What causes a 500 internal server error in WordPress?
Most often a corrupted .htaccess file, an exhausted PHP memory limit, or a plugin or theme fault. Rename .htaccess to .htaccess-old and reload — if that fixes it, resave your permalinks to regenerate a clean file.
How much memory does WordPress need?
WordPress defaults to 40MB for single sites and 64MB for multisite, which many plugin stacks exceed. Raise it with WP_MEMORY_LIMIT in wp-config.php, remembering that your host's own PHP limit is a separate ceiling this cannot exceed.
Should I edit wp-config.php myself?
Yes, with a backup of the file first, and edits placed above the "That's all, stop editing" line. It is a normal part of WordPress administration. Copy the original before changing it, because a syntax error in wp-config.php takes the whole site down.
What to do next
Check whether your site can send email at all — before you need it to. Trigger a password reset for a test account and see whether it arrives.
If it does not, fix that first. Every recovery route WordPress offers you depends on it, and it is the difference between a five-minute incident and an FTP session.
Related guides
- Blank page after a WordPress update? Fix it — the true white screen
- Find a WordPress plugin conflict safely — without breaking the live site
- Error establishing a database connection: fixed — credentials to corruption
- Locked out of WordPress admin? How to get back in — every route, by risk
- WordPress email: why your site's emails never arrive — why the recovery email never came
- How to set up SMTP in WordPress properly — the twenty-minute fix
- WordPress backups: what most people get wrong — before you change anything
The short version
- Check your email for the recovery linkIncluding spam. If it arrived, following it puts WordPress into recovery mode with the failing plugin or theme already paused.
- Fix the date of the break and what changed around itAn update, a new plugin, a PHP version bump, an edited file. Hosts keep logs of PHP changes and updates.
- Turn on logging and reproduce the errorSet WP_DEBUG and WP_DEBUG_LOG true and WP_DEBUG_DISPLAY false in wp-config.php, then read wp-content/debug.log. The last entries name the file and line that failed.
- Deactivate all pluginsFrom the admin if you can reach it, or by renaming wp-content/plugins over FTP if you cannot. Rename it back, then reactivate one at a time.
- Switch to a default themeRename the active theme's folder and WordPress falls back to a default. If the site returns, the fault is in the theme.
- Rule out .htaccess and memoryRename .htaccess to .htaccess-old for a 500 error and resave permalinks afterwards. Raise WP_MEMORY_LIMIT for memory exhaustion, noting the host's PHP limit is a separate ceiling.
- Escalate to the host with the log entryServer errors, PHP version mismatches and resource limits are theirs. Bring them the fatal error line rather than the symptom.
Chapters in this Guide
The WordPress Email Delivery Checklist
Stop your WordPress emails from failing silently. Get the complete setup guide.
Muhammad Basim has worked in digital marketing since 2013, focused on email deliverability and AI-assisted content production. He is the author of The Email Deliverability Playbook and The Email Copywriting Playbook.
Related Articles
Choosing a WordPress SEO Plugin
This page names no winner, and the reason is that the choice matters far less than the category's marketing implies. The major WordPress SEO plugins do the same six things. They have converged, they will continue to converge, and the difference between them is interface preference and a small number of features most sites never […]
Two-Factor and Login Hardening for WordPress
Login attacks against WordPress are constant, automated and indiscriminate. Every public WordPress site receives them, regardless of size or traffic, because the cost of trying is near zero. They are also the least successful route into a WordPress site. Vulnerable plugins account for more compromises than password guessing, which is worth holding onto — login […]
WordPress Email: Why Your Site’s Emails Never Arrive
WordPress sends email in a way that fails modern authentication by default, and it reports success while doing it. That combination is why this problem is so persistent. The site is not broken. Nothing is logged. wp_mail() returns true, the order is placed, the form says thank you — and the message never reaches an […]