A blank page is a hidden fatal error
WordPress White Screen of Death: Causes and the Fix Order
Diagnose the WordPress white screen of death, which is a fatal PHP error being hidden rather than a blank page. Work memory limit, then plugin conflict, then theme fault, in that order - the order matters because each test rules out the next. Enable debug output before touching a single file and the screen names its own cause.
The WordPress white screen of death is a fatal PHP error with error display switched off, so the page renders empty rather than showing the failure. Enabling WP_DEBUG reveals the file and line. The usual causes are an exhausted memory limit, a plugin conflict or a theme fault.
Is this what you are seeing?
Tick everything that matches. The result names the cause to start with.
Tick a symptom to narrow it down.
What actually causes it
| Cause | How to confirm | Typical fix |
|---|---|---|
| Fatal error in a plugin or theme | The debug log names the file and line | 20 min |
| Exhausted memory limit | The log reports allowed memory size exhausted | 15 min |
| Theme fault | Switching to a default theme restores the site | 15 min |
| Corrupt core file | A core checksum comparison fails | 30 min |
Nothing rendered, which is itself the clue
A white screen is not an absence of errors. It is a fatal PHP error with display suppressed – the standard production configuration, and a sensible one, because the alternative prints file paths and database detail to every visitor.
So the first move is never to change code. It is to route the error somewhere readable. Two constants in wp-config.php do it, and the log almost always names the exact file.
Which part is blank tells you where to look
The pattern narrows it before any log is read.
Everything blank, admin included. A fatal error early in the load sequence – a plugin, or a corrupt core file.
Front end blank, admin working. The theme. Rename its folder and WordPress falls back to a bundled one.
Admin blank, front end working. Memory, almost every time. Admin screens are heavier than cached front-end pages and hit a ceiling the visitor never approaches.
A blank page is a fatal with the error output hidden, so the same fault elsewhere is quieter still – a contact form that stops sending with no warning at all. A blank page immediately after an update is more often a site stuck in maintenance mode. The WordPress error index covers both.
How to fix it
- Enable debug logging. WP_DEBUG and WP_DEBUG_LOG true, WP_DEBUG_DISPLAY false. The blank screen exists because output is suppressed; this puts the reason in wp-content/debug.log instead of on a public page.
- Read the log and act on the name it gives you. A fatal error identifies its file, which is almost always inside one plugin or the active theme. This single step resolves the majority of cases.
- Raise the memory limit when the log says memory.
define('WP_MEMORY_LIMIT', '256M');in wp-config.php. A blank wp-admin over a working front end is the classic signature. - Rename the plugins folder to test as a group. Over SFTP, rename wp-content/plugins. The site returning means a plugin is responsible; rename it back and bisect by renaming folders individually.
- Switch to a default theme. Rename the active theme folder and WordPress falls back to a bundled one. A site that recovers points at the theme, and almost always at a recent functions.php edit.
- Verify core when nothing else explains it. Compare checksums with WP-CLI, or reinstall core from wp-admin, which replaces core files without touching content, plugins or themes.
When that fix does not hold
Do not edit theme files through the built-in editor in wp-admin. A syntax error saved there takes the site down instantly, including the editor you would need to undo it. Edit over SFTP where a bad save is one rename away from recovery, and set DISALLOW_FILE_EDIT to remove the trap entirely.
Questions people ask before calling
Why is the page blank instead of showing an error?
Production PHP configurations suppress error output so internal detail is not exposed to visitors. The error still occurred; nothing rendered it. WP_DEBUG_LOG writes it to a file instead.
How do I reach a site that is completely blank?
Over SFTP or through the host file manager. Every step above works without wp-admin, which is deliberate - the admin is frequently the first thing to disappear.
The site is blank only for logged-in users.
That points at an admin-only code path: a dashboard widget, an admin notice, or a role-specific query. The log still names it.
Can a white screen mean the site was hacked?
Occasionally. Injected code with a syntax error produces exactly this. Where the debug log names a file you do not recognise, or a core file, treat it as a compromise rather than a bug.
More errors