WordPress Critical Error Without Recovery Email: How to Fix It

Seeing the message “There has been a critical error on this website” is stressful, especially when WordPress tells you to check the administrator email but no recovery email arrives.

Fortunately, the missing email does not prevent you from repairing the website. You can troubleshoot the error through your hosting control panel, File Manager, SFTP, SSH, database, or WordPress debug logs—even when you cannot access wp-admin.

In most cases, the critical error is caused by a faulty plugin, an incompatible theme, a failed update, insufficient PHP memory, unsupported PHP code, or an error inside a custom code snippet.

This guide explains how to fix a WordPress critical error without a recovery email, identify the exact cause, restore dashboard access, and prevent the same issue from happening again.

TL;DR

If you did not receive the WordPress recovery email, start by disabling all plugins through File Manager:

1. Open your hosting control panel.
2. Go to public_html/wp-content/.
3. Rename the plugins folder to plugins-disabled.
4. Reload your website.

If the website starts working, rename the folder back to plugins and activate the plugins individually until you find the one causing the error.

If plugins are not responsible, temporarily disable the active theme, enable WordPress debug logging, check your PHP version and memory limit, and review the server error logs.

What Does the WordPress Critical Error Mean?

A WordPress critical error normally means that PHP encountered a fatal problem and could not finish loading the requested page.

Instead of displaying the raw PHP error publicly, WordPress shows a general message:

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

The website may become completely unavailable, or the error may only affect a specific area such as:

• The WordPress dashboard
• A particular page or post
• The checkout page
• The theme customizer
• The plugin editor
• A form or page builder
• WooCommerce product pages

The visible message is not the actual cause. It is only WordPress informing you that a fatal PHP error has occurred. You must inspect the plugins, theme, PHP configuration, or error logs to find the underlying problem.

Why Did You Not Receive the WordPress Recovery Email?

WordPress introduced Recovery Mode to help administrators regain access after a fatal error. When WordPress detects an eligible error, it attempts to send a special login link to the website administrator’s email address.

However, the recovery email may not arrive for several reasons.

1. WordPress Cannot Send Emails

Many WordPress installations rely on the server’s default PHP mail function. If the hosting server does not support it properly, WordPress emails may fail silently.

2. The Administrator Email Address Is Incorrect

The email may have been sent to an old, misspelled, or inaccessible administrator address stored in the WordPress database.

3. The Email Went to Spam

Recovery emails can be filtered into the spam, junk, promotions, or quarantine folder, especially when the website does not use authenticated SMTP delivery.

4. The Fatal Error Prevented Recovery Mode

Not every fatal error triggers a recovery email. Some errors happen too early in the WordPress loading process, preventing the recovery system from functioning correctly.

5. The Server Failed Before WordPress Loaded

If the issue comes from the PHP configuration, web server, damaged core files, or server-level permissions, WordPress may not load far enough to create and send the email.

6. Email Authentication Is Missing

Messages sent from a domain without correctly configured SPF, DKIM, or DMARC records may be rejected or filtered by the receiving email provider.

Before You Start Troubleshooting

Create a backup before editing your website files or database. Even if the site is currently broken, download a copy of the following:

• The complete WordPress installation
• The wp-content folder
• The wp-config.php file
• The WordPress database

You can normally create or download a backup through cPanel, DirectAdmin, Plesk, your hosting dashboard, a server snapshot, or phpMyAdmin.

A backup allows you to reverse any change that causes an additional problem.

Method 1: Disable All WordPress Plugins Through File Manager

A plugin conflict is one of the most common causes of a WordPress critical error. The problem may appear after:

• Installing a new plugin
• Updating an existing plugin
• Changing the PHP version
• Updating WordPress
• Activating two incompatible plugins
• Adding a broken custom snippet

You can disable all plugins without accessing the WordPress dashboard.

Disable Plugins Using File Manager

1. Sign in to your hosting control panel.
2. Open File Manager.
3. Navigate to your WordPress installation directory. It is commonly named public_html.
4. Open the wp-content folder.
5. Find the folder named plugins.
6. Rename it to plugins-disabled.
7. Reload your website and WordPress dashboard.

