Recover a WordPress Site After “There Has Been a Critical Error”

The public page shows one sentence, wp-admin may be unavailable, and the recovery email is either missing or too vague. The useful evidence is usually one level lower: the PHP error log, WordPress recovery mode, or the last deployment change.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: turn WordPress’s generic critical-error screen into a specific plugin, theme, PHP, or memory diagnosis without exposing debug output to visitors.

What the symptom narrows down

• A plugin or theme calls code that is unavailable in the active PHP or WordPress version.
• A deployment introduced a PHP syntax error or incomplete file set.
• The request exhausted memory while loading plugins, building a page, or running an update.

The branches are ordered to protect the strongest evidence around this possibility: a plugin or theme calls code that is unavailable in the active PHP or WordPress version. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Runtime incidents cross several boundaries: the browser reports an HTTP result, the web server hands work to PHP, and WordPress then loads core, plugins, the theme, and data; evidence from the earliest failing boundary is more useful than the component visible on screen; in this guide, the practical goal is to turn WordPress’s generic critical-error screen into a specific plugin, theme, PHP, or memory diagnosis without exposing debug output to visitors.

Evidence to collect before the fix

1. Record the exact URL, time, request, and most recent change before touching files.
2. Check the administrator mailbox for the recovery-mode link, then inspect the hosting PHP error log.
3. On a staging copy, enable WP_DEBUG_LOG while keeping WP_DEBUG_DISPLAY false; reproduce once and read the newest stack trace.
4. If WP-CLI works, run wp plugin list, wp theme list, and wp core verify-checksums.

The sequence moves from observation toward intervention. Preserve the result of the final check—if WP-CLI works, run wp plugin list, wp theme list, and wp core verify-checksums—because it provides a useful comparison after the repair.

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

Apply fixes in the safest order

1. Disable only the component named by the first relevant fatal error; do not begin by reinstalling everything.
2. Restore the changed file set from the same release or roll back the responsible plugin/theme on staging.
3. If the trace ends in memory exhaustion, identify the caller before raising a limit; a larger limit can hide an unbounded operation.

Before applying “Disable only the component named by the first relevant fatal error; do not begin by reinstalling everything,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can load the failed URL, wp-admin, and one uncached page; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Prove recovery

• Load the failed URL, wp-admin, and one uncached page.
• Trigger the original action again and confirm the log stays free of a new fatal error.
• Turn temporary debugging off and remove or protect any public debug log.

One successful refresh is not closure. Keep the incident open until you can also trigger the original action again and confirm the log stays free of a new fatal error, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

A hosting escalation should include the UTC timestamp, affected URL, response status, request or trace ID when available, PHP version, WordPress version, and the first relevant log entry; redact cookies, passwords, tokens, database credentials, and personal data; include the result of this first observation: record the exact URL, time, request, and most recent change before touching files.

State what was tested, including the result of “Record the exact URL, time, request, and most recent change before touching files,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Shortcuts that create a second incident

• Do not display PHP errors to visitors; paths and configuration details can leak.
• Do not delete the database or replace WordPress core before the stack trace identifies core corruption.

Primary references

• WordPress common errors — official reference consulted for this guide.
• WordPress debugging — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Disable only the component named by the first relevant fatal error; do not begin by reinstalling everything”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.