What Is the White Screen of Death?
The White Screen of Death (WSOD) is a WordPress failure where a page loads to a blank white screen with no content and no error message, leaving no clue what went wrong. It happens when a fatal PHP error stops the code before anything can render, usually caused by a faulty plugin or theme, a PHP memory limit being exhausted, or a coding error after an update. Because the screen gives no information, fixing it starts with enabling error logging or disabling recent changes to reveal the underlying fault.
- What you see
- A blank white page with no content and often no error text
- Underlying cause
- A fatal PHP error halts execution before the page renders (WordPress.org)
- Top triggers
- Faulty plugin or theme, exhausted PHP memory limit, bad code edit
- Key diagnostic
- Enable WP_DEBUG in wp-config.php to reveal the hidden error (WordPress.org)
- Fast test
- Disabling all plugins isolates whether a plugin is the cause
What the White Screen of Death is #
The White Screen of Death is the nickname for a WordPress failure where a page renders as nothing but a blank white screen, with no content, no layout, and frequently no error message to explain it. The name captures how unnerving it is: unlike a clear 404 or 500 page, the blank screen offers no clue about what broke. It occurs when a fatal error in the site's PHP code stops execution before WordPress can output anything to the browser. That halt can hit the front end, the admin dashboard, or both, and sometimes only a single page such as one plugin's settings screen. Because the screen itself is silent, the essential first move is to make the hidden error visible through logging or debugging, then address whatever it reveals. It looks catastrophic but is usually recoverable once you surface the cause. If a blank screen has taken your WordPress site offline, our /services/website-rescue team recovers exactly these situations.
Why the screen is blank #
The reason you see white and nothing else comes down to how PHP and web servers behave when a fatal error occurs. WordPress builds each page by running PHP code that assembles content and sends it to the browser. If a fatal error, such as calling a function that does not exist, running out of memory, or a syntax mistake, occurs partway through, PHP stops immediately. By default, many production servers are configured to hide error details from visitors for security, so instead of printing the error, they send an empty response, which the browser displays as a blank white page. This is actually a deliberate choice to avoid leaking sensitive information, but it leaves site owners in the dark. The cure is to temporarily turn on error display or logging so the underlying message appears, pointing you to the exact file and line at fault. Understanding this is the foundation of the debugging work our /services/wordpress-development team performs.
The most common causes #
The White Screen of Death almost always traces to one of a few sources. A faulty plugin is the most common: a plugin that is incompatible with your WordPress or PHP version, poorly coded, or conflicting with another plugin can throw a fatal error. A problematic theme does the same, especially after an update or a direct edit to its files. Exhausting the PHP memory limit is another frequent cause, where a heavy plugin or large operation needs more memory than the server allows, and PHP dies. Direct code edits gone wrong, a stray character in functions.php or wp-config.php, will blank the site instantly. Failed or interrupted updates to a plugin, theme, or WordPress core can leave broken code behind. Occasionally a server misconfiguration or corrupted core file is responsible. Because a plugin or theme is behind most cases, isolating those is the fastest route to a fix. Our /services/care-plans include managed updates that prevent many of these update-driven failures.
Making the hidden error visible #
Since the blank screen hides the real problem, your first diagnostic step is to reveal it by turning on WordPress debugging. Editing wp-config.php to enable WP_DEBUG and logging writes the underlying error to a file you can read, turning a silent failure into an actionable message.
<?php
// Add these lines to wp-config.php, ABOVE the line that says
// /* That's all, stop editing! */
define( 'WP_DEBUG', true ); // turn on debug mode
define( 'WP_DEBUG_LOG', true ); // write errors to a log file
define( 'WP_DEBUG_DISPLAY', false ); // hide errors from visitors
@ini_set( 'display_errors', 0 );
// Errors are written to: /wp-content/debug.log
// Reload the blank page, then open debug.log to read the fatal
// error, which names the exact file and line causing the crash.
// Remember to set WP_DEBUG back to false once fixed.
?>Isolating a plugin or theme conflict #
Because plugins and themes cause most white screens, systematically ruling them out is highly effective. If you can still reach the WordPress dashboard, deactivate all plugins at once; if the site returns, reactivate them one by one, reloading after each, until the culprit reveals itself. If you are locked out of the dashboard, do the same through your host's file manager or FTP by renaming the plugins folder, which forces all plugins off, then renaming it back and disabling plugins individually. To test the theme, switch to a default WordPress theme such as Twenty Twenty-Four; if the screen clears, your theme is the problem. This process of elimination reliably pinpoints the offending extension without needing to read a single line of code. Once identified, you can update, replace, or remove it. This kind of methodical conflict testing is routine for our /services/wordpress-development team, who resolve plugin and theme clashes without breaking the rest of the site.
Raising the PHP memory limit #
When debugging reveals an out-of-memory error, or the white screen appears only on heavy pages, an exhausted PHP memory limit is likely. WordPress and its plugins need memory to run, and demanding operations, importing data, running a page builder, or processing images, can exceed a low limit, causing PHP to halt and blank the page. You can raise the limit by adding a line to wp-config.php, editing the php.ini file, or asking your host to increase it. A common target is 256 megabytes, though the right value depends on your site's needs. If you constantly bump against the limit even after raising it, that usually signals an inefficient plugin or a site that has outgrown its hosting plan, since well-built sites rarely need extreme amounts of memory. Persistent memory pressure is a cue to optimize or upgrade rather than simply keep raising the ceiling. Our /services/managed-hosting team provisions appropriate memory and helps identify plugins that waste it.
Recovering from bad edits and failed updates #
A large share of white screens follow a change: a direct edit to a theme or core file, or an update that did not finish cleanly. If you just edited functions.php or another PHP file and the screen went blank, the fix is to undo that edit, ideally by restoring the file from a backup or removing the offending line via FTP, since even a single misplaced character causes a fatal error. If an update to a plugin, theme, or WordPress core triggered the blank screen, the offending component may be half-installed; reinstalling a fresh copy of that plugin or theme, or restoring the previous version, typically resolves it. This is exactly why backups and a staging environment matter: testing updates on a copy of the site first prevents these crashes from ever reaching visitors. Editing live code without a safety net is the riskiest habit in WordPress. Our /services/care-plans provide backups, staging, and managed updates so a bad change is always reversible.
Reading server logs when debug is not enough #
WordPress debug logging reveals most white screens, but when it does not, your host's server-level error logs are the next place to look. The web server and PHP keep their own logs recording fatal errors, memory exhaustion, and crashes, often with more detail than WordPress captures, including errors that occur before WordPress even loads. You can usually reach these logs through your hosting control panel or by asking your host, and they timestamp each failure so you can match it to when the blank screen appeared. Look for fatal error entries, out-of-memory messages, or references to a specific plugin or theme file, which point straight to the cause. Server logs are especially useful when the white screen affects the whole site including the dashboard, since WordPress-level debugging may not even run in that state. Combining WordPress debug output with server logs gives you the full picture of what stopped execution. Our /services/managed-hosting team reads these logs routinely to diagnose crashes that WordPress alone cannot explain, then applies the fix at the right layer.
Preventing the White Screen of Death #
You can dramatically reduce white-screen incidents with a few disciplined habits. Keep automated backups so any fatal error is a quick restore rather than a frantic debugging session. Test all updates and code changes on a staging copy before applying them to the live site, catching conflicts before customers see them. Keep WordPress core, themes, and plugins updated and remove anything you do not use, since abandoned plugins are a common source of incompatibility. Choose quality plugins from reputable sources, and avoid editing core or theme files directly; use a child theme or a code snippet plugin instead. Ensure your hosting provides adequate PHP memory for your site's real workload. When a white screen does appear, enable debugging first to see the true error, then isolate plugins and themes, and check memory. Because the whole site can be down, fast recovery protects revenue and trust. Our /services/care-plans and /services/website-rescue teams both prevent and rapidly resolve these failures.
FAQ
What is the White Screen of Death in WordPress?
It is a blank white page shown when a fatal PHP error stops WordPress before it can render any content, and usually no error message appears to explain it. It can affect the front end, the admin dashboard, or a single page. The most common causes are a faulty plugin or theme, exhausted PHP memory, or a bad code edit.
How do I fix the White Screen of Death?
First reveal the hidden error by enabling WP_DEBUG and logging in wp-config.php, then read the debug log. Next, isolate the cause by deactivating all plugins and switching to a default theme; reactivate them one by one to find the culprit. Also try raising the PHP memory limit and undoing any recent file edits or updates.
Why do I get a blank white screen with no error message?
Because many production servers are configured to hide error details from visitors for security, so instead of printing the fatal error, they send an empty response that shows as a blank page. Turning on WordPress debugging or PHP error logging makes the underlying message visible, revealing the exact file and line causing the crash.
Can a plugin cause the White Screen of Death?
Yes, a faulty, outdated, or incompatible plugin is the single most common cause. It can throw a fatal error that halts the page. To confirm, deactivate all plugins, either from the dashboard or by renaming the plugins folder via FTP, and see if the site returns. Then reactivate them one at a time to identify the offending plugin.
How do I fix a white screen if I am locked out of wp-admin?
Use your host's file manager or an FTP client. Rename the wp-content/plugins folder to disable all plugins at once; if the site returns, rename it back and disable plugins individually to find the culprit. You can also switch themes by renaming the active theme folder, and edit wp-config.php to enable debugging, all without dashboard access.
Does raising the PHP memory limit fix a white screen?
It fixes white screens caused by memory exhaustion, common on heavy pages or during large operations. Add a memory-limit line to wp-config.php or ask your host to raise it, targeting something like 256MB. But if you keep hitting the limit, an inefficient plugin or undersized hosting is the real issue, and optimizing or upgrading is the better long-term fix.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?