Severity: Critical · Fix time: 15–60 min · Skill level: Intermediate

White Screen of Death (WSOD) is the informal name for a critical WordPress error that renders the entire website — or just the admin dashboard — as a completely blank white page with no visible content, no error message, and no indication of what went wrong. It’s one of the most disorienting errors a WordPress site owner can face because the browser appears to be working normally — the page simply never loads anything.

The WSOD is caused by a PHP fatal error that stops WordPress from executing before any content can be rendered. When PHP hits an unrecoverable problem — a memory shortage, a plugin conflict, a syntax error in theme code, a corrupted core file — it halts immediately, before any page template, header, or visible HTML has been output. The result is a blank response. In WordPress 5.2 and later, many PHP fatal errors instead display a “There has been a critical error on this website” message, but the underlying causes and fixes are identical.

Need a quick map of every WordPress error? See our 70+ WordPress Errors Guide → for a categorized reference of every common WordPress issue.

[Image: Split comparison showing a normal WordPress homepage on the left and a blank white browser window — the WSOD — on the right]

What Causes the White Screen of Death

The WSOD is a symptom, not a single cause. Identifying which specific failure produced the blank screen is the entire diagnostic task. The most common triggers:

  • Plugin conflict — A recently installed or updated plugin clashes with your WordPress version, PHP version, or another active plugin. This is the most frequent cause, particularly after automatic overnight updates. The conflict produces a fatal PHP error that halts execution before any page output.
  • Theme PHP error — A syntax error in the theme’s functions.php file — a missing semicolon, an unclosed bracket — crashes PHP before any output is produced. Incompatibility between a theme and the server’s PHP version produces the same blank result.
  • PHP memory exhaustion — WordPress gets a limited amount of server memory. Sites running WooCommerce, many plugins, or complex page builders frequently push against the default memory limit. When PHP runs out of memory mid-execution, it stops without outputting anything. This is the silent version of the Memory Exhausted Error.
  • Corrupted WordPress core files — A failed or interrupted WordPress update can leave core files incomplete. If the update timed out at a critical point, the resulting file state can prevent WordPress from loading entirely.
  • .htaccess corruption — A corrupted or invalid .htaccess file can block all requests before WordPress even begins executing, producing a blank response.
  • File permissions errors — After a migration or server change, incorrect file permission settings can prevent the web server from reading PHP files, resulting in a blank response.

Check This First — 2-Minute Diagnostic

  1. Test wp-admin access — Navigate to yourdomain.com/wp-admin. If wp-admin loads but the front-end is blank, the problem is almost certainly theme-related. If wp-admin is also blank, the problem is a plugin, a memory issue, or a corrupted core file.
  2. Enable WP_DEBUG — Connect via SFTP and add define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to wp-config.php. Reload the blank page. The debug log at /wp-content/debug.log will contain the exact PHP error and file path causing the WSOD.
  3. Check for recent updates — Did automatic updates run overnight? A plugin or WordPress core update that introduced a fatal error is the most frequent WSOD trigger. Check your plugin update history in the dashboard if you can access it.
  4. Try renaming .htaccess — If you can access neither the frontend nor wp-admin, connect via SFTP and rename .htaccess to .htaccess_old. If the site loads, regenerate .htaccess via Settings → Permalinks.
  5. Check available PHP memory — If you can access wp-admin, go to Tools → Site Health → Info → Server and check the PHP memory limit. If it’s 64MB or lower, memory exhaustion is a likely contributor.

Purpose & Benefits

1. Knowing the Diagnostic Steps Compresses Recovery Time

Most WSOD incidents are resolved within minutes for someone who knows the diagnostic sequence. Understanding that the blank page is a PHP execution failure — not a hosting outage, not a hack — points the investigation immediately toward plugin files, theme files, and memory limits rather than toward hosting support or security tools. The first diagnostic question (can you access /wp-admin?) alone splits the possible causes in half.

2. Preventing WSOD Through Proactive Habits