The folder path should look similar to this:

public_html/wp-content/plugins

After renaming:

public_html/wp-content/plugins-disabled

WordPress will no longer be able to locate the active plugin files, so it will deactivate them automatically.

How to Identify the Faulty Plugin

If the site starts working after disabling all plugins:

1. Rename plugins-disabled back to plugins.
2. Open the plugins folder.
3. Rename one individual plugin folder at a time.
4. Reload the website after each change.

For example:

elementor
elementor-disabled

If the website starts loading after renaming a particular plugin folder, that plugin is likely responsible.

Keep the problematic plugin disabled and then:

• Update it to the latest compatible version.
• Check whether it supports your PHP version.
• Replace it with a maintained alternative.
• Contact the plugin developer with the fatal error details.
• Restore an earlier working version if the error started after an update.

Method 2: Disable the Active WordPress Theme

If disabling plugins does not fix the critical error, the active theme or child theme may contain incompatible PHP code.

This is especially likely if the error started after:

• Updating the theme
• Editing functions.php
• Adding custom PHP code
• Changing the PHP version
• Updating a page builder
• Installing a child theme

Disable the Theme Through File Manager

1. Open File Manager.
2. Go to public_html/wp-content/themes/.
3. Find the folder of the active theme.
4. Rename the folder by adding -disabled.

For example:

astra
astra-disabled

WordPress will attempt to activate another installed default theme, such as Twenty Twenty-Six.

Make sure a default WordPress theme is already installed before disabling the current theme. If no alternative theme exists, upload an official default theme to the themes directory first.

If the website works with the default theme, the original theme or its child theme contains the error.

Check the Theme’s functions.php File

If you recently added code to the theme’s functions.php file, remove or correct that code.

Common mistakes include:

• A missing semicolon
• An unmatched bracket
• An undefined function
• A duplicated function name
• Code using a removed PHP feature
• Code pasted outside the correct PHP tags

Restore the original file from a backup if you are unsure which change caused the error.

Method 3: Enable WordPress Debug Logging

Debug logging is one of the most effective ways to find the exact cause of a WordPress critical error when no recovery email is available.

WordPress can save PHP warnings and fatal errors inside a private log file instead of displaying them to website visitors.

Edit the wp-config.php File

Open the wp-config.php file in your WordPress root directory.

Find this line:

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

Add the following code immediately above it:

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

Save the file and reload the page that produces the critical error.

WordPress should create a log file at:

wp-content/debug.log

How to Read the Debug Log

Open debug.log and look near the bottom for recent entries containing phrases such as:

• PHP Fatal error
• Uncaught Error
• Allowed memory size exhausted
• Call to undefined function
• Cannot redeclare
• Class not found
• Parse error

A plugin-related error may look similar to this:

PHP Fatal error: Uncaught Error: Call to undefined function
in /public_html/wp-content/plugins/example-plugin/includes/file.php

The file path identifies the plugin or theme responsible for the failure.

For example:

• /wp-content/plugins/ indicates a plugin problem.
• /wp-content/themes/ indicates a theme problem.
• /wp-includes/ may indicate damaged core files, although plugins can also trigger errors inside core functions.

Disable Debug Mode After Troubleshooting

Do not leave debug logging enabled permanently on a production website.

After resolving the error, change the settings to:

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

You should also delete the debug.log file because it may contain server paths, plugin information, database details, or other technical data.

Method 4: Check the Hosting Error Log

If WordPress does not create a debug log, check the hosting server’s PHP error log.

Depending on your hosting environment, you may find it in:

• cPanel under Metrics > Errors
• DirectAdmin under Site Summary > Error Log
• Plesk under Websites & Domains > Logs
• Your managed hosting dashboard
• The website’s root directory as error_log
• The server log directory through SSH

Look for errors recorded at the exact time the website stopped working.

Server logs are particularly useful when the problem occurs before WordPress can load or write to its own debug file.

