WordPress Errors
WordPress White Screen of Death
Last reviewed
Direct answer
WSODA WordPress white screen of death almost always means PHP fatally crashed while error display is hidden from visitors. Enable logging (not on-screen display), disable plugins via FTP or file manager, switch to a default theme, and read debug.log plus host error logs to find the fatal — the blank page is a symptom, not the root cause.
A completely blank WordPress page usually means PHP crashed with display errors turned off. This guide shows how to capture the real fatal from logs, isolate plugins, themes, and must-use code, and restore the site without stacking random “white screen fixer” plugins on a crashing boot path.
What the error means
The White Screen of Death (WSOD) is WordPress returning little or no HTML — typically because a PHP fatal, parse error, or memory exhaustion occurred and the server hides error output from visitors. It can affect the front end, wp-admin, or both. Many hosts show WSOD instead of (or alongside) an HTTP 500 for the same underlying crash. Newer WordPress versions may show “There has been a critical error” when they can still render a message; WSOD appears when nothing useful is output.
Common symptoms
- Entirely blank white page with no WordPress or host error message
- Admin area also blank, or only wp-admin fails while the front end works (or the reverse)
- Site worked until an update, new plugin, theme edit, or PHP change
- RSS, REST API, or wp-cron requests return errors while HTML responses are empty
- Error logs contain “PHP Fatal error,” “Allowed memory size exhausted,” or parse errors
- A critical-error recovery email may arrive even when the browser shows only white
- Disabling one recently changed plugin or theme restores content immediately
Most likely causes
- 01 Plugin or theme PHP fatal error after an update or conflict
- 02 Syntax or logic error in functions.php or a custom code snippet
- 03 PHP version mismatch after a host upgrade (especially older plugins on PHP 8+)
- 04 Memory limit exhausted during bootstrap or on a heavy page
- 05 Failed auto-update leaving corrupt WordPress core or plugin files
- 06 Must-use plugin (mu-plugin) or drop-in fatalling on every request
- 07 Incomplete deploy or disk-full write that truncated PHP files
What changed before the problem started
- Plugin, theme, or WordPress core update (manual or automatic)
- New code snippet pasted into functions.php or a code-snippets plugin
- PHP version changed in the hosting panel
- Memory limit lowered, or a traffic spike exposing a memory leak
- Partial failed update, migration, or restore
- Security, caching, or optimization plugin change
Troubleshooting steps
- 01
Enable debug logging without showing errors to visitors
In wp-config.php set `define('WP_DEBUG', true);`, `define('WP_DEBUG_LOG', true);`, and `define('WP_DEBUG_DISPLAY', false);` plus `@ini_set('display_errors', 0);`. Reload the blank page once, then read `wp-content/debug.log`. Production visitors should never see raw PHP errors or file paths.
- 02
Check hosting error logs for the same timestamp
Open cPanel, Plesk, or your host’s error log around the moment you reproduced the white screen. The fatal often names the exact plugin file or theme path — far faster than blind folder renaming.
- 03
Disable all plugins via FTP or File Manager
Rename `wp-content/plugins` to `plugins.off`. If the site returns, the issue is plugin-related. Restore the folder name and rename individual plugin folders until you find the culprit. Settings stay in the database; you are only stopping code from loading.
- 04
Activate a default theme by renaming the active theme
Rename your active theme folder under `wp-content/themes` so WordPress falls back to a bundled default theme. For child themes, also test the parent if the child depends on broken parent code. Confirm both front end and wp-admin after each change.
- 05
Inspect functions.php and must-use plugins
Remove or comment recent custom code in the theme `functions.php`. Check `wp-content/mu-plugins` — must-use plugins load even when the regular plugins folder is renamed and are a common reason “I disabled everything and it’s still white.”
- 06
Verify PHP version compatibility as a diagnostic step
In the hosting panel, note the active PHP version. Older plugins on PHP 8.x often fatal. Temporarily select a previously working PHP version only to confirm the mismatch, then update or replace incompatible code rather than staying on an unsupported runtime forever.
When to stop troubleshooting
Get help when debug logs show core corruption you cannot safely replace, you are locked out of both admin and FTP/file manager, the white screen persists after plugin/theme/mu-plugin isolation, or WSOD hits during a launch or sale window. Hours of blind renaming on a revenue site is the wrong tradeoff — hand off with logs, timestamps, and backup details.
Information to collect before requesting help
- 01 Whether front end, wp-admin, or both are blank
- 02 Exact time you reproduced the issue
- 03 Excerpts from debug.log and the host error log
- 04 Recent plugin, theme, core, or PHP changes
- 05 PHP version and memory_limit
- 06 Whether renaming plugins, the theme, or mu-plugins changed anything
- 07 Whether a critical-error recovery email arrived
How a professional repairs the problem
A technician pulls the fatal from logs first, isolates the offending plugin, theme, mu-plugin, or PHP mismatch, restores clean core if needed, verifies memory and PHP version fit the stack, and confirms both front end and wp-admin before re-enabling optimization and security layers. They document the culprit so the next update does not recreate the outage.
Frequently asked questions
Why is there no error message on screen? +
Can WSOD affect only wp-admin? +
Will disabling plugins lose WooCommerce orders? +
Is WSOD the same as a 500 error? +
Is WSOD the same as “There has been a critical error”? +
Can a hosting outage cause WSOD? +
Repair dispatch
Still Need Help Fixing Your Website?
If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.
- You will receive a clear explanation of the likely cause.
- We will tell you if the issue falls outside our repair scope.
- No additional work will be performed without approval.
- A backup should be created whenever access and website condition allow it.
Do not share passwords through an unencrypted contact form.