“There Has Been a Critical Error on This Website” in WordPress: Causes and Fix

“There has been a critical error on this website” error: what does it mean and what should you do first?

“There has been a critical error on this website” is the generic message WordPress shows when PHP hits a fatal error and stops running your code. A plugin, a theme, or an unfinished update usually causes it. Start with a backup, then check your admin email and the error log.

Do not panic. Your content is not gone; WordPress simply refuses to run the broken code. The order below is the one our team finds safest in practice.

1. Take a full file and database backup first, because every fix carries some risk.
2. Then, look for the recovery mode email from WordPress in the admin inbox.
3. Also, if there is no email, turn on the error log and read the file name it points to.
4. Next, if the file belongs to a plugin, rename that plugin folder.
5. In addition, if it belongs to the theme, switch to a default theme.
6. Finally, if the problem stays, check the PHP version, the memory limit, and any half finished update.

We explain each step below. Note: this guide is general information. Results depend on your site, and no guide can promise a recovery.

Why does “there has been a critical error on this website” appear?

WordPress stops the request when PHP reports a fatal error. In the past that looked like a blank white screen. Since version 5.2, WordPress shows a generic notice to visitors and emails the site admin instead.

The exact wording can differ between versions and translations. If your screen shows a similar notice, you face the same problem. The root causes are limited, so the list is short.

• A plugin you just installed or updated has a code error.
• So a theme conflicts with a plugin or does not support the new PHP version.
• The server runs a PHP version that is too old or too new for your code.
• Then, a script used more memory than your hosting plan allows.
• An update stopped halfway, so files from two versions now clash.
• Also, a file upload broke, which left a damaged or missing file behind.

Therefore the answer to the “why” question always sits in the log. Instead of guessing, read the record first.

Why should you back up before you touch anything?

Because every fix means renaming folders, editing a config file, or switching off a plugin. Each step looks reversible, but one wrong keystroke can break settings. A backup gives you a way back if a step goes wrong.

You can back up even when the site is down. Use the file manager in your hosting panel or an FTP connection to download the site folder. For the database, use the backup tool in the panel.

• Download the whole site folder, especially the wp-content directory.
• Next, export the database from the panel and store the file somewhere separate.
• If your host keeps automatic backups, note the date of the latest one.
• In addition, after you download, check that the files open and are not empty.

If you want to build a proper routine, read our website backup strategy guide. For the database side, our database backup and restore guide helps as well.

How do you use the recovery mode link in the admin email?

When WordPress catches a fatal error, it emails the site administrator. The message names the plugin or theme that failed and contains a secret recovery mode link. You open the link and log in with your admin account.

According to the WordPress core team, recovery mode works through a cookie. That means it stays active in the same browser even after you log in. Inside the dashboard, a notice tells you which plugin or theme WordPress paused.

1. Open the error email and click the link.
2. So log in with your administrator username and password.
3. Then, read the notice to see which plugin or theme is paused.
4. Also, update the plugin, remove it, or report the error to its developer.
5. Finally, exit recovery mode and test the site as a visitor.

Use the link only in an email sent to your own address. A message from someone else that pushes urgency and sends you to another site may be phishing. Also remember that leaving recovery mode brings the paused code back, so the error returns if you did not fix it.

What can you do in recovery mode, and what can you not do?

Recovery mode is not a repair tool. It is a temporary safe entrance. WordPress pauses the faulty component and lets you reach the dashboard, but it does not fix the code for you.

The official announcement says you can deactivate the problem extension completely, fix the issue yourself if you have the skills, or contact the extension author with the exact error. Moreover, you can leave the mode with one button. Leaving wipes the cookie and every extension runs again.

• You can see the paused component and note its name.
• Next, you can switch off the plugin for good and bring the site back quickly.
• You can copy the log line and send it to the developer.
• In addition, you cannot rely on the fix staying in place after you leave the mode.

You can read the details in the official WordPress documentation on common errors. In short, treat the mode as a helper that makes the cause easier to find, not as a guaranteed rescue.

What if the recovery mode email never arrives?

First check your spam folder, then check the admin email address saved in the site settings. An old address may have received the message. If the server cannot send mail at all, the email may never leave.

In that case, skip the email and move to the log and file method. Finding the error at file level is often more reliable anyway. You can also fix the email problem separately after the site works again.

• Check the spam and junk folders.
• So check whether the admin email in the settings is current.
• Ask your host whether the server sends mail.
• Then, read the cause in the error log and continue with the file method.

If your site keeps losing outgoing mail, the SMTP setup in our WordPress email delivery guide makes sure alerts like this one reach you.

How do you turn on WP_DEBUG and WP_DEBUG_LOG for an error log?

WP_DEBUG is the constant that switches on debug mode in WordPress. WP_DEBUG_LOG writes errors to a debug.log file in the wp-content folder. The official developer documentation says WP_DEBUG_LOG needs WP_DEBUG to be on as well.

These settings live in the wp-config.php file. Copy the file before you edit it. Also keep WP_DEBUG_DISPLAY off, so errors go to the log and visitors do not see them. That is the safer path on a live site.

• Open wp-config.php in your hosting file manager.
• Also, set WP_DEBUG and WP_DEBUG_LOG to on and WP_DEBUG_DISPLAY to off.
• Reload the site once to reproduce the error.
• Next, download the debug.log file from wp-content and read the last lines.

The documentation advises against leaving debug mode on a live site. So when you finish, turn the settings off and delete the log, because it can contain server paths. See the WordPress debugging documentation for details.

How do you read the error line in the log?

The most useful part of a log entry is the file path after the words “Fatal error.” If the path contains plugins, a plugin is at fault. If it contains themes, the theme is at fault. The folder name usually matches the plugin name.

The line number matters to a developer, but the file name is enough for you. For example, when the path points to one plugin folder, switching off only that plugin often brings the site back.

• If the path has plugins, note the plugin folder name.
• In addition, if it has themes, note your active theme folder.
• If you see “allowed memory size exhausted” or something similar, go to the memory limit.
• So if you see a message about the PHP version, check the version.
• If the same line repeats, read the newest entry, not the oldest.

A single line is often enough. Paste the file name into the plugin support forum or send it to the developer. When you share the message, hide your server path and any passwords.

How do you find the server error log in your hosting panel?

Besides the WordPress log, the server keeps its own error record. Many hosting panels show it in a section called error logs or something close. Because panel names and menus differ by provider, we do not give an exact button name.

This record helps most when WordPress does not load at all. Some errors happen at server level before WordPress can write anything. It also shows when the error started.

• Look for an error log or logs section in the panel.
• Then, focus on lines close to the time the problem began.
• Note the file path and the line that contains the word fatal.
• Also, if you cannot find it, ask your host for the latest entries for your site.

A long list of lines is normal. What matters is the first fatal entry after the problem began. For longer files, our log file analyzer can help you sort through them.

How do you disable a plugin by renaming its folder?

If you cannot reach the dashboard, you can switch off a plugin at file level. Open the plugins folder inside wp-content, find the faulty plugin folder, and add a suffix to its name. WordPress cannot find the plugin, so it deactivates it.

This does not delete the plugin settings; it only stops the plugin from running. So after you find the cause, you can rename the folder back and update it. Still, confirm that you took a backup first.

1. Open the plugins folder inside wp-content through your panel or FTP.
2. Next, find the plugin folder named in the log.
3. In addition, add a suffix such as “_off” to the folder name.
4. So reload the site and the dashboard to see whether they open.
5. Finally, if they open, check whether the plugin has an update.

If the site opens, you found the culprit. Update the plugin, replace it, or report the bug to its developer. Before you delete anything, write down its settings.

How do you deactivate all plugins at once?

If you do not know which plugin causes the error, you can switch them all off together. The WordPress documentation explains how to rename the whole plugins folder, for example to plugins.hold. When you reach the dashboard, you will see a notice that plugins are missing.

After you log in, rename the folder back. The plugins stay inactive, so you can turn them on one by one and find the culprit. The official page says this method keeps your plugin settings.

• If the site opens after the rename, one of the plugins causes the error.
• Then, rename the folder back and activate the plugins one at a time from the dashboard.
• Reload the site after each one, and leave the last plugin off if the error returns.
• Also, if the site still fails, look at the theme, the PHP version, and the memory limit.

You can follow the steps on the WordPress troubleshooting FAQ. A database method exists too, but editing the wrong row is risky, so we suggest it only for people who know what they do.

How do you switch back to a default theme?

If the log path points to the themes folder, the active theme is the problem. When you can enter the dashboard, activate one of the default WordPress themes under the appearance section. When you cannot, rename the active theme folder inside wp-content.

WordPress falls back to an available default theme when it cannot find the active one. For that, the server needs at least one default theme installed. So check that a default theme exists before you rename anything.

• If you can log in, activate a default theme and test the site.
• Next, if you cannot, rename the active theme folder.
• Once the site opens, review your custom or child theme files with your developer.
• In addition, back up first so you do not lose theme customizations.

Also note that a custom theme with an old function often breaks on a newer PHP version. In that case the theme developer has to update the code.

Can a PHP version mismatch cause this error?

Yes. Every plugin and theme targets certain PHP versions. If the server runs a version older or newer than the code expects, the code fails and WordPress shows the fatal error notice. This often follows a version change by your host or by you.

The fix works in two directions. If the plugin has an update, install it to reach a compatible version. If not, roll PHP back to the last version that worked. You can see the version in your panel.

• Check in the panel whether the PHP version changed on the day the error began.
• So read the supported PHP versions in the developer notes for each plugin and theme.
• As a temporary fix, roll back to the previous working version.
• Then, for a lasting fix, move to updated plugins and themes.

The steps depend on the panel. Our cPanel PHP version guide shows the usual way. Since old versions stop receiving security fixes, see the rollback as a short step only.

What do you do when the memory limit runs out?

The memory limit is the most RAM a PHP script may use. When a script passes it, the script stops and the log shows a line about allowed memory size. Plugins that process large images, create backups, or import data hit this often.

In WordPress, the WP_MEMORY_LIMIT constant sets the limit, but it cannot pass the ceiling your host sets. Therefore raising it does not always work. Your host may need to raise the limit on your plan.

• If the log shows the memory line, first find the plugin doing that work.
• Also, raise the PHP memory setting in the panel if one exists, within reason.
• Do not invent a number; ask your host what your plan allows.
• Next, if a higher limit solves it, find out why the task needs so much memory.

We explain how limits work in our shared hosting resource limits guide. For repeated memory trouble, a bigger plan may last longer than removing plugins.

How can an unfinished update break the site?

During an update, WordPress places a maintenance file in the site root and deletes it when the job ends. If the connection drops or the time runs out, the update stops halfway. Some files then come from the new version and some from the old, and the code clashes.

You may see two symptoms. Visitors may get a message that the site is briefly unavailable for maintenance, or you may get the fatal error notice. For the first case, the WordPress documentation says to delete the .maintenance file in the site root.

1. Open the site root in your panel, the folder that contains wp-admin.
2. In addition, show hidden files and find the .maintenance file.
3. So delete the file and reload the site.
4. Then, if the update did not finish, restart it from the dashboard.
5. Finally, if the fatal error stays, restore the broken plugin or core files from your backup.

If an update damaged a plugin, deleting and reinstalling it often works. If core files broke, you need to refresh them from a clean WordPress copy, and you should never do that without a backup.

Which symptom points to which cause?

The table below links what you see in the log or on screen to the likely cause and the first step. It is a summary based on field experience, and only your own log can show the real cause of your site.

Use the table as a checklist. However, several causes can overlap, so test the site after each step and then decide the next one.

Where does the error occur: front end, dashboard, or one page?

This split helps you narrow the cause. If only visitors see the error, a theme or a front end plugin is the likely suspect. If the dashboard fails too, a shared plugin, PHP, or core becomes more likely.

For example, if only one page fails, a block or shortcode on that page is suspect. On the other hand, if the whole site fails at once, an update, a version change, or memory is more likely. So note where the error appears.

This split gives no certainty, but it puts your tests in order. That way you work step by step instead of switching off plugins at random.

Does caching or a CDN affect this notice?

Caching does not create the error, but it can prolong what you see. After you fix the problem, your browser or cache plugin may still hold the old error page. Then the notice seems to stay even though the fix worked.

For this reason, clear the cache after the fix. Also open the site in a private window or on another device, which is a quick way to confirm the fix. If you use a CDN, refresh its cache too.

• Open a private browser window and try again.
• Also, clear the cache from your caching plugin.
• Refresh the CDN cache if you use one.
• Next, test from another network or on mobile data.

For a quick outside check, try our website technology checker or the is it down tool. Together they show whether the problem is only yours or visible to everyone.

How is this notice different from a 500 error, a database error, or a hack?

“There has been a critical error on this website” is a designed notice that WordPress produces itself. An HTTP 500 is the generic failure code from the server, and the page often looks plain. The roots can be similar, but the fixes differ.

• If you see the raw server page, read our 500 Internal Server Error guide.
• In addition, if you see a database connection message, go to the database connection error fix.
• If you find unknown pages, redirects, or admin users, follow our hacked WordPress site guide.

Mixing up these cases wastes time. So read the message on your screen and pick the matching guide.

What should you check and turn off after the fix?

When the site returns, you are not finished. You still need to turn off debug mode, restore temporary folder names, and test the real visitor flow. Otherwise the next problem will be harder to spot.

1. Turn off WP_DEBUG and WP_DEBUG_LOG and delete the debug.log file.
2. So restore any folder names you changed temporarily.
3. Then, test the home page, a post, the contact form, and checkout if you have one.
4. Also, make sure you left recovery mode.
5. Next, take a fresh backup of the working site.
6. Finally, watch the site for the next week.

The same error can return, especially if you reactivated the faulty plugin. So observe the site for a few days without new changes.

How do you stop this error from happening again?

This error usually comes from unchecked updates. The prevention plan is simple: test changes on a staging copy first, back up on a schedule, and remove plugins you do not need. Every plugin adds maintenance work and a possible failure point.

• Take a full backup before every update and update when traffic is low.
• In addition, try big updates on a copy of the site first.
• Remove plugins that nobody maintains.
• So check plugin compatibility before you change the PHP version.
• Keep the admin email address current and reachable.

Also ask whether a new plugin is really needed. Sometimes a lighter option carries less risk than a heavy plugin. For the bigger choice, see our WordPress vs custom website guide.

There has been a critical error on this website: when should you call an expert?

Call an expert if you cannot read the log, you hesitate to edit files, or the site earns money. Our team starts with a backup, reads the log, and makes the smallest possible change. The result depends on your site, and we do not promise a certain fix.

Be careful when you look for help. Do not give admin credentials to strangers who charge money and promise a sure fix. Instead of sharing your password, create a temporary user with limited rights and delete it when the work ends.

• Your host can check the server side, such as PHP version and memory.
• Then, the plugin developer is best placed to fix a bug inside the plugin.
• If the site keeps breaking, our web design and maintenance service can look at your update routine.

This article is general information and does not guarantee the same result for every site. If your data matters, take a backup before you act.