Performance & troubleshooting
The WordPress critical-error screen means a fatal PHP-level problem prevented the request from completing. The fastest safe route is to capture the actual error, identify the recent change or component, and recover without destroying evidence.
Direct answer
A WordPress critical error is a symptom, not a diagnosis. Check the PHP/server error details, WordPress recovery email where available, recent plugin/theme/core/PHP changes, and reproduce the failure before deciding whether to disable, update or replace a component.
Answer scope
The public screen intentionally hides technical detail. Hosting PHP logs, WordPress debug logs or an error-monitoring service can show the failing file, function or memory condition.
Do not publish logs containing credentials or customer data; capture only what is needed to identify the failing component.
Plugin, theme, WordPress core, PHP version, server configuration or custom code changes are common triggers.
A timeline can narrow the search faster than disabling unrelated components.
If one plugin is clearly failing, disabling that component can restore the dashboard while preserving the rest of the site. On a production store, use a backup and verify customer paths after any emergency change.
Avoid deleting files blindly because that can make later diagnosis and rollback harder.
Some critical errors are caused by exhausted PHP memory or timeouts rather than a syntax or compatibility bug. Logs and hosting metrics help distinguish these cases.
Increasing limits may mask an inefficient plugin, so confirm why the resource is being consumed.
Update or replace the incompatible component, correct custom code, or adjust the environment as appropriate.
Then retest the exact URL/action that failed and monitor logs for recurring warnings or fatals.
Questions
Common causes include plugin/theme bugs, PHP incompatibility, custom-code errors, memory exhaustion and failed updates. The server/PHP error detail is needed to identify the actual cause.
Only if memory exhaustion is the cause. Raising limits without evidence can hide an inefficient component and will not fix syntax or compatibility errors.
A backup can be the fastest recovery if the failure followed a known change, but preserve enough evidence to identify what caused the problem before the same change is repeated.
Evidence
First-party platform documentation and clearly labelled public market benchmarks used for factual claims on this page. A source link does not imply endorsement.
Start a conversation
Send the current setup and the result you need. I will review the problem and suggest the most practical next step.