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

Seeing the message “There has been a critical error on this website” can be alarming, especially when you cannot open the WordPress dashboard. The good news is that the message alone does not mean your posts, pages, images or database have been deleted.

It normally means WordPress encountered a fatal PHP error and stopped loading the affected request. WordPress may display the message with a server response code of 500, and the wording may also tell you to check the site administrator’s email inbox for recovery instructions.

A plugin or theme problem is a common cause, particularly after an installation or update. However, the same message can also be caused by custom code, incompatible server settings, exhausted resources, damaged files or another PHP-level problem. Do not start deleting plugins or changing several settings at once.

The safest first action is to check your WordPress administration email for a Recovery Mode message and think about what changed immediately before the error appeared.

Quick diagnosis

The same critical-error message can have several causes, so use the timing and scope of the problem to narrow it down.

What you notice	Possible cause	Safest first check
The error appeared after updating a plugin	Plugin compatibility problem or failed update	Check the recovery email and deactivate only that plugin
The error began after installing a new plugin	Faulty plugin or conflict with existing software	Deactivate the newly installed plugin
The error appeared after changing the theme	Theme code error or compatibility problem	Use Recovery Mode to pause or change the affected theme
The error began after adding custom code	Syntax error or unsupported function	Remove the most recent code change
The front of the site fails but the dashboard works	A theme, template or front-end plugin problem	Test the most recent change from the dashboard
Both the website and dashboard fail	Fatal PHP error affecting the whole installation	Check the recovery email or hosting error log
No recovery email arrives	Wrong administration email or failed email delivery	Check spam, hosting email delivery and the saved administration address
The error appeared after changing PHP or moving hosts	Environment or compatibility problem	Ask the host to review the recent server change
The log mentions “Allowed memory size exhausted”	PHP memory or hosting-resource limit	Ask the host which process exhausted the limit

Treat this table as a starting point, not a guaranteed diagnosis. A plugin named in an error log may be where the failure became visible without necessarily being the original cause.

Before you start

Collect a few details before changing anything:

• The exact error message
• The approximate time the problem began
• Any plugin, theme, code, hosting or server change made shortly before it
• Access to the WordPress administration area, if it still works
• Access to your hosting account or File Manager
• A recent backup of both the website files and database
• Access to the site administration email address

If you do not have hosting access, contact the person or company that manages the hosting account. You may still be able to solve the problem through WordPress Recovery Mode, but hosting access becomes important when the dashboard is unavailable.

IMPORTANT BACKUP WARNING

Before renaming folders, editing files, changing PHP settings or restoring anything, create or confirm a current backup.

The backup should include:

• The WordPress database
• The wp-content folder
• Themes and plugins
• Uploaded media
• Important configuration files

Download a copy away from the same hosting account when possible. A backup stored only on the affected server may be unavailable if the hosting account itself develops a problem.

Also record every change you make. Rename one folder, test the website and note the result before moving to another step. This makes it much easier to reverse the change.

For a shop, membership site or website receiving form submissions, be especially careful with full-site restoration. An older database backup may overwrite recent orders, registrations, comments or customer information.

Confirm the scope of the critical error

Before disabling anything, work out which parts of the website are affected.

Check the public website

Open:

• The homepage
• A normal post or page
• The WordPress login page
• The administration dashboard, if accessible

If only one page fails, the problem may be connected to a shortcode, template, page builder element or plugin feature used on that page.

If every page and the dashboard fail, the error is more likely to affect something loaded across the whole website.

Test while logged out

Open the website in a private or incognito browser window.

Some plugins behave differently for administrators and visitors. A website may appear normal while you are logged in but fail for ordinary visitors, or the opposite may happen.

A browser test will not repair a fatal PHP error, but it can help confirm whether all users are affected.

Review the most recent change

Ask yourself what happened immediately before the error:

• Was a plugin installed, activated or updated?
• Was the active theme changed?
• Was custom code added?
• Was the PHP setting changed?
• Was the website migrated?
• Did the hosting provider move or update the server?
• Did an automatic update run?

The most recent change is often the best place to begin, but do not assume it is responsible without testing it.

Method 1: Check the WordPress recovery email

WordPress uses the Administration Email Address for important notices, including recovery mode, fatal errors and plugin or theme issues.

Check:

1. The inbox connected to the website administrator email
2. The spam or junk folder
3. Any mailbox previously used by the developer or agency that built the site
4. Messages containing the website name, “Recovery Mode” or “technical issue”

The email may include a special Recovery Mode link. Open it and log in to WordPress.

Recovery Mode is designed to pause the plugin or theme responsible for a fatal error during that recovery session, allowing you to enter the dashboard and investigate. WordPress can then show more information on the Plugins or Themes screen.

Once inside:

1. Open the Plugins or Themes area mentioned in the notice.
2. Look for a paused or failed extension.
3. Deactivate the suspected item.
4. Test the public website in a logged-out browser.
5. Check whether an update or confirmed fix is available from the official developer.
6. Exit Recovery Mode only after the website works normally.

Do not immediately reactivate the suspected plugin or theme on the live website. First determine why it failed.

What if the recovery email never arrives?

Possible reasons include:

• The Administration Email Address points to an old address
• The message went to spam
• The hosting server did not send it
• WordPress email delivery is not configured reliably
• The fatal error occurred before Recovery Mode could provide useful access
• The site is part of a configuration where the message is handled differently

If you regain dashboard access later, review the Administration Email Address in the general WordPress settings. WordPress documentation confirms that recovery and fatal-error notifications are sent to that address.

Do not delay the repair indefinitely while waiting for an email. Continue with the methods below if you have hosting access.

Method 2: Reverse the most recent change

When the error started immediately after a clear action, reverse that one action before making unrelated changes.

After a plugin installation or update

Deactivate the plugin that was installed or updated.

If the site works again, leave the plugin inactive while you:

• Check its official support information
• Look for a newer corrective update
• Confirm its requirements
• Contact the plugin developer
• Test it on a staging copy before using it again

Do not permanently replace the plugin until you understand whether it stores important forms, orders, memberships, redirects or other data.

After a theme change or update

If the dashboard works, temporarily activate another trusted theme that is already installed.

This test may alter the visible design, menus or widget positions, so make sure you have a backup and record the original active theme.

If changing the theme removes the error, the problem may be in:

• The theme itself
• A child theme
• Custom code added to the theme
• A plugin that depends on the theme
• A compatibility issue between the theme and the current environment

Do not delete the old theme. Keep it inactive while you investigate.

After adding custom code

Remove or reverse only the latest code change.

Check common locations such as:

• A child theme’s functions.php file
• A code-snippet plugin
• A custom plugin
• The theme editor
• A recently edited template
• wp-config.php
• .htaccess

Restore the previous copy of the edited file rather than trying random corrections on the live site.

After changing PHP or server settings

Ask the hosting provider to confirm:

• What changed
• When it changed
• Whether the previous setting can be restored temporarily
• Which file or extension is producing the fatal error
• Whether the affected plugin or theme supports the current environment

Avoid moving repeatedly between several PHP settings without checking the error log. The goal is to identify the incompatible component, not to hide it by trial and error.

Method 3: Deactivate the suspected plugin from the dashboard

Use this method when the WordPress dashboard still opens.

1. Open Plugins → Installed Plugins.
2. Find the plugin installed or updated before the error.
3. Deactivate it.
4. Open the public website in a private browser window.
5. Check the page that previously displayed the error.
6. Review important features such as forms, checkout, login and search.

If the error disappears, the plugin is involved in the failure. That does not always mean the plugin is badly made. It may conflict with another plugin, the theme, custom code or the hosting environment.

If you do not know which plugin is responsible, deactivate plugins one at a time, starting with the most recently changed item. Test after every deactivation.

Avoid deactivating every plugin immediately when the dashboard works. A one-by-one test provides much better evidence and causes less disruption.

Method 4: Deactivate plugins through File Manager or FTP

Use this method when you cannot open the WordPress dashboard.

FTP or SFTP is a method of accessing the files stored in your hosting account. Most hosting providers also offer a browser-based File Manager.

Disable one suspected plugin

1. Open your hosting File Manager or connect through FTP or SFTP.
2. Open the folder containing your WordPress installation.
3. Go to wp-content/plugins/.
4. Find the folder belonging to the suspected plugin.
5. Rename it by adding something clear to the end, such as:

plugin-name-disabled

6. Test the website again.

WordPress can no longer load the plugin from its original folder name, so it is effectively disabled for testing.

If the website starts working, keep that plugin disabled while you investigate. Do not delete its folder.

To reverse the test, rename the folder to its exact original name. However, do not reactivate the plugin until you have confirmed that it is safe to do so.

Disable all plugins when the cause is unknown

WordPress’s official troubleshooting documentation provides a method for disabling all plugins by renaming the entire plugins folder.

1. Open wp-content/.
2. Rename the plugins folder to:

plugins.hold

3. Try opening the WordPress dashboard.
4. If the dashboard opens, return to File Manager.
5. Rename plugins.hold back to:

plugins

6. Open the Plugins screen in WordPress.
7. Reactivate plugins one at a time.
8. Test the public website after every activation.

According to the official WordPress instructions, renaming the folder back restores access to the plugin files, but the plugins remain deactivated until you reactivate them.

This method may temporarily disable:

• Contact forms
• Security features
• Caching
• Online-shop functions
• Membership access
• Redirects
• Backup schedules
• Spam protection

Keep the testing period brief and restore essential services carefully.

Method 5: Test whether the theme is responsible

Only test the theme after plugins have been considered or when the error appeared directly after a theme-related change.

If you can access the dashboard, activate another trusted theme that is already installed.

If you cannot access the dashboard, do not simply delete or rename the active theme unless you know that another working fallback theme is installed. Without a usable alternative, WordPress may still fail or display a different problem.

A safer option is to ask the hosting provider to:

• Confirm the active theme
• Check whether another valid theme is installed
• Temporarily switch the active theme
• Review the PHP error log before changing anything

If changing the theme fixes the site, inspect:

• Recent theme updates
• Child-theme customisations
• Theme-specific plugins
• Custom functions
• Page-builder integrations
• Unsupported or abandoned theme components

Method 6: Read the hosting error log

An error log is often the quickest way to identify the file that failed.

Open your hosting dashboard and look for a section named something similar to:

• Error Logs
• PHP Error Log
• Website Logs
• Server Logs
• Logs and Reports
• Advanced Logs

The exact name differs between hosting providers.

Look for entries recorded at the same time the critical error appeared. Useful messages may include:

• Uncaught Error
• Fatal error
• Parse error
• Call to undefined function
• Class not found
• Allowed memory size exhausted
• A path containing wp-content/plugins/
• A path containing wp-content/themes/

A file path may reveal the plugin, theme or custom file involved.

For example, a path containing:

wp-content/plugins/example-plugin/

suggests that the failure occurred while WordPress was loading that plugin.

Do not assume every warning in the log caused the outage. Old warnings and unrelated notices may appear beside the important error. Match the log time with the time you reproduced the problem.

Do not publish complete logs in a public forum. Logs may expose:

• Hosting usernames
• Server paths
• Private directory names
• Email addresses
• Domain configuration
• Plugin names
• Technical information useful to an attacker

Share only the necessary error line with a trusted developer or hosting provider, and remove private details first.

Method 7: Use WordPress debugging carefully

This is an advanced method. Use it only when the hosting error log is unavailable and you are comfortable editing wp-config.php.

WordPress’s official documentation says its debugging tools are intended mainly for development and staging environments rather than live websites. Debug information can also expose sensitive technical details if displayed publicly.

On a live website, asking the hosting provider to inspect the private PHP error log is usually safer.

If brief logging is necessary:

1. Back up wp-config.php.
2. Open it using File Manager or SFTP.
3. Check whether debugging constants already exist.
4. Do not add duplicate copies of the same settings.
5. Place the following before the line that says WordPress has finished loading configuration:

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

These settings tell WordPress to record debugging information while hiding it from page visitors. WordPress documents the log location as wp-content/debug.log when the standard configuration is used.

After enabling the log:

1. Load the broken page once.
2. Open wp-content/debug.log.
3. Look at the newest entries.
4. Identify the plugin, theme or file path connected to the fatal error.
5. Download the relevant lines if you need them for support.
6. Disable debugging again.
7. Remove or protect the log file so it is not publicly accessible.

To disable debugging, change the existing setting to:

define( 'WP_DEBUG', false );

Do not write 'false' inside quotation marks. WordPress explains that quoted text is treated differently from the boolean value false.

Method 8: Handle memory and hosting-resource errors

If the log contains a message such as “Allowed memory size exhausted,” WordPress or one of its extensions used more PHP memory than the server allowed.

This can happen because:

• A plugin is processing too much information
• A backup or import task is too large
• Several resource-heavy extensions run together
• A process is stuck in a loop
• The hosting plan has strict resource limits
• The website has outgrown its present environment

Do not increase memory blindly without identifying which process exhausted it. Raising the limit may only delay the same failure.

Send the exact error to the hosting provider and ask:

• What memory or resource limit was reached?
• Which process or file triggered it?
• Is the limit fixed by the hosting plan?
• Did the failure come from one plugin or a wider server problem?
• Is a temporary increase safe while the cause is corrected?

If a specific plugin is repeatedly exhausting resources, contact its developer or replace it with a more suitable solution after protecting any data it stores.

Method 9: Restore a backup only when it is the safest option

A backup can be the quickest recovery method when:

• The error began after a known change
• A clean backup exists from shortly before the change
• The website does not contain important newer data
• You know how the backup was created
• You can test or reverse the restoration

Do not restore an old database over a live shop, membership site or active form system without checking what new information would be lost.

When possible, ask the host to restore the website to a staging location first. Confirm that it opens correctly before replacing the live installation.

After restoration:

1. Test the website and dashboard.
2. Check forms, login and payment functions.
3. Identify the update or change that caused the problem.
4. Do not repeat the same update until the cause is understood.
5. Create a new backup after the site is stable.

Alternative ways to access the website

Access method	Best use
WordPress dashboard	Deactivating one plugin, changing a theme and checking site health
Recovery Mode	Entering the dashboard while a faulty plugin or theme is paused
Hosting File Manager	Renaming a plugin folder when WordPress administration is unavailable
FTP or SFTP	Accessing files when File Manager is missing or unreliable
Hosting error logs	Finding the exact PHP file or process that failed
Hosting support	Reviewing server limits, PHP configuration and private logs
Staging website	Testing updates or fixes without risking the public site

Menu names and locations differ between Hostinger, cPanel, Plesk and other hosting systems. Look for the general function rather than expecting every dashboard to use identical wording.

What not to do

Do not delete the suspected plugin immediately

Renaming or deactivating it is safer. Deleting a plugin may remove files you need for investigation and, depending on the plugin, could trigger a cleanup process.

Do not change several things together

If you update PHP, deactivate plugins, switch themes and restore files at the same time, you will not know which action fixed or worsened the problem.

Make one change and test.

Do not copy random code into wp-config.php

A small syntax mistake in this file can prevent WordPress from loading. Use only verified instructions and preserve a copy of the original file.

Do not leave debugging enabled

Debug logs can contain private technical details and may grow over time. Disable debugging when the investigation is complete.

Do not assume the website has been hacked

A critical error is evidence of a fatal software failure, not proof of malware. Investigate security only when there are additional signs, such as unknown administrator accounts, unwanted redirects, altered files or a hosting security warning.

Do not restore an old database without checking recent activity

A restoration could remove newer orders, users, comments, form entries or content.

Do not repeatedly change PHP settings

Use the error log to find the incompatible component and ask the hosting provider for a controlled change.

Do not share passwords or complete logs

A genuine support provider should not ask you to post passwords, recovery codes or complete private logs in a public discussion.

If the critical error continues

Collect the following information:

• The exact message
• The affected URLs
• The approximate time the error began
• The last update or configuration change
• Whether the dashboard works
• Whether Recovery Mode works
• Plugins or themes already tested
• The newest relevant error-log entry
• Whether a current backup exists

Send this information to your hosting provider or the developer of the file named in the error.

Copy-ready support message

