WordPress White Screen; Diagnose and Fix in Ten Minutes

WordPress White Screen; When Your Site Shows No Error

You open the site and only see a white screen. No 500 error message, no error text, nothing. The browser says "Connection established" and then nothing. This is the moment every site administrator's heart rate spikes, especially if the site is an online store and it's peak traffic time.

The WordPress White Screen of Death (WSOD) means PHP is running, but a fatal error has occurred before any output is generated. Error display is disabled on the screen, so you only see a blank page. The good news is that in 90% of cases, the problem is caused by a newly installed plugin or theme. The bad news is that you need to enable the right tools to find it.

First Step: Enabling WP_DEBUG via wp-config.php

Access the wp-config.php file in the root of your WordPress installation. Do this via FTP, your host's file manager, or SSH. Open the file and look for a line containing WP_DEBUG. If it doesn't exist, add these three lines just before the /* That's all, stop editing! Happy publishing. */ line:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

I deliberately set the third line to false. Why? Because when WP_DEBUG_DISPLAY is enabled, errors are displayed on the page and may break the site's HTML structure. We want errors in the log file, not on the screen.

Now save the file and reload the site. If it's still white, go to the wp-content/debug.log file. This file should now have been created. If it wasn't created, it means the error occurs before WordPress executes, and the problem lies elsewhere.

This Is Where People Make Mistakes

Many people open the wp-config.php file with a Windows editor like Notepad and save the file with the wrong encoding. The result? A "headers already sent" error or another white screen. Use an editor that preserves UTF-8 without BOM. Notepad++ or VS Code are reliable options. If the site completely stops working after saving the file, the file encoding has likely been corrupted.

Reading the Error Log; What to Look For

Open the debug.log file. Look for the latest error at the end of the file. A typical error looks like this:

[12-Nov-2025 14:32:11 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_current_user() in /home/user/public_html/wp-content/plugins/some-plugin/functions.php:15

Separate the three important parts of this error: the error type (Fatal error), the message (Call to undefined function), and the path of the culprit file (plugins/some-plugin/functions.php). The file path is what tells you who the culprit is.

If the path points to wp-content/plugins/, the problem is with a plugin. If it points to wp-content/themes/, the theme is at fault. If it points to WordPress core files, the core files are likely corrupted or incompatible with the server's PHP version.

Disabling Plugins Without Access to the Admin Dashboard

When the screen is white, the WordPress admin dashboard is also inaccessible. So you need to go in from the outside. The simplest way: via FTP or file manager, go to the wp-content/plugins/ folder and rename the folder of the plugin you suspect. For example, rename woocommerce to woocommerce-disabled. When WordPress doesn't find a plugin in its expected path, it disables it.

If you don't know which plugin is the culprit, rename the entire plugins folder to plugins-disabled. This disables all plugins. Open the site. If it loads, the problem is with one of the plugins. Now rename the folder back to its original name and disable/enable plugins one by one by renaming their folders until you find the culprit.

This method is crude but it works. WordPress stores plugin activation settings in the wp_options table of the database, not in files. So renaming the folder forces WordPress to assume the plugin is "missing" and disables it.

Second Method: Disabling via phpMyAdmin

If you don't have FTP access but do have phpMyAdmin, you can go in from that side. Go to the wp_options table and look for the row where option_name is active_plugins. The value of this row is a serialized array of active plugins. Replace the value with this expression:

a:0:{}

This means "empty array." All plugins will be disabled. If you're not familiar with ServerNet's documentation and knowledge base, do this with caution. Take a database backup before making any changes. Read the complete guide on working with phpMyAdmin in this article.

The Culprit Isn't Always a Plugin; Check PHP Memory

Another common scenario: the error Allowed memory size of 134217728 bytes exhausted. This means the script needs more memory than the allowed limit. WordPress's default limit is 128M, which equals 134217728 bytes. For heavy sites with WooCommerce or page builders, this amount isn't enough.

To increase the memory limit, add this line to wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

If this doesn't work, the problem is with the server's PHP settings. Check the memory_limit value in the php.ini file. On Linux hosting, you can usually change this value through the control panel.

An important note: endlessly increasing memory isn't the solution. If a site needs 512M of memory to run a simple page, there's a problem elsewhere. Usually, a heavy plugin or an unoptimized database query is the culprit. Increase the memory to get the site back up, but then look for the root cause.

When None of This Works; Error 500 and Server Logs

If the screen is still white after all these steps, bring server logs into the picture. On shared hosting, the error_log file is usually in the root of public_html. On virtual servers, depending on the configuration, you can use the following command:

tail -f /var/log/apache2/error.log

Or if you have nginx and PHP-FPM:

tail -f /var/log/nginx/error.log /var/log/php8.1-fpm.log

These logs show errors that PHP doesn't see: file access issues, timeout errors, or problems related to opcache. A common error is that the file owner doesn't match the user running PHP, and you get a Permission denied error.

Restoring to a Previous State; The Last Resort

If the site was working a few hours ago and is now white, and you haven't made any changes, there's a possibility of an attack or an automatic update. In this case, the best course of action is to restore from the latest backup. If you don't have a backup, you'll learn this lesson forever: take backups before any change, not after a disaster.

To prevent this from happening again, install an uptime monitoring plugin that will notify you if the site goes down. Read the practical guide on website uptime monitoring and set up a simple alert. Ten minutes of setup time prevents a sleepless night.

Frequently Asked Questions

Why doesn't my WordPress white screen show a 500 error?

Because the PHP settings on the server are configured so that error display is disabled. WordPress sees the error but cannot display it, so it delivers a blank page to the browser. Enabling WP_DEBUG and WP_DEBUG_LOG records this error in the debug.log file.

How can I disable plugins without access to the admin dashboard?

Via FTP or your host's file manager, rename the plugin's folder in wp-content/plugins/. WordPress assumes a plugin that isn't in its path is disabled. To disable all plugins, rename the entire plugins folder.

Where is the debug.log file and how do I find it?

After enabling WP_DEBUG_LOG, the debug.log file is created in the wp-content folder. If it isn't created, make sure the wp-content folder is writable. Its permission should typically be 755 or 775.

Can a WordPress update cause a white screen?

Yes. If a plugin is incompatible with the new WordPress version, an automatic update can take the site down. In this case, first disable all plugins and then enable them one by one to find the incompatible one. If your site is on managed WordPress hosting, you usually have tools for quick restoration.