The WordPress White Screen of Death (often shortened to “WSOD”) is exactly what it sounds like: you load your site and… nothing. No error message, no helpful warning, just a blank white page. Sometimes it’s the whole site. Sometimes it’s only the admin area. Either way, it’s stressful—especially if your site is tied to bookings, leads, or sales.
The good news: WSOD is usually fixable without rebuilding your site from scratch. It’s typically caused by a plugin conflict, a theme issue, exhausted memory, a PHP error that’s being hidden, or a corrupted core file. In this guide, you’ll learn a practical, step-by-step workflow to diagnose the cause and get your WordPress site back online.
This walkthrough is written to be approachable if you’re not a developer, but it also includes deeper checks if you’re comfortable with FTP, file managers, and logs. Take it in order—WSOD troubleshooting is all about isolating the problem systematically.
What the White Screen of Death usually means (and why it’s so vague)
WSOD is frustrating because WordPress (or PHP) may be encountering a fatal error, but error display is turned off. Instead of showing a readable error, the server stops processing and returns a blank response. That’s why the “white screen” can feel like a mystery.
In many cases, the issue starts right after a change: a plugin update, theme update, PHP version change, new code snippet, or even a migration to a new host. If you can remember what changed right before the blank screen appeared, you already have a valuable clue.
It’s also worth noting that WSOD can be selective. You might see a blank screen only on certain pages, only for logged-in users, or only in wp-admin. Those patterns help narrow down whether you’re dealing with a front-end theme/template issue, an admin-only plugin problem, or a memory limit that’s only reached on heavier pages.
Before you touch anything: quick checks that save time
Try a different browser and a private window
Start with the simplest possibility: caching. Open your site in an incognito/private window. If it loads there, your normal browser session might be serving a cached broken version or a stale redirect.
If you use a caching plugin, CDN, or host-level cache, you may need to purge caches once the site is stable again. But for now, the goal is to confirm whether the issue is truly server-side or just a local caching hiccup.
Also try a different browser or device. It’s rare, but sometimes a browser extension or aggressive ad blocker can cause a page to appear blank—especially if the theme relies on scripts that are being blocked.
Check if it’s the whole site or just wp-admin
Visit both your homepage and /wp-admin. If only the front-end is blank but wp-admin works, the issue is more likely theme-related or tied to a front-end plugin (page builder, caching/minification, etc.).
If wp-admin is also blank, you’re likely dealing with a fatal error that loads early—like a plugin, a must-use plugin, a broken functions.php, or a core file problem.
If you can still access wp-admin, don’t start randomly deactivating things yet. You’ll get better results by enabling debug logs first so you can see what’s actually failing.
Step 1: Turn on WordPress debugging (so the error stops hiding)
Edit wp-config.php to log errors
The fastest way to stop guessing is to turn on logging. Using FTP or your host’s file manager, open wp-config.php (located in your WordPress root folder). Find the line that says /* That's all, stop editing! */ and add these lines just above it:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
This setup writes errors to a log file without showing them publicly on your site. That’s important on a live site—displaying raw errors can expose file paths and other details you don’t want visitors to see.
After saving, refresh the page that shows the white screen. Then check wp-content/debug.log. If the file doesn’t exist, load the broken page a couple of times and re-check, or confirm the server can write to wp-content.
What to look for in debug.log
In the log, you’re looking for “Fatal error”, “Uncaught Error”, or “Allowed memory size exhausted”. The line will usually mention a specific plugin file, theme file, or function name that’s failing.
If the error points to a plugin path like wp-content/plugins/plugin-name/..., you’ve likely found the culprit. If it points to your theme (like wp-content/themes/your-theme/...), the theme or a custom snippet is the likely cause.
If the log is empty but you still see a white screen, the issue may be happening before WordPress can initialize debugging (for example, a server-level PHP error, a corrupted core file, or a misconfigured PHP extension). In that case, server error logs become the next best clue.
Step 2: Increase memory limits (a common WSOD trigger)
Raise the WordPress memory limit in wp-config.php
Memory exhaustion is one of the most common causes of WSOD, especially on sites running heavy themes, page builders, WooCommerce, or multiple plugins. You can increase the memory available to WordPress by adding this to wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');
Place it above the “stop editing” line (same area as the debug settings). Then refresh your site.
If the white screen disappears, you’ve confirmed the issue was memory-related—but don’t stop there. Memory exhaustion often signals a deeper issue: a plugin doing too much, a runaway query, or a theme function that’s heavy. You’ll want to identify what’s consuming memory so you don’t hit the limit again later.
Adjust PHP memory limit at the server level
Sometimes WordPress settings aren’t enough because the server’s PHP memory limit is lower. Depending on your host, you may be able to increase it in your hosting dashboard, in php.ini, or in a .user.ini file. Common settings include:
memory_limit = 256M
If you’re on shared hosting and can’t change it, you may need to contact support. When you do, mention that you’re troubleshooting a WordPress WSOD and you suspect memory exhaustion—support teams usually recognize that pattern quickly.
Also note: if your site suddenly started hitting memory limits after a plugin update, rolling back that plugin (or switching to an alternative) may be a smarter long-term fix than simply increasing memory.
Step 3: Disable plugins safely (the fastest way to isolate conflicts)
If you can access wp-admin, deactivate plugins in batches
If wp-admin loads, go to Plugins and deactivate them all. Then reactivate them one by one (or in small groups), refreshing the site each time. When the white screen returns, the last plugin you activated is the likely source.
This approach is simple, but it can be time-consuming on a site with many plugins. To speed it up, activate plugins in groups of 3–5. Once the issue returns, narrow it down within that group.
Be aware that deactivating certain plugins (like caching, security, or membership plugins) can change site behavior temporarily. That’s okay for troubleshooting—your goal is to restore access and stability first.
If you can’t access wp-admin, disable plugins via FTP/File Manager
If wp-admin is also blank, you can still disable plugins by renaming the plugins folder. Using FTP or File Manager, go to wp-content and rename plugins to plugins_old. This forces WordPress to deactivate all plugins automatically.
Now refresh your site. If it loads, you’ve confirmed a plugin issue. Next, rename the folder back to plugins, then go inside and rename individual plugin folders one at a time (for example, plugin-name to plugin-name_off) until the site loads consistently.
Once you identify the plugin, check for an update, compatibility issues with your PHP version, or recent changes in that plugin’s settings. If it’s a mission-critical plugin, you may need a staging environment to test fixes safely.
Step 4: Switch themes to rule out theme-level fatal errors
Change the theme from wp-admin (if available)
If you can access wp-admin, go to Appearance → Themes and temporarily activate a default theme like Twenty Twenty-Four. Then reload the page that was blank.
If the site comes back, your original theme (or a child theme customization) is causing the fatal error. This can happen after updating the theme, adding a code snippet to functions.php, or using a feature that requires a newer PHP version.
At this point, keep the default theme active while you investigate. It’s better to have a plain-looking site that works than a styled site that’s down.
Change the theme via database if wp-admin is inaccessible
If you can’t reach wp-admin, you can switch themes via phpMyAdmin (or another database tool). In the wp_options table (prefix may vary), find the rows for template and stylesheet and set both to a default theme folder name (for example, twentytwentyfour).
Refresh your site. If it loads, you’ve confirmed a theme issue. Then you can review your theme files for recent edits, missing dependencies, or incompatible functions.
If you’re using a custom theme built years ago, this can also be a sign it needs modernization. Many WSOD incidents happen when older themes meet newer PHP versions.
Step 5: Check for a broken custom snippet (functions.php and mu-plugins)
Undo recent code changes in functions.php
If you recently added code to your theme’s functions.php (or a child theme), a small syntax error—like a missing semicolon—can take the whole site down. If you remember the snippet you added, remove it and try again.
If you don’t remember exactly what changed, compare your current file to a backup or earlier version. Even one extra character can trigger a fatal error.
When editing PHP files, it’s best to use a proper code editor and deploy changes carefully. Direct edits in production via the WordPress theme editor are risky because a mistake can lock you out instantly.
Don’t forget must-use plugins (mu-plugins)
Some sites have “must-use” plugins in wp-content/mu-plugins. These load automatically and won’t show in the normal plugins list. If a must-use plugin breaks, you can get WSOD even after disabling regular plugins.
Check whether that folder exists and whether any files were recently added or updated. Try temporarily renaming the mu-plugins folder to see if the site returns.
If renaming mu-plugins fixes it, you’ll want to restore the folder and then isolate which file is causing the issue by renaming files one at a time.
Step 6: Look at server logs (when WordPress logs aren’t enough)
Find your PHP error log in hosting tools
Many hosts provide an “Errors” section, “Raw Access Logs,” or a dedicated PHP error log viewer. If WordPress debug.log is empty but WSOD persists, server logs often reveal the real cause—like a missing PHP extension, permission error, or a fatal error that happens before WordPress initializes.
Search for entries that match the timestamp when you loaded the blank page. Look for “PHP Fatal error”, “Segmentation fault”, “Premature end of script headers”, or “Permission denied”. Those messages can point you in the right direction quickly.
If you’re not sure what you’re seeing, copy the error line into a note. The file path and function name are usually the most valuable parts.
Common server-level triggers that look like WSOD
Sometimes the site isn’t truly “blank”—it’s returning a 500 error that your browser displays as a white page. Misconfigured permissions (like folders set to 777 or files set incorrectly), a corrupted .htaccess file, or a PHP version mismatch can create this effect.
Another sneaky one: opcode cache issues after a PHP upgrade. Restarting PHP via your host panel (or asking support to restart PHP-FPM) can clear weird caching behavior.
And if you’re using Cloudflare or another proxy, temporarily bypassing it can help confirm whether the blank screen is happening at the origin server or at the edge.
Step 7: Repair .htaccess and permalinks (especially if only some pages are blank)
Reset .htaccess to a clean default
If your homepage loads but certain pages are blank (or you see WSOD only on pretty permalinks), your .htaccess file may be corrupted. Using FTP/File Manager, rename .htaccess to .htaccess_old and try loading the site again.
If the site starts working, you can generate a fresh .htaccess by going to Settings → Permalinks and clicking “Save Changes” (no need to change anything). WordPress will write a new set of rewrite rules.
If you can’t access wp-admin, you can create a new .htaccess file manually with the standard WordPress rules for Apache. Just be sure your server is actually using Apache; Nginx setups handle rewrites differently.
Watch for security and caching rules inside .htaccess
Some security plugins and caching plugins add lots of directives to .htaccess. A single malformed line can break responses and lead to blank pages.
If you find that resetting .htaccess fixes WSOD, reintroduce custom rules carefully. Add them back in small chunks and test between changes.
If you’re unsure which rules are safe, keep the minimal WordPress rules and let your host handle performance optimizations at the server level.
Step 8: Re-upload WordPress core files (without touching wp-content)
When core files get corrupted
Core file corruption can happen after a failed update, a partial upload, malware cleanup, or a hosting glitch. If you’ve ruled out plugins, themes, and memory limits, it’s time to consider that WordPress itself might have missing or altered files.
The safest fix is to re-upload a fresh copy of WordPress core files while keeping your content and configuration intact. That means you do not touch wp-content or wp-config.php.
Download a fresh WordPress zip from wordpress.org, extract it locally, then upload everything except wp-content and wp-config-sample.php. Overwrite existing files when prompted.
Why this step is less scary than it sounds
Your themes, plugins, uploads, and settings live in wp-content and the database. Replacing core files is basically like reinstalling the engine without touching the passengers or cargo.
After re-uploading, test the site again. If WSOD is gone, you likely had a corrupted core file or a mismatch between core files and your WordPress version.
If WSOD persists even after a clean core upload, the issue is almost certainly in a plugin, theme, custom snippet, or server configuration.
Step 9: Fix permissions and ownership (a silent cause of blank pages)
Check typical WordPress permissions
Incorrect file permissions can cause PHP to fail when it tries to load files. A common baseline is:
- Folders:
755 - Files:
644 wp-config.php: sometimes640or600depending on host
Using FTP or File Manager, verify that your WordPress directories and files follow these norms. If you see folders set to 777, that’s a red flag (and a security risk).
If you’re on a VPS or dedicated server, ownership matters too. Files owned by the wrong user can cause permission errors even if the numeric permissions look correct.
How permissions issues show up in practice
Permissions problems often appear after migrations, restoring backups, or changing hosting environments. A site might work for a while and then suddenly fail when WordPress tries to write cache files, update plugins, or generate thumbnails.
In logs, you might see “failed to open stream: Permission denied” or “Permission denied in …/wp-includes/…”. Those messages are strong indicators.
If you’re not comfortable changing permissions, ask your host to reset WordPress permissions and ownership. It’s a common support request.
Step 10: Handle PHP version and compatibility issues
Confirm your current PHP version
WordPress itself is compatible with modern PHP versions, but plugins and themes might not be. If WSOD started immediately after changing PHP versions in your hosting panel, roll back to the previous version to confirm.
A quick compatibility test is: switch to the previous PHP version, clear caches, and reload. If the site returns, you know you’re dealing with a compatibility issue rather than random corruption.
Once you’ve confirmed that, you can update or replace the incompatible plugin/theme, then move forward again to a supported PHP version.
What compatibility problems look like in logs
In debug logs, PHP compatibility issues often show as “undefined function”, “deprecated” warnings (not usually fatal), or “cannot redeclare function” errors. Fatal errors are the ones that cause WSOD.
Another common one: a plugin using an old library that conflicts with another plugin’s library. This can trigger class redeclaration errors and kill the page load.
If you find this kind of conflict, the cleanest fix is usually updating the offending plugin(s). If updates aren’t available, replacing the plugin is often safer than patching vendor libraries yourself.
Step 11: When WSOD only affects the admin area
Increase admin memory and disable admin-heavy plugins
Sometimes the front-end works, but wp-admin is blank. That can happen when an admin dashboard widget, analytics plugin, backup plugin, or security plugin loads heavy scripts and hits memory limits.
Try raising memory limits (as described earlier) and disabling plugins via FTP if you can’t access the dashboard. Pay special attention to plugins that add dashboards, reports, or scans.
Also check whether your host has a WAF (web application firewall) blocking admin requests. In rare cases, that can result in blank responses rather than clear blocks.
Clear browser storage for wp-admin quirks
Admin-only blank screens can also come from corrupted local storage or a stuck service worker (especially if your admin is behind a performance plugin). Clear site data for your domain in your browser settings and try again.
If you use a plugin that modifies the login URL, confirm you’re accessing the correct admin path. Misrouted admin requests can sometimes present as blank pages depending on how redirects are configured.
If the admin loads in a private window but not in a normal session, you likely have a browser-side issue rather than a server-side fatal error.
Step 12: Recovery habits that prevent the next WSOD
Use a staging site for updates
Most WSOD incidents happen right after an update. A staging site lets you test plugin/theme/core updates safely before pushing them live.
If your host offers one-click staging, use it. If not, you can create a staging environment on a subdomain. It’s a little setup work, but it pays for itself the first time an update goes sideways.
When you do updates, do them in small batches. Updating everything at once makes it harder to identify what caused the break.
Keep backups you can actually restore
Backups are only useful if they’re recent and restorable. Make sure you have both files and database backups, and that you know where they’re stored.
A smart routine is daily automated backups plus a manual backup before major changes. If you run WooCommerce or bookings, consider more frequent database backups.
And do at least one test restore on a staging site so you’re not learning the restore process during an emergency.
Step 13: When it’s time to bring in help (and what to ask for)
What to send to a developer or support team
If you’ve tried the steps above and you’re still stuck, you’ll get faster help if you provide clear information. Send:
- What changed right before WSOD (updates, new plugin, migration, PHP version change)
- Whether the issue affects front-end, wp-admin, or both
- The relevant lines from
wp-content/debug.logor server logs - Your WordPress version and PHP version
This turns your request from “my site is blank” into a solvable technical ticket.
If you run a business site where downtime costs money, consider ongoing maintenance rather than one-off emergency fixes. A stable update process, monitoring, and performance checks reduce the chances of WSOD happening again.
Why strong site foundations matter beyond WSOD
WSOD is often a symptom of deeper issues: outdated code, too many overlapping plugins, a theme that’s doing heavy lifting, or a hosting plan that’s stretched thin. Fixing the immediate blank screen is step one; building resilience is step two.
If your site is central to your marketing, it may be worth investing in expert WP web design & development so your theme, plugins, hosting setup, and update workflow work together instead of fighting each other.
And remember: site health isn’t only about uptime. It’s also about speed, accessibility, SEO readiness, and security—all of which influence how well your site performs after it’s back online.
Step 14: After the site is back—do these checks while everything is fresh
Purge caches and confirm key pages
Once WSOD is resolved, purge your caching plugin cache, CDN cache, and any host-level cache. A site can appear “fixed” for you but still show broken cached pages to visitors.
Then test your most important pages: homepage, contact page, service pages, and any checkout/booking flows. If you have forms, submit a test entry and confirm it arrives.
Also test on mobile. Some WSOD-like issues are actually front-end JavaScript crashes that only show up on certain devices or browsers.
Re-enable debugging settings responsibly
If you enabled WP_DEBUG, keep WP_DEBUG_DISPLAY set to false on production. Logging is fine temporarily, but you don’t want to fill disk space with logs forever.
After a day or two of stability, you can set WP_DEBUG back to false, or keep logging only if you’re actively monitoring it.
And if you found a plugin or theme issue, document it. A quick note like “Plugin X update on Feb 10 caused WSOD; fixed by version Y” can save hours next time.
Step 15: Keeping your business visible while you troubleshoot
Use status updates and alternative channels
If your site is down for more than a few minutes, it helps to communicate—especially if customers rely on your site for hours, bookings, menus, or contact info. A quick post on social media or a pinned update can reduce confusion.
For local businesses, your Google Business Profile is often the first place customers look. Making sure your hours, phone number, and key updates are accurate can keep calls and visits coming in even if your website is having a bad day.
If you want that profile working harder for you year-round, services like GMB optimization by Digital Envy can help keep your local visibility strong—so a temporary site issue doesn’t completely cut off discovery.
Let your email list do some heavy lifting
If you have an email list, it’s one of the best “owned” channels you can rely on during website problems. You can send a short update, share a direct booking link (if you have an external booking tool), or provide a phone number for urgent requests.
Even outside emergencies, email is a steady way to bring people back to your site once everything is fixed. If you’ve been meaning to build this channel, investing in newsletter creation and email campaigns can turn your list into a reliable source of traffic and repeat business.
And if you already send emails, consider adding a simple “backup contact plan” to your templates—like a phone number or social link—so customers can still reach you if your site ever goes down again.
Quick troubleshooting map (if you want the fast version)
If you need a simple order of operations
If you’re skimming because you’re in panic mode, use this sequence:
- Try incognito + check front-end vs wp-admin
- Enable debug logging in wp-config.php
- Increase memory limits
- Disable plugins (rename plugins folder if needed)
- Switch to a default theme
- Check mu-plugins and recent code snippets
- Check server logs
- Reset .htaccess
- Re-upload WordPress core files (not wp-content)
That flow solves the vast majority of WSOD cases because it focuses on isolating the most common failure points.
And if you find the cause, take a minute to address the root issue (compatibility, update process, plugin bloat, hosting limits) so you’re not repeating this next month.
If WSOD keeps coming back
Recurring WSOD is a sign of an underlying stability problem—often a specific plugin, a theme that’s doing too much, or a server resource limit being hit during traffic spikes or scheduled tasks.
In that case, consider monitoring (uptime + error logs), trimming plugins, and moving heavy features to better-supported solutions. It’s also worth reviewing your hosting plan if you’re consistently near memory or CPU limits.
With a solid foundation and a careful update routine, WSOD can go from a recurring nightmare to a rare, quickly solvable hiccup.