WordPress white screen of death: how to fix it
Kofi Agyem, Founder and CEO, CloudzyroPublished · 6 min read
On this page
A blank WordPress page or critical error usually means a PHP fatal error. Turn on WP_DEBUG, find the plugin or theme, and fix memory or PHP version issues.
1. The short answer
The WordPress white screen of death is a blank page caused by a PHP fatal error that stopped WordPress before it could show anything. Usually a plugin or theme is to blame, or PHP ran out of memory, or the code needs a different PHP version. Turn on debugging to see the actual error, then turn off whatever it names.
Newer WordPress versions often show "There has been a critical error on this website" instead of a blank page. It's the same problem with a friendlier face, and the fixes are the same.
2. Why the screen goes white
WordPress is PHP. When PHP hits a fatal error, such as a call to a function that doesn't exist or running out of memory, it stops on the spot. With error display turned off, as it should be on a live site, the visitor gets nothing at all.
Since WordPress 5.2, fatal error protection catches most of these. It shows the critical error message and emails the site's admin address a link to recovery mode, which lets you sign in with the broken plugin or theme paused. Check that inbox, including spam, before anything else.
3. Common causes
- A plugin update or a new plugin with a bug, or one that clashes with another plugin.
- A theme that's broken, or a mistake in the theme's
functions.phpafter an edit. - PHP memory exhausted. The error reads
Allowed memory size of 134217728 bytes exhausted. Page builders, big imports and image processing are common triggers. - The wrong PHP version. An old plugin on new PHP, or a new plugin that needs a newer PHP than the site runs.
- A failed or half-finished update that left files missing.
- A white screen only in wp-admin points to a plugin that loads in the dashboard, or a memory limit hit there.
4. Step 1: Turn on debugging
Open wp-config.php in the site's folder and add these lines above the line that says to stop editing:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // keeps errors off the page
@ini_set( 'display_errors', 0 );Reload the broken page, then open wp-content/debug.log. The last PHP Fatal error line names the file and line, and the path tells you who's responsible: wp-content/plugins/some-plugin/... is that plugin; wp-content/themes/... is the theme.
When you're done, set WP_DEBUG back to false and delete debug.log, since anyone who knows the address can read it.
5. Step 2: Rule out plugins
If you can sign in to wp-admin, deactivate plugins there. If you can't, do it from the files:
- Open the site's files with cPanel's File Manager, an SFTP app, or SSH.
- Rename
wp-content/pluginstoplugins-off. WordPress can't find the plugins, so it turns them all off. - Reload the site. If it works, a plugin was the cause.
- Rename the folder back to
plugins. The plugins stay deactivated. - In wp-admin, activate them one at a time, reloading the site each time, until it breaks. That's the one.
If the log already names a plugin, rename just that plugin's folder instead. With SSH, WP-CLI is quicker, and --skip-plugins lets it run even when a plugin crashes WordPress:
cd ~/public_html
wp plugin list --skip-plugins --skip-themes
wp plugin deactivate some-plugin --skip-plugins
wp plugin deactivate --all --skip-plugins # all of them6. Step 3: Rule out the theme
If plugins weren't it, switch to a default theme. In the files, rename your theme's folder in wp-content/themes; WordPress falls back to an installed default theme, if there is one. With WP-CLI:
wp theme list --skip-plugins --skip-themes
wp theme activate twentytwentyfive --skip-plugins --skip-themesIf the site comes back, the problem is in your theme, often a recent edit to functions.php. Undo the edit, or restore the file from a backup.
7. Step 4: Raise the memory limit
If the log says Allowed memory size ... exhausted, give WordPress more memory in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' ); // the public site
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // wp-admin tasksWordPress can't go above PHP's own memory_limit. On cPanel, raise that in MultiPHP INI Editor. If a page keeps needing more and more memory, something is wrong with a plugin; raising the limit only buys time.
8. Step 5: Check the PHP version
If the white screen started after a PHP change, or the log mentions an undefined function or a syntax error in a plugin you didn't touch, it's probably the PHP version.
- In cPanel, open MultiPHP Manager and see which version the site uses.
- Switch back to the version that worked to get the site online.
- Update WordPress, the plugins and the theme, or replace any that are no longer maintained.
- Move up to a current PHP version again. Check WordPress's requirements page for the version it recommends today.
9. On Cloudzyro Web Hosting
Everything above works on Cloudzyro Web Hosting. Open cPanel from the console for File Manager, MultiPHP Manager and MultiPHP INI Editor. Every account also has SSH, a walled-off shell of your own, with WP-CLI (wp) and Git.
Sites can run PHP 7.4 to 8.4, chosen per site in MultiPHP Manager, so an older site can stay on an older version while you update it. In SSH, the php command is PHP 8.2; for another version, use commands such as ea-php83 or ea-php84. If an update went badly, cPanel's JetBackup keeps 30 days of backups you can restore yourself. More on PHP hosting.
10. How to check
# Does the page return an error status?
curl -I https://www.example.com
# The latest errors WordPress logged
tail -n 30 ~/public_html/wp-content/debug.log
# Can WordPress load at all without plugins and themes?
wp option get siteurl --skip-plugins --skip-themesA blank page often comes with a 500 status. Once the site loads, sign in to wp-admin, look under Tools, Site Health for warnings, turn WP_DEBUG off again and delete the log.