WordPress says “There has been a critical error on this website.” The public message is brief, but a recovery email or PHP log may identify the failed component. Start there instead of reinstalling the entire site.
This guide helps you regain access, separate the PHP error from the generic message, and check that the normal site works after recovery.
Guide reviewed: October 8, 2026. Menu labels use English WordPress; provider-specific controls may differ.
Quick diagnosis
| Evidence | Start here | What it does not prove |
|---|---|---|
| Recovery email names a plugin | Open the private recovery session | Visitor requests are not necessarily repaired |
| Error began after editing PHP | Restore the known-good edited file | A cache purge cannot fix invalid syntax |
| No recovery email | Ask the host for the matching PHP fatal log | Missing email does not mean there was no fatal error |
| Only one action fails | Reproduce that action once with its timestamp | A working homepage does not cover every feature |
Find the recovery email
- Check the configured administrator inbox and spam folder.
- Confirm the domain and recent error match your site.
- Use the private recovery link; do not paste it into a public comment.
- Record the component, error and version before changing anything.
- After the repair, leave recovery mode and test normal access.
Check the site administrator’s inbox and spam folder for a message about a technical issue. WordPress may include the plugin or theme involved, the error details, and a private recovery link.
Keep that link private and confirm that the message belongs to your site. Recovery mode may allow you to enter a session where the affected component is paused. That gives you room to investigate, but it does not mean the normal public site has been repaired.
If no email arrives, use the hosting panel and logs instead. Some failures occur before the recovery handler or email integration can run, and recovery mode does not cover every background-task failure. Repeatedly waiting for another email can delay a more direct investigation.
Connect the error with the last change
Record the time and what happened just before the failure. A plugin update, new snippet, theme edit, or PHP-version change is a useful starting point. If only one type of page fails, include that pattern too.
A restored known-good file can be the quickest repair after a code edit. If an update was interrupted, the installed package may be incomplete. If the package is complete but requires a different PHP version, replacing it with the same copy will not solve the compatibility issue.
Keep the current files before making changes, and confirm a usable files-and-database backup. An old database restore can remove legitimate recent content or orders, so it should not be the automatic response to a broken plugin file.
Read the specific PHP failure
| Error clue | Follow-up |
|---|---|
| Parse or syntax error | Compare the edited PHP file with its known-good copy |
| Undefined function or class | Check dependencies, load order and version requirements |
| Allowed memory size exhausted | Check the task and active PHP memory allowance |
| Missing required file | Check whether an update or upload left an incomplete package |
Your host can match a failed request with the PHP error log. An undefined function, missing file, syntax error, or exhausted memory allowance gives you a more precise direction than the generic critical-error screen.
For invalid PHP, follow the syntax-error guide. For an allowed-memory message, follow the memory guide. Keep the file path and surrounding trace for a private support request.
If temporary debugging is needed, avoid displaying those details to visitors and protect the generated log. A developer can collect the relevant entry and remove unnecessary diagnostics when the repair is complete.
Repair or pause the affected component
A controlled comparison: on staging, repeat the failing action, pause one suspected component, then repeat the same action. If the error changes, record both results. A renamed plugin directory should be restored to its original name when the supported repair is ready; do not delete its data as a diagnostic step.
When recovery mode or the normal dashboard identifies one plugin, you can review its requirements and update or replace it using the developer’s supported method. Custom changes should be preserved separately before files are overwritten.
If the dashboard is unavailable, an administrator or host may temporarily prevent the suspected plugin from loading through the file manager. This stops the plugin’s features too. A site that opens again with checkout disabled is recovered enough to investigate, but not ready to call fully repaired.
A theme can depend on a parent theme or bundled plugin. Test a theme change on staging when possible, and make sure an appropriate replacement is available. Renaming theme folders blindly can create an additional failure.
Check the normal site after leaving recovery mode
Once the cause is repaired, exit recovery mode and test the ordinary public site and dashboard. Open the pages that previously failed and use the affected feature. Check fresh logs for the same error.
If the problem only appears under a particular action, keep a small reproducible example for the developer. This is more useful than repeatedly reactivating the component on a live site and hoping the error does not return.
Record the installed versions and the exact repair. If the site still returns a generic server response, the HTTP 500 guide covers other layers. WordPress’s recovery-mode guide explains how the temporary session works and what to do when its email is unavailable.
Recovery mode versus a completed repair
Recovery mode gives one administrator a way to investigate certain failures. Completion means normal visitor requests work, the original failing feature works, and the same fatal error is absent from new logs. Keep the repair and installed versions in your notes. The official WordPress error reference explains the broader checks; use official debugging guidance when collecting private logs.