Why WordPress Shows This Instead of a Real Error
Since WordPress 5.2, a PHP fatal error no longer produces a blank white screen by default — it shows "There has been a critical error on this website" instead, along with a link to the WordPress.org troubleshooting page. That's an improvement over a silent white screen, but the message itself still doesn't tell you what actually broke. It's a symptom, not a diagnosis. The real cause is sitting in your server's PHP error log, and finding it is the first real step, not an optional one.
Step 1: Enable Debug Logging to See the Real Error
Connect to the site via FTP or your host's file manager and open wp-config.php in the site's root directory. Find the line that says /* That's all, stop editing! Happy publishing. */ and add these lines just above it:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reload the site once, then check /wp-content/debug.log. It will contain the exact PHP fatal error — typically naming a specific plugin file and line number, for example a call to an undefined function inside a plugin that hasn't been updated for the current PHP version. That single log entry tells you exactly what to disable next, instead of guessing.
Step 2: If You Can't Even Reach wp-config.php Yet
If the critical error also blocks wp-admin and you don't have FTP access handy, WordPress 5.2+ automatically emails the site administrator a special "recovery mode" link the first time a fatal error occurs. Check the inbox tied to the admin account — that link lets you log in to a safe-mode wp-admin where the broken plugin or theme is visible but not active, so you can deactivate it through the normal dashboard instead of the file system.
Step 3: Force-Deactivate Plugins to Confirm the Cause
If a plugin is the cause — which it is in the large majority of critical-error cases — the fastest confirmation is renaming the /wp-content/plugins folder (to something like plugins-disabled) via FTP or your host's file manager. WordPress can't find any active plugins, deactivates them all, and the site typically loads again immediately. Rename the folder back to plugins afterward; every plugin will show as deactivated in wp-admin rather than actually removed.
From there, reactivate plugins one at a time, reloading the site after each one. The moment the critical error returns, you've found the plugin responsible. Update it, replace it, or contact its developer — don't just leave it deactivated indefinitely if the site depends on what it does.
Step 4: If It's the Theme, Not a Plugin
If deactivating every plugin doesn't resolve it, the theme itself is the likely cause. Via FTP, rename the active theme's folder inside /wp-content/themes. WordPress will automatically fall back to a default theme (like Twenty Twenty-Four) if it's present. If the site loads on the default theme, the problem is in your theme's code — often a function that assumes a plugin is active when it isn't, or a theme update that wasn't tested against your current plugin set.
Why This Keeps Happening After Updates
Critical errors cluster right after a core update, a PHP version bump, or a plugin update — because those are exactly the moments when previously-compatible code stops being compatible. A plugin that hasn't been updated in two years can work fine for months, then break the instant the server's PHP version is upgraded or a core update changes a function it depended on. The fix above gets the site back up after the fact. The way to stop it from happening in the first place is testing every update — core, plugin, and theme — on a staging copy of the site before it touches production, so a conflict like this gets caught before customers see a critical error instead of after — the same staging and validation process prevents most of the errors on this list.
