Seeing “There has been a critical error on this website” can make a small business owner expect the worst. The message alone does not tell you whether the problem is serious, permanent, or difficult to repair. It tells you that WordPress could not complete a request.
The useful next step is to collect evidence. A WordPress critical error fix should address the failing code or server condition, while protecting your content, customer details, and recent orders. Follow a short recovery plan before making changes.
1. Find out which requests fail
Open the homepage, an ordinary content page, and the dashboard. If you run a store, check a product page without submitting a payment. Write down the exact URL where the error appears.
A failure across every page suggests a different investigation from an error limited to one form submission. If only one action fails, record the steps needed to reproduce it. For example: “Open contact page, complete required fields, press Send.”
Also note when the issue began. A plugin update, theme change, new code snippet, or hosting change can provide a useful starting point. Timing is evidence to investigate, rather than proof of responsibility.
2. Check the administrator email
WordPress may send the site administrator an email describing a fatal error and offering a Recovery Mode link. Check the inbox and spam folder for the administrator address used by the website.
Read the message carefully. It can name the plugin or theme involved and describe the error. Keep that information private because it can reveal server paths.
If you receive a Recovery Mode link, use it privately and follow the on-screen instructions. Do not forward the link to public support forums. If no message arrives, continue through your hosting account; the missing email does not mean recovery is impossible.
3. Protect the current state
Create a backup of the database and website files before changing settings or replacing code. If the dashboard is unavailable, ask your host to create a snapshot or use its backup tools.
Check the dates of existing restore points. A backup from before the failure is useful, but it may exclude orders, enquiries, or content added afterward.
Keep a brief record of the current symptoms, affected URLs, and recent changes. That record helps distinguish a new result from an old symptom. It also makes handing the issue to another developer much easier.
4. Ask for the matching error log
The browser message is a summary. The PHP error log can provide the actual failure, including a file path and time.
Ask your hosting support team for the fatal error matching the request you tested. Provide the URL and approximate time, including your time zone. Avoid sharing passwords or full customer records.
A developer can also configure WordPress debugging to log errors without displaying them to visitors. Logs should have restricted access and should not remain available publicly. Copying a complete log into a public question can expose details unrelated to the problem.
5. Test the component named in the error
If the log names an ordinary plugin, temporarily deactivating that plugin may restore access. Use the dashboard or Recovery Mode where available.
If neither works, a developer can temporarily rename the specific plugin directory through SFTP or the host’s file manager. This should be a targeted change, with the original name recorded.
Before deactivating a payment, membership, booking, or security component, consider what will stop working. On a live business website, it may be better to pause the affected customer journey while testing a copy.
6. Separate a broken plugin from a conflict
A plugin mentioned in an error is an important clue, but another component may supply the bad input or missing dependency.
Use a staging copy to test the suspected plugin on its own, then with the components it depends on. Keep the test conditions consistent. Changing the PHP version, theme, and several plugins together makes the result difficult to interpret.
Record which combination reproduces the failure. A useful report says what was active, what action failed, and which version was installed. “The plugin is broken” gives its developer very little to investigate.
7. Check compatibility and custom code
Compare the failing component’s requirements with your WordPress and PHP versions. Review its release notes for compatibility information and known issues.
Custom snippets deserve attention too. An unfinished edit, duplicate function, or outdated integration can cause a failure even when every plugin is current. Ask the person responsible for the last code change to review it.
Do not edit WordPress core files to hide an error. A lasting repair belongs in the affected plugin, theme, integration, or server configuration. Keep the correction documented so the next update does not recreate the problem.
8. Choose a recovery method that preserves new data
You might resolve the incident by replacing damaged plugin files, installing a corrected release, removing a faulty snippet, or restoring selected files.
A complete rollback should be planned carefully. On an active store, replacing the database with yesterday’s copy can remove orders and customer changes created since then. Ask your developer or host which parts need restoring.
If a temporary rollback is necessary, record the version and the reason. Arrange the permanent fix before treating the incident as finished. Restoring service and removing the underlying cause are separate tasks.
9. Test beyond the homepage
Once the message disappears, repeat the original failing action. Then check the parts of the site that matter to your business.
- Submit a test enquiry and confirm delivery.
- Check customer and administrator login.
- Review important pages on mobile.
- Test cart and checkout using a safe payment test method.
- Confirm scheduled or background tasks affected by the repair.
Look for fresh errors at the matching time. A page that opens successfully does not prove that every background integration is healthy.
When to bring in a developer
Ask for help early if the website handles payments, the error involves custom code, or you cannot create a reliable backup. Send the symptom, affected URL, timing, recent changes, and any private log excerpt through an appropriate support channel.
For related prevention steps, use my monthly website maintenance checklist. For the wider recovery process after a release, read what to do when WordPress breaks after an update.
I provide website maintenance and fixes, including investigation, repair, and practical testing. The goal is to get the website working and leave you with a clear explanation of what changed.
For the official reference, see WordPress common errors.
