You open your WordPress site and see nothing — just a blank white page. No error message. No indication of what happened. Just white. This is the WordPress White Screen of Death (WSOD), and it is one of the most disorienting errors in the ecosystem precisely because it tells you nothing.
The problem can be on the front end, the back end, or both. Your admin panel may still work — or it may show the same blank screen. Visitors may be seeing it right now. And without knowing the cause, every fix attempt is a guess.
Why the White Screen Tells You Nothing
WordPress suppresses PHP errors by default in production mode. When a fatal error occurs, the page simply fails to render — resulting in a blank response. No stack trace. No error code. Just silence.
This is a deliberate security measure (publicly exposed PHP errors reveal your server configuration and file paths to anyone who looks), but it means that diagnosing WSOD requires access to server-level error logs that most site owners cannot easily reach through their hosting control panel.
The 7 Most Common Causes
1. Plugin conflict or fatal error
The most frequent cause. A plugin update introduces a PHP error — a missing function, a deprecated method, a naming conflict with another plugin. WordPress tries to load it, hits the error, and the page render stops entirely. Since WordPress loads all active plugins on every request, even a single broken plugin can take down the entire site.
2. Theme error
Themes can introduce the same class of PHP errors, particularly after a WordPress core update that removes or changes internal functions the theme was using. Custom themes — built by an agency years ago and never updated — are especially prone to this.
3. Memory limit exhausted
WordPress has a default PHP memory limit of 32–64MB. Poorly optimised plugins, large page builders, or sites that have grown significantly over time can exhaust this limit. When PHP runs out of memory mid-execution, the output is cut off — often producing a partial page or, more commonly, a white screen.
4. Corrupted core files
A failed or interrupted WordPress core update can leave critical files in a corrupt or incomplete state. The site's bootstrap process cannot complete. Nothing loads.
5. Bad wp-config.php edit
The wp-config.php file controls database connections, security keys, and environment settings. A single syntax error in this file — often introduced when someone manually edited it and accidentally deleted a character — produces a fatal parse error that prevents the entire site from loading.
6. Database connection failure
If WordPress cannot connect to the database — wrong credentials, database server down, corrupted tables — the result is usually an explicit error message, but in some configurations it produces a blank screen. Database issues are among the more difficult to resolve without direct server access.
7. Malware or injected code
Attackers frequently inject PHP code into WordPress core files, plugin files, or wp-config.php. If the injected code contains a syntax error or the malware payload itself triggers a fatal PHP exception, the site goes white. This is the scenario where ignoring the problem most directly costs you — the underlying infection remains even after the visible symptom is fixed.
Why Guessing Makes It Worse
The internet has no shortage of "WSOD fix" guides telling you to deactivate all plugins via FTP, switch to a default theme, or increase the memory limit in wp-config.php. These steps can work — but only when the cause is the specific one that step addresses.
Deactivating plugins when the cause is a corrupted core file wastes time and changes your site's state, making the eventual correct diagnosis harder. Editing wp-config.php when the cause is already a broken wp-config.php can permanently corrupt it. Increasing the memory limit when the cause is malware resolves nothing and leaves the infection in place.
Effective diagnosis starts with the error logs, not with guessing. Without reading the actual PHP error, you are troubleshooting blind.
What Recovery Looks Like
Resolving WSOD properly means reading the server-side PHP error logs, identifying the exact file and line causing the fatal error, and addressing the root cause — whether that is a broken plugin, a corrupt file, a memory issue, or an infection. If a clean backup exists from before the problem started, restoration is often the fastest path. If not, each cause requires a different resolution path, and the wrong one can complicate recovery significantly.
The time to sort this out ranges from 30 minutes (plugin conflict, clean backup available) to several hours (malware, no backup, corrupted database). For a site that is currently visible to customers, every minute it remains down has a direct cost.