Most WSOD events are preventable. Testing plugin and theme updates on a staging site before applying them to production eliminates the most common cause. Maintaining automated daily backups ensures that even a worst-case WSOD can be resolved by restoring a known-good state within minutes, without losing content. Setting an appropriate PHP memory limit proactively (256M in wp-config.php) prevents silent memory exhaustion from producing blank pages. These habits don’t eliminate every WSOD risk, but they eliminate the vast majority.

3. Recognizing When the Fix Requires Professional Help

Some WSOD causes — corrupted core files, server-level PHP version incompatibilities, complex permission issues — require server access and developer experience to diagnose correctly. Knowing when to call for help saves time and prevents well-meaning troubleshooting from compounding the problem. If deactivating plugins and switching themes doesn’t resolve the WSOD, and the debug log points to a core file or server configuration, professional intervention is faster than continued DIY troubleshooting.

Examples

1. Plugin Update Causes WSOD Overnight

A WooCommerce store wakes up to a blank screen. Automatic updates ran overnight, and a payment gateway plugin now has a fatal PHP error due to a function removed in a recent PHP version upgrade. The admin dashboard still loads. Recovery path:

  1. Navigate to Plugins → Installed Plugins
  2. Sort by “Recently Updated” to identify the likely culprit
  3. Deactivate the recently updated plugin
  4. Confirm the site loads
  5. Contact the plugin developer, roll back to the previous version, and schedule the update test on a staging site before reapplying

2. functions.php Edit Breaks the Site

A developer adds a custom code snippet to the theme’s functions.php but misses a closing semicolon. The site goes white immediately. Because wp-admin is also blank, they connect via SFTP and check the debug log:

// Debug log reveals:
// Parse error: syntax error, unexpected 'function' (T_FUNCTION)
// in /wp-content/themes/your-theme/functions.php on line 23

// Navigate to functions.php via SFTP, open in a code editor
// Find line 23 — the line before it is missing a semicolon
// Add the semicolon and upload the corrected file
// Site loads immediately

The takeaway: always test code changes on a staging site. Use a code editor that highlights PHP syntax errors before the file is saved and uploaded.

3. PHP Memory Limit Reached on Category Pages

A WooCommerce store begins showing WSOD on specific category pages while other pages load fine. The cause: PHP memory exhaustion during complex product filter and query execution on those specific pages — pages with more database-intensive rendering than standard pages. Fix:

// Add to wp-config.php before "That's all, stop editing!"
// 256M is the standard recommendation — not 512M
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

After the memory limit increase, the affected pages load correctly. The longer-term fix involves optimizing the query load on those pages — reducing the number of simultaneous product filter queries — to reduce peak memory consumption.

Common Mistakes to Avoid

  • Assuming it’s a hack — A blank white screen is almost never caused by malware or an attack. It’s a PHP execution failure. Malware and hacking typically produce different symptoms: strange redirects, injected content, or 403/500 errors. Panicking and wiping the site before diagnosing the actual cause destroys a problem that may have been two minutes from being fixed.
  • Making multiple changes at once — When troubleshooting, change one thing at a time: deactivate one plugin, revert one file, adjust one setting. Making several changes simultaneously makes it impossible to identify what actually fixed the problem — or what made it worse.
  • Not enabling WP_DEBUG — This is the most common reason a WSOD takes hours to diagnose rather than minutes. Without debug logging, you’re guessing at the cause. The debug log at /wp-content/debug.log contains the exact PHP error, file path, and line number. Always enable it first.
  • Skipping a backup before applying updates — The majority of preventable WSODs occur on sites that applied a plugin or WordPress core update without a pre-update backup. A backup makes any WSOD a temporary inconvenience rather than a potential data loss event. Enable automatic pre-update backups in your backup plugin settings.

Best Practices

1. Always Test Plugin and Theme Updates on a Staging Site First

Before applying major plugin, theme, or WordPress core updates to a live site, test them on a staging site that mirrors your production environment. This is especially important for WooCommerce stores, membership sites, and any site where downtime has direct revenue consequences. If an update causes a WSOD on staging, you troubleshoot it there — without any visitor impact.

2. Maintain Automated Daily Backups Stored Offsite

A daily backup is the WSOD insurance policy. If a WSOD can’t be diagnosed quickly, restoring the previous day’s backup brings the site back online while you investigate the cause in a safer context. Store backups offsite — not just on the same server as the site. Most managed hosting environments include automated backup schedules as part of the plan.

