White Screen of Death

This guide helps you troubleshoot the WordPress “White Screen of Death” (WSOD), where your site or WordPress admin area shows a blank white screen instead of loading normally.

A WSOD usually means WordPress encountered a fatal error before it could render the page. Common causes include plugin errors, theme errors, PHP compatibility issues, memory exhaustion, or recent code changes.

Use this guide when:

• Your site shows a blank white screen.
• WordPress admin also shows a blank screen.
• The frontend is blank but the admin area still works.
• The issue started after a plugin, theme, WordPress, or PHP update.
• The issue started after a code or configuration change.
• Visitors cannot access the site because no page content loads.
• You see no visible error message, but the site is not rendering.

Important: If the affected site is in production, create or confirm a backup before making changes.

The page contains:

• Common symptoms of the WordPress White Screen of Death
• Common causes, including PHP fatal errors, plugin conflicts, theme issues, memory limits, and recent changes
• Diagnostic steps to identify the source of the failure
• Common issues and solutions
• Recovery options when WordPress admin is unavailable
• Verification checks after applying a fix
• Best practices for preventing future WSOD incidents
• Support guidance and related next-step articles

Common symptoms

The White Screen of Death usually appears in one of these ways:

• Blank white screen: The page loads as a blank screen with no visible content.
• No error message: The browser shows no helpful error on the page.
• Frontend unavailable: Visitors cannot view the site.
• Admin also affected: /wp-admin shows the same blank screen.
• Partial failure: Only some pages, templates, or admin screens are blank.
• Error after update: The issue appears after a plugin, theme, WordPress, or PHP update.
• Error after custom code change: The issue appears after editing a theme, plugin, or custom snippet.

Common causes

PHP fatal error

A PHP fatal error can stop WordPress before the page renders.

Common causes include:

• Plugin code errors
• Theme code errors
• Syntax errors
• PHP version incompatibility
• Missing files
• Function or class redeclaration errors
• Memory limit exhaustion

Plugin conflict

A plugin can trigger WSOD if it conflicts with another plugin, the active theme, WordPress core, or the PHP version.

This is more likely after:

• Installing a new plugin
• Updating a plugin
• Activating multiple plugins with overlapping functionality
• Enabling a plugin feature that changes frontend or admin behavior

Theme issue

A theme can trigger WSOD if a template, function, or dependency fails.

This is more likely after:

• Updating the active theme
• Editing theme files
• Updating a child theme
• Switching PHP versions
• Updating WordPress core
• Adding custom code to functions.php

Memory limit exceeded

A memory limit error can happen when WordPress, a plugin, or a theme uses more PHP memory than available.

This may happen during:

• Heavy plugin activity
• Large imports
• WooCommerce operations
• Page builder edits
• Background tasks
• Inefficient custom code

Recent code or configuration change

A recent change is often the fastest clue.

Check whether the issue started after:

• Plugin update
• Theme update
• WordPress core update
• PHP version change
• File edit
• Custom code snippet
• Migration or restore
• Cache or optimization change

Database-related issue

Some database errors can make WordPress fail before the page renders.

If you see database-specific messages or the site shows “Error establishing a database connection,” use the database troubleshooting guide instead.

Diagnostic steps

Step 1: Confirm the scope of the issue

Test:

• The homepage
• A few internal pages
• /wp-admin
• /wp-login.php

Then confirm whether:

• The whole site is blank.
• Only the frontend is blank.
• Only WordPress admin is blank.
• Only specific pages or templates are blank.

Step 2: Check recent changes

Review what changed before the WSOD started.

Check for:

• Plugin installation or update
• Theme update
• WordPress core update
• PHP version change
• Custom code change
• Migration or restore
• Cache or optimization setting change

If the issue started immediately after one change, investigate that change first.

Step 3: Check error logs

Review available error logs for fatal errors.

Look for entries that mention:

