There Has Been a Critical Error on This Website: What It Means and How to Fix It

The error that tells your visitors you have a problem

You are running Google Ads. You are sending email campaigns. Maybe you just landed a mention on a popular blog. Traffic is flowing to your WordPress site. And instead of your homepage, every single visitor sees this:

"There has been a critical error on this website. Please check your site admin email inbox for instructions."

That message is meant for you, the site owner. But your visitors see it too. They do not have access to your admin email. They do not know what a critical error is. All they know is that your website is broken, and they are going somewhere else.

Every minute this error sits on your site, you are losing visitors, losing trust, and losing money. If you are running an ecommerce store, orders have stopped completely. If you depend on lead generation, your contact forms are gone. If Google crawls your site during the outage, your rankings take a hit that can take weeks to recover from.

The worst part? WordPress tried to tell you about it. It sent an email to your admin address with a recovery link. But that email depends on your server's mail function working correctly — and on shared hosting, it often does not. The email might be in your spam folder. It might never have been sent at all. You are sitting there thinking everything is fine while your site is publicly broken.

What actually triggers the critical error

Before WordPress 5.2, a PHP fatal error gave you the White Screen of Death — a completely blank page with no explanation. WordPress 5.2 introduced a fatal error handler that catches these crashes and displays the "critical error" message instead. It also added recovery mode, which lets you log into wp-admin even when a plugin or theme is causing the crash.

But the message itself does not tell you what went wrong. Here are the most common causes, and how to identify and fix each one.

1. A plugin update introduces a PHP fatal error

This is the number one cause. You update a plugin — or WordPress auto-updates it — and the new version contains code that crashes PHP. Maybe it calls a function that does not exist in your version of PHP. Maybe it has a syntax error. Maybe it conflicts with another plugin that hooks into the same WordPress function.

WordPress catches the fatal error, identifies which plugin caused it, and displays the critical error message. If the server mail is working, it sends you an email with a link to enter recovery mode, where you can deactivate the offending plugin from wp-admin.

How to fix it: If you received the recovery mode email, click the link. It gives you temporary access to wp-admin where you can deactivate the plugin. If you did not receive the email, connect via FTP or your hosting file manager. Go to /wp-content/plugins/ and rename the folder of the plugin you most recently updated — for example, rename my-plugin to my-plugin-disabled. Reload your site. If it comes back, that plugin was the cause. Check the WordPress common errors documentation for additional troubleshooting steps.

2. Theme incompatibility or broken functions.php

Your theme's functions.php file runs on every page load. A single syntax error, a missing semicolon, or a call to a deprecated function can trigger a fatal error that takes down your entire site. This commonly happens after updating your theme or after editing functions.php directly through the WordPress code editor.

How to fix it: Via FTP, navigate to /wp-content/themes/ and rename your active theme folder. WordPress will fall back to the latest default theme — Twenty Twenty-Five or whichever default is installed. If the site loads, your theme is the problem. Review the changes you made to functions.php, or contact the theme developer for a compatible version.

3. PHP memory limit exhausted

WordPress and its plugins share a pool of PHP memory. The default limit on many hosting providers is just 40MB or 64MB. A single memory-hungry plugin — especially page builders, large form plugins, or WooCommerce with many products — can exhaust this limit. When PHP runs out of memory, it crashes, and WordPress shows the critical error.

How to fix it: Open wp-config.phpvia FTP and add this line before the "That's all, stop editing" comment:

define('WP_MEMORY_LIMIT', '256M');

If this resolves the error, you have a memory problem. But increasing the limit is a band-aid. You need to find which plugin is consuming excessive memory. Deactivate plugins one by one and check memory usage. Some hosting providers also enforce a hard PHP memory limit at the server level that overrides your wp-config.php setting — contact your host if the change does not take effect.

4. Corrupted WordPress core files

A failed auto-update, a server crash during a file write, or disk corruption can damage WordPress core files. If a critical file like wp-settings.php, wp-includes/plugin.php, or wp-includes/class-wp-fatal-error-handler.php is corrupted, WordPress cannot initialise and throws a fatal error.

How to fix it: Download a fresh copy of your WordPress version from wordpress.org. Upload the wp-admin and wp-includes directories to your server via FTP, overwriting the existing files. This replaces all core files without touching your content, themes, or plugins in wp-content.

5. PHP version incompatibility

Your hosting provider upgrades PHP from 8.1 to 8.3. One of your plugins has not been updated for the new version. It uses a function that was removed or changed. PHP throws a fatal error, and the critical error message appears.

This is particularly insidious because you did not change anything on your end. Your site was working fine yesterday, and today it is broken because of a server-level change you were not told about.

How to fix it: Check your hosting control panel to see if PHP was recently changed. Most hosts let you switch PHP versions from cPanel or a similar dashboard. Temporarily downgrade to the previous PHP version and verify your site works. Then update the incompatible plugin or find an alternative before switching back to the newer PHP version.

Why WordPress recovery mode is not enough

WordPress 5.2 added recovery mode as a safety net. When a fatal error occurs, WordPress tries to send an email to the admin address with a special link. Clicking it lets you access wp-admin in a protected session where the crashing plugin or theme is paused.

In theory, this is helpful. In practice, it has serious gaps.

The email might never arrive. Many shared hosting providers do not have a properly configured mail server. The wp_mail() function fails silently, and the recovery email is never sent. Even if it is sent, your hosting IP might be on a spam blacklist, so the email goes to spam or gets rejected entirely.

