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

If your WordPress website suddenly displays "There has been a critical error on this website", it usually means a PHP error has prevented WordPress from completing a request.

The problem might affect your entire website, a particular page or just the WordPress dashboard. You might also encounter a completely blank page, sometimes called the WordPress white screen of death.

The solution depends on what caused the failure. This guide explains how to identify the underlying problem, recover access to WordPress and restore your website without making unnecessary changes.

What does ‘There has been a critical error on this website’ mean?

WordPress displays this message when its fatal error handler detects a serious PHP error.

PHP is the programming language used by WordPress, its plugins and themes. If PHP encounters certain errors that prevent the requested code from continuing, WordPress may be unable to generate the page.

Common causes include:

• Plugin errors: A recently installed or updated plugin contains incompatible or faulty code.
• Theme errors: The active theme or custom theme functions trigger a PHP failure.
• PHP compatibility problems: A plugin or theme uses code that is incompatible with the PHP version running on the server.
• Memory exhaustion: A PHP process reaches its available memory limit.
• Incomplete updates: Important files are missing or have not been replaced correctly during an update.
• Custom code problems: Changes to a theme, custom plugin or other PHP files introduce an error.

A critical error does not automatically mean your website has been hacked, and the message alone cannot identify which component is responsible.

The best starting point is to establish where the error occurs and look for evidence of the underlying PHP failure.

Before troubleshooting your WordPress website

Before changing plugins, themes or server settings, establish what is actually affected.

1. Check the scope of the problem.

Try opening the homepage, another published page and the WordPress dashboard at /wp-admin/.

If only one page fails, the cause may be related to the template or functionality used on that page. If everything fails, the problem could involve code loaded across the entire website or the hosting environment.

2. Check whether the problem is consistent.

Try a private browser window or another device. If the website uses caching, a CDN or a web application firewall, remember that visitors may receive a cached response rather than the current response from your server.

3. Review recent changes.

Check whether the error started after a WordPress, plugin, theme or PHP update. Also consider custom code changes, hosting migrations and recent deployments.

A recent change provides a useful starting point, although it does not prove what caused the error.

4. Check your hosting provider.

Look for service incidents, PHP failures, exhausted resources or other server problems. These may explain an error that cannot be investigated through WordPress itself.

5. Make sure you have a recoverable backup.

Before modifying files, changing the active theme or deactivating important plugins, ensure you have a suitable backup of your website files and database.

On websites handling live orders, memberships or bookings, test potentially disruptive fixes in a staging environment where possible.

1. Check your WordPress Recovery Mode email

WordPress includes a Recovery Mode feature that can help administrators regain access when certain fatal PHP errors occur.

When WordPress detects an eligible error, it may send an email to the website administrator with details of the problem and a special Recovery Mode login link.

The email commonly has a subject similar to:

[Your Site Name] Your Site is Experiencing a Technical Issue

Check the inbox associated with the administrator email address configured in WordPress, including its spam folder.

How to use Recovery Mode

If you receive the email:

1. Open the recovery link and sign in using your WordPress administrator credentials.
2. Look for notices identifying the plugin or theme associated with the error.
3. Review the reported error and any recent changes to that component.
4. If appropriate, temporarily deactivate the affected plugin or switch away from the faulty theme.
5. Correct the underlying problem, exit Recovery Mode and test the website normally.

Recovery Mode can temporarily pause a faulty plugin or theme for your administrator session, allowing you to investigate the issue.

It does not necessarily fix the website for visitors. A component paused during your recovery session may still cause errors outside that session until the underlying problem is resolved.

For further details, see the official WordPress Recovery Mode documentation.

What if the Recovery Mode email never arrives?

Not every fatal error triggers a recovery email, and email delivery itself can fail.

If you have not received a message, check whether the administrator email address is correct and whether your website can send outgoing email.

You do not need to wait for the email before investigating. Your hosting provider’s PHP error logs can often reveal the cause directly.

2. Find the underlying PHP error

When a critical error occurs, the most useful evidence is often in the server’s PHP error logs.

