Diagnosing a WordPress Critical Error After an Update

A WordPress critical error is a symptom of a PHP failure, not a diagnosis by itself. Record what changed and inspect the first relevant error before restoring the entire site. A plugin update, theme change and PHP version switch need different recovery paths.

Keep evidence and a recovery copy

1. Record the failing URL, time and last known working state.
2. Save the current files and database before replacing anything.
3. Check the hosting error log and any WordPress recovery email.
4. Identify the earliest relevant fatal error and the component path it names.
5. Reproduce the issue in a protected staging copy where possible.

WordPress supports debug logging without displaying errors to visitors. Enable it only for the diagnosis and turn it off afterward. Logs can contain sensitive paths or application data; do not leave a publicly downloadable debug log in place or post it unredacted.

Change one component at a time

If the dashboard or recovery mode works, deactivate the identified component and retest. If it does not, use the hosting file tools to disable the specific plugin directory after recording its original name. Avoid deleting it: its configuration and files may be needed for recovery.

A theme test needs a compatible installed fallback. A PHP error may require restoring a compatible runtime or updating the component. Do not interpret every warning as the cause of a fatal failure, and do not overwrite a live database merely to undo a plugin file change.

Check the restored functionality

Test the failing page, admin access, forms and any purchase flow. Inspect fresh logs for recurring errors. If a backup restore is necessary, account for newer content and orders before replacing the database.

Use the PHP compatibility checklist if the runtime changed, then rehearse the corrected update in staging.