Why Is My Website Only Showing a White Screen? Fix It Now

By /



Disclosure: This post contains affiliate links. If you purchase through our links, we may earn a commission at no extra cost to you. We only recommend tools we’ve researched and believe are genuinely useful.

You hit refresh, and instead of your site, you get a blank white rectangle. No error message, no 404, nothing in the browser tab except the site’s title. Open the page source and it’s empty too — no HTML, no CSS, just void. This is what developers call the White Screen of Death, and it almost always means PHP hit a fatal error and your server is configured to hide it instead of showing it. That’s the fix — showing the error so you can actually read it — and it takes about two minutes once you know where PHP logs it. The white screen is a symptom. The cause is sitting in a log file you haven’t checked yet.

Key Takeaways

  • White screen errors typically stem from PHP memory limits, plugin conflicts, or theme incompatibilities requiring systematic debugging.
  • Enable WordPress debug mode immediately to reveal hidden error messages that pinpoint the exact cause of failure.
  • Increase PHP memory limit to 256MB or higher, the most frequent solution for white screen of death issues.
  • Disable all plugins one by one to identify which plugin triggers the white screen and causes site crashes.
  • Monitor server resources and maintain regular backups to prevent white screens and recover quickly from unexpected failures.

Quick Fix

Increase your PHP memory limit to 256MB by adding define(‘WP_MEMORY_LIMIT’, ‘256M’); to wp-config.php—this resolves the majority of white screen issues. If that doesn’t work, enable debug mode to see the actual error, then disable all plugins to isolate the culprit.

tail -f /var/log/php-errors.log

In This Article

  1. What the White Screen Means and When It Hits
  2. Enable WordPress Debug Mode to See the Actual Error
  3. Check PHP Memory Limit (Most Common Cause)
  4. Disable All Plugins to Isolate the Culprit
  5. Check for Theme Conflicts and PHP Errors
  6. Verify the Fix and Confirm the Site Loads
  7. Prevent White Screens: Monitoring and Backups

What the White Screen Means and When It Hits

The White Screen of Death (WSOD) isn’t a specific bug — it’s a catch-all for any fatal PHP error that stops execution before WordPress can render <html>. When PHP dies mid-request and display_errors is off (the default on most production hosts), you get nothing. No stack trace, no line number, just a blank tab. The failure happened; you just can’t see it.

Three moments trigger this almost every time:

  • Right after updating a plugin or theme — the new version calls a function that doesn’t exist yet in your PHP version, or conflicts with another plugin.
  • Right after editing functions.php or a template file directly — a missing semicolon or unclosed brace is fatal in PHP, not a warning.
  • During a traffic spike or large import — the process hits your host’s memory limit and PHP kills it mid-render.

If you can pin the white screen to one of those three moments, you’ve already narrowed the search. A site that broke immediately after you clicked “Update” on a plugin has a 90% chance of a plugin conflict. A site that broke after a manual code edit has a syntax error waiting in that exact file. Both are fixable in the next five minutes — but first you need PHP to actually tell you what happened, which means checking the log before you touch any code.

Enable WordPress Debug Mode to See the Actual Error

Before you disable a single plugin or roll back a single file, get PHP to talk. This applies to every WordPress version from 2024 onward — the debug constants haven’t changed. It takes two minutes and turns a blank screen into an exact file name and line number.

Add Debug Constants to wp-config.php

Connect over SSH and open the file in your site root:

ssh user@yourserver.com
cd /var/www/yoursite/public_html
nano wp-config.php

This opens wp-config.php for editing. Find the line that reads /* That's all, stop editing! Happy publishing. */ and paste these three lines directly above it:

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

WP_DEBUG_DISPLAY is set to false on purpose — you don’t want raw PHP errors dumped on a live page for visitors to see. Save with Ctrl+X, then Y, then Enter. If you’re on Windows without SSH access, connect via SFTP (FileZilla or WinSCP), download wp-config.php, edit it in Notepad++ or VS Code, and upload it back overwriting the original.

Nothing visibly changes on the site yet — that’s expected. What changes is that PHP now writes every notice, warning, and fatal error to a log file instead of silently dying.

Read the Debug Log in Real-Time

Reload the broken page once, then tail the log:

tail -f wp-content/debug.log

