WordPress White Screen of Death — Diagnosis and Rescue
The page is blank, the admin may be gone with it, and nothing tells you why. The white screen is almost never mysterious — it is a PHP fatal error hiding in plain sight, and it has a specific, findable cause.
The white screen of death looks like the site has vanished. What actually happened is narrower: PHP hit a fatal error, and your server is configured to hide errors from visitors — so it renders nothing instead of rendering the problem. The blankness is a display setting, not the depth of the disaster. Sometimes it is total, sometimes only the homepage, sometimes only the admin, sometimes everything except a stray header. Each of those patterns narrows the search before any tool is opened. Narrowing it is the developer's job, not yours — the useful thing you can do tonight is capture what changed and hand that over.
The causes are honestly boring, and that is good news. The usual suspects, in real-world order: a plugin or theme injured by an update and now crashing mid-render, memory exhausted by a greedy component, a PHP version jump at the host that some old code cannot survive, or a hand-edited file with a syntax error in it. The single most diagnostic question in all of WordPress — what changed right before this started? — answers a majority of white screens before any debugging begins.
The rescue runs on evidence, not guesswork: the error log and WP_DEBUG capture the actual fatal message, the injuring plugin or theme is isolated with targeted deactivation (not scorched-earth disabling of everything, which destroys the evidence and sometimes the configuration), then the fix lands at the cause — a compatible rollback, a memory ceiling raised along with the component that was eating it, a repaired syntax error. The site is verified on the front end and in the admin, and you get a written note of what broke, why, and what prevents a repeat. This is one senior developer, async-first, IST timezone; urgent-priority work with a first response inside one business day — not a 3am pager, stated plainly.
If the white screen arrived alongside strange admin users, unfamiliar files, or content you did not write, treat it as a possible compromise instead — that is the structured track on the hacked-recovery page. If a specific update triggered it, the broken-update page covers the rollback and the staging discipline that prevents the next one. And when the site is stable again, the boring answer — updates tested before they touch production — is what makes white screens stop happening at all. General urgent triage lives on the emergency support page.
While you wait — the first 15 minutes
- Write down when it went blank and the last action before it — an update, a new plugin, a settings change, nothing at all
- Check whether the admin works too: /wp-admin/ loading tells you whether the injury is front-end, back-end, or both
- Check your host's status page and recent emails — a PHP version upgrade announcement explains many sudden white screens
- If you are comfortable with FTP, enable WP_DEBUG and the debug log — or simply capture whatever the hosting error log shows
- Do not reinstall WordPress over the site — the content lives in the database and blind reinstalls create second emergencies
- Do not delete plugins blind — deactivation is reversible, deletion can remove configurations and data the fix will need
- Gather hosting panel, FTP/SFTP and database access, note everything you observed, and send it — then step away from the problem. That preparation cuts the diagnosis time hard, and the fixing is not your weekend's job
These steps make every later fix cheaper. Do them in order, note what you changed, and include the notes in the brief.
What the engagement covers
Scope, stated plainly.
- Error-log capture and the actual fatal error identified — not symptom guessing
- Targeted plugin/theme isolation to find the injuring component without wrecking the estate
- Memory-limit fixes done properly: ceiling raised and the consuming component identified and addressed
- PHP version compatibility triage when the host moved the floor under you
- Syntax-error repair from hand edits, with the file's history respected
- Front-end and admin verification after the fix, not just "the homepage loads"
- A written incident note: what broke, why, and the specific thing that prevents a repeat
Honest limits
What to do instead.
A one-person senior practice is the right tool for a lot of emergencies and the wrong one for a few. The wrong ones, honestly:
- A 24/7 on-call promise — one senior, async-first, first response inside one business day
- White screens caused by an expired domain or lapsed hosting — that is the registrar or billing page, not code; check there first and honestly
- A compromise scenario — unfamiliar users, injected content, unknown files belong on the hacked-recovery track, not quick triage
- Host-side PHP outages at the provider layer — those run through host support while the site-level work waits or proceeds around them
- A completion-time guarantee before the error log is read — anyone who quotes a blank screen before looking at it is guessing
After the emergency: stop the next one.
Every rescue ends with the same question — why was this able to happen? The maintenance retainer exists to make the answer boring: updates applied, backups tested, monitoring in place.
Questions
Asked in emergencies.
Usually, but not always. Plugin and theme conflicts are the most common cause, followed by memory exhaustion, PHP version changes at the host, and hand-edit syntax errors. The error log removes the guessing — the fatal message names the file and line, and the diagnosis starts there rather than at trial and error.
No — posts, pages, orders and users live in the database, and a white-screen fix does not touch the database. What loses content is panic: reinstalling WordPress over the site or deleting components blind. The safe order is diagnose, fix at the cause, verify — and the data is never the thing being operated on.
The front end and the admin are different render paths loading different code. Admin working while the site is blank points at a theme or front-end plugin; site fine while admin is blank points at something in the admin load path. Either way the pattern is diagnostic gold, which is why the first step is always checking both.
The honest shape: once the error log is read, many white screens resolve within hours of urgent-priority work — the fatal error names the problem and the fix is targeted. Tangled cases (a conflict between several components, or a PHP-version compatibility web) take longer, and you get that assessment after the log is read, not before. Anyone quoting in minutes without looking is selling you a guess.
Other rescue work
WordPress Emergency Support
Your WordPress site is down, broken, or erroring and it cannot wait for the normal queue. Urgent work is slotted ahead of it — with an honest first response and realistic expectations.
WordPress Hacked Recovery
A hacked site is an incident, not a scramble. Recovery follows a standard sequence — isolate, backup, clean, patch, harden, rescan, monitor — with timelines scoped for realism, not false promises.
Website Takeover — When Your Developer Disappears
Your developer vanished, or the relationship ended badly, and you are locked out of your own website. This rescue recovers access, audits what you actually own, and takes the site back — properly.
"Error Establishing a Database Connection" — Rescue
That single error line means WordPress reached your server but could not open its database — a dead end with roughly four known doors. Finding which door is the whole job, and each has a different fix.
WordPress Emails Not Sending or Landing in Spam
Contact forms that never arrive, order confirmations in the spam folder, password resets that vanish. WordPress mail failure is an infrastructure problem wearing a plugin costume — and the fix lives at the email layer, not in the form.
Locked Out of wp-admin — Every Route Back In
The reset email never comes. The username is not recognized. Or the developer who held the keys has gone quiet. Lockout is the most common access emergency — and nearly every route back in is documented, legitimate, and ends with the keys in your name.