• PHP Fatal error
• Allowed memory size exhausted
• Plugin file paths
• Theme file paths
• Missing functions
• Missing classes
• Syntax errors
• Parse errors

The file path in the error usually points to the plugin, theme, or custom code causing the issue.

Step 4: Enable WordPress debug logging if needed

If the error logs do not show enough information, enable WordPress debug logging.

Add or confirm these constants in wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Then reload the affected page and check wp-content/debug.log.

Important: Keep WP_DEBUG_DISPLAY set to false on production sites so errors are logged instead of shown to visitors.

Step 5: Isolate plugins safely

If logs point to a plugin, or the issue started after a plugin change, test the suspected plugin first.

If the suspected plugin is unknown:

1. Confirm you have a recent backup.
2. Use staging if available.
3. Disable non-essential plugins one at a time.
4. Test the site after each change.
5. Stop when the site starts loading again.

Avoid bulk-disabling plugins on a live WooCommerce, membership, LMS, or business-critical site unless you understand the impact.

Step 6: Check the active theme

If logs point to the theme, or the issue started after a theme change, test the theme safely.

Check:

• Active theme version
• Child theme changes
• Recent edits to functions.php
• Template overrides
• Custom code snippets
• PHP compatibility

Use staging where possible before switching themes on production.

Common issues and solutions

The site is blank after a plugin update

Likely causes:

• Plugin update introduced a fatal error.
• Plugin conflicts with another plugin.
• Plugin requires a different WordPress or PHP version.
• Plugin code is incompatible with the active theme.

Resolution steps:

1. Check error logs for the plugin name or path.
2. Disable the affected plugin if it is identified.
3. Test the site again.
4. Roll back to a known working version if needed.
5. Contact the plugin developer if the fatal error is inside the plugin.

The site is blank after a theme update

Likely causes:

• Theme update introduced a fatal error.
• Child theme override is incompatible.
• Custom code conflicts with the updated theme.
• Theme requires a different PHP or WordPress version.

Resolution steps:

1. Check error logs for the theme name or path.
2. Review recent child theme or functions.php changes.
3. Restore the previous working theme version if needed.
4. Test the update on staging before reapplying it.
5. Contact the theme developer if the issue is isolated to the theme.

WordPress admin is also blank

Likely causes:

• PHP fatal error affecting all WordPress requests.
• Plugin or theme loads in both frontend and admin.
• Memory limit exhaustion.
• Custom code runs globally.

Resolution steps:

1. Check error logs first.
2. Identify the file path mentioned in the fatal error.
3. Disable the affected plugin or theme through file access if WordPress admin is unavailable.
4. Test /wp-admin again.
5. Contact Support if you cannot safely disable the affected component.

Only some pages are blank

Likely causes:

• Page template error.
• Page builder error.
• Plugin shortcode or block error.
• Custom field or template dependency issue.
• WooCommerce, LMS, or membership template conflict.

Resolution steps:

1. Identify the affected URLs.
2. Check whether affected pages use the same template, block, shortcode, or plugin feature.
3. Review logs while loading the affected page.
4. Disable or roll back the suspected component on staging.
5. Contact Support if the affected pages are business-critical.

Error logs show memory exhaustion

Likely causes:

• Plugin uses too much memory.
• Page builder operation is too heavy.
• Import, export, or background task exceeds available memory.
• Custom code creates inefficient loops or queries.

Resolution steps:

1. Note the memory error and file path.
2. Identify the plugin, theme, or operation involved.
3. Disable or optimize the component causing the memory error.
4. Reduce the size of the operation if possible.
5. Contact Support if the issue continues or requires a platform-level review.

Error logs show a syntax or parse error

Likely causes:

• Manual edit introduced invalid PHP.
• Custom code snippet is incomplete.
• Theme or plugin file was changed incorrectly.
• File upload or deployment was incomplete.

Resolution steps:

1. Identify the file and line number from the error log.
2. Revert the recent code change if possible.
3. Restore the file from a known good backup.
4. Test the site again.
5. Avoid editing production files directly.

