Fix the WordPress Critical Error: Step-by-Step (2026)

You refresh your site and instead of your homepage you get a single line: “There has been a critical error on this website.” No details, no clues, and possibly no wp-admin either. This is the WordPress critical error, and it means one thing: a fatal PHP error stopped WordPress from finishing the page.

The good news: your posts, pages, and database are almost certainly untouched. The error page replaces a fatal error; it doesn’t delete anything. This guide fixes a WordPress critical error the log-first way: read the real error, match its signature, then apply the one fix that fits — usually in minutes, not hours.

Last verified: 7 October 2026, against the official WordPress debugging documentation and current WordPress.org requirements.

Table of Contents

What “There Has Been a Critical Error on This Website” Actually Means

Since WordPress 5.2, fatal PHP errors no longer produce a blank white screen. Instead, WordPress catches the fatal error and shows the critical error message. Common triggers:

A plugin update that conflicts with another plugin, your theme, or your PHP version
Custom code pasted into a theme’s functions.php with a syntax or logic error
The PHP memory limit being exhausted by a heavy plugin or page builder
A plugin or theme that calls a PHP function your server’s PHP version doesn’t have
Corrupted core files from an interrupted update
Malware or incorrect file permissions (rare, but real)

The message hides the real error on purpose — showing raw PHP errors to visitors would leak your file paths. Your job is to make WordPress tell you what happened, while visitors keep seeing the safe page.

Step 0: Scope the Damage Before Touching Anything

Two minutes of observation saves twenty minutes of wrong fixes. Answer these before you change a single file:

Where does the error appear? Every page, only wp-admin, or only one page? An error only in wp-admin points at a plugin or theme; an error everywhere points at something lower-level.
What changed last? A plugin update, theme update, new code snippet, PHP version change, or migration right before the crash is your prime suspect. Write it down with the time.
Is it a cached page? Clear your browser cache or open the site in a private window. If you’re behind Cloudflare or a caching plugin, purge that cache too. Occasionally the real problem is already gone and you’re staring at a stale error page.

With that noted, work through the steps below in order — fastest to slowest.

Step 1: Check Your Admin Email for the Recovery Mode Link

WordPress ships with a safety net called Recovery Mode (introduced in WordPress 5.2). When a fatal error hits your dashboard or login page, WordPress emails your admin address with the subject line “[Your Site Name] Your Site is Experiencing a Technical Issue” and a one-time login link. Clicking it logs you into wp-admin with the broken plugin or theme paused — just for your session — so you can deactivate or update it.

Check your inbox and spam folder for that subject line. Two caveats, confirmed against how WordPress core behaves:

Recovery Mode only fires for errors on the dashboard or login page. A fatal error that only breaks the front end won’t trigger it — no email will come.
WordPress sends at most one recovery email per day. If errors keep firing, you won’t get a fresh email for each one.

No email? Don’t wait for one. You can go straight to the Recovery Mode login yourself at:

yoursite.com/wp-login.php?action=entered_recovery_mode

Once inside, WordPress shows a banner naming the broken plugin or theme. Deactivate it, then log out and back in normally to confirm the critical error is gone.

Step 2: Read the Real Error in debug.log (The Step Most People Skip)

The critical error page hides the actual PHP error. WordPress’s built-in debug logging reveals it. Connect via FTP/SFTP or your host’s file manager, open wp-config.php in the site root, and add these three lines above the line that reads /* That's all, stop editing! Happy publishing. */ (replacing any existing define( 'WP_DEBUG', false );):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

This turns on debugging, writes every error to wp-content/debug.log, and keeps errors hidden from visitors (WP_DEBUG_DISPLAY stays false on a live site). Reload the broken page once to trigger the error, then open wp-content/debug.log and scroll to the bottom — the newest entry is what matters. Look for lines starting with PHP Fatal error:

