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 →