Method 5: Increase the WordPress PHP Memory Limit

A plugin, theme, page builder, import process, or WooCommerce task may consume more memory than PHP allows.

The debug log may show an error similar to:

Allowed memory size of 134217728 bytes exhausted

You can try increasing the WordPress memory limit by adding the following lines to wp-config.php:

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

Add them above:

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

The normal limit applies to the public website, while the maximum limit is primarily used for administrative tasks.

Keep in mind that your hosting provider can enforce a lower server-level limit. If the value does not change, update the PHP configuration through your hosting panel or ask the provider to increase it.

Increasing memory can restore the website, but you should still identify why the application consumed excessive resources. A badly coded plugin, large database query, repeated background process, or malware infection may continue causing problems.

Method 6: Check the PHP Version

A WordPress website can produce a critical error when a plugin or theme is incompatible with the active PHP version.

This commonly happens after upgrading from an older PHP version to a newer release. Older code may depend on functions or syntax that are no longer supported.

Temporarily Change the PHP Version

Open the PHP version selector in your hosting dashboard and temporarily switch to the previous version that worked with the website.

For example, if the error started immediately after moving to a newer PHP release, temporarily return to the earlier supported version while you update or replace the incompatible extension.

Do not treat an outdated PHP version as a permanent solution. Older versions eventually stop receiving security updates and should not be used longer than necessary.

Review the Error After Changing PHP

If changing the PHP version restores the site, one of the following is probably true:

• A plugin is not compatible with the newer PHP version.
• The theme contains outdated PHP code.
• A custom snippet uses a removed function.
• An ionCube-encoded extension requires a compatible loader.
• The server is missing a required PHP extension.

Update the affected software before switching back to the newer PHP version.

Method 7: Undo a Recent Code Change

If the error appeared after adding a code snippet, tracking script, custom function, or theme modification, reverse that change first.

Check the following locations:

• The active theme’s functions.php file
• A child theme
• A custom plugin
• A must-use plugin inside wp-content/mu-plugins/
• A code snippets plugin
• The wp-config.php file
• The .htaccess file

If a code snippets plugin caused the error and you cannot access the dashboard, disable the plugin through File Manager. You can then log in and remove the faulty snippet.

Method 8: Restore the Default .htaccess File

A damaged or incorrectly configured .htaccess file can break page loading, redirect requests incorrectly, or cause server errors.

Open your WordPress root directory and rename:

.htaccess

to:

.htaccess-old

Reload the website. If it starts working, the original file contained an invalid rule.

After regaining dashboard access:

1. Go to Settings > Permalinks.
2. Do not change the selected structure.
3. Click Save Changes.

WordPress will attempt to generate a clean .htaccess file.

If it cannot create the file automatically, use the standard WordPress rewrite rules:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Websites installed in a subdirectory may require different rewrite paths.

Method 9: Reinstall the WordPress Core Files

Missing or damaged WordPress core files can also produce critical errors. This may happen because of:

• An interrupted update
• Incorrect file permissions
• A failed migration
• Malware removal
• Accidental file deletion
• Incomplete file uploads

You can safely replace the core files without deleting your content.

Manual Core Reinstallation

1. Download a clean WordPress package from the official WordPress website.
2. Extract it on your computer.
3. Delete the wp-content folder from the extracted copy.
4. Do not upload the included wp-config-sample.php file if it may overwrite custom configuration.
5. Upload the remaining WordPress folders and files to your website.
6. Allow the clean files to replace the existing core files.

Do not delete or overwrite your live wp-content folder or wp-config.php file.

Your posts, pages, users, and settings are stored in the database, while your themes, plugins, and media are stored in wp-content.

Method 10: Check File and Folder Permissions

Incorrect permissions can prevent WordPress or PHP from reading required files.

Typical WordPress permissions are:

Folders: 755
Files: 644
wp-config.php: 600 or 640, depending on the server

Do not set all files and folders to 777. It creates a serious security risk and rarely solves the actual problem.

