You click a link, wait, and get nothing. No error, no logo, no helpful message, just white. This is the WordPress white screen of death, and the good news is that it looks far worse than it is. Your content is almost certainly fine. Something in the code stopped partway through, and WordPress had nothing left to show.
This guide to the WordPress white screen of death walks through the fixes in the order that costs you the least. We start with the one that needs no technical skill at all, and we finish with the point where restoring a backup is smarter than digging further.
What the WordPress White Screen of Death Really Means
The blank page is a symptom. Behind it sits a PHP fatal error, which is PHP's way of saying "I cannot continue." When that happens in the middle of building a page, the server often sends back whatever it had so far, which is nothing.
Production servers hide error text on purpose, because showing code paths to strangers is a bad idea. So you get silence, and the real message sits in a log file waiting to be read.
The usual causes, roughly from most to least common:
- A plugin that crashed, often right after an update or a new install.
- A theme problem, especially an edit to
functions.phpor a theme update that needs a newer PHP version. - A PHP version change by your host, which can leave older code that no longer runs.
- A memory limit reached by a heavy page or import.
- An update that stopped halfway, leaving the site stuck in maintenance mode.
- Damaged files or a bad edit, including injected malicious code.
Key takeaway: A blank screen means PHP stopped, not that your data vanished. Posts, pages and settings live in the database, and a crashed plugin rarely touches it.
Before changing anything, think about what you did last. A plugin update ten minutes ago is a far better lead than any list of possible causes.
Step One: Check for the Recovery Mode Email
Since WordPress 5.2, the software tries to catch fatal errors for you. When one happens, visitors see a message that the site is experiencing technical difficulties, and the admin email address receives a message describing the problem. You can read the design in the WordPress core team's recovery mode announcement.
That email contains a special link. Opening it starts recovery mode for your browser only: the plugin or theme that caused the crash is paused for you, so you can sign in and reach the dashboard while everyone else still sees the problem.
Here is what to do:
- Search your inbox (and spam folder) for a message from your own site about a technical issue. It goes to the address set under Settings, then General.
- Open the link and sign in.
- Read the notice at the top of the dashboard. It names the plugin or theme and quotes the error.
- Deactivate the extension, or update or replace it, then use the exit button in the admin bar.
If that email never arrives, do not worry. Mail from a struggling site often goes missing, and the admin address may be one you no longer check. Move on to the next step.
Turn On the Debug Log to See the Real Error
Guessing is slow. Reading the actual error takes two minutes. WordPress has a debug mode controlled by constants in wp-config.php. The official debugging guide explains each one: WP_DEBUG turns it on, WP_DEBUG_LOG writes errors to a file, and WP_DEBUG_DISPLAY decides whether they also appear in the page.
Open wp-config.php in your host's file manager or over SFTP. Just above the line that says to stop editing, add this:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reload the broken page once, then open wp-content/debug.log. The last lines usually say something like this:
PHP Fatal error: Uncaught Error: Call to undefined function ...
in /wp-content/plugins/some-plugin/includes/helper.php on line 42
The path is the clue. plugins/some-plugin points at the plugin, themes/your-theme at the theme. If it says "Allowed memory size exhausted", jump to the memory section below. If the path points at a file you do not recognise, treat that as a possible sign your site has been hacked.
The WordPress documentation says debug mode is meant for local or staging copies, not for live sites you leave running. So when you have what you need, remove those three lines or set WP_DEBUG back to false. An old debug log can also contain file paths you would rather not leave lying around.
Disable Plugins by Renaming the Folder
If you cannot sign in and have no recovery email, you can switch off every plugin without touching the dashboard. WordPress only loads plugins from the wp-content/plugins folder, so if that folder disappears, the plugins stop loading.
- Connect over SFTP or open your host's file manager.
- Go to
wp-content. - Rename
pluginstoplugins-off. - Reload your site and the login page.
If the site comes back, a plugin was the cause. Rename the folder back to plugins, and the plugins will show as deactivated in the dashboard. Reactivate them one at a time, reloading after each, until the blank screen returns. The last one you switched on is your culprit.
You can do the same thing for a single plugin by renaming only its folder, which is faster when the debug log has already named it.
Pro tip: Write down which plugin you suspect before you fix it. If it is one you rely on, check whether the author has a newer version or a support thread, rather than just leaving it off for good.
Switch to a Default Theme
If plugins are not the cause, try the theme. Many blank screens come from a theme update or a recent change to functions.php.
Over SFTP, go to wp-content/themes and rename your active theme's folder, for example my-theme to my-theme-off. WordPress will fall back to a default theme such as Twenty Twenty-Five, provided one is installed. If none is, upload a fresh copy of a default theme first.
If the site returns, the problem is in your theme. If you edited its files yourself, look at the lines you changed. A missing semicolon or a stray bracket is enough to crash everything. Child themes help here, because your edits live in a small separate theme that you can undo.
Memory, PHP Versions and Failed Updates
Three more causes of the WordPress white screen of death catch people out, because nothing on the site itself changed.
Memory Limits
PHP gives each request a fixed amount of memory. When a page needs more, it stops, and you may see a blank screen with this line in the log: "Allowed memory size of ... bytes exhausted."
WordPress documents a WP_MEMORY_LIMIT constant on its wp-config reference. By default WordPress tries to raise the limit to 40MB for a single site, and the page notes some hosts allow far less. You can ask for more:
define( 'WP_MEMORY_LIMIT', '256M' );
Use this carefully. The same documentation warns that raising the limit can hide the underlying problem. If a plugin needs more and more memory, something is wrong with that plugin, and a bigger number only delays the next crash. Treat a higher limit as a patch while you find the real cause, and ask your host if they cap memory above WordPress.
A PHP Version Change
Hosts move customers to newer PHP versions, sometimes automatically. Code written years ago may use features that were removed. The site worked on Friday, the host upgraded PHP over the weekend, and now it is white.
Check your host's control panel for the PHP version. Switching back one version often brings the site up immediately, which proves the diagnosis. Then do the proper fix: update the plugin or theme that is too old, or replace it. Staying on an old PHP version forever is a security problem in itself, because old versions stop receiving fixes.
A Failed Update and the .maintenance File
When WordPress updates itself, a plugin or a theme, it briefly puts the site into maintenance mode by creating a file called .maintenance in the site's main folder. If the update is interrupted, the file can stay behind, and visitors see a maintenance message or a blank page for as long as it sits there.
Look for .maintenance in the same folder as wp-config.php. It is a hidden file, so turn on "show hidden files" in your SFTP client or file manager. Delete it and reload.
If the update was cut off in the middle, the plugin or theme may be half-installed. Delete that plugin's folder and reinstall a clean copy from the official source. Do the same for WordPress core if the update that failed was a core one.
When to Restore a Backup Instead
Troubleshooting a WordPress white screen of death is satisfying, but it is not always the best use of an hour. A restore is the better call when:
- The site broke right after a change you can name, and undoing that change does not help.
- The debug log shows several errors or files you do not recognise.
- You have been at it longer than you planned. Set a time limit before you start, say thirty minutes, and honour it.
- The site is earning money or sending enquiries while it is down.
A restore trades the last few changes for a working site. That is usually a fine deal, but it only works if you have a backup that is recent and that you trust. Our guide to restoring WordPress from a backup goes through the steps and the traps, such as database changes made after the backup was taken.
| Situation | Best first move |
|---|---|
| Broke right after a plugin update | Recovery email or rename that plugin's folder |
| Blank admin, front of site fine | Debug log, then theme and plugin screens |
| Memory error in the log | Raise the limit briefly, then find the cause |
| Site stuck after an update | Delete .maintenance, reinstall the half-updated item |
| Unknown files in the error | Scan for malware before restoring |
| Several changes and no clear cause | Restore a recent verified backup |
If you do not yet have a backup routine, start with how to back up a WordPress site. It takes ten minutes to set up and saves the worst afternoons.
How Stack Guard Helps When the Screen Goes White
Stack Guard cannot fix a plugin that crashes, and no security plugin can. But it helps in two ways.
It will not trap you outside your own site. If a Stack Guard setting such as a custom login address, two-factor or a ban keeps you from signing in, the recovery switches work in every plan. You add a single line to wp-config.php, for example define( 'SMG_SAFE_MODE', true );, and Stack Guard switches off the things that could keep you out, including Login Guard, two-factor, lockouts, bans, country blocking, firewall rules and CAPTCHA. Your settings are not changed, and everything returns when you remove the line. If you only forgot the custom address, the narrower SMG_DISABLE_LOGIN_GUARD switch is enough. You can read how the sign-in side works in the Login Guard documentation.
It gives you something to go back to. Stack Guard Free backups can be full or database only, and each one is read back and verified before it counts. A restore is one click and is staged: the backup is unpacked and checked before anything live changes, and afterwards you have 7 days to keep the restore or roll back to how the site was just before it. That safety net is worth having before you update a plugin. Backups are manual today. Scheduled backups and Google Drive storage are coming soon.
One honest limit: a restore only works onto the same site address the backup was made from. Moving a site to a new address is not supported yet.
A Calm Order for Fixing the WordPress White Screen of Death
Next time the screen goes white, run through this list and stop when the site returns:
- Think about the last change you made.
- Check your email for the recovery mode link.
- Turn on the debug log and read the last error.
- Rename the named plugin's folder, or all plugins if you cannot tell.
- Switch to a default theme.
- Look at the memory limit, the PHP version and the
.maintenancefile. - Decide whether a restore would be quicker.
Then do the part that stops it happening again: take a backup before every update, and try updates on a copy first. We cover how to set one up in our guide to a WordPress staging site. A copy where the screen can go white without anyone noticing is a cheap way to stay calm.