WordPress White Screen of Death: How to Detect It Before Your Visitors Do

The error that shows nothing at all

Imagine this. A potential customer clicks on your Google listing. They are interested. They land on your site and see... nothing. A blank white page. No content, no menu, no error message. Just white.

They hit refresh. Still white. They assume your business is gone, or your site has been hacked, or you are not a serious company. They click back to Google and visit the next result.

You, meanwhile, have no idea this is happening. Your hosting dashboard says everything is fine. Your server is running. If you have basic uptime monitoring, it probably shows a green checkmark because your server is returning a response — it is just an empty one.

This is the WordPress White Screen of Death, and it is one of the most frustrating errors in the WordPress world. Not because it is hard to fix — it usually is not — but because it is almost impossible to detect without the right monitoring.

What actually causes the WSOD

The White Screen of Death happens when PHP encounters a fatal error before WordPress can render any output. WordPress tries to load, hits a problem, crashes, and the browser receives either an empty response or a minimal error message that is hidden by default.

Here are the most common causes, roughly in order of frequency.

1. A plugin update introduces a PHP error

This is the single most common cause of the WSOD. You update a plugin — or WordPress auto-updates it for you — and the new version contains a PHP error. Maybe it uses a function that does not exist in your version of PHP. Maybe it has a syntax error. Maybe it conflicts with another plugin.

The result is a PHP fatal error on every page load. WordPress cannot recover from a fatal error, so it outputs nothing.

How to fix it: Access your site via FTP or your hosting file manager. Navigate to /wp-content/plugins/. Rename the folder of the plugin you just updated (e.g., rename my-plugin to my-plugin-disabled). If the site comes back, that plugin is the problem. Contact the plugin developer or find an alternative.

2. Theme with broken code

The same thing can happen with themes, especially after a theme update or when switching to a new theme. A broken functions.php file is the usual culprit — one missing semicolon or one call to a nonexistent function, and the entire site goes white.

How to fix it: Via FTP, rename your active theme folder in /wp-content/themes/. WordPress will fall back to the default theme (Twenty Twenty-Four or whatever default is installed). If the site loads, your theme is the problem. Check the WordPress debugging documentation to enable debug mode and see the exact error.

3. PHP memory limit exhausted

WordPress and its plugins consume PHP memory. If a plugin is memory-hungry, or if you have many plugins running simultaneously, you can exhaust the PHP memory limit. When memory runs out, PHP kills the process and WordPress outputs nothing.

How to fix it: Add this line to your wp-config.php file:

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

If this fixes the problem, you have a memory issue. But increasing the limit is a temporary fix — you need to find which plugin is consuming excessive memory and address it. Some hosting providers also set a hard PHP memory limit in their server configuration, so you may need to contact your host if the wp-config.php change does not work.

4. Corrupted WordPress core files

Core WordPress files can become corrupted during a failed update, a server crash, or disk issues. If a critical core file like wp-settings.php or wp-includes/load.php is damaged, WordPress cannot initialise and the WSOD appears.

How to fix it: Download a fresh copy of WordPress from wordpress.org. Upload the wp-admin and wp-includes folders to your server, overwriting the existing files. This replaces all core files without touching your content, themes, or plugins (those live in wp-content).

5. PHP version incompatibility

WordPress and its plugins require specific PHP versions. If your hosting provider upgrades PHP (say, from 8.1 to 8.3) and one of your plugins has not been updated for the new version, you can get fatal errors and a white screen.

How to fix it: Check with your hosting provider to see if PHP was recently changed. Most hosts let you switch PHP versions from the control panel. Try downgrading to the previous version temporarily, then update the incompatible plugin or find an alternative.

Why normal monitoring misses the WSOD

Here is the critical detail that makes the White Screen of Death so dangerous: your server is still running.

When a PHP fatal error occurs, the web server (Apache or Nginx) still handles the request. It still returns an HTTP response. In many configurations, it returns a 200 OK status code — just with an empty body. Or it might return a 500 error, but only sometimes, depending on your PHP and server configuration.

