GUIDE
A blank white page with no message is WordPress failing before it can render anything. This guide walks through the same isolation order professionals use — safely, in sequence — so you can find the root cause instead of guessing.
The white screen of death (WSoD) looks dramatic, but it is usually a single fatal PHP error. Common triggers include a plugin or theme conflict after an update, PHP memory exhaustion, a corrupted .htaccess or wp-config.php, wrong file permissions, an interrupted update that left a .maintenance file, or database trouble. Work methodically. Take notes. Do not delete files you cannot restore.
Before you change anything: confirm you can reach the site over FTP or your host’s file manager, and that you have a recent backup. If you have neither, stop and get help — recovery without a backup is how content disappears. If your host offers one-click staging, clone the site there first and rehearse the fix off production. If they do not, at least download a zip of wp-content and an SQL dump before you rename folders.
Keep a simple log as you go: time, what you changed, and what happened after a reload. That scrap of discipline is what separates a 20-minute recovery from a three-hour spiral of undoing your own experiments.
Open the homepage and /wp-admin/ in a private browser window. If both are blank for every visitor, you have a server-side failure, not a local cache quirk. Ask yourself what changed in the last hour: a plugin update, theme edit, PHP version bump, migration, or hosting panel tweak. That timeline almost always shortens diagnosis.
Also check whether a CDN or host page cache is serving a stale blank response. Purge those caches if you can. If only one page fails while the rest of the site works, you may be dealing with a template or shortcode error rather than a full WSoD — the same debug steps still apply.
Guessing is slow. Logging is fast. Via FTP or file manager, open wp-config.php in the WordPress root and add these lines above the “That’s all, stop editing!” comment:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reload the broken URL once, then open wp-content/debug.log. Look for the most recent Fatal error or Allowed memory size line. It usually names a plugin path, a theme functions.php line, or a missing class. That single line is your diagnosis.
If no log appears, confirm the wp-content directory is writable, or ask your host where PHP error logs live. Some hosts surface the same fatal error in their control panel without WordPress debug at all.
If the log points at a plugin — or if you have no log yet — deactivate everything in one move. Rename wp-content/plugins to plugins-disabled. WordPress will load with no plugins. If the site returns, the conflict is in that folder.
Create a new empty plugins folder, then move plugins back one at a time (or in small batches), reloading after each move. The plugin that brings the white screen back is the culprit. Leave it out, update or replace it, and only then restore the rest.
Do not bulk-delete plugins from the dashboard while the site is down — you may not reach the dashboard. FTP rename is the reliable path, and it matches how emergency recovery is done when the admin is inaccessible.
If plugins are not the cause, rename the active theme folder under wp-content/themes (for example mytheme to mytheme-off). WordPress should fall back to a default theme such as Twenty Twenty-Four. If the site loads, the problem sits in the theme or a child theme’s functions.php.
Inspect recent edits in functions.php, missing closing PHP tags, or a broken include. Restore a known-good copy of the theme from backup if you are unsure. Avoid editing production theme files under pressure unless you can roll back immediately.
Memory exhaustion is a frequent WSoD cause on WooCommerce and page-builder sites. In wp-config.php you can try:
define( 'WP_MEMORY_LIMIT', '256M' );If the host caps PHP memory below that, raise it in the hosting panel or php.ini / .user.ini as their docs allow. Separately, look in the WordPress root for a file named .maintenance. An interrupted update can leave it behind and serve a maintenance (or blank) state until you delete it.
While you are in the root, confirm there is no half-finished core upgrade. If core files look incomplete, restore WordPress core from a clean copy of the same version — never mix major versions casually.
Standard white-screen recovery is a one-time €129 fix: diagnosis typically starts within 30 minutes, most cases are resolved within six hours, and the process is non-destructive with a 30-day guarantee on the same issue.
€129
Get the white screen fix →A corrupted .htaccess — often after a security plugin change or bad redirect rule — can blank the site. Rename the current file to .htaccess.bak, then visit Settings → Permalinks once the site loads and click Save to regenerate defaults. If you cannot reach admin yet, create a minimal WordPress .htaccess with the standard rewrite block from the Codex documentation for your install type.
Reset permissions to the usual safe defaults: directories 755, files 644. Overly tight or overly open permissions both cause failures. Do not set 777 on production directories as a “fix” — it papers over the problem and creates a security hole.
Also open wp-config.php carefully for syntax errors (a missing quote or semicolon after a manual edit will white-screen the whole site). Restore from backup if the file looks wrong and you are not certain.
Once pages render again, verify the front end, checkout (if you sell), forms, and wp-admin login. Purge host cache, plugin cache, and CDN cache. Turn WP_DEBUG back to false on a live site so errors are not exposed to visitors; keep logging only while you are actively diagnosing.
Write down the root cause. Update the offending plugin or theme on staging next time. Take a backup before bulk updates. If WSoD followed a PHP version change, either fix the incompatible code or temporarily roll PHP back while you plan a proper upgrade. Prefer updating plugins in small batches rather than “Update all” on a Friday evening with no rollback plan.
If WordPress Recovery Mode emails you a link, use it — it can let you reach the dashboard when the front end is still blank. Treat it as a temporary bridge, not a cure. Still identify the fatal error and remove the cause, or the next page load will fail again for ordinary visitors.
Professional recovery follows the same arc at higher speed: stabilise with Recovery Mode and debug logging, isolate plugins and themes, repair config and permissions, then verify and leave prevention notes. That is why a clean DIY pass and a paid fix look similar — the difference is access, experience and how much downtime you can afford.
Stop and hand it over if any of these apply:
A standard WSoD fix is €129 and includes diagnosis, conflict isolation, config and permission repair, verification and a short post-mortem. Express and out-of-hours options exist when you need the site back sooner. Diagnosis starts within about 30 minutes of a clear request; most recoveries finish within six hours, always with zero data loss as the working rule.
White screens often travel with other problems. If Google has flagged the site or visitors are being redirected, read WordPress site hacked: what to do. If the site is up but painfully slow after recovery, follow how to speed up WordPress. Browse all guides on the Guides hub.
White screens, crashes and conflicts — fixed free, as often as needed.
Daily backups · Security monitoring · Priority support · Monthly report
Plans from €29/mo — most clients pick Pro at €59/mo