The issue started after a PHP version change

Likely causes:

• Plugin does not support the selected PHP version.
• Theme does not support the selected PHP version.
• Deprecated or removed PHP functions are used.
• Custom code is incompatible.

Resolution steps:

1. Check error logs for compatibility errors.
2. Identify the plugin, theme, or code path involved.
3. Switch back to the previous working PHP version if needed.
4. Update or replace the incompatible component.
5. Test PHP changes on staging before applying them to production.

No clear error appears

Likely causes:

• Errors are not being logged yet.
• The issue occurs before WordPress fully loads.
• Cache or browser state is hiding the current response.
• The failure is intermittent.

Resolution steps:

1. Enable WordPress debug logging.
2. Clear cache and retest in a private browser window.
3. Reproduce the issue and check logs again.
4. Review recent changes.
5. Contact Support with timestamps and affected URLs.

Recovery options

Restore from a known good backup

Use this option when the site is down and you need the fastest path back to a working state.

Steps:

1. Restore a backup from before the WSOD started.
2. Confirm the site loads.
3. Identify the change that caused the WSOD.
4. Test the change on staging before applying it again.

Disable a problematic plugin

Use this option when logs identify a plugin or the issue started after a plugin change.

Steps:

1. Access the site files.
2. Go to /wp-content/plugins/.
3. Rename the suspected plugin folder.
4. Test the site.
5. Update, replace, or remove the plugin before enabling it again.

Switch away from a problematic theme

Use this option when logs identify the active theme or the issue started after a theme change.

Steps:

1. Access the site files.
2. Go to /wp-content/themes/.
3. Rename the active theme folder only if you understand the impact.
4. Let WordPress fall back to an available default theme, if one exists.
5. Test the site.
6. Restore or fix the original theme before switching back.

Important: Switching themes on a live site can affect layout, widgets, menus, templates, and theme-specific settings. Use staging when possible.

Verification

After applying a fix, verify that the site works correctly.

Check that:

• The homepage loads.
• Several internal pages load.
• /wp-admin loads.
• You can log in to WordPress.
• Error logs no longer show the same fatal error.
• The issue does not return after clearing cache.
• Critical pages such as checkout, login, forms, or membership pages work if relevant.
• The site works in a normal and private browser session.

Best practices

• Test plugin, theme, WordPress, and PHP updates on staging first.
• Create a backup before major updates or code changes.
• Update one plugin or theme at a time when possible.
• Check the site after each important update.
• Avoid editing production theme or plugin files directly.
• Keep unused plugins and themes removed.
• Keep at least one default WordPress theme available for recovery.
• Monitor error logs after updates or deployments.
• Keep a rollback plan ready for production changes.

Need help?

Contact Support if:

• The site is blank and you cannot access WordPress admin.
• You cannot identify the fatal error source.
• Error logs point to a platform, PHP, or server-level issue.
• The issue affects a business-critical page.
• You are not sure whether it is safe to disable a plugin or switch themes.
• The issue continues after restoring a backup or disabling the suspected component.

Include the following details:

• The affected domain.
• The affected URLs.
• Whether the frontend, admin area, or both are blank.
• The exact time the issue started.
• Recent plugin, theme, WordPress, PHP, or code changes.
• Relevant error log entries.
• Steps you already tried.
• A screenshot, if the blank page shows any visible output.

Where to go next

• Troubleshoot database-related failures: Database Connection Errors
• Troubleshoot plugin conflicts that can cause fatal errors: Plugin Compatibility Problems
• Troubleshoot theme-related display problems: Theme Display Issues
• Troubleshoot WordPress admin access problems: Admin Access Issues
• Enable WordPress debug logs: Enable WordPress Debug Logs
• Switch your PHP runtime if a PHP version change caused the issue: Switch Your PHP Runtime
• Restore a known good backup: Restore an Instant Backup
• Open a support request: Open Support Request