The message "There has been a critical error on this website" means PHP hit a fatal error and WordPress stopped rendering the page. Older versions showed a blank page instead, the "white screen of death". Either way the cause is almost always one of a few things: a plugin or theme update, a PHP version change, a memory limit or a damaged file.
The fix is rarely hard. What takes time is guessing. This guide replaces guessing with an order of checks that finds the cause in minutes.
Step 0: don't make it worseLink to this section
- Take a backup of files and the database before changing anything, even if the site is down. Most hosts can snapshot in one click.
- Note what changed recently: a plugin update, a PHP upgrade by the host, a new snippet in
functions.php. The last change is the first suspect. - Work on staging if the site is still partly working and you can clone it.
Step 1: check your email for the recovery linkLink to this section
Since WordPress 5.2, a fatal error triggers recovery mode. WordPress emails the site admin address with a special login link and names the plugin or theme that failed.
Open the link, and WordPress pauses the faulty extension for your session so you can reach the dashboard and deactivate or update it. If the email never arrived, which is common on hosts without working mail, continue to step 2.
Step 2: turn on the debug logLink to this section
Edit wp-config.php and set these lines above /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // never show errors to visitors
@ini_set( 'display_errors', 0 );Reload the broken page, then open wp-content/debug.log. Look for the last PHP Fatal error line:
PHP Fatal error: Uncaught Error: Call to undefined function acme_get_rules()
in /var/www/html/wp-content/themes/acme-child/functions.php:42That line usually tells you the file, the line and the extension responsible. In this example a child theme calls a function from a plugin that is no longer active.
Turn debugging off again when you're done, and delete debug.log. A public log file can expose paths and other details about your server.
If the log is long, you can paste it into the regex tester and match PHP Fatal error:.* to pull out just the fatal lines.
Step 3: isolate pluginsLink to this section
If the log points at a plugin, or you can't get a log at all, switch plugins off.
With WP-CLI (fastest, works even when the dashboard is down):
# Run WP-CLI without loading plugins or themes, which would crash too
wp plugin list --skip-plugins --skip-themes
# Deactivate the suspect
wp plugin deactivate suspicious-plugin --skip-plugins --skip-themes
# Or deactivate everything, then re-enable one by one
wp plugin deactivate --all --skip-plugins --skip-themes
wp plugin activate woocommerce --skip-plugins --skip-themesWithout WP-CLI, connect over SFTP or the host's file manager and rename wp-content/plugins/suspicious-plugin to suspicious-plugin.off. WordPress deactivates a plugin whose folder disappears. Rename the whole plugins folder to test them all at once, then rename it back.
Re-enable plugins one at a time, reloading the site after each, until the error returns. The last one you enabled is the culprit.
Step 4: isolate the themeLink to this section
If plugins are fine, test with a default theme:
wp theme install twentytwentyfive --activate --skip-plugins --skip-themesIf the site loads, the problem is in your theme or child theme, very often in functions.php. A missing semicolon or a function declared twice is enough to cause a fatal error.
Step 5: check the PHP version and memoryLink to this section
PHP version. Hosts upgrade PHP on schedules, and older plugins can break on PHP 8.x. Typical log messages are Uncaught TypeError, Unsupported operand types or a call to a function removed in PHP 8. Either update the extension or temporarily switch PHP back in the hosting panel while you fix it properly.
Memory. A log line like Allowed memory size of 134217728 bytes exhausted means PHP ran out of memory. Raise the WordPress limit in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // admin and heavy tasksThe server's own PHP memory_limit caps these values, so you may also need to raise it in the hosting panel. If memory keeps running out, find the cause with Query Monitor rather than raising the limit forever.
Step 6: verify WordPress core filesLink to this section
A failed update or a compromised site can leave core files damaged. WP-CLI compares every core file with the official checksums:
wp core verify-checksums --skip-plugins --skip-themesIf files are reported as modified or missing, reinstall core without touching your content:
wp core download --skip-content --forceAny unexpected PHP files in wp-content/uploads are a red flag for a compromise. In that case, clean the site, update everything, change all passwords and regenerate the security keys in wp-config.php. The WordPress salt generator creates a new set locally in your browser, and replacing them logs every user out immediately.
Reading a stack traceLink to this section
Modern PHP errors include a stack trace: the chain of function calls that led to the crash. It looks noisy, but you only need two things from it.
PHP Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given
in /var/www/html/wp-content/plugins/acme-gallery/includes/render.php:88
Stack trace:
#0 /var/www/html/wp-content/plugins/acme-gallery/includes/render.php(88): count(NULL)
#1 /var/www/html/wp-includes/class-wp-hook.php(324): acme_gallery_render('')
#2 /var/www/html/wp-includes/plugin.php(205): WP_Hook->apply_filters('', Array)
#3 /var/www/html/wp-content/themes/acme/single.php(31): apply_filters('the_content', '')- The first line says what went wrong. Here PHP 8 refuses to
count()anull, something PHP 7 only warned about. That's why errors like this appear right after a host upgrades PHP. - The first frame inside
wp-contentsays whose code it is. Frame#0is inplugins/acme-gallery, so that plugin needs an update or a fix. Frames inwp-includesare WordPress passing the call along; they're rarely the cause.
When you can't reach WordPress at allLink to this section
Sometimes there's no SSH access, no WP-CLI and no recovery email. You can still work through the hosting panel:
- Error logs. Most control panels have an "Errors" or "Logs" page showing PHP errors even when
WP_DEBUGis off. The same fatal error line will be there. - File manager. Rename plugin or theme folders exactly as in steps 3 and 4.
- PHP version switcher. Temporarily selecting the previous PHP version confirms a compatibility problem in seconds. Treat it as a diagnosis, not the fix.
- Syntax check. If you have any shell access,
php -l wp-content/themes/acme-child/functions.phpreports a syntax error and its line without loading WordPress.
Other errors that look similarLink to this section
| Symptom | Likely cause | Fix |
|---|---|---|
| "Briefly unavailable for scheduled maintenance" that never ends | An interrupted update left a .maintenance file |
Delete .maintenance from the site root, then rerun the update |
| "Error establishing a database connection" | Wrong credentials in wp-config.php, or the database server is down |
Check DB_NAME, DB_USER, DB_PASSWORD and DB_HOST, then run wp db check |
| 500 Internal Server Error with no PHP log entry | A broken .htaccess rule |
Rename .htaccess, then re-save Settings → Permalinks to regenerate it |
| White screen only in the admin | Admin-only plugin code, or memory | Check debug.log and raise WP_MAX_MEMORY_LIMIT |
| REST API or block editor errors ("The response is not a valid JSON response") | PHP notices printed into JSON output, or a security plugin blocking /wp-json |
Check the response in the browser's Network tab; paste it into the JSON formatter to find the stray output |
Preventing the next oneLink to this section
- Update on staging first for anything that touches checkout, forms or page builders.
- Keep automatic backups off the server, with at least a week of history.
- Monitor uptime so you hear about the error before a customer does.
- Keep the stack current. Supported PHP, maintained plugins, fewer plugins overall.
- Put custom code in a plugin, not in
functions.php, so a theme switch can't take it down. The plugin development guide shows a clean structure.
Sites built with page builders such as Elementor, like the Brumley Law Firm website, depend on many plugins working together, so a staging-first update routine matters even more there.
Frequently asked questionsLink to this section
Does a critical error hurt my SEO?Link to this section
A short outage doesn't. WordPress returns a 500 status for a fatal error, and Google treats server errors as temporary and retries later. An error that lasts days can start to drop pages from the index, so fix it quickly and check Search Console's Pages report afterwards.
Why didn't the recovery mode email arrive?Link to this section
The email goes to the address in Settings → General, and many hosts don't deliver PHP mail reliably. Set up an SMTP plugin with a real mail provider, and you'll get these alerts next time.
Recovery mode let me log in. Is the site fixed?Link to this section
No. Recovery mode pauses the faulty plugin or theme only for your session. Visitors still see the error until you deactivate, update or fix the extension.
Can a hacked site show the critical error?Link to this section
Yes. Injected code often breaks on the next update. If verify-checksums reports modified core files or you find unfamiliar PHP files in uploads, treat it as a security incident: clean the site, update everything, change passwords and regenerate the keys.
If your site is down right now and you'd like a hand, contact me with the exact error message and what changed last.
Test yourself
3 quick questions on this lesson.
Finished this lesson?
Mark it complete to track your progress through the learning paths.