WordPress Critical Error Checklist: Logs, Recovery and Verification
Start a WordPress critical-error investigation with the failing action and its time. The generic error screen is a symptom. It does not identify the broken plugin, the PHP incompatibility or the server condition that caused it. Preserve evidence before trying a collection of unrelated fixes.
Describe the failure boundary
Record whether the error affects the whole site, administration, one page or a specific operation such as saving a post. Test a normal public page and an affected route without repeating payments or destructive actions. Note the exact time and timezone.
List recent core, theme, plugin and PHP changes. Include a deployment, a migration or a settings import even when nobody changed the content. An error appearing after a change suggests a useful starting point; it is not proof that the last change is responsible.
Use available recovery access
Check whether WordPress sent the administrator a recovery-mode email, and use only the link from the trusted message for this site. Keep recovery links private. Confirm access to the host’s management panel and a recent usable backup before making changes.
Agree whether the immediate goal is restoring availability or identifying the cause on a protected copy. A busy store may need containment first. Restoring an older database can discard newer orders or submissions, so establish what data changed since the recovery point.
| Check | Evidence to record | Next decision |
|---|---|---|
| Failing action | URL, account state and reproducible steps | Identify the smallest affected workflow |
| Change timeline | Version or deployment changes and time | Choose a controlled first hypothesis |
| Runtime evidence | Relevant PHP/server error entries | Ask support to correlate the failure |
| Recovery point | Backup coverage and newer business data | Choose a recovery route that preserves records |
| Verification | Public and administrative tests after the fix | Confirm the original failure is resolved |
Collect logs without exposing them
WordPress documents debugging controls for collecting errors and suppressing their display to visitors. Ask the maintainer or host to use the site’s supported logging method, especially when the host already provides managed logs. The relevant evidence is the error around your test time, not a giant unexplained archive.
Treat log files as private. They can include paths, identifiers and other sensitive information. Do not leave publicly downloadable debug output or display errors on a live page. Record how temporary logging will be disabled and how collected files will be retained or removed.
Test one hypothesis at a time
On staging or another agreed safe environment, reproduce the failure and change one relevant component. Use the plugin conflict workflow for isolation and the PHP compatibility checklist for runtime changes.
If the host must recover service directly, record the action and its result immediately. A page returning normally after a restart does not explain why it failed; retain the timeline so a recurring fault can still be investigated.
Verify business operations
Retest the original action plus login, an important form and any affected store operation using controlled data. Confirm expected records and notifications. Watch the relevant logs for a recurrence.
Close with the identified cause where known, the corrective change, remaining uncertainty and a named owner. If the cause remains unclear, say so in the support record rather than labeling the incident permanently fixed.
A working homepage can hide an editor failure
If a hypothetical homepage loads while saving an edited page triggers the critical-error message, record the failing save action and its timestamp. Ask the maintainer to correlate that attempt with private logs. Investigate the smallest relevant change on an isolated copy. Avoid calling the problem resolved after checking only a cached public page; repeat the original editor task and nearby dependent functions.
Sources and scope
Official documentation checked October 6, 2026: WordPress: Debugging; WordPress: Common errors. This is HRL’s general diagnostic workflow, not a diagnosis of your website. Server and security changes belong with the authorized administrator and the host’s supported procedures.