This message means PHP hit a fatal error. WordPress usually knows exactly which plugin caused it and has already emailed you — start there before touching any files.
Since WordPress 5.2, a fatal error triggers an automatic email to the site administrator that names the plugin or theme responsible and includes a recovery mode link. That link logs you into the admin with the failing component paused, so you can deactivate or update it normally.
No email? Add define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG', true ); to wp-config.php, reload the page, then read wp-content/debug.log. The last entry names the file.
A critical error is a PHP fatal error: the code stopped executing partway through and the page could not be finished. Before WordPress 5.2 this produced a blank white page with no explanation. Now WordPress catches the error, shows this message to visitors, and attempts to tell the administrator what happened.
In practice the cause is nearly always one of these:
If you see this worded message, WordPress caught the error and its fatal error protection is working. If you see a genuinely blank page instead, the failure happened too early for WordPress to handle it or error display is switched off — that is the white screen of death, and the diagnostic order is slightly different.
Search the administrator inbox for a message with a subject line about your site experiencing a technical issue. It names the offending extension and contains a login link that pauses it. This is the intended path and the fastest one — everything below exists for when the email never arrives.
Add these to wp-config.php above the “stop editing” line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reload the broken page, then open wp-content/debug.log. A fatal error entry names the file and line number, which usually identifies the plugin immediately from its folder name. Setting WP_DEBUG_DISPLAY to false keeps the errors out of the page while you work — visitors should not see stack traces. Turn all three off when you are done.
If you cannot reach the admin at all, connect over FTP or SFTP and rename wp-content/plugins to plugins-off. WordPress will find no plugins and deactivate everything, which nearly always restores access.
Then rename the folder back to plugins. All plugins stay deactivated, and you can re-enable them one at a time in the admin — reloading the site after each — until the error returns and identifies the culprit.
If disabling plugins changes nothing, rename the active theme's folder inside wp-content/themes. WordPress falls back to a default theme. If the site returns, the fault is in the theme — very often a recent edit to functions.php.
If the log mentions allowed memory size being exhausted, add:
define( 'WP_MEMORY_LIMIT', '256M' );This is a genuine fix for a site that has outgrown a low limit, and a temporary patch if some plugin is consuming memory unreasonably. If raising it repeatedly is the only thing keeping the site alive, find what is actually leaking.
In your hosting control panel, check which PHP version the site runs. Hosts upgrade PHP on their own schedule, sometimes with little notice, and an unmaintained plugin can break instantly on a new major version. Reverting temporarily buys time to update or replace the plugin — it is not a destination.
You have just spent an hour proving that a change you did not review broke a site you are responsible for. The lesson is rarely “update less” — unpatched plugins are the bigger risk — it is that the cost of a bad update should be seconds, not an FTP session.
When every change is snapshotted before it runs, a plugin update that triggers a fatal error is one click from reversed, from the dashboard, without file access. That is also what makes running updates unattended across a portfolio a reasonable thing to do rather than a gamble.
See how one-click undo works, or read the WordPress maintenance guide for the scheduled side.
It means PHP hit a fatal error while building the page, and WordPress caught it rather than showing a raw error. It replaced the old white screen of death in WordPress 5.2, alongside a fatal error protection feature that emails the administrator and offers a recovery mode link.
Check the email WordPress sent to the administrator address — it usually names the plugin or theme and the file involved. If that email never arrived, enable WP_DEBUG_LOG in wp-config.php and reload the page; the last entries in wp-content/debug.log will point to the responsible file.
Use FTP, SFTP or your host's file manager. Renaming the wp-content/plugins folder deactivates every plugin at once and almost always restores admin access, at which point you can rename it back and re-enable plugins individually to identify the culprit.
Recovery mode is a special login link included in the fatal error email. It logs you into the admin with the failing plugin or theme paused, so you can deactivate or update it through the normal interface instead of over FTP. The link expires, so request a fresh one if it has been sitting in the inbox.
Because that is the most common trigger. A plugin update can call a function removed from a newer version of PHP, conflict with another plugin, or require a version of WordPress core you have not applied yet. This is why testing updates on staging, or being able to reverse them instantly, matters more than the update itself.
Every change snapshotted before it runs, across every site you manage.
Start free