If permissions repeatedly change or cannot be corrected, the file ownership may be wrong. Your hosting provider may need to reset ownership at the server level.

Method 11: Disable Must-Use Plugins and Drop-In Files

Renaming the standard plugins folder does not disable must-use plugins or certain WordPress drop-in files.

Check:

wp-content/mu-plugins/

Temporarily rename the mu-plugins folder if it exists.

You should also inspect these optional files:

wp-content/advanced-cache.php
wp-content/object-cache.php
wp-content/db.php
wp-content/sunrise.php

These files may be created by caching, database, multisite, or hosting optimization tools. Rename them individually and test the website after each change.

Do not permanently remove a drop-in file unless you know which plugin or service created it.

Method 12: Clear Every Cache Layer

A cached fatal error, stale PHP opcode, or outdated generated file can make the website appear broken after the original issue has been corrected.

Clear all relevant cache layers:

• WordPress caching plugin cache
• Hosting or server cache
• Object cache such as Redis or Memcached
• Content delivery network cache
• Browser cache
• PHP OPcache
• Page builder generated CSS and files

If you cannot access the dashboard, clear the cache through your hosting panel or temporarily rename the cache plugin’s folder.

Method 13: Check the WordPress Database

A corrupted database table or incorrect configuration can prevent WordPress from loading normally.

Database problems more commonly show a database connection error, but they can also trigger fatal errors inside plugins that rely on damaged or missing tables.

Confirm the Database Credentials

Open wp-config.php and verify these values:

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'localhost' );

Do not share these values publicly.

Use WordPress Database Repair

Add the following line to wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

Then visit:

https://example.com/wp-admin/maint/repair.php

Select either:

• Repair Database
• Repair and Optimize Database

Remove the WP_ALLOW_REPAIR line immediately after finishing because the repair screen does not require a WordPress login while enabled.

Method 14: Disable Plugins Through the Database

If you cannot rename the plugin folder, you can deactivate plugins through phpMyAdmin.

1. Open phpMyAdmin from your hosting control panel.
2. Select the WordPress database.
3. Open the options table. It is usually named wp_options, although the prefix may be different.
4. Find the row named active_plugins.
5. Back up the existing value.
6. Replace the value with:

a:0:{}

This deactivates all standard plugins.

Be careful when editing serialized WordPress data. Incorrect values can damage settings. Renaming the plugin folder is generally safer when File Manager access is available.

Method 15: Use WP-CLI

If your hosting plan provides SSH and WP-CLI access, you can troubleshoot the site without using the dashboard.

Navigate to the WordPress installation directory and deactivate all plugins:

wp plugin deactivate --all

Check the installed plugins:

wp plugin list

Activate plugins individually:

wp plugin activate plugin-slug

Switch to a default theme:

wp theme activate twentytwentysix

Verify WordPress core checksums:

wp core verify-checksums

Reinstall the current WordPress core version:

wp core download --force --skip-content

WP-CLI is efficient, but commands should be executed from the correct WordPress directory and preferably after creating a backup.

Method 16: Restore a Working Backup

If the critical error began after a known update or code change and troubleshooting is taking too long, restoring a recent clean backup may be the safest recovery option.

Restore both:

• The website files
• The matching database backup

Restoring only the files or only the database can create version mismatches, especially on WooCommerce, membership, booking, and learning management websites.

For an online store, avoid restoring an old database without checking whether it will remove recent orders, customer accounts, form submissions, or inventory changes.

A staging restoration may be safer for websites with frequently changing data.

How to Change the WordPress Administrator Email Without wp-admin

If the recovery email was sent to the wrong address, you can update the administrator email through phpMyAdmin.

1. Open phpMyAdmin.
2. Select the WordPress database.
3. Open the options table.
4. Find the admin_email row.
5. Replace it with an email address you can access.

You may also need to update the email address of the administrator user:

1. Open the users table, commonly named wp_users.
2. Find the administrator account.
3. Update the user_email value.

Changing these values may help with future WordPress notifications, but it does not guarantee email delivery. Configure authenticated SMTP after restoring dashboard access.

