WordPress critical error: what it means and how to fix it safely

You open your website and see one line: There has been a critical error on this website. No menu, no content, sometimes not even the login page. It’s one of the most common jobs I get, and the good news is that it almost always has one clear cause: a plugin, a theme, a line of custom code or a server setting.

When I fix WordPress critical error messages on client sites, I work in the same order every time. You can follow most of it yourself with access to your hosting panel.

What the message actually means

WordPress shows this message when PHP hits a fatal error and has to stop. Since version 5.2, instead of printing the raw error or a blank white page, WordPress hides it and shows the friendly line. The real error is still there. You just need to know where to look.

In wp-admin and on the login page, the message adds Please check your site admin email inbox for instructions. That email, with the subject Your Site is Experiencing a Technical Issue, names the plugin or theme that failed and includes a recovery mode link. Check your inbox and spam folder first.

The email goes to the Administration Email Address under Settings > General, or to a RECOVERY_MODE_EMAIL address set in wp-config.php, and that’s often an old inbox nobody reads. WordPress also sends it at most once a day by default, so if it was deleted, go straight to the logs.

The usual causes

• A plugin or theme update that doesn’t work with your PHP version.
• Two plugins that clash with each other.
• A host that upgraded PHP and left an old plugin behind.
• Custom code in functions.php or a snippets plugin with a typo.
• PHP running out of memory on a heavy page, often in WooCommerce.

A safe way to fix WordPress critical error messages

The order matters. The goal is to find the real cause without making things worse.

1. Take a full backup first. Files and database. If wp-admin is down, use the host’s backup tool or export the database in phpMyAdmin. Never start a fix without a way back.
2. Use the recovery mode link from the email. It logs you in with the broken plugin or theme paused, but only for you, so visitors still see the error until you deactivate, update or replace it. Exit Recovery Mode is in the admin bar.
3. Read the actual error. Turn on logging (lines below), reload the broken page and open wp-content/debug.log or your host’s PHP error log. It names the file and line that failed, usually inside one plugin or theme.
4. Deactivate the culprit. Without wp-admin, rename that plugin’s folder in wp-content/plugins through the host’s file manager or FTP, for example by adding -off. WordPress deactivates it automatically. If the log points at the theme, rename its folder and WordPress falls back to a default theme, as long as one is installed.
5. Fix the cause, not just the symptom. Update the plugin, roll back to the last working version (Advanced View on its WordPress.org page has older downloads), or replace it. If PHP is the problem, Tools > Site Health > Info > Server shows your version; check which plugins aren’t ready before you switch.
6. Test what matters. Forms, checkout, payments and logins. A site that loads isn’t the same as a site that works.

The debug lines for wp-config.php

Add these above the line that says That’s all, stop editing!, as the WordPress debugging guide shows:

• define( 'WP_DEBUG', true ); switches debug mode on.
• define( 'WP_DEBUG_LOG', true ); writes errors to wp-content/debug.log.
• define( 'WP_DEBUG_DISPLAY', false ); keeps errors off the screen, so visitors never see file paths.

If a WP_DEBUG line already exists, change it rather than adding a second. Write true and false without quotes, because 'false' in quotes counts as true.

What the log is telling you

Each fatal error line names a file and a line number. The folder after /plugins/ or /themes/ in that path is usually the culprit. The words before it say why:

• Allowed memory size exhausted: PHP ran out of memory. WordPress asks for 40MB by default on a single site, and WP_MEMORY_LIMIT raises that within your host’s cap. Find out what’s using it, too.
• Call to undefined function: code calls something that no longer exists, often after a PHP upgrade or with an add-on’s main plugin off.
• Cannot redeclare: the same function loads twice, typically a snippet pasted into both functions.php and a snippets plugin.
• Syntax error, unexpected: a typo in custom code, at the file and line shown.
• Uncaught TypeError: older code that newer PHP versions are stricter about.

Things I would not do

• Deleting plugins at random until the error goes away. You lose settings and never learn the cause.
• Leaving debug mode switched on afterwards. On many servers anyone who knows the address can open debug.log, so delete it when you’re done.
• Restoring an old backup without checking what changed since. You can lose orders or form entries.

When the first fix doesn’t work

• The log stays empty. Check the debug lines sit above the stop editing line and that wp-content is writable. Errors that happen before WordPress loads only reach the host’s PHP log. On many cPanel hosts, that’s a file named error_log in the site’s main folder.
• The error only appears in wp-admin. That points to a plugin that loads only there, or to memory. WordPress has a separate WP_MAX_MEMORY_LIMIT for the admin.
• Renaming the plugin folder changed nothing. Clear the server and CDN cache, then check wp-content/mu-plugins: must-use plugins can’t be switched off from the Plugins screen, so rename the file instead. Leftover drop-ins such as advanced-cache.php can fail too.
• It comes back after every update. Turn off auto-updates for that plugin until its developer ships a fix, and test the next version on staging.
• The log names files you don’t recognize, such as PHP in uploads. That can mean a hack, not a bug, and my malware removal service covers that cleanup.

Quick checklist

• Full backup of files and database taken.
• Recovery email found, or the debug log switched on.
• Failing file and line noted from the log.
• Culprit deactivated through recovery mode or a folder rename.
• Cause fixed: update, rollback, replacement, PHP version or memory.
• Forms, checkout, payments and logins tested.
• Conversion tracking still firing (here’s how I test it).
• Debug mode off and debug.log deleted.

Questions I get about the critical error

Will I lose my content?

Almost never from the error itself. Posts, orders and settings live in the database, and a fatal error only stops PHP from building the page. The risk is rushed fixes, like restoring an old backup over new orders.

Why did it break when nobody changed anything?

Something did, just not by hand. Plugins, themes and WordPress can update automatically, hosts upgrade PHP on their own schedule, and growing data can push a page past its memory limit.

Can I fix it without FTP?

Often, yes. The recovery link needs no file access, and most hosting panels have a file manager. With SSH, WP-CLI can switch a plugin off: wp plugin deactivate plugin-name --skip-plugins.

When to call for help

If the site makes you money, every hour it’s down costs real orders or leads. If the error log doesn’t make sense, or the fix touches WooCommerce checkout or payments, it’s worth getting someone who has seen the error before. I fix most critical errors within 24 hours, with a backup taken first and a short note on what broke and how to avoid it next time. A care plan with updates tested on staging stops most repeats.

See how I fix WordPress errors, or send me your site link for a free look.