3. Enable Error Logging (Not Display) on Production Sites

On a live site, WP_DEBUG_DISPLAY should be false — raw PHP error messages visible to visitors expose file paths and code structure. But WP_DEBUG_LOG should be true, writing errors silently to a log file you can access privately. When a WSOD happens, that log file tells you the exact cause within seconds:

// In wp-config.php — safe production debug configuration
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Never true on live sites

4. Bulk-Deactivate Plugins via SFTP When Dashboard Is Inaccessible

If the WSOD prevents wp-admin access, SFTP is the recovery path. Deactivate all plugins at once by renaming the plugins directory:

# Via SFTP: bulk-deactivate all plugins
# Navigate to /wp-content/
# Rename: plugins → plugins-disabled
# Reload the site — if it loads, a plugin was the cause
# Rename back to "plugins" to restore
# Then deactivate plugins individually from wp-admin to find the culprit

This eliminates plugin conflicts as a cause in one step, without having to access a broken wp-admin.

5. Set a Proactive PHP Memory Limit

Don’t wait for memory exhaustion to set the memory limit. Add the memory configuration to wp-config.php as part of every new WordPress site setup:

// Standard memory configuration — add to every WordPress site
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

This prevents silent memory exhaustion from ever producing a WSOD on a site that would otherwise have loaded successfully with a slightly higher limit.

Frequently Asked Questions

What causes the White Screen of Death most often?

Plugin conflicts — particularly those triggered by automatic updates — are the most frequent cause. A plugin update that introduces a PHP error or incompatibility with the current PHP version produces a fatal error that halts WordPress execution entirely. After plugin conflicts, the next most common causes are PHP memory exhaustion (especially on sites running WooCommerce or page builders) and functions.php syntax errors from manually adding code snippets.

How do I fix the WSOD when locked out of wp-admin?

You need SFTP access. Connect via SFTP or your hosting file manager. First, check /wp-content/debug.log for the error message (if you’ve enabled debug logging). If you haven’t, enable it by adding define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); to wp-config.php, then reload the blank page. The log will contain the exact cause. If it’s a plugin, rename /wp-content/plugins/ to deactivate all plugins. If it’s a theme file, rename the active theme’s folder to force WordPress to use a default theme.

Can the WSOD hurt my SEO?

Yes, while the site is down. A blank white page returns no useful HTTP response to search engine crawlers — they’ll record the URL as returning an error. Brief WSOD incidents (under a few hours) rarely cause lasting SEO damage. Extended WSOD situations — hours to days — can reduce crawl frequency and cause pages to temporarily drop from search results. Fast recovery, combined with submitting your XML sitemap through Google Search Console after the site is restored, minimizes the impact.

Is the WSOD the same as the “There has been a critical error” message?

Functionally, yes. Starting with WordPress 5.2, the fatal error handler attempts to display a “There has been a critical error on this website” message and send an email to the administrator rather than producing a pure blank screen. However, this recovery mode only works for errors caught after WordPress has begun bootstrapping. Errors that occur very early in the loading sequence — before the WordPress core is loaded — may still produce a pure blank white page. The critical error message and the WSOD have identical causes and fix paths.

Does WordPress 5.2+ still show a blank white screen?

Less often than older versions, but yes. WordPress 5.2’s fatal error recovery mode catches many PHP fatal errors and displays a message rather than a blank page. But it doesn’t catch errors that occur before WordPress itself has loaded — a corrupted wp-config.php, a corrupted core file, or a server-level PHP configuration problem can still produce a pure WSOD even on current WordPress versions.

Related Glossary Terms

How CyberOptik Can Help

Still broken? Our team fixes WordPress errors like this in under 30 minutes for maintenance clients. A White Screen of Death at the wrong moment — during a product launch, a high-traffic day, or a critical business period — costs real money and customer trust. Our WordPress maintenance plans include automated backups, staged update management, and priority support for exactly these situations. If your site is white right now, or if you want to make sure this doesn’t happen again, we can help. Contact us immediately if your site is down or learn about our WordPress maintenance services.