A WordPress critical error usually means PHP stopped executing because of a fatal error. The fastest safe fix is to identify the exact error source, isolate the failing code and restore the site without hiding the underlying cause.
Symptoms
- “There has been a critical error on this website” appears on the front end or wp-admin.
- The site works for some requests but fails on specific pages or admin screens.
- The problem began after a plugin, theme, WordPress or PHP update.
- Hosting error logs show a PHP fatal error, uncaught exception or incompatible method signature.
Common causes
The same visible WordPress error can have several causes. A reliable fix starts by matching the symptom to logs, request behavior and recent changes.
- Plugin or theme code incompatible with the current PHP or WordPress version.
- A failed or partial update left mixed file versions.
- PHP memory exhaustion during a request.
- Custom code or snippets triggering a fatal error.
- Corrupted plugin/theme files or autoloaded code.
Safe diagnosis
- Capture the exact PHP fatal error from server logs or WordPress recovery mode.
- Confirm the time the failure began and match it to updates, deployments or configuration changes.
- Temporarily isolate the suspected plugin/theme in a reversible way rather than deleting random files.
- Check PHP version, memory limits and dependency compatibility before re-enabling components.
Production safety: create a recovery point before changing code, plugins, database values or server configuration. Business-critical WooCommerce sites should avoid random deactivate/update experiments during active traffic.
How the issue is fixed
- Restore a known-good version of the failing component or patch the incompatible code.
- Complete or roll back interrupted updates so WordPress runs a consistent codebase.
- Correct PHP compatibility issues and verify the fix on both frontend and wp-admin.
- Clear page/object caches only after the underlying failure is repaired.
Avoid this shortcut: Do not simply enable display_errors on a production site and leave it exposed. Error details can reveal filesystem paths, plugin names and other sensitive information.
When to request expert WordPress bug fixing
Professional troubleshooting is useful when the site is business-critical, the error returns after a temporary fix, wp-admin is unavailable, the failure began after a complex update/migration, or you cannot identify the responsible code from logs. WP•FIX focuses on the smallest safe change that restores the failing path and explains the root cause.
Find the failing component before changing it
“There has been a critical error” is an outcome, not a diagnosis. Record the affected URL, the time of the failure and whether the error also affects wp-admin. Note the most recent code, plugin, theme or PHP change.
Read the fatal error and its context
Start with the hosting error log. If WordPress sent a recovery-mode email to the administrator, review the component identified there. A stack trace can show where a failure surfaced without proving that component was the original cause.
Illustrative log pattern — not a finding from your site:
PHP Fatal error: Uncaught Error: Call to undefined function ...
in /.../wp-content/plugins/example-plugin/... on line ...Use debugging deliberately
When logs are insufficient, WordPress debugging can help collect evidence. Work on staging where possible, keep error display disabled on public pages and store logs in a protected location. Do not leave debugging enabled indefinitely or expose log files to visitors. Review existing constants before changing wp-config.php; duplicate definitions can create confusion.
Change one variable and keep a rollback
If the failure followed an update, compare requirements and compatibility, then test a controlled rollback or repair on a recoverable copy. Avoid switching off every plugin on a live shop without considering payments, subscriptions and order processing. Keep a record of each change.
Confirm the failure is actually resolved
Revisit the affected URL and action, check wp-admin if relevant, and confirm that no new fatal error is recorded. Test the business flow that mattered, not only the homepage. A repaired display does not prove that scheduled tasks or checkout also work.
Reference: WordPress debugging handbook.
FAQ
Can a critical error be fixed without wp-admin?
Yes. Hosting, SFTP/SSH and error-log access are often enough to identify and isolate the failing component.
Is a WordPress critical error always caused by a plugin?
No. Plugins are common causes, but themes, custom code, PHP incompatibility, memory exhaustion and incomplete updates can produce the same message.
Will disabling all plugins fix it?
It may restore access, but it does not identify the root cause. A controlled diagnosis is safer, especially on WooCommerce or business-critical sites.
Can WP•FIX repair the site without losing content?
The goal is to change only the code or configuration responsible for the failure. A recovery point should be created before risky changes.
Need this WordPress issue fixed?
Send the URL, error message and what changed immediately before the problem started.
Request troubleshooting