Short answer: WordPress caught a fatal PHP error and replaced the page with a safety screen. Since version 5.2 it usually emails the site administrator with the offending plugin or theme and a recovery-mode link. That email is the fastest way back in.
Check the recovery email and mode first
Look in the administrator inbox (and spam) for “Your site is experiencing a technical issue”. It normally names the failing component and includes a recovery-mode link that logs you in with that component paused, so you can update or delete it from a working admin. If the email never arrived, the site cannot send mail — a finding worth noting on its own.
Read the actual fatal error
Enable logging in wp-config.php (WP_DEBUG_LOG on, WP_DEBUG_DISPLAY off) and open /wp-content/debug.log. The last line names the file, line and function — for example a plugin calling a function that no longer exists in your PHP version. The named component is where the error surfaced, not always where it originated: a plugin can fail today because PHP was upgraded last night.
Isolate without destroying the evidence
If you have no admin access, disable the suspect at file level: over SFTP, rename its folder inside /wp-content/plugins. To confirm it is plugins at all, rename the whole plugins folder to plugins_off; if the site returns, re-enable one by one. For a theme fault, rename the active theme folder to fall back to a default. Bulk-deactivating everything at once restores the front page but changes the application state and can obscure the original sequence of events and can break payments or forms in the process.
Memory, PHP version and custom code
If the log shows exhausted memory, raise WP_MEMORY_LIMIT. If it names an undefined function or rejected syntax, you are on a PHP version the component no longer supports — test a compatible one rather than staying on an unsupported version. If custom code in functions.php or a snippet plugin caused it, restore the previous version instead of patching blind.
Check more than the home page
Once it loads, repeat the exact action that triggered the error, sign in to the admin, and test any business-critical function tied to the repaired component — checkout, booking, login. Confirm scheduled tasks run again, since a fatal error can silently stop WP-Cron. Do not simply re-enable and re-update the component without knowing why it failed, or the same update reproduces the same error.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
WordPress recovery mode is a containment mechanism around a fatal PHP error. The component named in the email is where the error surfaced; the underlying cause may still be PHP, memory or another dependency.
- Preserve the recovery email and its timestamp.
- Open the fatal-error line and note the first project file in the stack trace.
- Compare the component's supported PHP and WordPress versions with the runtime.
- Reproduce the exact action in recovery mode or staging before reactivating the component.
What must be verified
- Recovery mode is no longer required.
- The triggering feature works with normal plugins and theme active.
- Cron, forms, checkout or the relevant integration complete without fatal errors.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
I got the recovery-mode email but it names a plugin — does that mean the plugin itself is broken?+
Not necessarily. The named component is where the error surfaced, not always where it originated — a plugin can start failing today because PHP was upgraded overnight, for instance. Read the actual fatal error in /wp-content/debug.log to confirm the real cause before assuming the plugin's code is at fault.
The recovery email never arrived, what does that tell me and what should I do instead?+
It tells you the site cannot send mail, which is worth noting as a separate finding. Without the email or admin access, you can disable the suspect component at file level over SFTP by renaming its folder in /wp-content/plugins, or rename the whole plugins folder to confirm whether plugins are the cause at all.
Is it fine to just deactivate all my plugins at once to get the site working again quickly?+
It restores the front page, but bulk-deactivating everything changes the application's state all at once and can obscure the original sequence of events — and it can break payments or forms in the process. Isolating one plugin at a time, or renaming the whole folder only to confirm the category before re-enabling individually, preserves more information about what actually failed.
Once the site loads again, is that enough to consider it fixed?+
No — repeat the exact action that triggered the error, sign in to admin, and test any business-critical function tied to the repaired component, such as checkout, booking, or login. Also confirm scheduled tasks are still running, since a fatal error can silently stop WP-Cron without any other visible symptom.