WordPress critical error: what causes it and how to fix it

What the critical error message actually means

Since WordPress 5.2, a fatal PHP error no longer shows a raw stack trace to visitors. Instead WordPress catches it, displays a generic message, and emails the site administrator a recovery link. The generic message is deliberate, because stack traces leak file paths and software versions that are useful to attackers. It is also, unhelpfully, completely uninformative to you.

The important thing to understand is that this is a symptom, not a diagnosis. Something in PHP threw a fatal error: a function that does not exist, a class that failed to load, a call to a method on null, or a script that ran out of memory. Your job is to find which one, and WordPress has already recorded the answer somewhere.

Step one: check the recovery email

WordPress sends a message to the administrator email address with the subject line indicating a technical problem on the site. It contains a recovery-mode link that logs you into wp-admin with the failing plugin or theme temporarily disabled, and crucially it names the file that caused the error.

That email is the fastest route to an answer, and it is also the one most often missed, because it lands in whatever inbox was configured when the site was built. If you manage client sites, that address is frequently a former employee or a generic mailbox nobody reads. Checking and correcting the administrator email across a portfolio is worth doing before you need it.

Step two: read the error log

If the email is unavailable, enable debug logging by editing wp-config.php and setting WP_DEBUG and WP_DEBUG_LOG to true while setting WP_DEBUG_DISPLAY to false. That last one matters: it writes errors to a file rather than printing them to visitors.

Reload the failing page once, then read wp-content/debug.log. The final entries will name the file and line number where PHP gave up. In the overwhelming majority of cases, the file path tells you which plugin or theme is responsible without any further investigation.

When a WordPress update failed: common causes in order

A plugin or theme update

This is by far the most frequent cause. A plugin updated, the new version calls a function your PHP version does not have or conflicts with another plugin, and the site dies. If the error appeared immediately after an update, you already know the cause.

To confirm without admin access, rename the plugin's folder in wp-content/plugins/ via SFTP or your host's file manager. WordPress will deactivate it automatically because the files have vanished. If the site returns, you have your culprit. If you cannot tell which plugin, rename the whole plugins directory to disable everything, confirm the site loads, then rename it back and disable plugins one at a time.

A PHP version mismatch

Hosts upgrade PHP, sometimes with limited notice. A plugin or theme that has not been updated for a while may use syntax or functions removed in newer PHP versions. The error log will typically show an undefined function or a syntax error rather than a plugin conflict.

Most hosting control panels let you roll the PHP version back temporarily. Do that to restore service, then update or replace the offending component before switching forward again. Staying on an end-of-life PHP version indefinitely is not a fix, because it stops receiving security patches.

Exhausted memory limit

If the log mentions allowed memory size exhausted, PHP ran out of memory. Raising WP_MEMORY_LIMIT in wp-config.php will often restore the site, but treat that as a tourniquet rather than a cure. Something is consuming an unusual amount of memory, and it is usually an inefficient plugin, an import running on every page load, or a query returning far more rows than it should.

A corrupted core file

Less common, but it happens after a failed update or a partial file transfer. Download a fresh copy of WordPress matching your version, and replace the wp-admin and wp-includes directories entirely. Do not touch wp-content or wp-config.php.

The faster route: restore, then investigate

If the site is a live client site earning money, debugging on production is the wrong priority order. Restore your most recent good backup first, get the site working, and then reproduce the fault on a staging copy where nobody is watching.

This only works if the backup is recent and if it restores. Both assumptions fail more often than agencies expect, which is why restore testing on a schedule matters more than backup frequency. A daily backup you have never restored is a hypothesis, not a safety net.

How to stop it happening again

• Take a restore point immediately before every update, automatically rather than by remembering
• Verify the site still works after each update, rather than assuming a successful update means a working site
• Roll back automatically when a post-update health check fails
• Keep PHP versions current across the portfolio and know which sites are behind before the host forces the issue
• Correct the administrator email on every site so recovery messages reach someone who reads them
• Test restores on a schedule so you know your backups work

None of these are exotic. They are the difference between a fatal error being an incident and a fatal error being a line in a report the client never has to read.