WordPress white screen of death

How to Fix the WordPress White Screen of Death

To fix the WordPress white screen of death, identify the failing component, disable or repair it, then clear cached pages. Start with a recoverable backup, because speculative edits can make recovery harder.

A blank homepage and a blank dashboard can have different causes, even when they look identical. Follow the steps below in order, making one change at a time and retesting the exact failing request.

Key takeaways

  • Back up files and the database before changing settings, and preserve recent orders or enquiries.
  • Use Recovery Mode and timestamp-matched error logs to identify likely causes.
  • Test plugins, themes and hosting settings separately. Restore an older backup only after protecting newer data.

1. Diagnose the WordPress white screen of death

Download your WordPress files and export the database through your hosting panel. Include wp-content, wp-config.php and hidden files such as .htaccess. Keep the copy outside the hosting account without overwriting your last working backup.

Next, open the homepage, an affected internal page and /wp-admin/ separately. Record the time and recent changes.

Use the scope to choose your starting point.

SymptomFirst investigation
Entire site and dashboard blankPHP logs, plugins, recent updates
Admin dashboard blank, public pages workAdmin request errors, memory, plugins
Only one page blankIts template, builder or page-specific plugin
Failure after a PHP changePHP compatibility
Maintenance message after updatingLeftover .maintenance file

A cached homepage can conceal a sitewide PHP failure, so test uncached actions too.

A person sitting at a desk looking at a computer monitor displaying a blank white screen.

Since WordPress 5.2, some fatal errors display a “critical error” message instead of an empty page. Both can require the same troubleshooting.

2. Recover access and reveal the hidden error

Try WordPress Recovery Mode

Check the administrator email inbox, including spam, for a WordPress fatal-error notification. Follow its protected Recovery Mode link.

Recovery Mode can pause the faulty plugin or theme for your session, allowing dashboard access. Deactivate the identified component, then test outside Recovery Mode. Pausing it doesn’t repair it for visitors.

If no email arrives, continue through your hosting file manager or SFTP, the encrypted alternative to FTP.

Enable debug logging safely

First inspect the PHP or web-server error log in your hosting panel and match its timestamp to the failure.

If needed, back up wp-config.php. Enable WordPress debug mode and logging by editing existing definitions or adding missing ones before its stop-editing comment:

define('WP_DEBUG', true);

define('WP_DEBUG_LOG', true);

define('WP_DEBUG_DISPLAY', false);

WordPress debugging guidance explains these settings. Don’t duplicate definitions.

Reproduce the failure once, then open wp-content/debug.log. Find the latest matching PHP Fatal error, uncaught exception or parse error. The path can identify a plugin or theme, but inspect the stack trace because another component may be involved.

A syntax error naming functions.php and line 231 identifies where parsing failed. Restore that file’s known-working copy over SFTP rather than guessing at corrections.

Restrict log access because logs expose server paths and potentially sensitive information. Afterwards, set WP_DEBUG to false, remove temporary logging settings and securely delete unneeded logs.

3. Isolate plugins, then test the theme

Deactivate plugins without deleting them

If the logs identify one plugin, disable that first. Otherwise, open Plugins > Installed Plugins, select all plugins and choose Deactivate. WordPress’s plugin management documentation distinguishes deactivation from deletion.

Without dashboard access:

  1. Open the WordPress installation through your hosting file manager or SFTP.
  2. Rename wp-content/plugins to plugins_disabled, then retest.
  3. If access returns, visit the dashboard’s Plugins screen whilst the folder remains renamed.
  4. Rename it back to plugins, then reactivate plugins individually, testing after each activation.

The last plugin activated before the white screen returns is the immediate suspect. Disable it again. The issue may be a plugin conflict with another component, rather than a fault in that plugin alone. Our guide to diagnosing WordPress plugin conflicts covers that distinction.

If renaming makes no difference, restore the original folder name before continuing. Must-use plugins and hosting drop-ins aren’t disabled by this test. Never run uninstall routines during diagnosis.

Switch to a default theme

Open Appearance > Themes and activate an installed default theme such as Twenty Twenty-Five.

If locked out, first ensure that default theme is installed. Rename the active theme’s folder inside wp-content/themes. WordPress can then fall back to an available default theme; if it doesn’t, hosting support can activate it.

If this resolves the fault, investigate the original theme, child theme and recent custom code. A temporary switch can change web design and digital branding. To reverse it, restore the folder name and reactivate the original theme once repaired.