How to Fix WordPress Email Delivery After Recovery

Once your website is working again, fix the email problem so future recovery links and administrative notices can reach you.

Use an SMTP Plugin

Configure WordPress to send mail through a proper email provider rather than depending only on the server’s default PHP mail function.

Use an SMTP service or transactional email provider that supports authenticated delivery and provides delivery logs.

Use a Domain-Based Sender Address

Send website emails from an address on your own domain, such as:

wordpress@example.com
notifications@example.com

Avoid using a free personal address as the sender for website-generated mail when the message is actually being sent from your hosting server.

Configure Email Authentication

Make sure the sending domain has valid:

• SPF records
• DKIM signatures
• DMARC policy

These records improve message authentication and reduce the chance of administrative emails being rejected or marked as spam.

Send a Test Email

After configuring SMTP, send a test message and confirm that:

• The message reaches the correct inbox.
• The sender address is correct.
• SPF and DKIM pass.
• The message does not enter the spam folder.
• The email provider records successful delivery.

What If the Critical Error Only Appears in wp-admin?

If the public website works but the dashboard shows a critical error, the problem may be related to:

• An admin-only plugin function
• A dashboard widget
• A plugin update screen
• A page builder editor
• Insufficient administrative memory
• A corrupted user preference
• A security or optimization plugin

Start by disabling plugins and increasing WP_MAX_MEMORY_LIMIT. Then review the debug log while requesting the affected dashboard page.

You can also try accessing a direct dashboard URL:

https://example.com/wp-admin/plugins.php
https://example.com/wp-admin/themes.php
https://example.com/wp-admin/update-core.php

If only one admin page fails, the error log should reveal which function runs on that page.

What If Only One WordPress Page Has the Critical Error?

A critical error affecting only one page may be caused by:

• A broken shortcode
• A page builder widget
• A damaged reusable block
• A plugin function used only on that page
• An invalid template assignment
• A large database query
• An embedded custom PHP snippet

Enable debug logging and load the affected page to capture the error.

If you use a page builder, try opening the page in safe mode or disabling third-party builder extensions. You may also duplicate the page and remove sections individually to identify the broken element.

What If the Critical Error Started After a WordPress Update?

A WordPress core update may expose outdated code in a plugin or theme even when the core update itself completed correctly.

Follow this order:

1. Disable all plugins.
2. Switch to a default theme.
3. Verify or reinstall the WordPress core files.
4. Update compatible plugins and themes individually.
5. Review the debug log after each activation.

Avoid immediately downgrading WordPress unless you have confirmed a genuine core compatibility issue. In many cases, the real cause is an outdated extension.

What If the Critical Error Started After Updating a Plugin?

Disable the recently updated plugin first. If the website returns:

• Check the plugin changelog.
• Confirm its WordPress and PHP requirements.
• Clear all caches.
• Install a corrected release when available.
• Restore the previous plugin version from a clean backup if necessary.

Do not download old plugin versions from unofficial websites. Modified plugin packages may contain malware or hidden backdoors.

When Should You Contact Your Hosting Provider?

Contact your hosting provider when:

• You cannot access File Manager, SFTP, or SSH.
• The PHP version cannot be changed.
• The PHP memory limit is locked.
• The error log is unavailable.
• File ownership is incorrect.
• The server returns repeated 500 or 503 errors.
• The database server is unavailable.
• Permissions automatically revert.
• The website was suspended or isolated.
• You suspect a server-level failure.

Send the provider the exact time of the error, the affected URL, your recent changes, and any fatal error entry you found. Specific details make the investigation faster.

How to Prevent WordPress Critical Errors

Use a Staging Website

Test WordPress, plugin, theme, and PHP updates on a staging copy before applying them to the production website.

Create Automatic Backups

Maintain scheduled backups of both the files and database. Store at least one copy outside the main hosting account.

Update Plugins Carefully

Avoid updating every plugin at once on an important website. Update in smaller groups and check the website after each change.

Remove Abandoned Plugins and Themes

