How to Fix "There Has Been a Critical Error on This Website" in WordPress

One sentence, white background, no further explanation: "There has been a critical error on this website."

Your site is down, your customers see nothing, and WordPress, helpfully, won't tell you why. If the admin dashboard is also locked out, it feels like the whole thing is bricked.

It isn't. Behind that vague message is an ordinary PHP fatal error with a specific cause, and in our experience the cause is one of four things: a plugin, a theme, a PHP version mismatch, or exhausted memory. This is a diagnostic problem, not a disaster. Here's the sequence.

Step 0: What changed?

Ninety percent of critical errors follow a change. Did you (or auto-updates, check your email for "Your site has updated...") just update a plugin, a theme, WordPress core, or PHP? Did you install something new? Did your host migrate you to a new server?

If you can name the change, you've probably named the culprit, skip straight to disabling that thing in Step 3. If you can't, work the sequence.

Step 1: Read the actual error

WordPress hides the real message from visitors. Get it two ways:

The easy way: check your inbox. Since WordPress 5.2, the site emails the admin address when a fatal error occurs, including the failing file path and a special "recovery mode" login link that lets you into the dashboard with the broken component paused. If that email exists, it hands you the answer, the file path will say something like /wp-content/plugins/some-plugin/..., and now you know exactly which plugin to disable.

The reliable way: turn on the debug log. Connect via SFTP or your host's file manager, open wp-config.php, and above the /* That's all, stop editing! */ line add:

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

Reload the broken page, then open /wp-content/debug.log. The last "PHP Fatal error" line names the file that failed. The folder it lives in names your suspect.

Step 2: If it's a plugin (it's usually a plugin)

Can't get into wp-admin? Disable plugins from the outside:

1. Via SFTP or file manager, go to /wp-content/.
2. Rename the plugins folder to plugins-off. This deactivates everything at once.
3. Load your site. If it's back, a plugin was the problem. Rename the folder back to plugins, WordPress will keep them all deactivated, then log in and reactivate them one at a time, reloading the site after each, until the error returns. The last one you activated is your culprit.
4. If the debug log already named the plugin, skip the ceremony: rename just that plugin's folder (e.g. bad-plugin → bad-plugin-off).

Found it? Check the plugin's support forum, if the latest update is broken, you won't be the only one. Roll back to the previous version (WP Rollback makes this painless) and hold the update until a fix ships.

Step 3: If it's the theme

Same trick, different folder: rename your active theme's folder inside /wp-content/themes/. WordPress falls back to a default theme (make sure one is installed, twentytwentyfive or similar should be in that folder). Site comes back? The theme, or something in its functions.php, is the problem. If you or a previous developer added custom code to functions.php recently, that snippet is suspect number one.

Step 4: If it's PHP itself

Two server-side causes remain:

• Memory exhaustion. The debug log says "Allowed memory size ... exhausted." Add define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php, or raise the limit in your hosting panel.
• PHP version mismatch. Hosts upgrade PHP; old plugins and themes don't always survive it. Conversely, ancient plugins can force sites to limp along on outdated PHP. Check your PHP version in the hosting panel, WordPress currently runs best on PHP 8.1-8.3, and test changes on a staging copy, not in production.

Step 5: Still down?

Restore last night's backup to get the site up, then diagnose the cause on a staging copy at leisure. No backup? Your host may keep one, ask before assuming. (And after this is over, read our guide to WordPress backups, because "no backup" should never happen twice.)

Preventing the next one

Critical errors are almost never random; they're update collisions. The fix is process, not luck: updates applied deliberately on a staging site first, with a fresh backup before each round, and monitoring that alerts someone within minutes if the live site goes down. That's precisely what a maintenance plan is, the boring subscription that makes this article irrelevant to you.

When WordPress is the wrong tool for the job

Notice what caused this outage: not your code, not your traffic, a version collision between independent pieces of software that each update on their own schedule. That's the WordPress bargain. You get an enormous ecosystem; you accept that your site's uptime depends on strangers' changelogs.

For most sites, staging plus managed updates makes that bargain perfectly livable. But if your site is genuinely business-critical (bookings, orders, operations that stop when it stops) and you're experiencing this kind of outage more than rarely, the arithmetic changes. A custom-built application has one codebase, one deployment pipeline, and updates that happen when you decide, tested before they ship. Downtime becomes something you control rather than something that happens to you. If that sounds like the relationship you'd rather have with your website, that's a conversation we're happy to have, and if it doesn't, we'll just fix your WordPress and set up staging so this doesn't recur.

Down right now and out of patience?

The sequence above solves the overwhelming majority of critical errors within the hour. If you'd rather not spend that hour in an SFTP client, or the log is pointing at something genuinely gnarly, our emergency debugging service can usually have you back online the same day, with a written explanation of what broke and why it won't again.

May the Code Be With You.

---

WordPress Pro builds, fixes, and maintains WordPress sites, and builds custom solutions for businesses that have outgrown them. [Get emergency debugging →]