A standard uptime monitor that checks HTTP status codes sees a 200 response and reports your site as "up." Your monitoring dashboard shows a green checkmark. Everything looks fine.

But your visitors see a blank page. Your site is technically up but functionally dead.

This is why keyword monitoring exists.

How to detect the WSOD with Uptrue

Uptrue's keyword monitoring solves this problem by checking what your page actually contains, not just whether the server responded. If your content disappears — for any reason — you know about it in under a minute.

Step 1: Set up a keyword monitor for your homepage

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor
3. Select Keyword as the monitor type
4. Enter your homepage URL
5. Set the keyword to something that always appears on your homepage — your site title, your tagline, a menu item, or a heading. Choose something stable that does not change often
6. Set the check type to "Page must contain"
7. Set the check interval to 1 minute
8. Configure alerts — Slack, email, or Microsoft Teams

When the WSOD hits, your homepage becomes blank. The keyword is gone. Uptrue detects the missing content within 60 seconds and sends you an alert.

Step 2: Monitor your critical pages too

The WSOD does not always affect every page. Sometimes it only hits pages that use a specific plugin or template. Set up keyword monitors for your most important pages:

• Homepage
• Contact page
• Pricing or services page
• Checkout page (if you run WooCommerce)
• Landing pages that receive paid traffic

For each page, choose a keyword that is unique to that page and always present.

Step 3: Add an HTTP monitor as a backup

1. Add an HTTP/HTTPS monitor for your homepage
2. Set expected status to 200
3. Set check interval to 1 minute

This catches the cases where the WSOD returns a 500 status code instead of a 200. Between the keyword monitor and the HTTP monitor, you have full coverage.

Step 4: Set up alerts that actually reach you

An alert that goes to a shared email inbox at 2am is an alert nobody reads until 9am. Configure your alerts to go where you will actually see them:

• Slack — if your team lives in Slack, alerts appear in a dedicated channel
• Microsoft Teams — same idea, different platform
• Email — good as a backup, but not for urgent issues
• Webhook — pipe alerts into your own systems, incident management tools, or PagerDuty

Step 5: Create a status page

If your site serves clients or customers, a public status page lets them check whether you are aware of the problem. When the WSOD hits and your monitors trigger, your status page updates automatically. This reduces the "is your site down?" messages and shows your users you take reliability seriously.

Preventing the WSOD before it happens

Monitoring catches the problem fast. But these habits reduce the chances of it happening in the first place.

Never update everything at once

Update one plugin at a time. Check your site after each update. If you update five plugins simultaneously and the WSOD appears, you do not know which one caused it. One at a time gives you a clear rollback path.

Keep a staging environment

Most managed WordPress hosts offer a staging site. Update plugins on staging first, verify everything works, then push to production. This is the single most effective way to prevent the WSOD.

Enable WordPress debug logging

Add these lines to wp-config.php:

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

This logs PHP errors to /wp-content/debug.log without showing them to visitors. When the WSOD hits, the log tells you exactly what went wrong — which file, which line, which function. The WordPress debugging guide explains all the debug options.

Check PHP compatibility before updating

Before your host upgrades PHP, check your plugins for compatibility. The Developer plugin and WP CLI can help you audit compatibility. If a plugin has not been tested with the new PHP version, wait until it has.

Maintain regular backups

A daily backup means you can restore your site in minutes instead of hours. Make sure backups are stored off-server — if your server has disk issues, you do not want your backups on the same disk.

Stop finding out from your customers

Your WordPress site could be down right now and you would not know.

Uptrue monitors your site every 60 seconds and alerts you on Slack, email, or Teams the moment something goes wrong — from full outages to subtle content changes that only a keyword monitor catches.

The White Screen of Death is invisible to standard monitoring. It returns a 200 status code with an empty page. Only keyword monitoring catches it — by checking that your content is actually there, not just that your server responded.

Uptrue checks your pages every 60 seconds. If your content disappears, you know in under a minute.

Frequently asked questions