Inactive software can still create security risks. Delete extensions you no longer use instead of leaving them installed indefinitely.

Use Supported PHP Versions

Keep PHP current, but verify that your plugins and themes support the target version before upgrading.

Monitor PHP Errors

Review error logs periodically. Repeated warnings may reveal an incompatibility before it develops into a fatal error.

Use a Reliable SMTP Service

Authenticated SMTP helps WordPress deliver security notices, password reset messages, order emails, and Recovery Mode links more reliably.

Avoid Editing Production Files Directly

Test custom code in staging and keep a copy of the original file. A small syntax error can make the entire website inaccessible.

Use Child Themes for Customizations

A child theme keeps custom code separate from the parent theme and reduces the risk of losing modifications during an update.

WordPress Critical Error Troubleshooting Checklist

• Check spam and junk folders for the recovery email.
• Back up the website files and database.
• Disable all standard plugins.
• Disable must-use plugins and drop-ins if necessary.
• Switch to a default WordPress theme.
• Enable private debug logging.
• Review the WordPress and server error logs.
• Check the PHP version and required extensions.
• Increase the PHP memory limit when appropriate.
• Undo recent code changes.
• Regenerate the .htaccess file.
• Clear plugin, server, object, CDN, and browser caches.
• Check file permissions and ownership.
• Verify or reinstall the WordPress core files.
• Repair the database if the logs indicate database problems.
• Restore a clean backup if manual recovery is unsuccessful.
• Configure SMTP after the website is restored.

Frequently Asked Questions

Can I fix a WordPress critical error without the recovery email?

Yes. You can disable plugins and themes through File Manager or SFTP, enable WordPress debug logging, inspect the server error log, change the PHP configuration, repair the database, or use WP-CLI without opening the recovery email.

Why did WordPress not send the recovery email?

The email may fail because WordPress mail delivery is not configured properly, the administrator address is incorrect, the message was filtered as spam, or the fatal error occurred before Recovery Mode could generate the message.

What is the fastest way to fix a WordPress critical error?

Disable all plugins by renaming the wp-content/plugins folder. If the website starts working, reactivate the plugins individually to identify the faulty one.

Where is the WordPress critical error log?

After enabling WP_DEBUG_LOG, WordPress normally stores errors in wp-content/debug.log. Your hosting panel may also provide a separate PHP or web server error log.

Will renaming the plugins folder delete my plugins?

No. Renaming the folder only prevents WordPress from loading the plugins. The plugin files and settings remain available. Rename the folder back after testing.

Will disabling the theme delete my website design?

No. Renaming the active theme folder does not delete its files, settings, pages, or content. WordPress temporarily switches to another available theme until you restore or repair the original one.

Can low PHP memory cause a critical error?

Yes. Resource-heavy plugins, page builders, imports, database queries, and administrative tasks can exhaust the available PHP memory and trigger a fatal error.

Should I display PHP errors publicly?

No. Publicly displayed errors can reveal server paths, plugin names, database information, and other technical details. Save errors privately to a debug log instead.

Should I restore a backup or troubleshoot the error?

Restore a backup when you need the website online quickly and have a recent clean copy. Troubleshooting is preferable when restoring would remove recent orders, content, users, or other important data.

How can I make sure future recovery emails arrive?

Use an authenticated SMTP service, verify the WordPress administrator email, configure SPF and DKIM, publish an appropriate DMARC policy, and test email delivery after setup.

Final Thoughts

A missing recovery email can make a WordPress critical error feel more serious than it is. However, the email is only one recovery method. File Manager, SFTP, debug logs, hosting error logs, phpMyAdmin, and WP-CLI provide several ways to restore the website.

Start with the most common cause by disabling all plugins. If that does not work, test the theme, enable debug logging, check PHP compatibility and memory, and inspect the server logs. The first recent fatal error usually points directly to the plugin, theme, file, or function responsible.

After restoring the website, configure reliable SMTP delivery, create automatic off-site backups, and test future updates in staging. These steps reduce downtime and make the next WordPress error much easier to diagnose.