Short answer: a white screen means PHP stopped executing and WordPress is hiding the error from visitors. The error still exists — it is written to a log. Your job is to read that log, then isolate the component, not to guess.
First, map where the blank appears
Load the front page, a single post, and /wp-admin/. A blank front end with a working admin points at the theme or a front-end plugin. Everything blank, admin included, points at a global fault — memory, a must-use plugin, PHP, or a corrupted core file. This one observation removes half the possibilities.
Turn on the log, not on-screen errors
Add these three lines to wp-config.php, just above /* That's all, stop editing! */:
define('WP_DEBUG', true);define('WP_DEBUG_LOG', true);define('WP_DEBUG_DISPLAY', false);
Reload the blank page and open /wp-content/debug.log. The last Fatal error line names the file, the line and the function. Keep WP_DEBUG_DISPLAY off so errors never render to visitors — they leak file paths and plugin names. If you have hosting access, the server’s PHP error log carries the same detail.
Isolate plugins over SFTP, one by one
If the log blames a plugin, or you cannot reach the admin at all, work at file level:
- Over SFTP or the hosting file manager, rename
/wp-content/pluginstoplugins_off. That disables every plugin at once. If the page returns, a plugin is the cause. - Rename the folder back to
plugins. WordPress now shows the plugins as deactivated. - Re-enable them one at a time and reload after each. The one that brings the blank screen back is the culprit — which is what you actually need to know, rather than just clearing the symptom.
Rule the theme in or out
If plugins are clear, rename the active theme’s folder inside /wp-content/themes. WordPress falls back to a default theme automatically, and if the blank screen clears, the fault is in the theme — most often a recent edit to functions.php or a template calling a function removed in a newer PHP version.
Memory and incomplete files
If the log says “Allowed memory size exhausted”, add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php — and note many hosts cap this at server level, so confirm it applied. A blank screen that began right after an upload or migration can mean missing files; reinstalling WordPress core over itself replaces core files without touching your content.
Preserve first, then verify
Back up the current state before editing, and remove the debug constants when you finish so a log file does not sit exposed. A loading home page is not proof — re-test the exact route that failed, sign in to the admin, and submit a form, because a memory or PHP-compatibility cause is often waiting on another page.
See the official WordPress debugging documentation for the supported constants.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
A white screen is not a diagnosis. The useful distinction is whether PHP failed before WordPress loaded, while a plugin or theme was loading, or only on one route.
Compare the front page, one inner URL and /wp-admin/ to map the scope.
Read the server PHP log as well as debug.log; an early bootstrap failure may never reach WordPress logging.
Record the exact PHP version and the most recent deployment or update.
Disable only the component named by the fatal error before testing broader isolation.
What must be verified
- The exact failed URL loads twice without a new fatal error.
- The administrator and a business-critical form or checkout path work.
- Debug display is off and temporary logging is removed or protected.
Official technical sources
Continue the diagnosis
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →