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

Quick answer:

“There has been a critical error on this website” is WordPress’s way of telling you a fatal PHP error stopped your site from loading. It is almost always caused by one of seven things: a broken plugin update, a theme conflict, a PHP version mismatch, exhausted memory, a syntax error in wp-config.php or .htaccess, a database connection failure, or malware that corrupted core files.

Here is the fastest safe order to fix it:

Open your admin email inbox and click the WordPress Recovery Mode link (subject: “Your Site is Experiencing a Technical Issue”).
If no email arrived, enable WP_DEBUG_LOG in wp-config.php and read wp-content/debug.log for the exact failing file path.
If the log points to a plugin, rename that plugin folder via FTP. If it points to a theme, rename the theme folder so WordPress falls back to a default theme.
If the log says “Allowed memory size exhausted,” raise WP_MEMORY_LIMIT to 256M.
If the log shows “undefined function,” “deprecated,” or “syntax error” referencing PHP, switch your PHP version (or update the offending plugin/theme).
If the site started crashing after a hack, suspicious redirects, unknown admin users, or weird new files in wp-content, do not just deactivate plugins. Treat this as a malware case and scan for backdoors before going further.

I have personally fixed this exact error on more than 4,500 hacked WordPress sites. About 70% of cases are normal plugin or theme conflicts. The remaining 30% have a deeper cause that generic “increase memory limit” guides will never solve. This post covers both.

If your site is down right now and you cannot afford the diagnostic time, see my WordPress Critical Error Fix Service or hire me directly.

What “There has been a critical error on this website” actually means

WordPress 5.2 introduced a fatal error handler. Before that, a fatal PHP error gave you the famous White Screen of Death with no information at all. Now, WordPress catches the fatal error, shows a generic public-facing message, and quietly emails the site administrator a Recovery Mode link so you can still log into wp-admin.

The full message visitors see is usually:

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

Three things matter here:

Your data is safe. Posts, pages, products, users, and uploads live in the database and uploads folder. The crash is in PHP execution, not in your data.
The error message is intentionally vague. WordPress hides the technical details from public visitors so attackers cannot read your server paths.
The real error is in the log, not on the screen. Your job is to find that log entry, because it names the exact file and line that crashed.

Decide which type of critical error you have first

Most guides skip this step. They throw 12 fixes at you and hope one works. That is how people break sites worse. Before you touch anything, answer these three questions:

What changed last? A plugin or theme update, a PHP version change from your host, a custom code edit, a migration, a new install? Whatever changed last is the leading suspect.
Did you receive the Recovery Mode email? If yes, this is a normal plugin or theme issue and Recovery Mode will tell you which one. If no, your site email may be broken or the failure is happening before WordPress can send mail.
Were there warning signs of a hack before the crash? Strange redirects, fake admin users, Google Search Console security warnings, blacklist alerts, sudden spam pages indexed, or unknown files in your install? If yes, treat this as a security incident, not a normal plugin conflict.

That last question is the one I see ignored most often, and it is the reason “fixed” sites keep breaking again two days later. If a backdoor caused the crash, deactivating a plugin will not fix anything. The malware just runs again.

Step 1: Use WordPress Recovery Mode if the email arrived

Check the inbox of the email address listed under Settings → General → Administration Email Address. Look for a message titled something like “Your Site is Experiencing a Technical Issue.” Inside, you will find a unique, time-limited link that bypasses the fatal error and lets you into wp-admin.

Once inside Recovery Mode:

WordPress will display a banner naming the plugin or theme that triggered the error.
Deactivate that plugin (Plugins → Installed Plugins) or switch to a default theme (Appearance → Themes).
Click “Exit Recovery Mode” in the top admin bar.
Visit your homepage in a private window to confirm the site loads.

What if the Recovery Mode email never arrived?

This is extremely common, and it usually means one of three things:

Your site’s email function is broken (no SMTP, no DNS records, host blocks mail()).
The fatal error happens so early in the WordPress boot process that the email handler never runs.
The email was sent but landed in spam.

You can try forcing Recovery Mode manually by visiting:

https://yourdomain.com/wp-login.php?action=entered_recovery_mode

This only works if WordPress already registered a fatal error in the current session. If it does not work, move to Step 2.

Step 2: Enable debug logging and read the actual error

This is the single most important step in this entire guide, and the one most people skip. The debug log tells you exactly which file and line broke. Without it, you are guessing.

Connect to your site using FTP, SFTP, or your host’s File Manager. Open wp-config.php in the WordPress root. Find the line that says:

/* That's all, stop editing! Happy publishing. */

Just above that line, add:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Important: setting WP_DEBUG_DISPLAY to false means errors get written to a log file instead of being printed publicly on your live site. Never run debug mode with display enabled on a production site, since attackers can read your file paths from public errors.

Save the file. Reload the broken page. Then open wp-content/debug.log and scroll to the bottom. Newest errors are at the end.

How to read your debug.log: the patterns that matter

Most error log entries follow this format:

[09-May-2026 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function some_function() in /home/yoursite/public_html/wp-content/plugins/broken-plugin/includes/class-main.php on line 42

That single line tells you the cause type (“Uncaught Error: Call to undefined function”), the file path (plugins/broken-plugin/...), and the line number. The file path is the most valuable piece because it tells you whether to look at a plugin, theme, the WordPress core, or your own custom code.

Here is how to translate the most common log entries into the actual problem:

What the log says	What it actually means	Where to fix
`Allowed memory size of X bytes exhausted`	WordPress hit the PHP memory ceiling.	Step 6 (memory limit)
`Call to undefined function`	Plugin or theme calls a function that does not exist on this PHP/WordPress version, or a dependency failed to load.	Step 3 or Step 5
`Cannot redeclare function`	Two plugins (or a plugin and theme) define the same function name.	Step 3 (plugin conflict)
`syntax error, unexpected ...`	Broken PHP code, often after a manual edit to `functions.php` or after a partially uploaded plugin update.	Step 7
`deprecated` or `passing null to parameter`	PHP version mismatch, common after a host upgrades you from PHP 7.4 / 8.0 to PHP 8.2 / 8.3 / 8.4.	Step 5
`Class "X" not found`	An autoloader failed, usually a partial update or a missing vendor folder.	Step 8 (reinstall)
`Error establishing a database connection` in the log	DB credentials wrong, DB server down, or table corruption.	Step 9
References to `wp-content/uploads/*.php` or strange filenames in `wp-includes`	Suspicious. Legit code does not run from uploads. Possible malware.	Step 10 (security path)

Once you know which category you are in, jump to the matching step below. Do not run all of them in sequence.

Step 3: Fix a plugin-caused critical error

Plugin issues are the cause about 70% of the time, especially right after an automatic update or a manual update from outside the WordPress repository.

If your debug log named a specific plugin, you only need to disable that one. The fastest method is to rename its folder so WordPress can no longer load it:

Connect via FTP / File Manager and go to wp-content/plugins/.
Rename the offending folder, for example: broken-plugin → broken-plugin-DISABLED.
Reload your site. If it loads, you have your culprit.

If you do not know which plugin is broken, rename the entire plugins folder to plugins-OLD. WordPress will boot with no plugins active. If the site comes back up, rename the folder back to plugins, then reactivate plugins one at a time from wp-admin until the site breaks again. The last one you turned on is the cause.

Important caveat: renaming the plugins folder does not deactivate must-use plugins inside wp-content/mu-plugins/. If you have any files there, check those too. Some hosts also install MU plugins automatically.

WP-CLI shortcut for power users

If your host gives you SSH access, WP-CLI is the fastest way to handle this without FTP at all:

# Deactivate all plugins
wp plugin deactivate --all --skip-plugins --skip-themes

# Reactivate them one by one and watch for the crash
wp plugin activate plugin-name --skip-plugins --skip-themes

The --skip-plugins --skip-themes flags let WP-CLI run even when WordPress itself is crashed.

Step 4: Fix a theme-caused critical error

If disabling all plugins did not fix the site, your active theme is the next suspect. Themes commonly trigger this error after an update or after a custom edit to functions.php.

You cannot switch themes from inside wp-admin if you cannot log in, so do it from the file system:

Go to wp-content/themes/ via FTP.
Rename your active theme’s folder. WordPress will fall back to whichever default theme (Twenty Twenty-Four, Twenty Twenty-Five, etc.) is installed.
If no default theme is installed, upload a fresh copy of one from WordPress.org first, then rename your theme.

If the site loads with the default theme, the issue is in your theme. The most common single cause is a broken edit in functions.php, especially a missing semicolon or an unclosed function. If you recently pasted a code snippet into functions.php, that is almost certainly your problem. Restore the file from backup or remove the new snippet.

Step 5: Fix a PHP version mismatch

This is the cause that is rapidly growing in 2026. Hosts have been pushing sites onto PHP 8.2, 8.3, and 8.4. Plugins and themes that were last updated for PHP 7.4 will hit deprecated or removed functions and crash hard.

You will recognize this in your debug log as messages like:

PHP Fatal error: Uncaught TypeError: ...
PHP Deprecated: Creation of dynamic property ...
PHP Fatal error: Uncaught Error: Call to undefined function each() ...

You have two options:

Roll PHP back temporarily. In cPanel, look for “PHP Selector” or “MultiPHP Manager.” Drop your site to the previous version (often PHP 8.1) so it loads. This is a stopgap, not a fix.
Update or replace the broken plugin or theme. The right fix is to find the abandoned extension and update it, or switch to a maintained alternative.

WordPress officially supports PHP 7.4 and above, but in practice you should be on PHP 8.2 or 8.3 in 2026 for security and performance. Anything older is a security liability on its own. If you are stuck on legacy PHP because of a single old plugin, that plugin is the real problem.

Step 6: Fix exhausted PHP memory

If your debug log says Allowed memory size of 134217728 bytes exhausted (or any “memory exhausted” message), your site needs more PHP memory.

Add this above the “stop editing” line in wp-config.php:

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

The first line is for normal page loads. The second is for admin tasks like image processing, imports, and updates.

If raising memory does nothing, the limit is being enforced at the server level. Contact your host or update php.ini directly if you have access. On many shared hosts the cap is fixed and the only way to fix it long term is to upgrade your plan or move to a better host.

Important: only do this when memory exhaustion is the actual error in the log. Raising memory will not fix a plugin syntax error or a missing function. People do this blindly all the time and waste hours.

Step 7: Fix a syntax error in wp-config.php or .htaccess

If the critical error appeared right after you edited wp-config.php or your site is throwing a 500 alongside the WordPress message, your config file may have a typo. Look for:

Missing semicolons at the end of lines.
Unmatched single or double quotes.
A blank line or extra characters before the opening <?php tag at the very top of the file.

For .htaccess, rename the file to .htaccess-OLD and reload your site. Then in wp-admin → Settings → Permalinks, click Save (you do not have to change anything). WordPress will write a fresh, correct .htaccess for you.

Step 8: Repair corrupted or incomplete WordPress core files

This is rarer than people think, but it does happen after failed updates, interrupted migrations, or hosting outages mid-deploy.

To fix it without touching your content:

Download a fresh copy of WordPress from wordpress.org/download/.
Unzip it on your computer.
Upload everything except the wp-content folder and wp-config.php, overwriting the existing files. This refreshes only the WordPress core.

This will not delete posts, settings, plugins, themes, or uploads. It only replaces core files in wp-admin, wp-includes, and the loose root files.

Step 9: Fix a database-related critical error

If your debug log mentions mysqli, Error establishing a database connection, or table-related errors, the issue is at the database level.

Check three things in this order:

Credentials in wp-config.php. The DB_USER, DB_PASSWORD, DB_NAME, and DB_HOST values must match what your host provides.
Database server status. Ask your host whether the database server is online. Sometimes DB outages produce a critical error instead of the usual database connection screen.
Table corruption. Add define( 'WP_ALLOW_REPAIR', true ); to wp-config.php, then visit https://yourdomain.com/wp-admin/maint/repair.php to run the built-in repair tool. Remove that line afterwards.

Step 10: When the critical error is actually malware

This is the section other guides do not write, because most authors have never cleaned a hacked site. Of the 4,500+ infected WordPress sites I have personally recovered, a meaningful chunk first showed up to me as “There has been a critical error on this website.” Here is what that looks like:

Your debug log references a file that should not exist — for example wp-content/uploads/2024/wp-tmp.php, a random filename in wp-includes, or a plugin folder you do not recognise like wp-compat.
The crash started without any update, edit, or migration on your part.
The site fixes itself when you remove a file but the crash returns hours or days later.
You have other symptoms: spam pages indexed in Google, redirects to gambling or pharma, fake “I’m not a robot” pop-ups, blacklist warnings, hidden admin users you did not create.
You see PHP errors referencing obfuscated code, eval(), base64_decode(), or gzinflate().

If any of those match, this is not a normal plugin conflict. It is a malware-induced crash, and disabling plugins will not fix it. The malicious file usually re-creates itself from a backdoor elsewhere on the site. I have a full breakdown in why WordPress malware keeps coming back and a real example of a hidden persistence mechanism in how I found a hidden backdoor in a client’s WordPress site.

For a malware-induced critical error, the right order is:

Take a forensic backup of the current state before you change anything.
Scan the file system for backdoors, not just the active plugins. Many backdoors live in wp-content/uploads, wp-includes, or as fake plugins.
Scan the database for injected code, especially in wp_options, wp_posts (post_content), and any custom tables.
Replace WordPress core from a fresh download.
Replace plugins and themes from clean sources, not your own files.
Reset all admin passwords and wp-config.php security keys.
Audit user accounts and remove unknown admins.

If you do not have time for that or are not comfortable with it, this is exactly what my WordPress malware removal service handles end to end. For more on detection patterns, see how to detect WordPress malware and the list of known fake plugins in comprehensive list of fake and malicious WordPress plugins.

Real-world example: a critical error that was actually a backdoor

One client’s WooCommerce store hit “There has been a critical error” repeatedly. They had already done what every guide on Google says: disabled all plugins, switched themes, increased memory to 512M, reinstalled core, even reinstalled WordPress fresh on a new server.

The error came back within hours every time.

The debug log named a file in wp-content/plugins/wp-compat/ — a plugin they had never installed. That folder was an obfuscated backdoor masquerading as a compatibility plugin. The “critical error” was actually that backdoor crashing on a PHP 8.2 deprecation warning. Once we removed the backdoor and the persistence script that kept rewriting it, the critical error stopped permanently.

That site spent two weeks chasing memory limits and plugin updates because nobody read the debug log path carefully. The lesson: the file path in the log is the answer. Always.

What NOT to do when you see a critical error

Do not blindly update everything else hoping it will fix the crash. You may stack a second broken update on top of the first.
Do not delete random files in wp-content, wp-includes, or wp-admin unless your debug log specifically points to them.
Do not raise memory to 1GB or more as a default fix. If memory is not the actual error, you are masking the real problem.
Do not turn on WP_DEBUG_DISPLAY on a production site. It exposes server paths and file structure to attackers.
Do not edit core files directly to “patch” the error. Replace them from a clean download instead.
Do not assume it is not malware just because no plugin update happened. Hacks happen on their own schedule.

How to prevent the critical error from coming back

Almost every critical error I clean up could have been avoided with five habits:

Keep automated backups. Daily off-site backups (UpdraftPlus, BlogVault, JetPack) save you. See my UpdraftPlus backup guide.
Stage updates first. Use a one-click staging environment for plugin, theme, and WooCommerce updates. Most managed hosts (SiteGround, Kinsta, WP Engine) include this.
Stay on a supported PHP version. Run PHP 8.2 or 8.3 in 2026, with all plugins updated to match.
Audit and remove plugins quarterly. Every active plugin is a failure point and a security surface. Drop the ones you do not actively use.
Use a hardened security baseline. Strong passwords, 2FA, admin user hygiene, file integrity monitoring, and a real WAF. My WordPress security guide walks through the full setup, and the best WordPress security plugins guide compares the major options.

When to bring in expert help

Hire someone if any of these are true:

The site is still down after Steps 1 through 6 and the debug log is not making sense to you.
The error returns repeatedly even after you “fix” it (almost always a malware persistence mechanism).
The site is WooCommerce, a membership site, or any other site where downtime is costing money per hour.
You see signs of compromise: redirects, fake admin users, blacklist warnings, spam pages indexed.
You are not sure whether the cause is a normal bug or a security incident, and you do not want to guess.

I have personally recovered more than 4,500 hacked or broken WordPress sites since I started doing this full-time. If you want this off your plate today, see my Critical Error Fix Service, my WordPress Malware Removal service, or just hire me directly.

Final thoughts

The biggest mistake people make with “There has been a critical error on this website” is treating it as a mystery. It almost never is. WordPress, PHP, and your server logs leave a clear trail every single time. Once you read that trail in the right order — Recovery Mode email first, then the debug log, then the matching fix — the cause becomes obvious in minutes.

Start with the email. If it is not there, enable logging. Read the file path. Match it to the table above. Apply the right fix, not all of them.

And if the fix keeps undoing itself, stop chasing the symptom. You are looking at a security problem dressed up as a critical error.

Frequently asked questions

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

It means WordPress hit a fatal PHP error severe enough to stop the page from loading, and the fatal error handler caught it before showing a blank screen. Your data is safe. The cause is almost always a plugin, a theme, a PHP version mismatch, exhausted memory, a syntax error in a config file, or in some cases malware.

Will I lose my content if I get a critical error?

No. Your posts, pages, products, users, comments, and uploads live in the database and the uploads folder. The critical error is a code execution problem, not a data problem. Restoring or fixing the site does not require touching your content.

How do I fix the critical error if I cannot log into wp-admin?

Use FTP, SFTP, or your host’s File Manager. From there you can enable WP_DEBUG_LOG in wp-config.php, read wp-content/debug.log for the real error, rename the offending plugin or theme folder, fix syntax errors in your config file, or replace WordPress core files. WP-CLI is even faster if your host supports SSH.

I never got the WordPress Recovery Mode email. What now?

It usually means your site’s outgoing email is broken or the fatal error happens before the email handler can run. Try visiting yourdomain.com/wp-login.php?action=entered_recovery_mode directly. If that does nothing, skip Recovery Mode and use the debug log method instead.

Will increasing the PHP memory limit fix every critical error?

No. Only memory-exhaustion errors. If your debug log shows “undefined function,” “syntax error,” or “deprecated,” memory is not the issue and raising the limit will not help. Always read the log first.

Can a hacked site cause “There has been a critical error on this website”?

Yes, and more often than people realise. Malware can corrupt core files, inject broken code into functions.php, drop fake plugins like wp-compat, or trigger PHP errors when its own obfuscated code fails on a newer PHP version. If your critical error keeps coming back after a “fix,” or if it appeared without any update on your end, treat it as a possible compromise.

How long does it take to fix the WordPress critical error?

If it is a normal plugin or theme conflict and you have FTP access, it is typically a 10 to 30 minute fix once you have the debug log. PHP version mismatches and database issues take longer. Malware-induced critical errors take from a few hours to a full day depending on how deeply the site is compromised.

Should I just restore from backup instead of debugging?

If your last clean backup is recent and you have not made important changes since, restoring is often the fastest fix, especially for ecommerce or client sites where every hour offline costs money. Just be sure the backup itself is from before the critical error started.

Why is debug.log empty even though the site is broken?

Three reasons. Either WP_DEBUG_LOG is not actually set to true, or the fatal error happens so early that WordPress never reaches the logging step (in which case you need to check your server-level PHP error log via cPanel or your host’s dashboard), or the file does not have write permissions. Try setting wp-content to writable and reload.

Is the critical error the same as the WordPress white screen of death?

They are caused by the same family of fatal PHP errors. The critical error message is the modern, friendlier version that WordPress 5.2 introduced to replace the silent white screen. The diagnostic process for both is identical.