Fix WordPress white screen of death: the actual culprit

The white screen of death stops your site cold, but it’s almost never what you think it is. Most fixes take 10 minutes—if you know where to look. Here are the five that actually work.

1. Enable Debugging to Reveal the Error

Debugging turns a blank page into something actionable. By revealing the underlying PHP error, you can identify whether a plugin, theme, or core file is at fault. In practice, you’ll often see a fatal error pointing to a specific plugin file or a missing function in a theme. This lets you triage quickly and avoid broad site changes.

How to turn on WP_DEBUG and WP_DEBUG_LOG

Access your WordPress files and add these lines to your wp-config.php file. They enable detailed error reporting without exposing messages to visitors. For a live site, keep WP_DEBUG_DISPLAY off to preserve a clean user experience.

• Define the debugging constants in wp-config.php
• Set WP_DEBUG to true when testing, then to false for live environments
• Enable WP_DEBUG_LOG to save errors to a log file

Setting	What it does	Where to place
define(‘WP_DEBUG’, true);	Shows errors on the page during testing	wp-config.php
define(‘WP_DEBUG_LOG’, true);	Saves errors to wp-content/debug.log	wp-config.php
define(‘WP_DEBUG_DISPLAY’, false);	Hides errors from visitors while logging remains active	wp-config.php

Interpreting the error messages in the logs

Open the debug log to locate the exact file and line causing the issue. Look for PHP fatal errors or warnings that reference a plugin or theme. Note the timestamp, file path, and error type to speed up the fix.

If the log points to a plugin, you can deactivate it and test the site again. If it points to a theme, switch to a default theme to confirm the culprit. For commercial sites with VIP-grade hosting, you can request a targeted rollback for the problematic plugin version within the last 24 hours.

2. Deactivate All Plugins to Isolate Conflicts

Plugins are a common source of WSoD. When you suspect a conflict, a quick deactivation helps confirm whether a plugin is at fault. If you run a business site, keep a backup handy and document which plugin version you test last.

Accessing plugin folders via FTP or hosting file manager

Use FTP or your hosting control panel to reach the WordPress installation. Navigate to the wp-content/plugins folder. This location holds every active plugin’s files. For a quick check, note the timestamp on recently updated plugin folders to infer recent changes.

• Connect with your FTP client or the file manager in your hosting panel.
• Open the plugins folder to view all plugin directories.
• Check for recent changes if you can access the admin area.

Renaming the plugins directory to deactivate all plugins and reactivating selectively

Renaming the plugins folder stops all plugins from loading, effectively deactivating them. You can then reactivate them one by one to pinpoint the cause. This approach works even on busy sites where admin access is sluggish.

• Rename the folder from plugins to plugins_old to deactivate all plugins at once.
• Test the site to see if the WSoD resolves, confirming a plugin culprit.
• Restore the original name and reactivate plugins individually from the admin dashboard to identify the offender.

3. Switch to a Default Theme to Rule Out Theme Issues

A faulty theme can trigger the white screen of death even when plugins are clean. Testing with a default theme isolates whether the problem comes from your current Theme.

How to change the active theme via the database or file system

Choose a safe, repeatable method to switch themes without admin access if needed.

• Database method: edit the option that stores the active theme in the wp_options table. Update the theme option to a known default theme slug, such as twentyTwentyFour.
• File system method: rename the active theme folder in wp-content/themes to disable it, then WordPress will fall back to a default theme if available.
• Verification: clear your browser cache and reload the site to confirm the default theme is in effect.

What to look for in theme-related fatal errors

Theme issues often surface as PHP errors tied to the theme’s files or functions.

• Check for errors in the theme’s functions.php or template files that reference missing functions or deprecated code.
• Look for problematic enqueues or syntax errors introduced by the theme update.
• Test with the default theme to determine if the WSoD reappears, which confirms a theme-level fault.

Practical steps to prevent future theme failures

Keep a local staging site where you install theme updates before applying them to production. This lets you catch fatal errors without affecting visitors.

• Run error reporting on the staging site and enable WP_DEBUG to surface notices that hint at compatibility issues.
• Audit customizations by wrapping functions in child-theme files to minimize core conflicts during updates.
• Document compatibility notes with PHP versions and plugin requirements to avoid surprises after updates.

4. Increase PHP Memory Limit and Adjust PHP Settings

When PHP runs out of memory, WordPress can show a white screen even if other parts are functioning. Raising the memory limit gives your site room to process requests, especially during busy periods or on feature-heavy setups like WooCommerce. If you run a store with 50+ products and a busy checkout, a small memory bump can prevent customer drop-offs during peak traffic.

Editing wp-config.php for memory limit

You can set a higher memory ceiling directly in WordPress’ config. This approach works even if the hosting control panel is limited. For a site with image-heavy pages, increasing memory by 256M can smooth image processing during backups or plugin updates.

