“There has been a critical error on this website.”
This is the exact English message WordPress can display when a fatal error prevents a page from loading. You may also see “Please check your site admin email inbox for instructions.” The notice identifies a failure, not which plugin or theme caused it. Wording varies by WordPress version, language and recovery state.
If this appeared after an update, use the checks below. If there was no update, ask your host to inspect PHP errors and recent server changes too. If you are only visiting someone else's site, contact its owner; these recovery steps require administrator access.
Need someone to investigate? Request a free review of this WordPress error. Include the affected URL, the exact message and when it started. We confirm availability, scope and any cost before paid work.
A critical error immediately after a plugin update gives you a useful starting point: the change and its timestamp. It does not prove that the plugin is the only cause. A dependency, an incompatible PHP version, or an incomplete update can produce a similar outage.
First checks: identify what actually stopped working
Open the homepage, the affected page, and the login page in a private window. Record which ones fail. Check your hosting dashboard for a wider outage. If a store is taking orders, avoid restoring an old database just to undo plugin files: that can discard transactions placed after the backup.
- Record the plugin name, old and new versions if available, and update time.
- Save the error message and the affected URL.
- Confirm the latest usable backup with your host before changing files.
- Pause further updates so you do not add more variables.
Recover access and isolate the failure
Check the administrator email for a WordPress Recovery Mode link. If it arrives, use it to inspect the reported component. Recovery Mode can pause a failing component for your session; being able to log in does not mean visitors are now unaffected. Deactivate the identified plugin only after considering the features it powers.
If no email arrives, ask your host for the PHP fatal-error entry at the recorded time. When the evidence points to a normal plugin, an administrator with file access can temporarily rename that plugin's directory under wp-content/plugins. Record its original name. This can remove its functionality, so use particular care with payments, memberships, and security plugins. Do not delete plugin data or rename unrelated directories. See WordPress Recovery Mode documentation.
Read the evidence before choosing a permanent fix
On staging, WordPress debugging can record errors with display disabled. Prefer hosting logs on production; do not expose debug output to visitors. A warning is not automatically the fatal error responsible for the outage. Match the timestamp, file path, and error type to a reproduced failure. See WordPress debugging documentation.
For example, if the homepage recovers after one plugin is disabled but checkout is still broken, treat those as two test results. The recovery narrows the investigation; it does not demonstrate that the whole store is healthy. Ask the plugin vendor about the exact version combination rather than requesting a generic rollback.
What the more specific PHP error can tell you
The public critical-error screen often hides the underlying cause. Ask your host for the matching fatal entry. These are error patterns, not errors every affected site will have:
Allowed memory size of ... bytes exhausted: PHP reached its memory limit. Check the failing operation and effective limit; raising it alone may hide a runaway process.Uncaught Error: Call to undefined function ...: code called a function unavailable in that request. Check dependencies, version compatibility and whether an update left incomplete files.Uncaught TypeError: a call received an incompatible value or argument. The stack trace and version combination matter; the message alone cannot identify the repair.
Share only a redacted excerpt. Logs can contain private filesystem paths, tokens or customer details. Do not publish complete logs or enable visible debugging on a live site.
No recovery email, or wp-admin shows the same error?
A missing email does not rule out a fatal error: delivery may fail, or the message may go to another administrator address. Check spam and the configured admin inbox, then ask the host for logs and safe file access. Do not repeatedly reinstall WordPress or restore the database merely because the email is missing. A recovery link is private access information; do not paste it into a public forum or initial support form.
Verify the business workflow
Test the original failing URL, login, contact form, and any purchase or booking flow the plugin touches. Use a sandbox payment method for purchase tests. Review fresh logs, exit Recovery Mode, and repeat the visitor check. Document which version or configuration is safe before re-enabling automatic updates for that component.
When to stop and request help
Stop if the failing component controls payments, if no usable backup exists, or if restoring files would also overwrite customer data. Send the symptom, update timestamp, plugin versions, and a redacted error excerpt for a free plugin issue review. Never put passwords, recovery links, or private customer records in the initial request.