[07-Oct-2026 13:02:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function some_plugin_init() in /home/user/public_html/wp-content/plugins/bad-plugin/bad-plugin.php:212

Now match the path and the error type against this signature table:

Log signature	What it means	Jump to
`Call to undefined function … in …/wp-content/plugins/…`	Plugin calls a PHP function your server’s PHP version lacks — a version mismatch	Step 6
`Allowed memory size of … bytes exhausted`	PHP hit its memory ceiling	Step 5
`Cannot redeclare class … / Cannot redeclare function …`	Two plugins (or a plugin and a snippet) define the same thing — conflict	Step 3
`syntax error, unexpected … in …/wp-content/themes/…/functions.php`	Broken custom code in the theme	Step 4
`… in …/wp-content/plugins/some-plugin/…` (any fatal)	That plugin is the culprit	Step 3
`… in …/wp-content/themes/your-theme/…` (any fatal)	The theme is the culprit	Step 4
`… in …/wp-includes/… or …/wp-admin/…`	Core files are likely corrupt	Step 7

Turn debugging off when you’re done. Set WP_DEBUG back to false and delete wp-content/debug.log. A debug log left running on a live site grows forever and can expose your server paths to anyone who guesses the log’s URL.

Step 3: Isolate the Guilty Plugin (The Most Common Cause)

Plugins cause the majority of WordPress critical errors, usually right after an update. If you can’t reach wp-admin, deactivate all plugins at once from the filesystem:

Connect via FTP/SFTP or your host’s file manager and open wp-content/.
Rename the plugins folder to plugins-off. WordPress can no longer find any plugin files, so it treats every plugin as inactive.
Reload your site. If it loads, a plugin was the culprit — confirmed in one move.

Now find which one. Rename the folder back to plugins, log into wp-admin (everything will show as deactivated — your settings are safe), and reactivate plugins one at a time, checking the site after each. When the critical error returns, you’ve found it. Leave it deactivated and update it, roll it back, or find an alternative.

If the log named a specific plugin, skip the wholesale step and rename just that plugin’s folder (e.g. bad-plugin → bad-plugin-off). Faster, and it doesn’t disturb your other plugins.

One thing most guides miss: check wp-content/mu-plugins/ too. Must-use plugins load automatically and don’t appear in the Plugins screen — renaming the plugins folder doesn’t disable them. A rogue mu-plugin can crash everything while remaining invisible in your dashboard.

Step 4: Rule Out the Theme

If plugins weren’t the problem, the active theme (or a child theme’s functions.php) is next. Without wp-admin, rename your active theme’s folder — e.g. mytheme → mytheme-off. WordPress detects the missing theme and falls back to an installed default theme such as Twenty Twenty-Four. If the site loads, the theme or its custom code caused the crash.

If no default theme is installed, the fallback won’t work — upload a fresh copy of a default theme first, then rename the broken one. When the log points at functions.php, look at whatever was added there last; that’s usually the offending code.

Step 5: Raise the PHP Memory Limit

Heavy plugins — page builders, WooCommerce, security suites — can exhaust PHP’s memory on a single request. The log signature is unmistakable: Allowed memory size of 134217728 bytes exhausted. WordPress defaults to 40 MB, which is tight for a modern plugin stack.

Add this to wp-config.php, above the “stop editing” line:

define( 'WP_MEMORY_LIMIT', '256M' );

Reload the site. If the error clears, memory was the ceiling. This raises the limit for the front end; some hosts also let you set it in the hosting panel. Note the honest caveat: if the error returns after you raise the limit, something is genuinely leaking or looping — the fix is finding the offending plugin (Step 3), not endlessly raising the number.

Step 6: Fix a PHP Version Mismatch

This is the sneakiest cause, and a real case study published this year traced a critical error to exactly it: a plugin update started calling PHP functions the server’s old PHP version didn’t have. A backup wouldn’t have fixed it — the same crash would have returned on the next auto-update.

WordPress.org currently recommends PHP 8.3 or greater, and its hosting handbook points production sites at 8.4. Anything on PHP 7.4 or 8.0 is end-of-life with no security fixes; PHP 8.1 lost security support at the end of 2025 and 8.2 follows at the end of 2026. A log line like Call to undefined function right after a plugin update almost always means the plugin moved forward and your server didn’t.

Check your current version under Tools → Site Health → Info → Server in wp-admin, or in your hosting control panel’s PHP selector (cPanel → Select PHP Version, and most panels have an equivalent). To fix:

Take a backup before changing server settings.
Test the new PHP version on a staging copy if your host offers one.
Switch PHP in the hosting panel, clear any server-side cache, reload the site, and skim debug.log again — jumping several major versions can break other old plugins even while it fixes the one that crashed.

Step 7: Reinstall WordPress Core Cleanly

If the log points at wp-includes or wp-admin files — or nothing else has worked — your core files may be corrupt, often from an interrupted update. You don’t need FTP for this one:

Go to Dashboard → Updates in wp-admin (or Recovery Mode if needed).
Click Re-install Now. This downloads a fresh copy of WordPress and replaces the core files.

It touches only core — your wp-content folder, themes, plugins, and wp-config.php are left alone. If you can’t reach the dashboard at all, the manual equivalent is re-uploading the wp-admin and wp-includes folders from a fresh WordPress download over FTP.

Step 8: Check for a Botched Update

Sometimes the error appears right after a core, plugin, or theme update that never finished. Two quick checks:

Stale maintenance file: an interrupted core update can leave a .maintenance file in the site root that keeps the site stuck. If the update actually finished, deleting this file restores the site.
Upgrade backups: since WordPress 6.3, the updater stashes the replaced plugin or theme in wp-content/upgrade-temp-backup/ before installing the new version. If an interrupted update deleted a plugin folder, the old copy is often still sitting there — move it back into wp-content/plugins/, reactivate it, and run the update again on its own.

When It’s Not a Bug: Hacked or Exhausted Server

Most critical errors are ordinary software failures. But if the log shows nothing conclusive and the error keeps returning, consider two darker causes:

Malware: injected code can break PHP execution or eat resources until the site fails. Warning signs: unfamiliar administrator accounts, files or plugins you never installed, spam pages showing in Google, or redirects to odd domains. This is a hack-recovery job, not a settings tweak — restore from a backup you trust.
Server resources: on cheap shared hosting, disk space exhaustion or a killed database can surface as a critical error. Your host’s error logs (cPanel → Errors, or the panel’s log viewer) see things WordPress never logs.

When to Stop and Call a Developer

You’ve done the right work if you reach this point. Stop guessing and get help when:

The log names no plugin or theme and points at wp-includes even after a core reinstall
The error only appears during background tasks (cron, imports) — Recovery Mode never fires for these
You find signs of compromise (unknown admin accounts, unfamiliar files)
The database itself is corrupted (that’s a different repair — WP_ALLOW_REPAIR or phpMyAdmin table repair)

Bring the developer your notes from Step 0 and the newest PHP Fatal error lines from debug.log. That ten-minute record is worth more than an hour of them re-discovering the problem.

Keep the WordPress Critical Error From Coming Back

Stage your updates: update plugins one at a time on a staging copy, not all at once on production.
Keep PHP current: run what WordPress.org recommends (8.3+) — plugin authors are moving on, and old PHP is where version-mismatch crashes come from.
Back up on a schedule and test restores: a backup nobody has restored from is a guess, not a safety net.
Keep one default theme installed: it’s your fallback when the active theme breaks.
Uptime monitoring: a monitor catches the crash before a customer tells you about it.

How to Fix the WordPress Critical Error (Log-First Debugging Guide, 2026)