A fatal error screen locking you out of wp-admin is one of the more panic-inducing things that can happen to a WordPress site, mostly because the error message itself is often unhelpfully vague (“There has been a critical error on this website”) while the actual cause could be anywhere across dozens of active plugins, a theme file, or a corrupted core file. The good news is that fatal errors are almost always mechanically simple to diagnose once you know where to look, because PHP itself tells you exactly what broke and on which line, you just usually need to turn that information on first.
What a “fatal error” actually means, technically
PHP fatal errors happen when the interpreter hits something it fundamentally cannot recover from and continue executing past, calling a function that doesn’t exist, referencing a class that was never loaded, running out of allocated memory, or a syntax error in a file that prevents PHP from parsing it at all. This is categorically different from a warning or notice, which PHP logs but keeps running past; a fatal error stops execution of that request entirely, which is why the whole page, including wp-admin, goes blank or shows the generic error screen instead of partially rendering. Understanding this distinction matters because it tells you the fix has to happen at the file-system or database level, outside the broken PHP execution, since you can’t fix a fatal error by clicking around inside an admin interface that can’t finish loading in the first place.
WordPress’s own built-in recovery mode, since 5.2
Before reaching for FTP or a hosting file manager, check whether WordPress’s own fatal error protection already has you covered. Since version 5.2, WordPress detects a fatal error triggered by a theme or plugin and, if it recognizes the pattern, automatically emails the site administrator a unique, time-limited “recovery mode” link. Clicking that link logs you into a special admin session where the specific broken plugin or theme is paused just for your session, letting you access wp-admin normally to deactivate it properly through the UI without needing any file-system access at all. This feature only triggers for errors WordPress’s own error-catching mechanism can intercept, so it won’t catch every possible fatal error (a syntax error in wp-config.php, for instance, happens before this protection layer can even load), but it’s worth checking your admin email first since it turns what used to require FTP access into a two-click fix for a meaningful share of cases.
Enabling debug mode to see the actual error
If recovery mode didn’t trigger or isn’t available, the next step is making the underlying error visible instead of guessing. Access your files via FTP, SFTP, or your host’s File Manager, open wp-config.php in the root directory, and add or modify these lines above the line reading /* That's all, stop editing! */:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);Setting WP_DEBUG_DISPLAY to false while WP_DEBUG_LOG stays true is deliberate: it keeps the actual error message out of the public-facing page (where displaying raw PHP errors would leak server file paths and potentially sensitive details to any visitor) while writing the full error, including the exact file and line number, to a debug.log file inside wp-content. Reload the site once, then open that log file and look at the most recent entries; the error message will typically name the exact plugin or theme file responsible, which turns the rest of the recovery from guesswork into a targeted fix.
Deactivating plugins without admin access
If the debug log points to a specific plugin, or if you want to rule plugins out entirely as a first pass, you don’t need working wp-admin access to deactivate them. Connect via FTP or File Manager, navigate to wp-content/plugins, and rename the specific problem plugin’s folder (adding -disabled to the end works fine), WordPress can’t find and load a plugin whose folder name no longer matches what it expects, which effectively deactivates it without touching the database. If you’re not sure which plugin is responsible, renaming the entire plugins folder to something like plugins-old deactivates everything at once; if the site loads again, rename it back and then deactivate plugins one at a time, renaming each folder back individually and reloading between each, until the error returns and identifies the culprit. This is slower than reading a clear debug log but works even without one.
Switching themes the same way, if the theme is the suspect
The same renaming trick works for themes: navigate to wp-content/themes and rename your active theme’s folder. WordPress will fall back to a default theme like Twenty Twenty-Four if one is installed, and if the site loads normally after that, the previous theme (or more likely a recent edit to its functions.php) was the source. Since functions.php runs on every single page load including the admin area, a single syntax error introduced there, a missing closing brace, an unclosed string, an accidentally duplicated function name, is one of the single most common causes of a site-wide fatal error immediately following a manual theme edit.
The memory exhaustion error, and why it’s different from the others
A specific, very common fatal error reads something like “Allowed memory size of X bytes exhausted,” and it has a different fix from a broken plugin or theme file: PHP simply ran out of the memory WordPress was allowed to use for that request, usually because a plugin, a large import, or an inefficient query needed more than the configured limit. You can raise this limit by adding a line to wp-config.php:
define('WP_MEMORY_LIMIT', '256M');This raises WordPress’s own internal limit, but it’s capped by whatever your hosting server’s actual PHP memory_limit setting allows, so if your host caps PHP at 128M, asking WordPress for 256M won’t help until the host-level limit is raised too, usually through a support ticket or a setting in your hosting control panel. Raising memory is a legitimate fix for a genuinely memory-hungry but otherwise healthy site, but if the memory exhaustion started suddenly after installing something specific, treat that as the more likely root cause and consider whether that plugin has a memory leak or an inefficient operation rather than just raising the ceiling indefinitely.
Database connection errors look similar but need a different fix entirely
It’s worth distinguishing a genuine PHP fatal error from a database connection error, which produces a similarly blank or broken-looking page but stems from an entirely different cause: WordPress can’t reach or authenticate with the MySQL database, usually because the credentials in wp-config.php no longer match the database (common after a migration or a host changing database server details), or because the database server itself is down or has hit a connection limit. The message “Error establishing a database connection” is the giveaway here, distinct from the generic “critical error” fatal error screen; the fix path is checking and correcting the DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST constants in wp-config.php against what your hosting control panel actually shows, not deactivating plugins or themes at all, since neither of those is the actual point of failure in this scenario.
The .maintenance file trap after an interrupted update
If WordPress was in the middle of updating core, a plugin, or a theme when something interrupted the process, a connection drop, a timeout, a manual page close, it can leave a file called .maintenance in the site’s root directory, which WordPress uses to show a “Briefly unavailable for scheduled maintenance” message during updates and normally deletes automatically once the update finishes. If that file gets stuck because the update never completed cleanly, the entire site, including wp-admin, stays locked in maintenance mode indefinitely even though nothing is actually broken. The fix is simply deleting that file via FTP or File Manager; if the underlying update genuinely didn’t finish, you may need to re-run it afterward, but removing the stuck file at least restores access so you can see what state things are actually in.
WP-CLI as a faster path for anyone comfortable with a terminal
If your host provides SSH access, WP-CLI offers a considerably faster diagnostic and recovery path than manually renaming folders through an FTP client. wp plugin list --status=active shows exactly what’s currently active without needing the admin UI to load at all, and wp plugin deactivate --all deactivates everything in a single command, after which you can reactivate individually with wp plugin activate <plugin-slug> to isolate the culprit far faster than the folder-renaming approach. For anyone managing multiple WordPress sites regularly, investing a little time in learning basic WP-CLI plugin and theme commands pays for itself the first time a fatal error locks out the admin UI, since every fix described above has a WP-CLI equivalent that doesn’t require an FTP client at all.
White screen versus a visible error message: two different starting points
It’s worth distinguishing a completely blank white screen from the more recent, slightly more helpful “There has been a critical error on this website” message, because they indicate different things about your site’s configuration. A totally blank page with nothing at all, the classic “White Screen of Death,” usually means WP_DEBUG_DISPLAY is already off (or PHP’s own display_errors is off at the server level) and the fatal error is being suppressed entirely rather than shown, which is generally the correct production configuration but means you get zero information without checking the debug log or your host’s PHP error log directly. The newer “critical error” message, standard since WordPress 5.2, is WordPress’s own fatal-error handler catching the failure and showing a generic, non-technical message to visitors while still logging the technical detail separately, so seeing that specific phrasing rather than a blank page is actually useful information: it tells you WordPress’s own error-catching layer engaged, which is part of what makes recovery mode emails possible in the first place.
Where to actually find the error log on common hosting setups
Beyond the WordPress-specific wp-content/debug.log file covered earlier, most hosts also keep a separate, server-level PHP error log that captures fatal errors even when WordPress’s own debug constants aren’t configured at all, which matters because you may not have edit access to wp-config.php yet if you’re still working out how to log in. On cPanel-based hosting, this typically lives under “Errors” or “Metrics” in the control panel, or as a raw error_log file sitting in your site’s root or home directory. Managed WordPress hosts like WP Engine, Kinsta, and similar typically expose an equivalent log directly in their own dashboard rather than through cPanel. Checking this server-level log first, before touching wp-config.php at all, can sometimes hand you the exact same file-and-line error information without needing to enable anything yourself.
A concrete, common example: the trailing character that breaks everything
A specific, extremely common real-world case worth knowing by name: a fatal error appearing immediately after editing functions.php or a plugin file directly through the WordPress admin’s built-in theme or plugin editor, where a stray character, an extra closing brace, whitespace after the closing ?> PHP tag, or a single missing semicolon, breaks the file’s syntax entirely. PHP’s parser is unforgiving about this; a single misplaced character is enough to make the entire file fail to parse, which cascades into a site-wide fatal error rather than a contained, local one. This is precisely why WordPress core strongly discourages using the built-in file editor on a live production site at all, a broken save there can lock you out of the very editor you’d use to fix it, and why any direct code edit is safer made through FTP, SFTP, or a code editor with the file open locally, where a typo doesn’t immediately propagate to the live, publicly served version of the file. Many hosts and security plugins now disable the built-in editor entirely by default for exactly this reason, and re-enabling it purely to make a quick one-off change is rarely worth the risk it reintroduces.
Health Check & Troubleshooting: a purpose-built plugin for exactly this
If you can still reach wp-admin at all, even intermittently, or if the error is isolated to specific pages rather than the whole site, the official Health Check & Troubleshooting plugin offers a cleaner alternative to manually renaming plugin folders. Its troubleshooting mode lets you, as a logged-in administrator, temporarily disable all plugins and switch to a default theme for your own browsing session only, while every other visitor continues seeing the site exactly as configured. This is meaningfully safer for diagnosing an intermittent or partial fault than the blanket folder-rename approach, since it doesn’t take the live site down for real visitors while you investigate, and it’s worth having installed proactively on any site you maintain regularly, before you actually need it during an active incident.
Auto-update rollback: a newer safety net worth knowing about
WordPress’s automatic background updates for plugins and themes, expanded significantly in recent core versions, include a fatal-error check that runs immediately after an automatic update completes: if the update introduces a fatal error, WordPress detects it and automatically rolls the plugin or theme back to the previous working version rather than leaving the site broken. This specifically covers automatic background updates, not manual ones triggered directly from the admin’s “Update Now” button, so a fatal error appearing right after you personally clicked to update something manually won’t benefit from this automatic protection the way a silent background update would. Knowing this distinction is useful when diagnosing why a similar-looking update caused a fatal error in one case but not another; it often comes down to which update path was actually used.
Restoring from a backup as the last resort, not the first move
If none of the above resolves things, or if the error appeared after a change you can’t easily identify or undo, restoring from a recent backup remains the reliable fallback, but it’s worth treating as the last option rather than the first, because it can undo legitimate content changes made since that backup ran, and it doesn’t teach you what actually caused the error, which matters if the same cause could recur. Working through the debug log and folder-renaming steps first, even when a backup is available, tends to produce a faster and more surgical fix, one that leaves everything else on the site untouched, whereas a full restore is a broader, blunter tool best reserved for when the specific cause genuinely can’t be isolated in a reasonable amount of time.
The broader pattern across nearly every fatal error scenario is the same: the fix is almost never mysterious once the actual PHP error message is visible, the real difficulty is usually just getting to that message in the first place when the normal admin interface that would show it to you is exactly what’s broken. Building the habit of checking the debug log or your host’s error log as the very first step, before touching plugins, themes, or a backup, turns most fatal-error incidents into a five-minute fix rather than an hour of trial-and-error deactivation. Keeping WP_DEBUG_LOG enabled permanently on a staging copy of a site, even if it’s off on production, also means the next time something breaks after testing a change there first, the exact cause is already sitting in a log file waiting to be read rather than something you have to reconstruct after the fact.
Related reading:
Best WordPress Backup Plugins for Websites