Fix the WordPress Critical Error

When WordPress shows “There has been a critical error on this website”, PHP has hit a fatal error and stopped. The screen is a safety curtain, not a diagnosis. Below is the exact order a specialist works through — designed to find the real cause while keeping a way back at every step.

Step 1 — Check the recovery email before anything else

Since WordPress 5.2, a fatal error triggers an email to the site administrator titled around “Your site is experiencing a technical issue”. It usually names the exact plugin or theme and includes a recovery-mode link that logs you in with the faulty component paused. Check that inbox (and spam) first — it often solves the incident in one click. If the email never arrived, the site cannot send mail, which is a finding in itself.

Step 2 — Read the actual error

The generic message hides the detail, but PHP has written it down. Enable logging to a protected file by adding this to wp-config.php above the “stop editing” line:

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

Reload the failing page, then open /wp-content/debug.log. The last Fatal error line names the file, the line number and the function. Never set WP_DEBUG_DISPLAY to true on a live site — it leaks paths and plugin names to visitors. Your host’s PHP error log works just as well if you have access to it.

Step 3 — Isolate the plugin, safely, one by one

If the log points at a plugin, or you have no admin access at all, the fastest safe test is at file level over SFTP or the hosting file manager:

1. Rename /wp-content/plugins to plugins_off. That disables every plugin at once. If the site returns, the cause is a plugin.
2. Rename it back to plugins. WordPress now sees the plugins as deactivated.
3. Re-enable them one at a time — from the admin, or by renaming each plugin’s own subfolder back — reloading the site after each. The one that brings the error back is your culprit.

This is slower than deactivating everything in bulk, but it tells you precisely which plugin failed instead of just making the symptom vanish and destroying the evidence.

Step 4 — Rule the theme in or out

If plugins are not the cause, temporarily switch to a default theme (such as Twenty Twenty-Four). If you cannot reach the admin, rename the active theme’s folder inside /wp-content/themes — WordPress falls back to a default theme automatically. If the error clears, the fault is in the theme or a recent theme edit.

Step 5 — Memory and PHP version

If the log shows “Allowed memory size exhausted”, raise the limit in wp-config.php with define('WP_MEMORY_LIMIT', '256M'); — and note that many hosts cap this at server level, so confirm it actually applied. If the fatal error mentions an undefined function or a syntax the interpreter rejects, you are almost certainly on a PHP version the component no longer supports; test a compatible version rather than leaving the site on an unsupported one.

Before any of this: preserve a way back

Take a backup or snapshot of the current broken state before editing files. It costs minutes and it is what lets you undo a change that makes things worse. If custom code in functions.php caused the fatal error, restore the previous version rather than patching blind.

When it is worth calling a specialist

Escalate if there is no backup, the error touches checkout or customer data, the log points at core files you do not recognise, or the site is also redirecting or showing unknown users — that last combination suggests a compromise, not a configuration fault. If you would rather not touch wp-config.php or SFTP at all, send the URL, the exact error and the recent changes and the case can be assessed before any access is requested.