A WordPress white screen of death (WSoD) usually means PHP stopped before your site could display a page or error message. Faulty plugins, theme errors, and exhausted memory are common causes, so test those before changing server settings.
Your priority is restoring service without losing business data. A blank homepage doesn’t necessarily mean your content is gone.
Start by identifying what still works, then follow these checks in order, making one change at a time.
Key Takeaways
- Preserve your files and database before troubleshooting, and test code repairs on staging.
- Disable plugins and test an installed default theme before changing memory limits or permissions.
- Use error logs to identify the failure, then test forms, bookings, and checkout after recovery.
1. Identify Where the WordPress White Screen Appears
Open your homepage, an internal page, and yourdomain.com/wp-admin. Also try a private browser window.
If the dashboard loads but the frontend doesn’t, a plugin or theme is a likely cause. A complete lockout can also involve PHP incompatibility, memory exhaustion, or server configuration.
An HTTP 500 error means the server couldn’t complete the request. Chrome may say, “This page isn’t working” or “is currently unable to handle this request.” That message doesn’t identify the underlying fault.
Before changing anything, create a WordPress backup of both your files and database. My website backup and recovery guidance explains why both matter.
Then clear your browser cache and any accessible WordPress, hosting, or CDN caches. For WP Super Cache, use Settings > WP Super Cache > Delete Cache. Cached output can obscure whether a repair worked.
Record the last plugin update, theme change, code edit, or PHP upgrade.
2. Disable Plugins Without Deleting Their Files
A plugin conflict can interrupt an entire page, even if the plugin controls only one feature. You can disable plugins without deleting their settings, and the change is reversible.
When the Dashboard Works
Open Plugins > Installed Plugins, select the active plugins, and choose Deactivate from Bulk actions. Record which plugins were active first.
Reload the affected page. If it works, reactivate plugins one at a time and reload after each activation. Repeat the action that failed, such as submitting a form.
Keep the plugin linked to the failure disabled. The issue may involve an interaction between plugins, so test relevant combinations on staging before replacing or updating anything.
When wp-admin Is Unavailable
Use your hosting file manager or an FTP client. Prefer SFTP when it’s available. In the wp-content folder, locate plugins and rename it to plugins_old.
Try opening wp-admin again. If access returns, visit the Plugins screen while the folder is still renamed. WordPress will register the missing plugins as deactivated.
In the wp-content folder, rename plugins_old back to plugins. Reactivate previously active plugins one at a time, testing after each.
Must-use plugins in wp-content/mu-plugins and caching drop-ins can still run. Don’t remove them blindly if the white screen continues.
3. Test an Installed Default Theme
If disabling plugins doesn’t help, temporarily activate Twenty Twenty-Five under Appearance > Themes.
Your design will change during this test. The result helps isolate whether the active theme, child theme, or theme-specific code causes the failure.
Without dashboard access, confirm an installed default theme is inside wp-content/themes. Use SFTP where available, or an FTP client or hosting file manager, to rename only the active theme’s folder.
WordPress may fall back to an available default theme, but recovery isn’t guaranteed in every configuration.
Don’t rename the entire themes directory. That also hides the default theme WordPress needs for the fallback.
If Twenty Twenty-Five or another default theme works, keep the original files intact. Test theme repairs on staging, especially changes involving a child theme’s functions.php.
4. Read the Error Log Before Editing Code
I prefer an error message over another round of guesses. A fatal error stops execution, while a warning or deprecation notice usually doesn’t.
Enable Private Logging on Staging
On a protected staging copy, enable debug mode by editing wp-config.php before the line that loads WordPress, normally before the “stop editing” comment.
Replace existing definitions rather than adding duplicates. Use define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true);, and define('WP_DEBUG_DISPLAY', false);.
Keep PHP error display disabled too, using @ini_set('display_errors', 0); where appropriate. Reproduce the failing request, then open wp-content/debug.log.
If debug.log remains empty, inspect the hosting PHP error log. Some failures happen before WordPress starts logging.
Don’t edit application code directly on the live production site. Test the repair locally or on staging, then deploy the validated files.
Match the Error to the Failing Request
Record the timestamp, error message, file path, and line number. Focus on entries matching your test, rather than old warnings.
“Allowed memory size … exhausted” points toward memory pressure. A parse error indicates invalid PHP syntax. “Call to undefined function each()” identifies code using a function removed in PHP 8.0.
A plugin or theme path identifies implicated code, although another component may trigger it.
After troubleshooting, turn debug mode off by setting WP_DEBUG and WP_DEBUG_LOG to false. Secure or remove generated logs because they can expose sensitive details. WordPress’s Site Health documentation flags logging configurations that may create publicly accessible files.
5. Increase Memory Only When the Error Supports It
A WordPress white screen caused by memory exhaustion may call for a higher PHP memory limit. A syntax error needs a different fix, since more memory won’t repair broken PHP.
The familiar setting define('WP_MEMORY_LIMIT', '64M'); requests 64 MB. However, that won’t help a site already exhausting 128 MB.
For a controlled staging test, define('WP_MEMORY_LIMIT', '128M'); or define('WP_MEMORY_LIMIT', '256M'); may fit the workload. Replace an existing definition instead of duplicating it.
WooCommerce’s memory-limit documentation describes increasing the WordPress allowance for more demanding sites. There isn’t one universal value for every business website.
WordPress requests memory within the PHP environment’s permitted configuration. A hosting cap can prevent the requested increase.
At the server level, memory_limit = 64M is PHP configuration syntax for php.ini. The .htaccess equivalent, php_value memory_limit 64M, works only in compatible Apache configurations.
Adding
php_valueto.htaccesson an incompatible server can cause another HTTP 500 error. Use the hosting PHP settings interface instead.
If wp-admin alone fails, WP_MAX_MEMORY_LIMIT may also matter. Investigate repeated exhaustion rather than continually raising limits, since faulty code can consume any allowance.
6. Resolve Failed Updates and Recent Syntax Errors
An interrupted update can leave WordPress in maintenance mode. In the WordPress root directory, alongside wp-admin and wp-includes, look for .maintenance.
Enable hidden-file visibility if necessary. Once no update process is running, delete only that .maintenance file and reload the site.
Removing it clears the maintenance flag; it doesn’t repair an incomplete update. If an update stopped midway, restore or reinstall the affected component from a trusted package.
Recent manual edits deserve separate attention. Missing semicolons, mismatched brackets, or damaged quotes can create syntax errors in functions.php or wp-config.php.
Stray whitespace before <?php or after a closing ?> can also trigger “headers already sent” warnings. PHP-only files generally omit the closing tag to avoid accidental output.
Those warnings alone don’t prove the cause of a blank page. Use the log to distinguish unwanted output from a fatal error.
I recommend restoring the known-good file, then testing the intended change on staging.
7. Correct Permissions or Restore a Known-Good Backup
When ordinary plugin and theme tests fail, use server evidence before making broader changes. Permissions and restoration need care because mistakes can affect the whole site.
Use Ownership-Appropriate File Permissions
Common WordPress permissions are 755 for directories and 644 for files. Some group-based hosting setups use 775 and 664.
For wp-config.php, appropriate permissions may be 600, 640, 644, or 660. More restrictive 440 can work when server ownership and access rules support it.
These file permissions depend on ownership and hosting configuration, so don’t try values at random. Avoid 777 permissions and blanket recursive changes across the account.
If logs show “Permission denied,” ask hosting support to correct ownership and access for the affected path. Incorrect ownership can remain a problem even when permission numbers look reasonable.
Restore Without Overwriting New Business Data
A recent backup can reverse a failed update, but choose a recovery point from before the failure. Match the website files and database when restoring the full site.
Before restoring, preserve new orders, bookings, submissions, and content created after that backup. A full database rollback can erase those records.
When one update caused the outage, restoring that component may protect newer transactions better than reverting everything. Afterward, test uncached pages, logins, forms, checkout, and confirmation emails.
Our WordPress website maintenance plans provide ongoing updates, backups, and monitoring.
Frequently Asked Questions
What causes the WordPress white screen of death?
It usually means PHP stopped before WordPress could display a page or error message. Faulty plugins, theme errors, and exhausted memory are common causes.
What should I do first when my site shows a white screen?
Check whether the homepage, an internal page, and wp-admin are affected, then back up your files and database. Record recent plugin updates, theme changes, code edits, or PHP upgrades before troubleshooting.
How can I disable plugins if I can’t access wp-admin?
Use SFTP or your hosting file manager to rename the wp-content/plugins folder to plugins_old. If access returns, rename it back to plugins, then reactivate plugins one at a time and test after each activation.
Should I increase the PHP memory limit?
Only increase memory when the error log reports memory exhaustion, since a higher limit won’t fix a syntax error. Your hosting configuration may also cap the memory WordPress requests.
Can restoring a backup delete recent orders or bookings?
Yes. Restoring a full database backup can remove orders, bookings, submissions, and content added after the backup was made. Preserve those records before restoring, or restore only the component involved in the failure when appropriate.
Restore Service, Then Prevent the Next Failure
The safest WSoD recovery follows the evidence: isolate plugins and themes, read the error logs, and change server settings only when justified.
I recommend keeping tested, independent backups and using staging for updates or code changes. After recovery, test the customer actions that generate business, rather than relying on a working homepage.
If you’re locked out or concerned about losing recent transactions, Contact Us for a free consultation about your website support needs.