The WordPress message “There has been a critical error on this website” usually means PHP stopped while loading a plugin, theme or core process. The safe goal is to recover access, identify the failing component and preserve evidence before making broad changes.

Protect the current state first

  1. Record the time, affected URL and most recent change.
  2. Check whether wp-admin and other pages still work.
  3. Create a file and database backup through the hosting panel.
  4. Do not update every plugin at once.
  5. Check the administrator email for a WordPress recovery-mode message.

For risky changes, use a WordPress staging site rather than experimenting on production.

Use WordPress recovery mode

WordPress may email the administrator a special link that pauses the faulty extension for that session. Confirm the email belongs to your site. After logging in, note the identified plugin or theme and test a compatible update or rollback on staging.

If wp-admin is unavailable

Using the hosting file manager or SFTP, temporarily rename wp-content/plugins. If the site loads, restore the folder name and rename individual plugin folders until the failing component is identified. This disables code without deleting plugin data.

Test the active theme

A broken theme or child-theme function can cause the same error. Temporarily switch to a current default WordPress theme if one is installed. Do not delete the active theme during diagnosis.

Check PHP compatibility and logs

  • Confirm the hosting PHP version meets WordPress and plugin requirements.
  • Review the server error log around the failure time.
  • Look for memory exhaustion, undefined functions and file paths.
  • Do not increase memory indefinitely; leaks and loops require correction.
  • After changing PHP, test forms, checkout, scheduled tasks and wp-admin.

Enable debugging safely

WordPress can write errors to wp-content/debug.log without displaying them to visitors:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Back up wp-config.php first, add each constant only once and disable debugging after diagnosis. Logs may contain sensitive paths or context.

Recover from a bad update

Roll back only the identified component using a trusted previous package and a backup. Never install nulled plugins or random ZIP files. If core files are damaged, use the dashboard reinstall function or an official WordPress package while preserving wp-content and wp-config.php.

If you need professional help, contact SiteChai with the error time, recent changes and relevant log excerpt.

Post-recovery checklist

  • Disable debugging and protect or remove exposed logs.
  • Clear relevant caches.
  • Test public pages, login, forms and checkout.
  • Update the responsible component after compatibility testing.
  • Confirm backups complete successfully.
  • Document the cause and prevention.

FAQ

Does this mean the database is lost?

Usually not. The message commonly indicates a PHP fatal error, though database problems can also disrupt a site.

Can increasing PHP memory fix it?

Only when the log confirms memory exhaustion and the increase is appropriate. It cannot repair incompatible code.

Should I delete the faulty plugin?

Disable or rename it first. Deleting files can complicate recovery and investigation.

Bottom line

Make one reversible change at a time. Recovery mode, logs and controlled isolation are safer than mass updates. Preserve a backup and rollback route throughout the repair.