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.
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.