Depending on your hosting setup, these may be available through a hosting control panel, a log viewer or direct server access.

Look for entries recorded around the time the error occurred.

For example, an error might include wording such as:

PHP Fatal error: Uncaught Error: Call to undefined function ...

Or:

PHP Fatal error: Allowed memory size of ... bytes exhausted

The complete error entry may identify a file path, line number and stack trace.

How to interpret the error

The wording provides clues about what failed.

Undefined function or class errors may indicate missing code, an incomplete update or incompatible components.

Uncaught exceptions and type errors can point towards problems within plugin, theme or custom PHP code.

Memory exhaustion errors indicate that a PHP process reached its configured memory limit.

If the error references a file inside wp-content/plugins/, investigate the relevant plugin. If it references wp-content/themes/, investigate the theme or its customisations.

However, the file where PHP reports an error is not always the original cause. Another component may have called the failing code or created the conditions that triggered it.

Focus on the first relevant fatal error and its surrounding details rather than changing everything mentioned in the log.

If the logs are unavailable, ask your hosting provider how to access them.

3. Enable WordPress debugging if the logs are insufficient

WordPress provides debugging settings that can help identify errors that are otherwise difficult to investigate.

These settings are controlled through the wp-config.php file.

If existing server logs do not provide enough information, a developer can temporarily enable WordPress debugging and error logging.

The relevant settings are:

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

These settings enable WordPress debugging, write messages to a log and prevent WordPress debug messages from being displayed directly to visitors.

By default, WP_DEBUG_LOG writes to wp-content/debug.log, although an alternative log location can be configured.

Important precautions

WordPress recommends using debugging tools in development or staging environments rather than routinely enabling them on live websites.

If debugging must be enabled temporarily on a live site:

• Take a backup of wp-config.php before editing it.
• Modify existing configuration definitions rather than adding duplicates.
• Keep error messages hidden from visitors.
• Ensure log files cannot be accessed publicly or expose sensitive information.
• Disable temporary debugging after the investigation and handle the resulting logs securely.

A PHP log can contain file paths, technical details and potentially sensitive information. Do not publish its contents or leave an unprotected debug log accessible from your website.

Follow the official WordPress debugging documentation for the complete configuration instructions.

4. Investigate plugin and theme errors

Plugins and themes are common places to investigate because they introduce additional PHP code into WordPress.

However, deactivating every plugin immediately is rarely the best first step on a live business website.

Doing so could interrupt payments, forms, memberships, bookings, security controls or other essential functionality.

Check a suspected plugin first

If the error appeared immediately after a particular plugin was installed or updated, start there.

If you can access the dashboard:

1. Open Plugins > Installed Plugins.
2. Locate the suspected plugin.
3. Review its version and any available compatibility information.
4. Temporarily deactivate it if doing so is safe.
5. Test the previously failing page.

If the error disappears, the plugin is a likely contributor, but further investigation may still be needed.

The proper fix could involve updating compatible components, correcting configuration, repairing custom code or contacting the plugin developer.

Do not simply reactivate a known faulty plugin and assume the problem will remain resolved.

What if you cannot access the dashboard?

If the error log identifies a particular plugin, an experienced administrator can use hosting file access to temporarily rename that plugin’s directory within wp-content/plugins/.

This prevents WordPress from loading the plugin from its original location.

For example, a directory named example-plugin might temporarily become example-plugin-disabled.

Renaming the directory is reversible, but the plugin’s functionality will be unavailable while it is disabled.

Once the issue has been investigated, restore the original directory name, check the plugin’s activation state and test its functionality before returning it to normal use.

Do not rename the entire plugins directory unless broader plugin isolation is genuinely necessary and you understand the effects on the website.

Investigate the active theme

If logs or recent changes suggest a theme problem, inspect the active theme and any custom code.

When dashboard access is available, switching temporarily to an installed default WordPress theme can help establish whether the current theme contributes to the failure.

However, changing themes on a live website can disrupt layouts, navigation, widgets and theme-dependent functionality.

Test this on staging where possible.