You might not check your email for hours. The critical error could happen at 2am. The recovery email sits in your inbox until you wake up. Meanwhile, your site has been broken for six hours and every visitor has seen the error.

Recovery mode only catches some errors. If the fatal error happens before WordPress's error handler can load — for example, a corrupted wp-settings.php — recovery mode never triggers and no email is sent.

You cannot rely on WordPress to tell you about its own failures. You need external monitoring.

Why standard uptime monitoring misses this error

Here is the detail that makes the critical error so dangerous from a monitoring perspective. When WordPress displays "There has been a critical error on this website," your web server is still running. Apache or Nginx is still handling requests. In many configurations, it still returns a 200 OK HTTP status code — just with the error message as the body content instead of your actual website.

A standard uptime monitor that checks HTTP status codes sees a 200 response and reports your site as "up." Your monitoring dashboard shows green. You think everything is fine.

But your visitors see the critical error. Your site is technically up but functionally broken.

This is why keyword monitoring is essential. It does not just check whether your server responded — it checks what the response actually contains.

How to detect the critical error with Uptrue

Uptrue's keyword monitoring catches this error by checking the actual content of your pages. If your normal content disappears and is replaced by an error message, you know about it in under a minute.

Step 1: Set up a keyword monitor to detect the error text

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select Keyword as the monitor type
4. Enter your homepage URL
5. Set the keyword to "There has been a critical error"
6. Set the check type to "Page must NOT contain"
7. Set the check interval to 1 minute
8. Configure alerts — Slack, email, or Microsoft Teams

The moment that error text appears on your page, Uptrue detects it and sends you an alert. No waiting for a WordPress email that might never arrive. No depending on a customer to tell you about it.

Step 2: Add a positive keyword monitor as a second layer

1. Click Add Monitor again
2. Select Keyword as the monitor type
3. Enter your homepage URL
4. Set the keyword to something that always appears on your homepage — your site title, a tagline, or a navigation item
5. Set the check type to "Page must contain"
6. Set the interval to 1 minute

This catches not only the critical error but any situation where your content disappears — the White Screen of Death, a hacked page, a misconfigured maintenance mode, or a failed migration. If your expected content is gone, you know.

Step 3: Add an HTTP monitor for full coverage

1. Add an HTTP/HTTPS monitor for your homepage
2. Set expected status to 200
3. Set check interval to 1 minute

Some server configurations return a 500 status code instead of 200 when the critical error occurs. The HTTP monitor catches those cases. Between the keyword monitors and the HTTP monitor, the critical error has nowhere to hide.

Step 4: Monitor your critical inner pages

The critical error does not always affect every page. If only one plugin causes the crash and that plugin only loads on specific pages, your homepage might work fine while your checkout page, contact form, or blog is broken. Set up keyword monitors for:

• Homepage
• Contact page
• Checkout page (if you run WooCommerce)
• Any landing page receiving paid traffic
• Your most popular blog post

Step 5: Configure alerts that reach you immediately

A monitoring alert is only useful if you actually see it. Configure your alerts to go where you will notice them within minutes, not hours:

• Slack — instant notification in a dedicated channel
• Microsoft Teams — same idea, different platform
• Email — fine as a backup, but not fast enough for critical errors
• Webhook — pipe alerts into PagerDuty, Opsgenie, or your own incident management system

Preventing the critical error before it happens

Monitoring catches the error fast. But these habits reduce the chances of it happening in the first place.

Update one plugin at a time

Never batch-update all your plugins at once. Update one, check your site, then update the next. If the critical error appears, you know exactly which plugin caused it. If you updated twelve plugins simultaneously, you are guessing.

Use a staging environment

Most managed WordPress hosts offer a staging site. Test every update on staging first. If a plugin update causes a fatal error on staging, you caught it before it hit production. This is the single most effective prevention measure.

Enable debug logging

Add these lines to wp-config.php:

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

This logs PHP errors to /wp-content/debug.log without showing them to visitors. When the critical error hits, the debug log tells you exactly which file and which line caused the crash.

Increase the PHP memory limit proactively

Do not wait until you hit the memory limit. Set it to 256MB in wp-config.php now. If your hosting plan allows it, go higher. Running close to the memory limit means one traffic spike or one large import away from a crash.

Disable the WordPress theme and plugin file editor

Add this line to wp-config.php:

define('DISALLOW_FILE_EDIT', true);

This prevents anyone from editing theme or plugin files directly from wp-admin. A misplaced semicolon in the code editor can crash your entire site. If you need to edit code, do it via FTP or a proper code editor where you can undo mistakes.

Keep regular backups

A daily backup means you can restore your site in minutes. Make sure backups are stored off-server — if your hosting has issues, your backups should be somewhere else. Test your restore process before you need it.

Stop finding out from your customers

Your WordPress site could be showing the critical error right now and you would not know.

WordPress's built-in recovery email is unreliable. Standard uptime monitoring often misses the error because the server still returns a 200 status code. The only reliable way to catch it is keyword monitoring that checks what your page actually says.

Uptrue checks your pages every 60 seconds. If your content disappears — or if an error message appears — you know in under a minute. On Slack, Teams, email, or webhook. Before your customers see it. Before Google crawls it. Before you lose another lead.

Frequently asked questions