Your site is a blank white page. No error, no message, nothing. Here is the fastest path back, in order – the same sequence we run on client emergencies.
Rather not do this yourself? We fix WordPress emergencies. Get in touch – phone, email, live chat, whatever’s fastest for you. Or read what WordPress repair covers first.
Everyone else: start here.
Do this first: get the error message back
The white screen is not an error. It is the absence of an error — PHP crashed and error display is turned off, so the browser receives an empty response. Everything below is much easier once you can see what actually broke.
Open wp-config.php via FTP, SFTP or your host’s file manager. Find the line that reads /* That's all, stop editing! */ and add this above it:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reload the site, then open /wp-content/debug.log. The last entries are your answer — usually a fatal error naming a specific file and line number. That file is almost always inside a plugin or theme folder, which tells you the culprit immediately.
Note the two settings that matter: WP_DEBUG_DISPLAY is set to false on purpose. Errors go into the log, not onto the screen where visitors and search engines can read your file paths. Turn WP_DEBUG back off once you are done.
No debug.log appears? Then PHP died before WordPress loaded — check your server’s own error log instead. In cPanel it is under Metrics → Errors; on managed hosts it is usually in the dashboard; on a VPS look in /var/log/php-fpm/ or /var/log/apache2/error.log.
Check your email
Since WordPress 5.2, a fatal error triggers an automatic email to the address in Settings → General. Subject line: “Your site is experiencing a technical problem.”
That email names the plugin or theme that failed and contains a recovery-mode link — a one-time login that loads your admin area with the offending extension paused. If the email is there, you can often fix the whole thing from the dashboard without touching a single file.
Two reasons people miss this: the admin email is an address nobody reads, or it is on a domain hosted by the very site that is down. Worth fixing either way, before the next incident.
The nine causes, in diagnostic order
Ordered by how often they are the answer, weighted by how fast they are to rule out.
1. A plugin conflict or plugin fatal error
By far the most common cause, and it almost always follows an update — WordPress core, a plugin, or PHP.
If you can reach the dashboard: deactivate all plugins, confirm the site returns, then reactivate one at a time, reloading the site after each. The one that breaks it is yours.
If you cannot reach the dashboard: rename the folder /wp-content/plugins to plugins-off. WordPress finds no plugins, deactivates all of them, and the site comes back. Rename it back, then rename individual plugin folders one at a time to find the offender.
If you have WP-CLI access, this is faster:
wp plugin deactivate --all
wp plugin activate <name> # one at a time
Do not delete anything while diagnosing. Renaming is reversible; deleting takes settings with it.
2. A theme fatal error
Same mechanism, second most common cause. Typical trigger: a theme update, or a PHP version bump that breaks older theme code.
Rename your active theme’s folder in /wp-content/themes. WordPress falls back to a default theme if one is present — which is exactly why you should always keep a Twenty-Twenty-Something theme installed, even if you never use it.
Custom code in functions.php counts here too. A single missing bracket or a stray closing ?> at the end of the file produces exactly this symptom.
3. PHP memory exhausted
The site works, then stops working on a specific page — often the admin, the media library, or a heavy WooCommerce screen. The log says Allowed memory size of X bytes exhausted.
Raise the limit in wp-config.php:
define( 'WP_MEMORY_LIMIT', '512M' );
If that changes nothing, the real ceiling is your server’s memory_limit in PHP, which WordPress cannot override. Raise it in your host’s PHP settings, or ask support.
Important caveat: memory exhaustion is usually a symptom, not the disease. If a site that ran fine on 256 MB suddenly needs 512 MB, something started consuming it — a plugin with a runaway loop, a corrupted image, an unbounded query. Raising the limit buys you a working site and the time to find out why. It is not the fix.
4. PHP version incompatibility
Hosts upgrade PHP, sometimes automatically, sometimes with an email you missed. Code written for PHP 7.x can fail outright on 8.x — and the failure mode is a fatal error, which is a white screen.
Check which version you are running in your host panel. If it was changed recently, roll it back temporarily. That gets the site up; it does not solve the problem. The plugin or theme that broke needs updating or replacing, because the rollback is borrowed time — your host will upgrade again.
5. A failed or interrupted update
A PHP timeout mid-update leaves files half-replaced. Core files from two different versions do not work together.
Symptoms: the white screen appeared during an update, or the site shows “Briefly unavailable for scheduled maintenance.” For the latter, delete the file .maintenance in your WordPress root — it is a leftover flag, and removing it is safe.
For genuinely broken core files: download the matching WordPress version from WordPress.org, and upload wp-admin and wp-includes over the existing ones, replacing everything. Do not touch wp-content or wp-config.php. Your content and settings live there.
6. A corrupted .htaccess
Apache-specific, and easy to rule out. Rename .htaccess in your WordPress root to .htaccess-old and reload.
If the site returns, the file was the problem. Log in, go to Settings → Permalinks, and click Save without changing anything — WordPress writes a clean one. Note that you will lose any custom rules in there, so read the old file before discarding it.
7. Database connection or corruption
Usually you get “Error establishing a database connection” rather than a white screen — but not always. If the log points at database errors, check the credentials in wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) and confirm the database server is running.
For corrupted tables, add to wp-config.php:
define( 'WP_ALLOW_REPAIR', true );
Then visit yoursite.com/wp-admin/maint/repair.php. Remove that line immediately afterwards — the page requires no login, and leaving it enabled is a genuine security hole.
8. Caching serving a broken page
You fixed the problem and the site is still white. Before you keep digging: clear every layer. Plugin cache, object cache, server cache, CDN, and your own browser. Then test in a private window.
A CDN can happily serve a cached blank page for hours after the underlying issue is gone. This wastes more debugging time than any other item on this list.
9. You have been hacked
Consider this if the white screen appeared with no update, no change and no explanation — or if it comes back after you fix it.
Signs worth checking: recently modified PHP files in /wp-content/uploads (there should be none at all), administrator accounts you do not recognise, unfamiliar scheduled tasks, obfuscated code at the top of index.php or wp-config.php.
If any of that turns up, stop treating it as a bug. Change all passwords, run a malware scan, and restore from a backup that predates the intrusion. A cleaned site with the original entry point still open gets reinfected within days.
What not to do
Because these turn a bad afternoon into a bad week:
Do not edit files through the WordPress editor while the site is broken. You cannot reach it, and if you can, a syntax error locks you out completely.
Do not delete plugins to test them. Rename. Deleting removes settings and data that may not come back.
Do not change several things at once. You will fix it and never know what worked — which means it will happen again.
Do not work on the live site if you have a staging environment. Reproduce there.
Do not skip the backup, even now. Yes, the site is already broken. It can get worse, and a broken site with a backup is a much better position than a broken site without one.
Prevention, honestly
Every cause on this list is a maintenance failure rather than bad luck. Specifically:
Staging. Updates applied to a copy first, tested, then deployed. This eliminates causes 1, 2, 4 and 5 — the majority of white screens — before they ever reach a visitor.
Backups stored off-server. A backup on the machine you are restoring is not a backup. Before every change, not weekly.
Monitoring. The gap between “site went down” and “someone noticed” is where the damage happens. If you find out from a customer, the answer is hours, not minutes.
An admin email someone reads, on a domain not hosted by the site in question. This one is free and takes two minutes.
A default theme kept installed. Also free. It is the difference between a fallback and a dead site.
PHP version awareness. Know what you run, know when your host plans to change it, and test before they do.
Site down right now?
We do WordPress emergency repair — diagnosis first, then the fix, then an explanation of what actually happened so it does not repeat.
WordPress repair and emergency fixes.
Would rather not have this afternoon again? WordPress maintenance with staged, tested updates
