Fixing the WordPress White Screen of Death: A Safe Order of Operations
WordPress white screen of death, fixed in a safe order: turn on error logging, rule out plugins and the theme, then check the PHP memory limit.
By Matthew Zhao · Editor, Hosted EZ
The WordPress white screen of death is a blank page with no error message: PHP hit a fatal error and stopped before printing anything. You will see it abbreviated WSOD in forum threads, and the fix is rarely dramatic — turn on logging, find the fatal line, disable the plugin or theme responsible. Worked in that order, a WordPress blank page is usually a short repair, not a lost weekend.
This guide focuses on the checks a small-site owner can make safely, and points out where a host or developer should take over. Read how to choose a web host if you are still picking a provider, and how to migrate hosting without downtime before changing live infrastructure.
Back up, then turn on error logging
Take a backup even though the site looks broken — the files and database are usually intact, and the backup protects them from your fixes. Then enable logging so the blank page starts talking: our WordPress error log guide covers turning on the debug log without printing errors to visitors.
Make a short note of what changed last — an update, a new plugin, an edit to the theme — and the last known working time. The white screen almost always follows the most recent change.
Likely causes of a WordPress white screen of death
The usual suspects, in order: a plugin update with a fatal error, a theme edit gone wrong, an exhausted PHP memory limit, and an update that died halfway and left maintenance mode on. Check the log first — the fatal line usually names the file, and the file names the plugin or theme.
If the admin area still loads, deactivate the named plugin there. If it does not, rename the plugin's folder over SFTP or the host's file manager — WordPress skips a plugin it cannot find, which is the polite version of deactivation.
Test the fix like a visitor
Load the site in a private browser window after each change. Cached pages can keep showing the white screen of death after the fix, or hide it from you while visitors still see it.
Test the normal path first, then the part that has the most consequence. For a store, that is checkout. A test should answer one question rather than produce a vague impression.
When to stop and ask for help
Stop when the log points at the server rather than the site — memory limits you cannot raise, versions you cannot change. Send support the domain, UTC time, the fatal line from the log, and what you have renamed or disabled. Never send passwords.
A memory limit or version mismatch behind a WSOD is worth checking against WordPress's server requirements. Use it to understand the terms, then return to the small, reversible next step.
A sensible maintenance habit
Most cases of the WordPress white screen of death follow updates applied in bulk without a test. Update one thing at a time, keep the debug log's location in your notes, and write down what caused each incident. A dated note turns the next blank page into a lookup instead of an investigation.
Keep the change auditable
Keep a short record: the fatal line you found, the plugin or theme you disabled, the exact time, and the result. A few months later, it tells you why a plugin is deactivated on purpose.
Do not confuse the admin dashboard with evidence from the live site. The dashboard can load while visitors still get the blank page, and the reverse. Test from outside the account, on a second connection if you can.
If you hand the incident to someone else, give them the record rather than a conclusion. "The site went white" is hard to investigate. "Fatal error in this plugin's file at this time, gone after renaming the folder" gives the next person a useful starting point.
One last check
Once the site renders, re-enable what you disabled one item at a time, watching the log between each. The goal is a working site with a known cause, not a working site with a plugin mysteriously missing.
Leave a useful handoff
Save the log excerpt, the cause, and the fix with the date. The next white screen will look identical from the front; your notes are what make it different from the back.
Bottom line
The WordPress white screen of death is a fatal PHP error with the messaging turned off. Turn logging on, read the fatal line, disable the culprit, and re-enable carefully. Keep the backup and the notes — the blank page is only mysterious the first time.
Frequently asked questions
Should I deactivate all plugins at once to fix a white screen?
No. Disable one at a time, guided by the log, and keep each previous state until you know the result is stable. Bulk deactivation fixes the page and destroys the evidence.
What information should I give hosting support?
Give the domain, exact URL, UTC time, the fatal line from the error log, and steps already tried. That is usually enough for support to find the relevant server logs.
Should I back up even though the site is already broken?
Yes. The files and database are usually intact behind a blank page — verify a backup before edits that affect them, so a fix gone wrong cannot make things worse.
About the author
Matthew Zhao
Matthew has spent his career running production server fleets — tens of thousands of machines' worth. He writes about hosting the way he wishes someone had explained it to him: plainly.
About Hosted EZ →Get the next guide in your inbox
One email when we publish something worth your time. No spam, unsubscribe whenever.
