WordPress critical error: how to fix "There has been a critical error on this website"

Step 1: access the dashboard through the recovery mode link

If dashboard access is unavailable, the first and easiest route is the recovery mode link in the administrator email. In this mode, the faulty plugin or theme is paused only for the browser of the person using the link; visitors continue to see the error.

1. Click the email link and sign in with the administrator account.
2. Identify the faulty plugin or theme in the notice at the top of the dashboard; the relevant plugin is marked paused on the Plugins screen.
3. Deactivate the faulty plugin; update it if a newer version exists, or find a compatible alternative otherwise.
4. Close recovery mode using the exit button in the admin bar.
5. Check the site in a logged-out incognito browser window.

Pausing applies only to the recovery mode session, not the whole site. Exiting without deactivating the plugin leaves the error in place for everyone. An incognito check is the easiest way to confirm the WordPress critical error screen is also gone for visitors.

Step 2: read the error log with WP_DEBUG_LOG

If the email did not arrive or the source is unclear, the error log is the most reliable source identifying the file and line responsible. WordPress’s debugging documentation recommends adding these lines to wp-config.php to enable logging:

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

With these settings, errors are written to debug.log in wp-content instead of displayed on screen. Open the site again to trigger the error; the final lines show a record beginning “PHP Fatal error” and the path of the responsible file. A folder under wp-content/plugins points to that plugin; wp-content/themes points to the theme.

WordPress documentation recommends using debugging tools on local and staging installations rather than live sites. The Site Health screen also warns that errors are written to a potentially public file. Once the issue is identified, remove these lines or set them to false, and delete debug.log from the server.

Step 3: disable plugins through FTP if you cannot access the dashboard

Without a recovery link, plugins can be disabled together by renaming the plugins folder through FTP or the hosting file manager. WordPress cannot find plugins in the renamed folder, so it does not load them; official documentation recommends this when dashboard access is unavailable.

1. Use an FTP client or hosting file manager to enter the site’s root directory, then open wp-content.
2. Rename plugins to plugins_old.
3. Refresh the site; if it opens, one of the plugins is responsible.
4. Rename the folder back to plugins; plugins appear deactivated in the dashboard and can be activated one by one.
5. Check the site after each activation; leave the plugin that brings the error back disabled.

If the error log already identifies the faulty plugin, rename just its folder rather than the entire plugins folder. This method does not delete plugin files and is reversible; settings for most plugins remain in the database and return upon reactivation.

Step 4: check the theme, PHP version, and memory limit

If the WordPress critical error remains with plugins disabled, the next suspects are the active theme, server PHP version, and memory allocated to WordPress. Evaluating these three checks alongside the error log message substantially narrows the problem.

Switching to a default theme

If dashboard access is available, switch to a default Twenty-series theme through Appearance > Themes; otherwise rename the active theme’s folder in wp-content/themes. If the site opens with a default theme, investigate the theme or code added to the child theme’s functions.php. Keeping at least one default theme installed makes this step easier.

PHP version

WordPress’s server requirements page recommends PHP 8.3 or higher; WordPress also runs on PHP 7.4 and above, but these older versions have reached end of official support. If the error began after the hosting company upgraded PHP, an old plugin or theme may be incompatible. The temporary solution is reverting through the hosting panel; the permanent solution is updating or replacing the incompatible component.

Memory limit

If the log contains “Allowed memory size exhausted”, PHP lacks sufficient memory. By default, WordPress tries to raise memory to 40 MB for single sites and 64 MB for multisite; according to the wp-config.php documentation, the limit can be raised with this line:

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

Add the line in wp-config.php before wp-settings.php is called. Some hosts do not allow this increase; then the limit must be raised on the hosting side. If memory regularly runs out on shared hosting, review the package choice too; options appear on the hosting prices page.

Step 5: restore a backup if nothing works

If the source cannot be found or files are damaged, the safest way out of a WordPress critical error is restoring a clean backup from before the error. WordPress’s backup documentation emphasizes that both files and the database must be backed up for full restoration.

• Hosting backups: Choose a date from automatic backups in the hosting panel and restore files and the database together.
• Plugin backups: Copies sent to remote storage (cloud or a separate server) remain accessible even when server files are corrupted.
• Backup date: Restoring a backup made after the error began brings the problem back; choose the last clean copy from before the error.
• Loss of new content: Posts, orders, and form records added after the backup date may be lost when restoring.

For e-commerce sites, exporting recent orders before restoration is recommended. When core files are corrupted, reinstalling wp-admin and wp-includes from a clean WordPress package is also a method listed in the official error documentation.

Common mistakes: random intervention or systematic diagnosis?

What prolongs a WordPress critical error is often rushed intervention before finding the source rather than the error itself. The table below compares common practices with systematic diagnosis:

Another common mistake is adding code directly to core or parent theme files. These changes disappear with the first update or cause a new conflict; keeping custom code in a child theme or separate plugin is healthier.

When should you consult a specialist for a WordPress critical error?

If dashboard and file access are unavailable, the log is unclear, or malicious code is suspected, specialist support reduces time and data loss risks. Independent intervention becomes risky in these situations:

• FTP, hosting panel, or backup credentials are unknown
• The error has stopped order and payment flows on an e-commerce site
• The log shows unfamiliar filenames, unreadable encoded snippets, or unexpected redirects
• The error remains after plugin, theme, PHP, and memory checks
• The problem is in a custom theme or plugin’s code

For hack-related errors, simply disabling a plugin is insufficient; if a backdoor remains, the problem soon returns. These situations fall within the hacked WordPress site recovery service. Our approach to other faults without signs of hacking is explained on the WordPress troubleshooting page.

Maintenance and staging to prevent recurrence

The two habits reducing recurrence risk most are backing up before updates and testing updates in staging first. WordPress’s backup documentation recommends regular database backups and one before every upgrade; it mentions weekly backups for small sites and daily backups for busy sites.

• A full pre-update backup of files and the database, with multiple copies in different locations
• Updates in groups rather than all at once, checking the frontend, forms, and payment step after each group
• Regular Site Health monitoring without postponing old PHP and pending update warnings
• Removal of unused plugins and themes
• A current, accessible administration email because recovery emails arrive there

A staging environment is a copy of the live site closed to visitors. The environment types feature introduced in WordPress 5.5 allows an installation to be marked “staging” through WP_ENVIRONMENT_TYPE and plugins to respond accordingly. Test updates on this copy first, then apply them live if no issues occur.

How does Onur Freelance’s WordPress maintenance process work?

At Onur Freelance, based in Maltepe since 2019, our WordPress maintenance order is backup first, testing second, live updates last. The same order applies to critical errors: copy the current state before touching the site, then investigate the source through the error log.

Annual WordPress maintenance and updates provides controlled core, plugin, and theme updates; afterward, key pages, contact forms, and the payment step, if present, are checked. Every action is recorded, making it possible to see which change preceded a problem. Maintenance costs 500–2,000 TL per month depending on site size and scope, clarified in the initial consultation.

We do not say every fault takes the same time to resolve; timing depends on the source and whether access details are ready. Other work such as setup, migration, and speed is listed on the WordPress services page.