VIENNA / WEBSITE REPAIR & SUPPORT / REMOTE SERVICEsupport@virtuaworx.net ↗

Technical guide / Published 25 October 2026

WordPress critical error: a safe recovery checklist

A “critical error” usually means PHP could not finish a request. It is a symptom, not proof of a hack or a particular broken plugin. Check the administrator recovery email, preserve backups, and find the matching private error log before changing the site.

Published by VirtuaWorx.Net. Only authorized operators with a verified recovery path should change files or settings.

Record the failure and check Recovery Mode

Start with the first failed request, not a sequence of speculative fixes. A plugin update, theme change, PHP switch or exhausted resource can lead to a fatal error.

  1. Record the exact message, affected URL, time and time zone. Note whether the public site, administration area or only one action fails, plus the last known working time.
  2. List recent core, plugin, theme and hosting changes. Preserve current files and database alongside any pre-incident backup; check that a backup can actually be restored.
  3. Check the site's administrator mailbox and spam folder for the WordPress recovery email. If present, use its private Recovery Mode link only after checking the sender and site domain. Do not share the link.
Recovery Mode can let an administrator investigate a detected fatal error in their recovery session. It is not a repair for every failure and does not prove the public site is working. If no email arrives, ask the host for the matching PHP error rather than repeatedly triggering the fault.

Find the fatal error without exposing logs

Ask the host for private PHP logs around the recorded time. The error type, file path and stack trace can narrow the investigation; the last file named is evidence, not automatically the cause.

  1. Correlate the log entry with the failed request. Check installed component versions and PHP compatibility against the component's official support information.
  2. If additional WordPress debugging is necessary, have an authorized developer configure private logging with public error display disabled. Follow the WordPress debugging reference; do not expose a debug log through a publicly accessible URL.
  3. Redact credentials, tokens, customer data and private paths before sharing excerpts. Disable temporary debugging after diagnosis and securely remove or restrict temporary logs under the site's retention policy.
Do not turn on public error display or post a complete log to a public forum. A backup or staging copy can also contain personal data and must be access-controlled.

Isolate on staging, then verify the repair

Reproduce the failure on a protected staging copy using equivalent PHP and component versions before testing a suspected plugin or theme conflict.

  1. Change one suspected component at a time on staging and record the result. Do not blanket-disable production plugins or switch a live theme: checkout, security and custom functionality may depend on them.
  2. Test a supported fix, compatible update or known-good restoration with a rollback plan. Restoring an old database can discard new orders or content; agree how to preserve them first.
  3. After an approved production change, check the original failing action, public pages, login, forms and checkout where applicable. Confirm that no new matching fatal errors appear in private logs.
Unknown administrators, injected files or suspicious redirects need a separate compromise investigation. Preserve evidence and use WordPress malware help rather than assuming an ordinary update fault.

Relevant official documentation

WordPress.org — Critical error message ↗WordPress Developer Handbook — Debugging in WordPress ↗WordPress.org — Troubleshooting FAQ ↗WordPress Core — Fatal Error Recovery Mode ↗

These references inform the guidance; they do not establish the cause on your site or guarantee recovery.

Need someone to investigate?

See the WordPress update recovery service, or describe the error and recent changes. Do not send passwords, Recovery Mode links or raw logs through the public form.

Request critical-error help ↗