Hello, my WordPress website is displaying the message “There has been a critical error on this website.” The problem began around [DATE AND TIME] after [RECENT CHANGE, IF KNOWN]. It affects [THE WHOLE WEBSITE / SPECIFIC PAGES / THE ADMINISTRATION AREA]. I have already checked the administration email and tried [SAFE STEPS COMPLETED]. The latest relevant error-log entry mentions [PLUGIN, THEME, FILE OR ERROR]. Please check the PHP error log, hosting-resource limits and any recent server changes. I have a current backup. Please let me know what non-sensitive information you need.

Remove anything inside brackets that does not apply.

How to prevent another WordPress critical error

Keep reliable off-site backups

Back up both files and the database, and periodically confirm that the backup can be restored.

Test important updates before using them on the live site

A staging website lets you test plugin, theme and server changes without affecting visitors. WordPress’s administration guidance also recommends testing changes away from the public site when they could cause disruption.

Update one important component at a time

After each major update, test:

• The homepage
• The dashboard
• Forms
• Login
• Search
• Checkout or membership functions
• Important mobile pages

Keep a simple change log

Record:

• What was updated
• When it was updated
• Who made the change
• Whether the site was tested afterwards

Remove abandoned software

Use plugins and themes that receive active maintenance and security updates. WordPress’s security guidance recommends keeping WordPress, plugins and themes updated and choosing extensions that continue to receive support.

Keep the administration email current

WordPress uses this address for recovery and fatal-error notifications. Make sure it belongs to someone who can respond when the site develops a problem.

Review website performance after recovery

If the critical error was connected to exhausted resources or heavy plugins, fixing the immediate failure may not solve the wider performance problem. Review the causes covered in Why WordPress Is Slow before the same resource problem returns.

For a broader guide to setting up and maintaining WordPress correctly, see The Comprehensive WordPress Setup Guide.

Frequently asked questions

Does a WordPress critical error mean my content is lost?

Not necessarily. The message shows that WordPress could not complete a request because of a fatal error. It does not, by itself, prove that the database or uploaded files were deleted.

Avoid making destructive changes until you have confirmed a backup.

Can I fix the error without access to WordPress administration?

Yes. You can use the hosting File Manager, FTP or SFTP to rename a suspected plugin folder. WordPress also documents renaming the whole plugins folder as a way to deactivate all plugins when the administration menus are unavailable.

Why did I not receive the WordPress recovery email?

The administration email may be wrong, inaccessible or unable to receive messages from the website. The message may also be in spam, or the hosting server may not be delivering WordPress emails correctly.

WordPress documentation confirms that fatal-error and recovery notifications use the saved Administration Email Address.

Is a plugin always responsible?

No. Plugins are common causes, but themes, custom code, damaged files, server changes, memory exhaustion and other PHP failures can produce the same message.

Use the recent-change history and error log rather than assuming every critical error is a plugin conflict.

Will deactivating a plugin delete its settings?

Normal deactivation usually leaves plugin data in place, and the official folder-renaming method is intended to preserve plugin settings while disabling the plugins. However, plugin behaviour varies, so make a backup before changing an important extension.

Should I restore a backup immediately?

Restore only when the backup is known to be clean and you understand what newer information could be overwritten.

For an active shop, booking system, membership site or form-based business, diagnosis may be safer than restoring an older database.

Can a prolonged critical error affect SEO?

A critical error can make pages unavailable to visitors and search-engine crawlers. Google states that website-availability problems prevent Googlebot from crawling as much as it otherwise might, and repeated server errors can reduce crawling. Repair the public pages promptly, but do not make unsafe changes merely to restore them a few minutes faster.

Final summary

A WordPress critical error usually means a fatal PHP problem stopped part or all of the website from loading. The message does not automatically mean your content is gone.

Start by checking the site administration email and using Recovery Mode. Next, reverse the most recent update or code change. If the dashboard is unavailable, rename only the suspected plugin folder through File Manager or FTP. When the cause remains unclear, use the hosting error log or ask the host to identify the failing file.

Keep a backup, test one change at a time and avoid deleting files or restoring an old database without understanding the effect.