Originally published: April 6, 2025 · Last reviewed and updated: October 2026
The WordPress “white screen of death” (WSOD) is when your site, or your admin area, loads as a blank white page with no error message. In current WordPress versions you will more often see the message “There has been a critical error on this website” instead. Both usually have the same cause: a PHP error that stops WordPress from building the page.
This guide explains how to fix the WordPress white screen of death in 2026, step by step, from the quickest checks to the less common causes.
The Short Answer
To fix the WordPress white screen of death:
- Check your admin email for a “Your Site is Experiencing a Technical Issue” message and use its recovery link.
- Clear your browser, plugin, and server caches, then reload.
- Turn on debugging to see the actual error.
- Deactivate plugins, then switch to a default theme, to find the one causing the error.
- Increase the PHP memory limit if the error mentions “Allowed memory size exhausted”.
- Check your PHP version, file permissions, and the
.htaccessfile. - If nothing works, restore a recent backup and contact your host.
What the White Screen Looks Like
Depending on your setup, you may see:
- A completely blank page. Common on older sites or when error display is turned off.
- “There has been a critical error on this website.” WordPress’s fatal error protection, added in WordPress 5.2, shows this instead of a blank screen.
- “This page isn’t working” or HTTP 500. The browser shows this when the server returns an internal server error.



The error can affect only the front end, only the admin area, or one page. That detail helps you narrow down the cause.
Common Causes
| Cause | Typical trigger | Where to look |
|---|---|---|
| Plugin conflict or bug | A plugin update or new plugin | Plugins folder |
| Theme error | Theme update or edited functions.php | Active theme |
| PHP memory limit | Large plugins, page builders, imports | wp-config.php, hosting PHP settings |
| PHP version mismatch | Host upgraded PHP, or old code | Hosting control panel |
| Syntax error in custom code | A snippet pasted into functions.php | The file you last edited |
| Corrupted core files | Failed update | wp-admin and wp-includes |
| File permissions | Migration or server change | Folders and files |
Step 1: Use Recovery Mode
When WordPress catches a fatal error, it usually emails the site admin with the subject “Your Site is Experiencing a Technical Issue”. The email names the plugin or theme that failed and includes a special recovery mode link. Open the link, log in, and deactivate the plugin or switch the theme it names. Then update or replace it.
If the email doesn’t arrive, check your spam folder. If WordPress can’t send email at all, see our guide on WordPress not sending emails after the site is back.
Step 2: Clear the Cache
A cached copy of the broken page can keep showing after the problem is fixed. Clear your browser cache, your caching plugin, and any server or CDN cache, then load the site in a private window.
Step 3: Turn On Debugging
To see the real error, edit wp-config.php in your site’s root folder and add these lines above /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reload the broken page, then open wp-content/debug.log. The last lines usually name the file and line that caused the error, which points to a plugin, theme, or snippet. The WordPress debugging documentation explains each setting. Turn debugging off again when you are done, and delete the log file, because it can expose details about your site.
Step 4: Deactivate Plugins
If you can reach the dashboard, go to Plugins, deactivate all plugins, and check the site. Then reactivate them one at a time until the white screen returns. The last plugin you activated is the cause.
If you can’t log in, connect with SFTP or your host’s file manager and rename wp-content/plugins to plugins-off. WordPress deactivates every plugin. Rename the folder back, then rename single plugin folders to find the faulty one.
Step 5: Switch to a Default Theme
If plugins aren’t the cause, test the theme. In the dashboard, activate a default theme such as Twenty Twenty-Five. Without dashboard access, rename the active theme’s folder in wp-content/themes, and WordPress falls back to an installed default theme.
If a recent edit to functions.php caused the error, undo that edit. Custom code belongs in a child theme or a code snippet plugin, so a mistake is easier to undo.
Step 6: Increase the PHP Memory Limit
If the debug log shows “Allowed memory size of … bytes exhausted”, WordPress ran out of memory. Add this line to wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
Your host’s PHP limit still caps this value. Our guide to the allowed memory size exhausted error covers the other ways to raise it.
Step 7: Check PHP Version, Permissions, and .htaccess
- PHP version. Old plugins can break on newer PHP versions, and new plugins may need a recent one. Check the version in your hosting panel and the error in the log. See how to update the PHP version in WordPress.
- File permissions. Folders are usually
755and files644. Wrong permissions after a migration can stop PHP from reading files. - .htaccess. On Apache servers, rename
.htaccessto test. If the site loads, go to Settings → Permalinks and click Save to create a fresh file.
Step 8: Reinstall Core Files or Restore a Backup
If an update failed, reinstall WordPress from Dashboard → Updates, or upload fresh wp-admin and wp-includes folders from WordPress.org. Don’t overwrite wp-content or wp-config.php.
If you still can’t find the cause, restore your latest working backup. Our guide on how to back up a WordPress site explains backup and restore options. Then contact your host with the error from the log, because some causes, such as server limits or a PHP module problem, can only be fixed on their side.
How to Prevent It
- Test major updates on a staging site first. See our WordPress staging plugins guide.
- Keep automatic daily backups that include the database.
- Update plugins and themes regularly, and remove ones you don’t use.
- Never edit theme files directly in the live site’s theme editor.
Common Mistakes
- Leaving debug display on. Visitors can see file paths and error details.
- Deleting plugins instead of deactivating them. You may lose settings you need.
- Editing the parent theme. The next update erases the fix.
- Skipping the backup before troubleshooting. A wrong step can make things worse.
FAQ
What causes the WordPress white screen of death?
Most often a PHP fatal error from a plugin, theme, or custom code. Other causes include exhausted memory, an incompatible PHP version, and corrupted files.
Is the white screen of death the same as “There has been a critical error”?
Usually, yes. Since WordPress 5.2, the critical error message often replaces the blank page for the same kinds of PHP errors.
Can I fix it without access to the dashboard?
Yes. Use the recovery mode email, or use SFTP or your host’s file manager to rename the plugins folder or the active theme folder.
Why is only the admin area white?
A plugin that runs only in the dashboard, or a memory limit reached on admin pages, can cause this. Debugging and deactivating plugins will show which one.
Will I lose content when I fix it?
No. Your posts and pages are stored in the database, so deactivating plugins or switching themes doesn’t delete them. For other common problems, see our list of 15 easy fixes for common WordPress issues.
The Bottom Line
The WordPress white screen of death is almost always a PHP error. Start with the recovery email and a cache clear, then turn on debugging to find the cause. Deactivate plugins, test a default theme, and raise the memory limit if needed. Keep backups and use staging, so the next update can’t take your site down.
Sources & Further Reading
- WordPress Developer Resources: Debugging in WordPress
- Make WordPress Core: Fatal error recovery mode in 5.2
- WordPress Developer Resources: Editing wp-config.php
- WordPress Developer Resources: Changing file permissions
- WordPress.org: Download WordPress
Articles are editorially reviewed by Jackober and factual claims are checked against cited sources.