This streams new lines as they’re written, so you see the error the moment it fires. Look for three patterns:

  • PHP Fatal error — execution stopped here, this is almost certainly your white screen cause.
  • PHP Parse error — a syntax mistake in a specific file and line, usually from a manual edit.
  • PHP Warning — usually not fatal on its own, but worth noting if it repeats right before a fatal error.

Press Ctrl+C to stop tailing once you’ve got the message. On Windows, open the same file with WinSCP’s built-in editor or pull it via PuTTY’s pscp command and read it in a text editor. Copy the exact error text — you’ll match it against the fixes below.

Check PHP Memory Limit (Most Common Cause)

If your debug log shows PHP Fatal error: Allowed memory size of 134217728 bytes exhausted, you’ve found it. This is the single most common white screen cause for self-hosters — a plugin, theme, or media upload asked for more RAM than PHP was allowed to give it. Applies to PHP 7.4 through 8.3 and WordPress 5.8+.

Increase Memory via wp-config.php

This is the safest method because it only affects WordPress, not the whole server. Open the file:

nano wp-config.php

Add these two lines above the line that reads /* That's all, stop editing! Happy publishing. */, and before your WP_DEBUG constants if you added them earlier:

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

Save with Ctrl+X, Y, Enter. Reload the site. If this was the cause, the page loads normally and debug.log stops appending memory exhaustion errors.

Increase Memory via .htaccess (Apache Only)

This only works if you’re on Apache with mod_php — it does nothing on Nginx or PHP-FPM setups, where the directive gets ignored or throws a 500. Edit the file in your site root:

nano .htaccess

Add this line near the top, above the WordPress block:

php_value memory_limit 256M

Save and test with curl instead of a browser, so you see the raw HTTP status:

curl -I https://your-site.com

You want HTTP/1.1 200 OK. If you get 500 Internal Server Error instead, your host isn’t running mod_php — remove the line and use the php.ini method below.

Increase Memory via php.ini (VPS/Dedicated)

For anyone managing their own server, find the active config file first:

php -i | grep "php.ini"

This prints the loaded path, something like /etc/php/8.2/fpm/php.ini. Edit it:

nano /etc/php/8.2/fpm/php.ini

Find the memory_limit line and set it to memory_limit = 256M, then restart PHP-FPM matching your installed version:

systemctl restart php8.2-fpm

A clean restart returns no output and no error. Reload the site — this fixes the problem for every site on that server, not just one.

Disable All Plugins to Isolate the Culprit

If bumping memory didn’t fix the white screen, check debug.log again — if it’s quiet now (no memory errors) but the screen is still blank, a plugin is the likely cause. This is the culprit in roughly 60% of white-screen cases once memory is ruled out. You have two ways to disable plugins: through the database, or by renaming the plugins folder over SSH/FTP.

Disable Plugins via Database (Safer)

This is the better option if you have phpMyAdmin or SSH access to MySQL, because it doesn’t touch any files — just one row in wp_options. Run this via phpMyAdmin’s SQL tab, or from the command line:

mysql -u dbuser -p dbname -e "UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';"

This clears the serialized array WordPress uses to track active plugins, effectively deactivating all of them without deleting any files. Reload the site — the white screen should be gone and you’ll likely see a “plugins deactivated” notice in wp-admin. From there, reactivate plugins one at a time from the Plugins screen, reloading the front end after each, until the white screen comes back. That plugin is your culprit — delete or replace it.

Disable Plugins via File Rename (No Database Access)

If you don’t have database credentials — shared hosting with no phpMyAdmin, or a client site you only have FTP for — do it at the file level instead:

mv wp-content/plugins wp-content/plugins-disabled

WordPress can’t find any plugin files now, so it loads with everything disabled. Confirm the site loads, then restore the folder:

mv wp-content/plugins-disabled wp-content/plugins

Now rename individual plugin folders one at a time (mv wp-content/plugins/plugin-name wp-content/plugins/plugin-name-disabled) and reload between each. It’s slower than the database method but works entirely offline with no SQL knowledge required.

Check for Theme Conflicts and PHP Errors

If deactivating plugins didn’t clear the white screen, the problem is your theme — or a custom snippet living in it. This is especially common with child themes that override functions.php with hand-edited code and no syntax checking before upload.