If the dashboard is inaccessible, a developer may be able to investigate the theme using hosting file access or WP-CLI. Avoid renaming or deleting theme directories without a controlled recovery plan.

5. Check PHP compatibility and server resources

Not every critical error is caused by a plugin or theme conflict.

Your hosting environment can also contribute to PHP failures.

Check the PHP version

An update to PHP can expose incompatible code in plugins, themes or custom integrations.

If the critical error appeared after a PHP version change, compare the installed versions of WordPress and its extensions with their documented PHP requirements.

Check the fatal error logs before deciding whether a compatibility problem exists.

Do not automatically downgrade PHP to an outdated or unsupported release just to make a website work. The appropriate long-term solution is to make the affected code compatible with a supported PHP version.

Investigate PHP memory exhaustion

If the logs contain an error mentioning Allowed memory size exhausted, a PHP process has reached its configured memory limit.

Review the configured limit and investigate which operation consumed the memory.

Possible causes include demanding plugins, inefficient code, unexpectedly large operations or insufficient hosting resources.

Increasing the memory limit may be appropriate in some circumstances, but it is not a universal fix.

The WP_MEMORY_LIMIT setting in WordPress also operates within the limits imposed by the server’s PHP configuration. Changing it does not guarantee additional memory will be available.

Investigate the cause and coordinate any necessary PHP configuration changes with your hosting provider.

Check disk space and other hosting problems

Insufficient disk space, failed updates, PHP service problems or exhausted hosting resources can prevent WordPress from functioning correctly.

Check the hosting dashboard and relevant server logs for evidence.

If the underlying issue is with the hosting infrastructure, changing WordPress plugins or themes may not help.

6. What if WordPress shows a completely blank white screen?

Sometimes WordPress displays no critical error message at all.

Instead, visitors see an entirely white page with no visible content. This is commonly called the WordPress white screen of death.

A blank screen can be caused by a PHP fatal error, but it does not always mean WordPress’s fatal error handler has detected one.

The useful distinction is whether the server failed to generate a page or the browser failed to display the expected content.

Check whether WordPress is returning content

Start by comparing the affected page with other URLs.

• Does the homepage load while a particular page remains blank?
• Can you access /wp-admin/ or the WordPress login screen?
• Does the blank page appear in another browser or private window?
• Does the problem affect everyone or only particular visitors?
• Does the response contain HTML, or is it genuinely empty?

If the server returns HTML but the page appears blank, investigate frontend scripts, styling and browser errors rather than assuming PHP has crashed.

If the server returns an empty response or a server error, PHP and hosting logs are more useful starting points.

Check caching and security layers

A CDN, page cache or reverse proxy can sometimes serve a stale or unexpected response.

Where possible, compare the public response with the origin server to determine whether the problem is happening inside WordPress or elsewhere in the delivery chain.

Clear the relevant cache only when there is a reason to suspect stale content, and avoid broad security configuration changes without identifying the cause.

Follow the same PHP troubleshooting process

If the evidence points to a PHP fatal error, follow the Recovery Mode, log inspection and component isolation steps above.

There is no need to treat the white screen as a completely separate category of PHP problem.

For other symptoms, such as database connection failures, 404 responses or gateway errors, see our broader guide to common WordPress errors and how to fix them.

7. Recover when the WordPress dashboard is inaccessible

A critical error can prevent access to the WordPress administration area.

When this happens, you may need to investigate through your hosting provider rather than through WordPress itself.

Use your hosting control panel

Many hosting providers offer access to files, PHP logs, backups and server configuration.

This may be enough to identify the faulty component and make a controlled, reversible change.

If you are unfamiliar with editing WordPress files, ask your hosting provider or a WordPress developer for assistance rather than experimenting on the live website.

Use WP-CLI if available

WP-CLI is a command-line interface for managing WordPress installations.

It can be useful when the dashboard is unavailable, allowing an experienced administrator to inspect installed plugins, check their status and deactivate a specific plugin.

For example, wp plugin deactivate example-plugin deactivates the named plugin.

