What Should I Do About a WordPress Critical Error?
Respond safely to a WordPress critical error using recovery evidence, controlled changes and customer-journey checks rather than random reinstalls.

Part of our guide: What WordPress Maintenance Does a Small Business Website Need?
A WordPress critical error is a reason to pause changes and collect evidence, not to reinstall the website immediately. The visible message describes a failure to run normally; it does not identify the responsible component by itself.
Your first priorities are protecting current data, finding the recovery route and restoring the customer tasks the business depends on.
Record what happened before the error
Write down the time, exact message and recent changes. Include plugin updates, theme changes, custom code and hosting changes if known.
Check whether the public site, dashboard or only one action fails. Do not expose detailed server errors to visitors or paste logs containing secrets into a public forum.
A short incident record is more useful than repeatedly pressing update in the hope that a different result appears.
Check the administrator email carefully
WordPress’s Recovery Mode documentation explains that certain fatal errors can trigger a recovery email. The recovery session can pause the faulty component for the logged-in administrator so the problem can be investigated.
That does not mean all visitors are automatically seeing a repaired website. Treat recovery access as a diagnostic capability, not proof of restoration.
Verify that any recovery message refers to your own site and expected incident. Keep the link private; do not forward it casually or publish screenshots containing it.
If no recovery email arrives
Check the correct administrator mailbox and spam folder. If access is unavailable, contact the existing host or authorised maintainer through a known channel.
Do not assume that creating a new WordPress installation alongside the old one will recover the data. Do not delete plugin or theme folders without a clear plan and recoverable copy.
The login recovery guide covers legitimate account access. A site-wide fatal error may need hosting support even when the password is correct.
Choose one evidence-based intervention
Ask the maintainer to identify the failing component and the change that introduced the problem. A recent update is a lead to investigate, not automatic proof of fault.
For a fictional appointment business, a critical error after an extension update might affect both the booking form and dashboard. The first safe action is to preserve current booking records and inspect the error evidence, not restore yesterday’s database without checking today’s activity.
The plugin-conflict process explains controlled testing. Use it where appropriate rather than trying many live combinations.
Protect the recovery point
Before reverting software or restoring data, establish:
- Which files and database are included.
- When the recovery copy was taken.
- What new orders, bookings or edits exist since then.
- Who can perform and verify the restoration.
- How the original failure evidence will be retained.
Our backup and recovery guide explains why a backup timestamp is not enough on its own.
A temporary rollback may restore service, but it also needs a follow-up plan for security and compatibility.
Test outside the recovery session
Check the public site while signed out. Test a service page, contact route and any booking or checkout flow using safe test procedures.
Confirm that the error no longer appears and that expected notifications or records are created. A dashboard that opens successfully is only one part of the business service.
Record the cause, corrective change and remaining follow-up work in the WordPress maintenance record.
Prevent the same uncertainty next time
Maintain current administrator contact details, a tested recovery route and a release log. Agree who responds when the usual developer is unavailable.
Keep enough records and recovery options to handle a failure without improvised changes. Verify that the site works again before closing the incident.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.


