WordPress Critical Error and White Screen Fix
Your WordPress site is either showing a completely blank white page, or the message: “There has been a critical error on this website. Please check your site admin email inbox for instructions.”
Both mean the same thing — PHP encountered a fatal error and could not complete the page load. The difference is WordPress version: sites running WordPress 5.2 or later show the critical error message; older installations or sites with error display suppressed show a blank white page (the “white screen of death”). The causes and fixes are identical.
Every visitor hitting the site sees this until it is resolved. Zero leads, zero calls.
What Triggers the Error
Plugin Failure
The most common cause. A plugin — usually one that auto-updated overnight — contains code incompatible with the current WordPress version or the PHP version on the server. PHP throws a fatal error loading it.
Common scenarios:
- A plugin updated automatically and introduced a breaking change
- WordPress auto-updated to a new major version the plugin is not compatible with
- Two plugins define a function with the same name
See Plugin Conflicts for how plugin-to-plugin conflicts cascade.
Theme Error
A syntax error in a theme’s functions.php file — a missing semicolon, a mismatched bracket — causes a fatal PHP error on every page load. This is common after manually editing theme files. A child theme that references functions removed from the parent theme after an update produces the same result.
PHP Version Mismatch
WordPress 6.x recommends PHP 8.1 or 8.2. If a hosting provider upgrades the server’s PHP version without notice, and installed plugins or themes are not compatible, the site immediately throws critical errors across every page.
To check the PHP version in use: log into cPanel → PHP Selector or MultiPHP Manager.
See WordPress PHP Errors.
PHP Memory Limit Exceeded
WordPress has a configurable memory ceiling. Sites with many active plugins, large pages, or heavy image galleries can hit this limit on load, causing a silent crash — no message, just a blank page. More common on shared hosting where the ceiling is set low by the provider.
Corrupted Core Files
Less common. A WordPress core update interrupted by a server timeout or power cut can leave files in a damaged state. WordPress tries to load a corrupted file and crashes.
How to Fix It
Step 1 — Use the Recovery Link (Critical Error Only)
If you see the critical error message, WordPress sent a recovery email to the admin address. That email contains a temporary link that bypasses the crashed plugin or theme and gives access to the WordPress admin. Use it immediately to deactivate the problematic plugin or switch themes.
If the email did not arrive: check spam. If the admin address is old or incorrect, skip to Step 2.
Step 2 — Deactivate All Plugins via FTP
Connect via FTP or your hosting file manager (cPanel → File Manager). Navigate to /wp-content/plugins/. Rename the entire plugins folder to plugins-disabled. WordPress cannot load any plugins and will attempt to start clean.
Test the site. If it loads, the problem is a plugin. Rename the folder back to plugins, then deactivate plugins one at a time from the WordPress admin until the crash returns — that is the offending plugin.
Step 3 — Switch to a Default Theme
If deactivating plugins does not fix it, navigate to /wp-content/themes/ via FTP. Rename your active theme folder. WordPress falls back to the most recently installed default theme (Twenty Twenty-Four or similar).
If the site loads with the default theme, the error is in your theme files — usually functions.php. Review any recent manual edits to that file.
Step 4 — Enable Debug Mode to Find the Exact Cause
Edit wp-config.php and add these lines:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
This writes the exact error to /wp-content/debug.log without displaying it publicly. The log identifies the specific file, plugin, and line number that caused the crash — the fastest way to pinpoint the problem.
See WordPress Debug Errors for how to read the output.
Step 5 — Increase PHP Memory Limit
Add to wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
If the crash was caused by memory exhaustion (blank white screen with no plugin conflict identified), this resolves it. Most shared hosts allow this override.
Step 6 — Restore from Backup
If none of the above isolates the cause, or if you need the site back online immediately, restore from the most recent clean backup. See Backup Problems for recovery options and what to do if no backup exists.
No FTP Access?
This is where most contractors get stuck. Without FTP credentials or access to the hosting file manager, steps 2–5 are not possible without help.
Options:
- Contact your hosting provider — most can rename the plugins folder or restore a backup via support ticket
- Log into cPanel or Plesk directly and use the built-in file manager
- If your host offers one-click staging restore, use it
Preventing It From Happening Again
- Daily automated backups — gives you a restore point before any update failure. UpdraftPlus (free) on a connected cloud storage is the standard setup.
- Staging environment — test plugin and theme updates on a copy of the site before applying to the live version
- Disable auto-updates for plugins on production — update manually, one at a time, after checking compatibility notes
- Keep PHP current — WordPress recommends PHP 8.1 or 8.2. Older PHP versions have known compatibility issues with current plugins
- Check the site after every WordPress core update — a 30-second frontend and admin check catches problems before they sit unfixed for days
For ongoing maintenance that catches update failures before they take the site down, see Website Maintenance for Contractors.
Related Issues
- WordPress Update Broke Site
- Plugin Conflicts
- WordPress Debug Errors
- WordPress PHP Errors
- Backup Problems
- Hosting Issues
Emergency Recovery
A WordPress critical error or white screen takes the site completely offline. If you do not have FTP access or cannot reach the hosting control panel, technical recovery assistance can typically restore access within a few hours — without needing to rebuild the site.