Skip to content
Website Rescue Rescue

WordPress Errors

WordPress White Screen of Death

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

WSOD

A 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.

Intermediate

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

  1. 01 Plugin or theme PHP fatal error after an update or conflict
  2. 02 Syntax or logic error in functions.php or a custom code snippet
  3. 03 PHP version mismatch after a host upgrade (especially older plugins on PHP 8+)
  4. 04 Memory limit exhausted during bootstrap or on a heavy page
  5. 05 Failed auto-update leaving corrupt WordPress core or plugin files
  6. 06 Must-use plugin (mu-plugin) or drop-in fatalling on every request
  7. 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.”

  6. 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? +
Production servers usually hide PHP errors from visitors for security. That is why WSOD looks like “nothing happened” even when PHP fatally crashed — logs hold the real message.
Can WSOD affect only wp-admin? +
Yes. A plugin that loads only in admin can break the dashboard while the front end still works, or vice versa. Test both URLs after each isolation step.
Will disabling plugins lose WooCommerce orders? +
Disabling plugins does not delete orders or products stored in the database. Some front-end features will be unavailable until you reactivate the right plugins.
Is WSOD the same as a 500 error? +
Often the same root cause — a PHP fatal error. WSOD is what visitors see when errors are hidden; some hosts return HTTP 500 instead. Fix the underlying PHP issue for both.
Is WSOD the same as “There has been a critical error”? +
Related. WordPress may show the critical error screen when it can still render a message; WSOD appears when nothing is output. Both usually trace to a fatal in a plugin, theme, or PHP mismatch.
Can a hosting outage cause WSOD? +
Rarely. WSOD is almost always application-level PHP failure. If the host is down you typically see connection timeouts or 503, not a blank WordPress response with empty body from origin.

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.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.