• Open wp-config.php and add a line to define the memory limit.
• Common safe targets are 256M or 512M, depending on your host and needs.
• Test the site after saving to confirm the white screen of death does not reappear during page loads.

Understanding PHP configurations that commonly trigger WSoD

Beyond memory, several PHP settings influence stability. Knowing these helps you spot underlying issues faster. If a plugin adds large arrays or logs extensively, you may see timeouts or slow admin pages.

• max_execution_time: too low a value can cause scripts to time out on heavy requests; consider testing with 30, 60, or 120 seconds depending on workload.
• max_input_vars: insufficient input variables can break form submissions and admin saves; increase when you see repeated 400 errors on settings pages.
• memory_limit vs. script usage: ensure the memory_limit covers peak operations without over-allocating server resources; measure with real traffic spikes.

Setting	Impact	How to adjust
memory_limit	Directly affects how much memory PHP can use	Modify via wp-config.php or php.ini
max_execution_time	Prevents long-running scripts from hanging	Set higher value in php.ini or .htaccess
max_input_vars	Controls how many form fields are processed	Adjust in php.ini or server config

5. Restore or Replace Core Files and Corrupted Data

When core WordPress files become corrupted, the white screen of death can persist after other fixes. Restoring clean core files resets the baseline without touching your content.

Re-uploading WordPress core files safely

Use a fresh copy from the official source and replace only the core files. Do not overwrite wp-content or wp-config.php unless directed.

• Download the same major version you are running to avoid compatibility issues.
• Extract the package and delete the wp-content folder in the new copy to preserve yours.
• Upload the remaining files to your site via FTP or hosting file manager, overwriting existing files.

Verifying file integrity and repairing corrupted files

After replacement, verify that the critical core files are intact and not altered by mistake.

• Confirm that wp-includes and wp-admin folders contain expected files from the fresh package.
• Check for missing or altered PHP files that could trigger fatal errors.
• Run a quick page load test to ensure the site renders and the admin area responds.

Action	Purpose	Notes
Replace core files	Reset WordPress to a clean baseline	Keep wp-content and wp-config.php intact
Verify folders	Ensure wp-admin and wp-includes match the fresh package	Look for mismatched or missing files
Test access	Confirm the site loads without WSoD	Check both frontend and admin

FAQ

What if I can’t access admin or hosting files?

Blocked access often stems from WSoD or server security rules. Try offline debugging with a local copy of your site to reproduce the issue. For remote access, use a different device or network, and try FTP or the hosting file manager. If access remains blocked, contact your provider to confirm user permissions and any IP or firewall blocks in place.

How to prevent WSoD from recurring?

Apply concrete, repeatable safeguards to keep WordPress stable after fixes.

• Keep software current Regularly update WordPress core, plugins, and themes, and test updates on a staging site before pushing live.
• Limit plugins and review new ones on staging first, removing unused or conflicting plugins.
• Monitor error logs after changes for patterns and recurring issues.
• Ensure PHP memory_limit is sufficient and optimize image handling for high-traffic periods.

When to seek professional help?

Call in a professional when issues require server access, complex database work, or WSoD reappears after basic troubleshooting. Experts can run a full diagnostic, verify core integrity, and implement a resilient remediation plan with a documented rollback path.

Conclusion

Recap of the 5 fixes

These five steps provide a clear sequence to recover from the WordPress white screen of death. Start by enabling debugging to surface the underlying error, then deactivate all plugins to identify conflicts. If needed, switch to a default theme to rule out theme issues, raise the PHP memory limit to support heavier operations, and finally restore core files to establish a clean baseline. Use hosting tools to perform these checks without impacting content.

• Enable WP_DEBUG and WP_DEBUG_LOG to reveal the root cause, then check the log file for repeated errors over time.
• Deactivate plugins via FTP or hosting file manager to isolate conflicts, testing one plugin at a time to pinpoint the offender.
• Switch to a default theme to eliminate theme-related problems, and temporarily disable child themes if used.
• Increase memory and adjust PHP settings to address resource exhaustion, for example raising memory_limit and execution_time values in php.ini or hosting panel.
• Re-upload core WordPress files and verify integrity to restore a healthy baseline, using the official package checksum to confirm matches.

Best practices to maintain WordPress health

Adopt a proactive approach to reduce WSoD occurrences. Routine monitoring and careful change management are essential.

• Keep WordPress core, plugins, and themes up to date, and test updates on a staging site first, then propagate to production after a quick smoke test.
• Limit plugin usage and review each new add-on for compatibility before deploying live, aiming for a lean stack.
• Store a clean backup of wp-content and configuration files so you can recover quickly, schedule automated weekly backups, and verify restore procedures monthly.
• Allocate adequate PHP memory and use caching to improve resilience under load, consider object caching for high-traffic sites.
• Regularly review error logs and implement a structured rollback plan for failed changes, including a documented go-back point and a tested restore workflow.