However, WP-CLI commands still interact with WordPress and may encounter the same underlying errors. Some commands can run without loading normal plugins and themes, but they need to be used with an understanding of the site’s configuration.

Deactivating plugins through WP-CLI is a real website change, not simply a diagnostic query.

See the official WP-CLI plugin command documentation for supported operations.

Avoid broad plugin deactivation, database modifications or file replacement unless you have identified a good reason to take those steps.

8. Restore the website safely if the problem persists

If the error cannot be resolved through targeted troubleshooting, you may need to consider restoring a backup or repairing damaged files.

These should be evidence-based recovery decisions rather than automatic troubleshooting steps.

Restore from a known working backup

A backup taken before the problem appeared may provide a recovery route.

However, restoring an older database can overwrite information created since the backup, including orders, bookings, customer accounts, form entries and content changes.

Before restoring:

1. Confirm the backup is complete and recoverable.
2. Identify which files or database data actually need restoring.
3. Consider what information has changed since the backup was created.
4. Preserve a copy of the current website before replacing anything.
5. Test the restored website and its important functionality.

Where possible, perform the restoration on staging first.

If only a plugin or theme file is faulty, restoring the entire database may be unnecessary.

Repair damaged WordPress core files

Missing or corrupted WordPress core files can sometimes cause PHP failures, particularly after an interrupted update.

If there is evidence of a core-file problem, an experienced administrator can verify the installed WordPress files against official checksums and determine whether a core reinstall is appropriate.

A correctly performed WordPress core reinstall does not inherently remove posts, pages, uploads or other database content.

However, incorrect manual file replacement can cause further problems. Do not delete wp-content, overwrite wp-config.php or replace unrelated files as part of routine troubleshooting.

If core integrity is in doubt, use the official WordPress distribution and a documented recovery process.

9. Confirm the critical error is actually fixed

Removing the visible error message is not always enough to confirm that the underlying problem has been resolved.

After making a correction:

• Open the page that originally failed and repeat the action that triggered the error.
• Test both the public website and WordPress dashboard.
• Check the PHP logs for new fatal errors.
• Verify that important plugins and integrations are functioning.
• Test relevant forms, logins, checkout processes or membership features.
• Confirm the results from a normal visitor session, outside Recovery Mode.
• Check cached and uncached responses where applicable.

If a plugin was temporarily disabled, decide whether it should remain disabled, be repaired or be replaced.

Record what caused the error and how it was resolved. This makes future troubleshooting easier and helps prevent the same issue from recurring.

How to reduce the risk of recurring WordPress critical errors

Not every WordPress error is preventable, but maintaining a reliable update and recovery process reduces the risk of avoidable failures.

Useful precautions include:

• Keep WordPress, plugins and themes updated. Review compatibility and test important updates before applying them to live websites.
• Maintain reliable backups. Keep recoverable copies of website files and the database, and periodically confirm they can be restored.
• Use staging for higher-risk changes. Test PHP upgrades, theme changes, major plugin updates and custom code before deploying them.
• Monitor website availability and errors. Detect problems early rather than relying entirely on customers to report them.
• Review unused or unsupported components. Remove unnecessary dependencies carefully and keep custom code maintained.
• Understand your hosting environment. Make sure PHP, database services and available resources are appropriate for your website’s requirements.

These measures cannot guarantee that a critical error will never occur. They make it easier to identify problems, recover safely and minimise disruption when something does go wrong.

When to get professional help with a WordPress critical error

Some WordPress critical errors can be resolved by identifying a faulty plugin and applying a suitable fix.

Others require a deeper investigation into PHP, custom code, hosting configuration or an unsuccessful update.

Professional assistance is particularly worthwhile when the dashboard is inaccessible, the error keeps returning, the logs are unclear or the website handles important customer transactions.

If your website is showing a critical error or blank white screen, Newt Labs offers one-off WordPress website repair for defined problems.

You can explain what has stopped working and share any error messages or recent changes. We’ll investigate the agreed issue and explain if the problem requires a different service or additional work.

The important thing is to identify the underlying failure and apply a controlled fix, rather than making unrelated changes until the error disappears.