In this article9 sections
The white screen of death is a blank page with no error message. WordPress has crashed before it could print anything, so the browser shows nothing at all. It is frightening, but the cause is almost always one of three things: a plugin or theme that throws a fatal error, a PHP memory limit that was reached during a request, or a PHP version that the code no longer supports. The fix is to find which one, and the method below does that in a fixed order, without guessing and without touching the database.
If your site runs on SiteHarbour’s WordPress hosting, the server handles PHP and memory for you, but the plugin or theme causes are the same on any host. The steps work on a cPanel account too.
Step 1: Turn on the error log
A blank page hides the error from the visitor, so the first job is to make WordPress write it to a file. Open wp-config.php in File Manager and add these lines above the line that says to stop editing:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Reload the blank page. Then open wp-content/debug.log. Expected: a line with PHP Fatal error, the file name and the line number. That line names the cause in most cases. Turn the debug settings off again when you have fixed the problem.
Step 2: Read the error and match it to a cause
The message tells you which fix applies:
- Allowed memory size of N bytes exhausted. The request ran out of PHP memory. The fix is in Step 4.
- Call to undefined function, or Call to a member function on null. A plugin or theme calls code that is missing or no longer loads. The fix is in Step 3.
- Parse error, or syntax error. A file has a typing error, often after a manual edit or an update that was interrupted. Restore that file from a copy.
- Something about an unsupported PHP version. The code needs a newer or older PHP. The fix is in Step 5.
Step 3: Disable the plugin that crashed
If the error names a plugin folder, such as wp-content/plugins/example-plugin/, disable it without the dashboard, because the dashboard may not load. Rename the folder in File Manager, or over SSH:
mv ~/public_html/wp-content/plugins/example-plugin ~/public_html/wp-content/plugins/example-plugin.offReload the site. Expected: the page returns. If it does, the plugin was the cause. Rename it back only after you have an update or a fix for it. Renaming all plugins at once is a valid test when the error does not name one. Put them back in groups to find the culprit.
If the error names a theme, switch to a default theme first. Rename the active theme’s folder in wp-content/themes, and WordPress falls back to the next installed theme, usually a default one such as Twenty Twenty-Four. Do not delete the theme until you have checked the cause.
Step 4: Raise the memory limit to test
If the error was a memory error, raise the limit once to confirm it is the cause. Add this line to wp-config.php above the stop-editing line:
define('WP_MEMORY_LIMIT', '256M');If the page returns, memory was the limit, and the real question is why the site needs so much. A plugin that loads large data on every request is a common cause. A higher limit is a temporary fix, and it uses more of the account’s share. Compare the causes in how to fix allowed memory size exhausted in WordPress.
Step 5: Check the PHP version
A plugin released for PHP 8.4 may crash on an older version, and an old plugin may crash on a newer one. Check the PHP version the site uses, and the minimum version the plugin or theme requires. Change the version in your hosting panel, then reload. Test on staging if the site earns money, because a version change affects every plugin at once.
Step 6: Restore from a backup if nothing else works
If the site still shows a blank page and the log is empty, a file may be corrupted. Restore the last known good copy of the file that changed most recently, such as functions.php in the theme or wp-config.php. A backup taken before the change makes this quick. If you have no backup, the full restore steps are in how to back up and restore a cPanel account.
Step 7: Turn debugging off and confirm
When the site works, remove the three debug lines from wp-config.php, or set WP_DEBUG_LOG to false, because the log can grow large and reveal file paths. Then load the home page, a post, the login and the admin dashboard. Check the log again after an hour.
Common mistakes
- Reinstalling WordPress first. That does not touch plugins or themes, and it hides the cause.
- Editing the database. A white screen is almost never a database problem, and database edits are hard to undo.
- Leaving debug on. A public debug log can show file paths and internal details.
- Deleting the plugin folder. Rename it instead, so you can restore it.
Frequently asked questions
Can I fix this from the WordPress dashboard?
Often not, because the dashboard is part of what breaks. The file-based steps above work without it.
Is my data lost?
Usually not. The white screen stops the page, not the stored content. Check the database through phpMyAdmin before you assume anything has been deleted.
Why only the admin area is blank?
A plugin that loads only in the admin, or an admin-only theme feature, can crash there. The debug log shows which file.
How do I stop it happening again?
Update on staging, keep plugins to what you need, and keep a backup taken before each update.
A white screen has a cause, and the debug log will name it. Turn on logging, read the error, then disable the plugin, adjust the memory limit or change the PHP version, one at a time. Keep the change small, and test it on staging before you repeat it on live, as shown in how to set up a WordPress staging site.