Mend
Errors
Stop the WordPress Recovery Email Loop for Good
If WordPress says “This site is experiencing technical difficulties” and keeps sending recovery emails, the real problem is usually a fatal PHP error in a plugin, theme, or custom code. The fastest fix is to identify the exact failing component, disable it safely, and then confirm the site is loading without triggering recovery mode again.
If you are locked out, work from a backup and avoid random plugin deletion or file edits until you know what broke. In a lot of cases, the fix is simple once you stop chasing the symptom and look at the error source.
What this error actually means
That message is WordPress’s safety net. It appears when WordPress hits a fatal error during a request, then switches into a recovery process so you can regain access without taking the whole site down permanently.
What many site owners see next is a recovery email, then another one, then the same error on the front end. That usually means the underlying fatal error was never fixed, so WordPress keeps entering recovery mode every time the broken code runs again.
Common symptoms you may notice
- The front end shows “This site is experiencing technical difficulties.”
- You receive a WordPress recovery mode email, often more than once.
- The admin dashboard may work briefly, then break again after a refresh.
- A specific page, form, cart, or admin screen fails consistently.
- The issue started right after a plugin, theme, or WordPress update.
What usually causes the recovery email loop
The most common cause is a plugin or theme that triggers a fatal PHP error every time WordPress loads it. Less often, the problem is a custom snippet in functions.php, a must-use plugin, a PHP version mismatch, or corrupt files after an update.
Recovery mode itself is not the problem. It is WordPress trying to protect the site from a crash. The loop happens when the broken code is still active, so every new request repeats the failure.
First: make a safe backup before you change anything
Before disabling plugins, editing files, or changing PHP settings, take a full backup of the site files and database if possible. If the site is unstable, even a partial backup is better than none.
If your host provides snapshots or restore points, use those. If not, export what you can from the hosting control panel or via SFTP and database tools. Backup first, then troubleshoot.
Step 1: use the recovery email to identify the failing component
The recovery email often names the plugin or theme file that caused the fatal error. Open the email and look for clues such as the plugin name, theme name, and file path. That is your best starting point.
If the email mentions a plugin, you can usually disable that plugin by renaming its folder over SFTP or in your file manager. If it mentions the theme, switch to a default WordPress theme if possible, or rename the active theme folder so WordPress falls back to another installed theme.
Need a structured path for that part? Use our critical error fix guide alongside this article.
Step 2: disable the most likely culprit safely
Start with the plugin or theme named in the recovery email. If you have access to wp-admin, try deactivating it there first. If the dashboard is not stable, disable it at the file level.
- Connect by SFTP or your host’s file manager.
- Go to
wp-content/plugins/. - Rename the suspected plugin folder, for example from
plugin-nametoplugin-name.disabled. - Reload the site and check whether the error disappears.
If the site recovers, you have confirmed the source. If not, restore the folder name and test the next likely plugin or theme. Do this one change at a time so you know what actually fixed it.
Step 3: check for a bad theme file or custom snippet
If the problem started after editing a theme file or adding a code snippet, the issue may live in the theme itself rather than a plugin. Common trouble spots include functions.php, custom hooks, and snippets pasted into a child theme.
Switching themes can help isolate the failure. If the site loads after changing themes, the problem is probably in the previous theme or one of its customizations. If you recently added code manually, revert that change first before looking elsewhere.
Step 4: confirm the PHP version is compatible
A plugin or theme can fail if the server is running a PHP version it does not support. This is especially common after a host updates PHP or after an older plugin is left behind for too long.
Check your hosting panel for the active PHP version, then compare it against the requirements of the plugin or theme that failed. If needed, test a slightly older supported PHP version, but do not keep an outdated version longer than necessary. Use compatibility as a diagnostic step, not a permanent workaround.
Step 5: look for a clue in the error log
If the recovery email is vague, the server error log may show the exact fatal message. You are looking for a file path, plugin name, theme name, or function name that appears at the moment the site breaks.
Depending on your host, logs may be in the control panel, a file named error_log, or a site-specific log viewer. If logging is not already enabled, avoid turning on broad debug output on a live site unless you know where it will be written and who can access it.
Step 6: clear caches after the fix
Once you disable the failing component or repair the code, clear every cache layer that could still be serving the old error page. That may include your caching plugin, host cache, CDN cache, and browser cache.
This step matters because WordPress can be fixed while cached pages still show the old failure. If the site works in one browser but not another, caching is often the reason.
When the recovery email keeps coming back
If you fix one plugin and the email returns with a different file or a different fatal error, you may have more than one issue. That can happen after a messy update, a compromised plugin, a broken mu-plugin, or a custom code stack that depends on several moving parts.
It can also happen if the site has a deeper problem in the database, file permissions, or hosting environment. At that point, the fastest path is usually to inspect the full stack carefully instead of guessing at the next disabled plugin.
What not to do
- Do not keep clicking recovery emails without fixing the underlying error.
- Do not delete plugins blindly if you have not identified the failing one.
- Do not edit multiple files at once, or you will not know what changed.
- Do not ignore backups before making server-side changes.
- Do not assume the newest update is the cause without checking logs and timestamps.
How to prevent this from happening again
The best prevention is boring but effective: update plugins and themes in a safe order, keep backups before updates, and remove plugins you no longer use. A smaller, cleaner code stack is much easier to troubleshoot when something breaks.
It also helps to use only trusted plugins, keep PHP within a supported range, and test updates on staging when the site is business-critical. If a plugin has a history of breaking after updates, replace it before it becomes a recurring outage.
When to call a professional
If the error keeps looping, the recovery email is unclear, or the site is a revenue channel you cannot afford to leave unstable, it is worth handing off. A senior engineer can trace the fatal error, isolate the root cause, and fix the site without making the damage worse.
If you want that done fast, start with free diagnosis. Mend’s engineers work from a backup-first process, most fixes are completed the same day, and you get a plain-English report of what broke and exactly what changed. If the site is fully down or time-sensitive, use Emergency Rescue; if you just need the issue pinned down and fixed quickly, Quick Fix is often the right fit.
For sites that keep breaking after updates, a Care Plan can prevent repeat emergencies with managed updates, backups, security, and uptime monitoring. If you want to connect the site securely without sharing passwords, use Mend Connect.
A practical shortcut for today
If the error began right after a plugin or theme update, your first test should be disabling the most recently changed component. If the site is still broken after that, check the recovery email, then the error log, then the PHP version. That order catches most cases quickly.
If you have already spent too long on it, stop cycling through guesses. A focused diagnosis is usually cheaper than the downtime caused by a half-fixed site.
Related reading
Frequently asked questions
Is “This site is experiencing technical difficulties” the same as a critical error?
They are closely related. WordPress often shows this message when a fatal PHP error stops a plugin, theme, or custom code from loading.
Why do I keep getting the recovery email after fixing one thing?
Usually because the original cause is still active somewhere else, or because there is more than one fatal error. Check the exact file or plugin named in each email and test one change at a time.
Can I just delete the plugin that caused it?
You can remove it after you confirm it is the source, but start by disabling it safely and taking a backup first. Deleting blindly can make recovery harder if the issue is actually in a theme or custom snippet.
What if I cannot access wp-admin at all?
Use SFTP or your host’s file manager to rename the suspected plugin or theme folder. If you still cannot identify the source, a professional diagnosis is the fastest way to avoid more downtime.