When WordPress shows a white screen of death—a blank page with no theme, no Admin chrome, and usually no helpful message—PHP often failed before anything could print. That is different from the modern “There has been a critical error on this website” screen. If you see that critical-error page, use the critical error checklist instead of this one.
Work this checklist in order. Prefer staging when you can reproduce the blank page there. Take a backup before renaming plugins or editing wp-config.php on production. Once a normal page loads again, restore only changes that are safe. Keep the faulty plugin disabled or use a working theme until the cause is repaired or replaced. After restoring a plugin folder name, check its activation state; reactivate only safe plugins, one at a time, and retest. Do not automatically restore the failing theme. Recheck homepage, Admin, forms, and checkout if you use them. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix after you can authorize access.
Blank page versus critical error versus “site down”
- White screen / blank page — browser gets a response, but the body is empty or nearly empty. No WordPress critical-error template. Often a PHP fatal with errors hidden, an early exit, or output never started.
- Critical error page — WordPress (or recovery mode) renders a message. Follow critical error on this website.
- Site down / connection failure — DNS, SSL, or host not answering. Follow site down or not loading.
- HTTP 403 / 500 / 502 — status code page from the server or proxy. Follow 403/500/502 errors.
Define what failed
- Note whether the blank page hits the homepage, only
/wp-admin, only after login, or every URL.
- Try a private window. If a cached HTML shell appears for visitors but Admin is blank (or the reverse), say so—that changes where you look.
- Write down the last change: plugin/theme/core update, PHP version change, migration, or new snippet.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| Blank everywhere; host error log shows a PHP fatal | Plugin / theme / PHP | File and line in the log; isolate that component on staging |
| Blank after a large import or media-heavy Admin screen | Memory / limits | Host memory_limit and max_execution_time; raise temporarily only as a test |
Public blank; a static file under wp-content still loads | PHP / WordPress bootstrap | PHP-FPM or app pool health with the host; recent deploy |
| Started right after a plugin update | That plugin | Rename only the suspect plugin folder on staging; see plugin not working |
| Blank only in Admin | Admin-only plugin / memory | Disable Admin-heavy plugins on staging; check memory on /wp-admin requests |
Safe triage order
- Read the host error log first. Retry one request that blanks, then open the PHP or web-server error log for that minute. A path under
wp-content/plugins or wp-content/themes is the first suspect. Keep logs private—they can include paths and tokens. Ask the host if you cannot find the log.
- Use debug output carefully. On staging only when possible, turn on WordPress debugging the way your host documents, capture the error once, then turn it off. Do not leave debug display on for public visitors. Prefer logging to a file over printing errors on the blank page in production. Ask your host to store logs outside the public web root or block web access to them. After diagnosis, turn off temporary debug logging and remove or protect the captured logs.
- Isolate plugins and the theme on staging. If the log names a plugin, test that plugin first and change one thing at a time. Keep required login and security dependencies in mind. If Admin is unavailable, rename only the suspected plugin folder on staging and retest. Restore only changes that are safe. Keep the faulty plugin disabled or use a working theme until the cause is repaired or replaced. After restoring a plugin folder name, check its activation state; reactivate only safe plugins, one at a time, and retest. For a theme test, switch staging to an installed default WordPress theme and retest; do not automatically restore the failing theme. Check login, forms, and checkout where used after each safe change.
- Treat a memory increase as a test, not a fix. If the log shows memory exhausted, ask the host whether a temporary higher
memory_limit is allowed for diagnosis. If the blank page disappears only while the limit is raised, find the plugin, query, or import that consumes memory—do not leave an oversized limit as the permanent “solution” without knowing why.
- Rule out cache and opcode layers. Purge page cache and ask the host about OPcache or server cache after a deploy. A blank cached response can survive after you already fixed the PHP error.
- Ask the host about core and PHP. If isolation does not help and logs point at WordPress core or the PHP version, ask the host to verify core file integrity and whether a recent PHP upgrade matches the plugins you run. Partial updates after a timeout can leave core half-written.
- Retest the full path. Load homepage and Admin, complete one normal Admin task, then restore only changes that are safe. Keep the faulty plugin disabled or use a working theme until the cause is repaired or replaced. After restoring a plugin folder name, check its activation state; reactivate only safe plugins, one at a time, and retest. Do not automatically restore the failing theme.
Common causes
- PHP fatal error with display of errors turned off—white page, details only in the log.
- Plugin or theme conflict after an update or PHP version change.
- Memory exhausted on Admin, import, or image-heavy requests.
- Corrupted or incomplete core/plugin files after a failed update.
- Must-use (
mu-plugins) or drop-in files that load even when you “disable all plugins.”
- Cached blank HTML at the CDN or full-page cache after a fixed origin.
- Database connection failures sometimes show other errors—if you see a database message instead of a blank page, use error establishing a database connection.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help with one clearly defined blank-page issue on one WordPress site. Name whether homepage or Admin is blank, when it started, the last change you made, and any host log line you can share (secrets redacted). We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full rebuilds, new custom features, full migrations, account-wide host outages, and multiple unrelated issues are outside this offer. If a plugin update broke the site along with other features, see also plugin update broke WordPress site.
Related checks
If the checks do not identify the cause, send your host the blank URL, start time, and matching log lines. Suspected compromise needs a security investigation as well as restoring normal pages—see site hacked / malware cleanup when security warnings or defacement are present.