The message “There has been a critical error on this website” means PHP encountered a fatal error. WordPress catches the error so visitors don’t see a raw stack trace. The cause is often a plugin, theme, or change to the PHP version.
Read the email and check the logs first
If a site administrator email is configured, WordPress may send a recovery-mode link after a fatal error. This link lets you access the dashboard while the affected component is disabled for your session.
Next, check wp-content/debug.log or the PHP error log in your hosting control panel. The most recent fatal error often points to a specific file inside a plugin or theme. That gives you a useful starting point for the investigation.
Enable logging, not public error display
Use a staging copy whenever possible. If you have no staging environment, you may need to enable logging briefly on the production site. Set WP_DEBUG and WP_DEBUG_LOG to true, and keep WP_DEBUG_DISPLAY set to false.
Displaying errors on the front end can expose server paths and interfere with page layouts. You need the log entries, not error messages shown to visitors. Keep the log private and disable debugging when the investigation is complete.
Identify the most recent change
Think about what changed shortly before the error appeared. Was there a plugin update, a PHP version change on the host, a new code snippet, or a database migration?
When possible, restore only the suspected plugin or theme files from a known-good copy instead of rolling back the entire website. If the dashboard is inaccessible, renaming the plugins folder through SFTP can help determine whether a plugin is responsible. It’s a blunt test, but it can be useful when you’re locked out.
Check PHP compatibility
Hosting providers eventually retire older PHP versions. Code that worked on PHP 7.4 may produce a fatal error on PHP 8.2 because of changes such as stricter parameter handling or removed classes.
If the error log points to an abandoned plugin, keeping the site on an unsupported PHP version isn’t a long-term solution. The plugin needs to be updated or replaced with something maintained and compatible.
Don’t stop once the site loads again
After restoring the site, test the areas people actually use. Check the login page, homepage, forms, and, for WooCommerce stores, the cart and checkout.
Some fatal errors only occur on specific admin screens or during scheduled cron events. Those problems can remain hidden until someone opens the affected page or the scheduled task runs.
Document what failed, what caused it, and which changes you made. This makes future troubleshooting easier and reduces the risk of running into the same issue during the next update.
If the site is down and you need help investigating it, see WordPress emergency fixes or describe the error.