Switch to Default Theme via Database

Same logic as the plugin fix: swap the active theme without touching any files. Run this via phpMyAdmin’s SQL tab or the CLI:

mysql -u dbuser -p dbname -e "UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template'; UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';"

This forces WordPress to load the default Twenty Twenty-Four theme instead of whatever’s currently active. Reload the site. If it comes back, your theme — or more likely a child theme built on top of it — is broken. Time to check the code directly rather than guess.

Check functions.php for Syntax Errors

Before touching anything in the editor, let PHP itself tell you where the break is:

php -l wp-content/themes/your-theme/functions.php

A healthy file returns No syntax errors detected in wp-content/themes/your-theme/functions.php. A broken one returns something like PHP Parse error: syntax error, unexpected '}' in wp-content/themes/your-theme/functions.php on line 214. Go to that exact line — 90% of the time it’s a missing semicolon, an unclosed bracket, or a stray closing ?> tag left over from a copy-pasted snippet. Fix it, re-run php -l, and don’t reload the browser until you get the “no syntax errors” message. This single check catches roughly 80% of custom code breaks, especially ones introduced right after a theme update or a “quick fix” snippet added from a tutorial.

Verify the Fix and Confirm the Site Loads

Once you’ve applied a fix, don’t just eyeball the homepage and call it done. Check the command line, the browser, and the debug log — all three. A white screen has a habit of coming back if you only checked one.

Test via Command Line and Browser

curl -I https://your-site.com

Expect HTTP/2 200 in the response headers. Anything in the 500 or 503 range means the server is still choking.

curl https://your-site.com | head -20

This should return actual HTML — a <!DOCTYPE html> tag, a <title>, opening <body> markup — not a blank response or a PHP fatal error dumped as plain text. Load the site in a browser too, and separately check your-site.com/wp-admin/index.php. A frontend that loads but a dashboard that’s still white points to a plugin that’s admin-only, so don’t skip this step.

Confirm Debug Log Is Clean

tail -50 wp-content/debug.log

A clean log shows either nothing new or only routine deprecation notices unrelated to your issue — no lines starting with PHP Fatal error, PHP Parse error, or PHP Warning tied to your theme or plugin files. If it’s quiet, you’re done.

Before deleting anything: this permanently erases the log history, so only run it once you’ve confirmed the site is stable.

rm wp-content/debug.log

WordPress will recreate the file automatically the next time an error occurs, so there’s no downside to clearing it once you’ve confirmed things are working.

Prevent White Screens: Monitoring and Backups

Set Up Persistent Error Monitoring

Don’t wait for the next white screen to find out something broke. Keep logging on permanently, but keep it off the frontend where visitors — and search engines — can see raw PHP errors. Edit wp-config.php:

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

This writes every notice, warning, and fatal to wp-content/debug.log without printing anything on the live page. Check it weekly, or better, script it:

grep -i fatal wp-content/debug.log

Any output here is a plugin or theme update quietly failing in the background before it takes down the whole site. If you’re running a client site or an agency stack of a dozen installs, wire this into a cron job that greps the log every hour and emails you on a match — a five-line bash script piped through mail or a Slack webhook is enough. Add a logrotate rule too, since an unrotated debug.log can grow past a gigabyte on a busy site and eat your disk quota silently.

Frequently Asked Questions

What causes a white screen on WordPress?

White screens usually result from exhausted PHP memory limits, incompatible plugins, theme conflicts, or fatal PHP errors. Enable debug mode to see the actual error message and identify the root cause quickly.

How do I fix the white screen of death?

First, increase your PHP memory limit to 256MB in wp-config.php. If that fails, disable all plugins and switch to a default theme. Then re-enable items one by one to find the culprit.

Why is my website showing blank white page?

A blank white page indicates a fatal PHP error, memory exhaustion, or plugin conflict. Check your server error logs and enable WordPress debug mode to reveal the specific error message causing the issue.

How do I enable debug mode in WordPress?

Add these lines to wp-config.php: define(‘WP_DEBUG’, true); and define(‘WP_DEBUG_LOG’, true);. WordPress will log errors to wp-content/debug.log, revealing the exact problem without displaying errors on your site.

Scroll to Top