A blank white screen or a 500 error when opening a WordPress site means the same thing: PHP crashed before it could send any HTML to the browser. Here is how to find the cause in 15 minutes and get the site back online without reinstalling WordPress from scratch.
What a white screen and a 500 error in WordPress mean
The "White Screen of Death" appears when a PHP script ends with a fatal error while on-screen error output is turned off — the default setting on production servers. A 500 Internal Server Error is essentially the same thing, except the message is generated by the web server instead of WordPress itself.
Both problems almost always share the same causes: a plugin or theme conflict after an update, PHP running out of memory, a corrupted .htaccess file, or a syntax error in code after manually editing functions.php. The first step is to turn on logging and read the actual error text instead of guessing.
How to turn on the error log in wp-config.php
Open the wp-config.php file in the site root and add three constants before the line /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
After this, WordPress stops showing the error on screen to visitors but writes the full call stack to wp-content/debug.log. You can view the latest log lines with:
# Show the last 50 lines of the error log
tail -n 50 wp-content/debug.log
Look for a line with PHP Fatal error — it names the file and line number where the crash happened. Usually the path is inside wp-content/plugins/ or wp-content/themes/.
How to find the culprit among plugins and themes
If the log points to a specific plugin, rename its folder through FTP or the hosting panel's file manager, for example plugin-name to plugin-name-off. WordPress will see the plugin file is missing and automatically deactivate it without needing admin access.
It is faster to do the same through WP-CLI if it is available on the server:
# Deactivate all plugins at once
wp plugin deactivate --all
# Activate plugins one by one, checking the site after each
wp plugin activate plugin-name
For more plugin and theme management commands from the terminal, see the article WP-CLI: managing WordPress from the command line. If the site starts working after deactivating all plugins, the problem is one of them — activate them one at a time until the error returns.
If plugins are not the issue, switch the theme to a default one:
wp theme activate twentytwentyfour
500 error caused by insufficient PHP memory
A log line reading Allowed memory size of 134217728 bytes exhausted means the script ran past its memory_limit. The value 134217728 bytes equals 128 MB, the standard limit on many plans. You can raise it in three places, in order of priority:
| File | Line | When to use it |
|---|---|---|
| wp-config.php | define( 'WP_MEMORY_LIMIT', '256M' ); | works almost always, top priority |
| .htaccess | php_value memory_limit 256M | only if PHP runs as an Apache module |
| php.ini / hosting panel | memory_limit = 256M | if you have access to PHP settings in the panel |
256 MB is enough for most WooCommerce sites and heavy page builders. If the error persists after raising the limit, the cause is not memory but an infinite loop or recursion in a plugin's code.
Problems with .htaccess and file permissions
A 500 error with no entry in debug.log almost always means a corrupted .htaccess. Rename the file to something like .htaccess-old and open the site again:
# Temporarily disable .htaccess
mv .htaccess .htaccess-old
If the site opens, create a new file by going to "Settings → Permalinks" in the admin panel and clicking "Save Changes" — WordPress regenerates the rules automatically. The second common culprit is wrong file permissions. The correct values for WordPress are:
# Folders get 755, files get 644
find /var/www/site/public_html -type d -exec chmod 755 {} \;
find /var/www/site/public_html -type f -exec chmod 644 {} \;
White screen diagnostic checklist
Before calling hosting support, go through these points:
- Enabled
WP_DEBUG_LOGand checkedwp-content/debug.log. - Deactivated all plugins via FTP or WP-CLI and checked the site again.
- Switched the theme to a default one (Twenty Twenty-Four).
- Raised
memory_limitto 256M in wp-config.php. - Checked
.htaccessand permissions of 755/644.
If you made a backup before the last update, it is often faster to roll back than to hunt for the cause manually; the restore procedure is described in the article WordPress backup: UpdraftPlus and the manual method. And to stop white screens from appearing after every plugin update, set up a safe process — it is covered in the article Safe WordPress updates: procedure and rollback.