A completely blank white page means WordPress's fatal error handler did not run — and that narrows the cause before you touch anything. Since WordPress 5.2, an ordinary fatal error produces "There has been a critical error on this website" plus a recovery email. A blank page means something prevented even that.
Three things cause it:
- PHP memory exhaustion — the script died before it could render an error
- An error very early in loading, before the handler was registered
- The handler was disabled, via
WP_DISABLE_FATAL_ERROR_HANDLER
That distinction matters because it changes where you look first, and almost every guide to this problem treats a blank page and a critical-error message as the same thing. They are not.
First: check which one you actually have
Look carefully, because the difference is the diagnosis.
| What is on screen | What it tells you |
|---|---|
| "There has been a critical error on this website" | The handler worked. Check your email for the recovery link |
| Completely blank, no text at all | The handler did not run. Memory, early error, or disabled handler |
| 500 Internal Server Error | The server rejected it — often .htaccess or a server-level limit |
| Blank on the front end, admin loads | A theme fault |
| Blank in the admin, front end loads | A plugin fault in an admin-only path |
View source on the blank page. If there is any HTML at all — a <head>, a partial page — the failure happened partway through rendering, which usually points at a theme or a plugin firing late. Genuinely empty source points at memory or a very early failure.
Take a backup first
Files and database. Everything below is reversible with one and permanent without one, and a broken site is precisely the situation where people skip this and regret it. The method is in WordPress backups: what most people get wrong.
The fix, in order
Six steps. Stop when the site returns.
Step 1 — Check your email, including spam
If a recovery link arrived, use it. WordPress will have paused the failing plugin or theme already, and you are done in a minute rather than an hour.
If nothing arrived, note that as a second problem to fix later. A site that cannot email you cannot send password resets or order confirmations either — see WordPress email.
Step 2 — Turn on error logging
In wp-config.php, above /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reload the broken page, then read wp-content/debug.log. The last entries name the file and line that failed, and the file path usually contains the plugin's own folder name — which is your answer.
Copy wp-config.php before editing it. A syntax error in that file takes the site down completely, which is a worse position than the one you are in.
Step 3 — Raise the memory limit
Memory exhaustion is the most common cause of a truly blank page, because a script that runs out of memory cannot render anything at all.
define( 'WP_MEMORY_LIMIT', '256M' );
WordPress defaults to 40MB for single sites and 64MB for multisite. Modern plugin stacks exceed that easily.
Your host's PHP limit is a separate ceiling. If raising WP_MEMORY_LIMIT changes nothing, the host's memory_limit is lower and only they can raise it.
Step 4 — Deactivate all plugins by renaming the folder
You cannot reach the admin, so do it over FTP or the host's file manager.
Rename wp-content/plugins to wp-content/plugins-off. WordPress deactivates every plugin it cannot find.
- Site returns — a plugin is the cause. Rename the folder back and reactivate one at a time. The safe method is in find a WordPress plugin conflict safely
- Still blank — rename it back and continue to step 5
Renaming the parent folder does not lose your settings. Plugin settings live in the database, not the folder.
Step 5 — Switch to a default theme
Rename your active theme's folder in wp-content/themes. WordPress falls back to a bundled default.
If the site returns, the fault is in the theme — most often a recent functions.php edit, and most often a stray character or an unclosed function.
If you have no default theme installed, download one from WordPress.org and upload it before renaming yours, or you will trade a blank page for a different failure.
Step 6 — Check .htaccess and the PHP version
For anything resembling a 500 error: rename .htaccess to .htaccess-old and reload. If that fixes it, the file was corrupt — go to Settings → Permalinks and save to regenerate a clean one.
PHP version mismatches break sites silently. A host upgrading PHP under an older plugin produces exactly this symptom. Your host's control panel shows the current version and usually lets you roll back temporarily — which buys you time to update the plugin properly rather than leaving PHP old permanently.
After it is fixed
Turn debugging off. Set WP_DEBUG back to false and delete wp-content/debug.log. WordPress's own guidance is that debug tools belong on local and staging installs — a growing log file is a disk-space problem and, if publicly reachable, an information leak.
Update the thing that broke, rather than leaving it deactivated and forgetting. A deactivated plugin is not a fix; it is a pause.
Fix the email, if the recovery message never arrived. That is the difference between the next incident taking five minutes and taking an afternoon.
Consider a staging site if this has happened more than once. Updating on staging first converts an outage into a non-event, and most decent hosts include one.
What not to do
Re-uploading WordPress core, first. It is a real fix for genuinely corrupted core files and it is rarely the cause. Try it after plugins and themes, not before.
Changing several things at once. You will not learn which one it was, and the next occurrence starts from zero.
Editing files through the WordPress admin. You cannot reach it, and it is the reason many of these faults exist — a stray character in functions.php saved through the built-in editor with no undo.
Deleting the plugins folder. Rename it. Deleting loses the plugin files, and reinstalling from scratch is a longer road back.
Leaving WP_DEBUG_DISPLAY on. It shows PHP errors, including file paths, to every visitor.
Frequently asked questions
What causes the WordPress white screen of death?
A truly blank page means WordPress's fatal error handler did not run — usually PHP memory exhaustion, an error occurring very early in loading, or the handler being disabled. Since WordPress 5.2, an ordinary fatal error instead shows "There has been a critical error on this website" and emails a recovery link.
Why did I get a blank page instead of the critical error message?
Because the error prevented WordPress from rendering its own error screen. Memory exhaustion is the most common reason — a script that runs out of memory cannot output anything, including an error page.
How do I fix a WordPress site I cannot log into?
Work over FTP or your host's file manager. Rename wp-content/plugins to deactivate all plugins at once, and rename your active theme's folder to force a default theme. Both are reversible and neither loses settings, which live in the database.
Will renaming the plugins folder lose my settings?
No. Plugin settings are stored in the database, not in the plugin folder. Renaming the folder deactivates the plugins; renaming it back makes them available again, and you reactivate them individually.
How much memory should I give WordPress?
WordPress defaults to 40MB for single sites and 64MB for multisite. Raising WP_MEMORY_LIMIT to 256M in wp-config.php resolves most memory-related blank pages. Your host's PHP memory_limit is a separate ceiling that this setting cannot exceed.
Where is the WordPress error log?
At wp-content/debug.log, once WP_DEBUG and WP_DEBUG_LOG are set to true in wp-config.php. Set WP_DEBUG_DISPLAY to false at the same time so errors are recorded without being shown to visitors.
Can a PHP version change cause a blank page?
Yes, and it is a common cause after a host upgrade. An older plugin or theme using removed PHP functions fails fatally. Your host's control panel shows the current version and usually allows a temporary rollback while you update the code properly.
Should I re-upload WordPress core files?
Only after ruling out plugins and themes. Corrupted core files do cause this, but far less often than a plugin conflict or a theme edit, and re-uploading core is a bigger intervention than the alternatives.
What to do next
Look at the page again and decide which of the three screens you actually have — critical error message, truly blank, or 500. That single distinction determines everything you do next, and most people skip it.
Then check your email. If a recovery link is sitting there, the rest of this is unnecessary.
Related guides
- When WordPress breaks: a diagnostic order — the full symptom-to-cause map
- Find a WordPress plugin conflict safely — once you know it is a plugin
- Locked out of WordPress admin? How to get back in — if the admin is the problem
- WordPress email: why your site's emails never arrive — why the recovery email never came
- WordPress backups: what most people get wrong — before you change anything
The short version
- Check your email, including spamIf a recovery link arrived, WordPress has already paused the failing plugin or theme and the job takes a minute.
- Turn on error loggingSet WP_DEBUG and WP_DEBUG_LOG true and WP_DEBUG_DISPLAY false in wp-config.php, reload the broken page, and read wp-content/debug.log. Copy wp-config.php before editing it.
- Raise the memory limitAdd WP_MEMORY_LIMIT of 256M. WordPress defaults to 40MB for single sites and 64MB for multisite, and the host's PHP limit is a separate ceiling.
- Deactivate all plugins by renaming the folderRename wp-content/plugins over FTP. Settings live in the database, so nothing is lost. Rename it back and reactivate one at a time.
- Switch to a default themeRename the active theme's folder so WordPress falls back to a bundled default. Make sure a default theme is installed first.
- Check .htaccess and the PHP versionRename .htaccess to .htaccess-old for 500-type errors and resave permalinks afterwards. Check whether the host recently changed PHP versions.
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 […]