“There has been a critical error on this website”: what it means and how to fix it

A white page with one line on it: “There has been a critical error on this website.” If you are reading this with that line on your own site, the short version is that PHP crashed partway through building the page. Something changed, and one piece of code can no longer run. The steps below find which piece.

What does “There has been a critical error on this website” mean?

PHP hit a fatal error, and WordPress caught it. Since version 5.2, WordPress catches the crash, shows a stock message in place of the half built page and sends the site’s admin a recovery link. This exact wording has been that message since version 5.6. When nothing catches the crash, the visitor gets an empty page instead, and our test of the WordPress white screen of death shows the same fatal error ending in 0 bytes.

The message names nothing, which is why it is hard to act on. WordPress.org lists five usual causes in its guide to common errors: conflicts between plugins, a theme with compatibility problems, an incompatible PHP version, hitting the memory limit, and corrupted WordPress files.

Finding the cause, and making sure the site does not fall over again next week, is part of our WordPress maintenance work.

How do you find out which plugin or theme caused it?

Work through three places, in this order.

1. The admin email. The address is set under Settings, General. Search that inbox and its spam folder, because WordPress.org’s guide says to start there. What the “technical issue” email contains is laid out line by line in our lab write up. If it arrives, its recovery link opens the login page in recovery mode. Log in, and the broken plugin or theme stays paused for you, so you can deactivate it from the dashboard.
2. Your host’s PHP error log. Many control panels show it. It holds the same line and needs no change to the site.
3. debug.log. Open wp-config.php over SFTP or your host’s file manager. Above the line that says “That’s all, stop editing”, add define( 'WP_DEBUG', true );, define( 'WP_DEBUG_LOG', true ); and define( 'WP_DEBUG_DISPLAY', false );. The last one keeps the error text off the screen your visitors see. Reload the broken page once, then open wp-content/debug.log.

In the log, look for the line that starts “PHP Fatal error”. It ends with a path. The folder name after wp-content/plugins/ or wp-content/themes/ is the culprit.

Switch debugging off when you are done. Our own test showed that debug.log can be read by anyone who requests the address, so leaving it on publishes your errors.

How do you get the site back while you look?

Rename the plugins folder. The WordPress.org troubleshooting FAQ describes it: in wp-content, rename plugins to plugins.hold, then open /wp-admin/plugins.php. WordPress shows the plugins as missing, which switches them all off. Rename the folder back afterwards, and every plugin stays off until you turn each one on.

Do that one plugin at a time and the one that brings the error back is your answer. If the log named a theme, upload a fresh copy of that theme or restore it from a backup instead.

Take a backup before you edit anything on the live site. On a site that earns money, this is the point where we would rather you called us than guessed.

Can a PHP update cause the critical error?

Yes. WordPress.org lists an incompatible PHP version among the usual causes, and it is the one people miss, because the host does it for you.

A plugin written years ago may call a function that newer PHP no longer has. PHP’s manual says create_function() was deprecated in 7.2.0 and removed in 8.0.0. On a version that still has it, the plugin works. On a version that does not, the first page that reaches that line ends in a fatal error.

We tried it on 17 Oct 2026. On our WordPress 7.1.3 lab, which runs PHP 8.3.33, we added a temporary plugin file that calls create_function() when the front page is built. The front page returned a 500 and the critical error line, 2,704 bytes in all. The last PHP error our test file recorded read:

Uncaught Error: Call to undefined function create_function() in /wordpress/wp-content/mu-plugins/zz-ops95-crit.php:12

The detail that would have fooled us on a real site: the login page, with the same file loaded, returned 200. Only the path that ran the broken line failed. So “I can log in” does not mean the site is fine. Open the home page in a private window as well.

When the cause is a PHP change, the quickest fix is to put the old version back in your host’s panel, then update or replace the plugin before moving up again. WordPress.org recommends PHP 8.3 or greater, and our guide to checking your WordPress PHP version shows where to read yours and how we test the move on a staging copy first.

Could it be the memory limit?

It could: the log then reads “Allowed memory size of 134217728 bytes exhausted”, which is 128 MB. In our earlier lab the dashboard still loaded, because WordPress gives admins more memory than visitors. Why a memory error shows visitors a critical error while the dashboard works has the one line in wp-config.php that fixed it.

What did we not test?

• A real host’s PHP version switch. We changed nothing about PHP itself, and one plugin file stood in for old code.
• A real old plugin. A real one may fail on a different line, or only on one page.
• The recovery mode email, because Playground sends no mail.
• The debug.log file on this lab. We could not set WP_DEBUG_LOG from a plugin file, so those steps come from WordPress.org’s own pages, cited below.

What should you do right now?

Check the admin inbox, then your host’s PHP error log, then debug.log, and find the folder named in the last “PHP Fatal error” line. If the line points at a file you do not recognise, the first hour steps for a hacked WordPress site come before anything else.

Stuck, or the site is losing orders while you read this? Ask for a free site check. Send the site address and what the screen says, and we reply within 2 business days with a written report on what broke and the work to fix it. If you already know what to fix, the one-off fixes are listed here. You can also tell us what the site shows. A new site fix goes up each day on DistroCode’s LinkedIn Page.