4. Check memory, PHP compatibility and caches

Change resource settings only with evidence

Allowed memory size exhausted means PHP has reached its memory limit. After backing up wp-config.php, edit its existing memory definition or add this before the stop-editing comment:

define('WP_MEMORY_LIMIT', '256M');

Retest the failing request. A WordPress setting can’t override a lower PHP limit imposed by your hosting provider or cure a memory leak. If it doesn’t help, restore the previous setting and investigate the failing component.

If the outage followed a PHP version change, use the hosting panel to return temporarily to the previous supported version. Repair incompatible code before moving forward again. Don’t keep an unsupported PHP release as the permanent fix.

Purge every cache layer

After repairing the underlying error, clear the caching plugin, hosting server cache and CDN cache, including Cloudflare where used. Then hard-refresh your browser and test logged out.

A straight-on perspective of a clean data center aisle lined with server cabinets.

Without dashboard access, use hosting or CDN controls and the cache plugin’s documented file-access procedure. Renaming its folder may leave cached files behind.

Purging doesn’t need a rollback because caches rebuild. However, record any caching settings you disable so you can restore them afterwards.

5. Repair interrupted updates and damaged files

WordPress troubleshooting guidance covers a wider range of problems. Follow the evidence instead of applying every repair.

Remove a stale maintenance flag

If an update stopped midway, show hidden files in your hosting file manager and look for .maintenance in the WordPress root.

Check that no update is running, download a copy, then delete the stale file and retest. Don’t recreate it to reverse this action. A maintenance message usually looks different from a true blank screen.

Rebuild .htaccess where applicable

On Apache or compatible servers, download .htaccess, then rename it to .htaccess.bak. Retest.

If access returns, open Settings > Permalinks and select Save Changes to regenerate WordPress rules. Save custom redirects and security rules separately. If this doesn’t help, restore the original filename.

Nginx doesn’t use .htaccess. If you can’t access the dashboard, ask hosting support to restore suitable rewrite rules.

Replace damaged WordPress core files

For an interrupted core update or damaged installation, download a fresh package for your installed WordPress version from WordPress.org.

Follow the official manual WordPress update instructions to replace wp-admin, wp-includes and the appropriate root core files.

Never overwrite wp-content or wp-config.php. They contain uploads, themes, plugins and configuration. Keep other custom root files too.

Keep copies of replaced files outside the public directory so you can reverse the repair. If file permissions or ownership errors appear, ask hosting support to correct them rather than making everything writable.

6. Restore a backup only when necessary

If diagnosis stalls, restore the most recent known-good backup from before the failure. First preserve the current site and identify newer orders, bookings and enquiries. A database rollback can erase them.

Use compatible file and database copies together. If the restore fails, your preserved current copy provides a route back.

After recovery, test beyond the homepage. Submit forms, complete booking or checkout tests, and confirm email marketing notifications and systems automation reach their destinations. Check mobile-responsive layouts too.

For a small business, working landing pages support lead generation and conversion optimisation. Revisit destinations used by your Google Business Profile, social media and local SEO campaigns before resuming paused digital marketing activity.

Schedule daily off-site backups, with more frequent database copies for busy transactional sites. Add restore testing and update ownership to your website support plan.

Agencies needing technical web development and web hosting support can See how we collaborate with creative agencies.

Frequently asked questions

Does a white screen mean my content is lost?

Usually, the error prevents WordPress from displaying content without deleting it. However, deletion, damaged data and an older backup restore can cause losses. Preserve files and the database before troubleshooting.

What if only the editor is blank?

If /wp-admin/ works but the editor stays blank, inspect your browser’s developer Console for JavaScript errors. PHP logs may show nothing because the failure occurs in the browser. Test editor-related plugins on staging rather than assuming the whole site has failed.

Is WordPress down for everyone?

A self-hosted WordPress outage usually concerns your installation or hosting, rather than a central WordPress service. Compare affected requests and hosting logs before assuming a wider incident.

Keep the repair small and reversible

The safest fix follows evidence: preserve data, reproduce the failure and isolate the component responsible. A working homepage alone doesn’t prove recovery.

Finish by removing diagnostic settings and testing the customer journey. Regular website care and maintenance makes the next failure easier to detect and reverse.

Leave a Reply

Your email address will not be published. Required fields are marked *