LiveChat 
Support 
There Has Been a Critical Error on This Website: How to Fix It in WordPress
You open your WordPress site and instead of your homepage you see a stark, unhelpful line of text: “There has been a critical error on this website.” Sometimes it adds, “Learn more about troubleshooting WordPress.” That single sentence is WordPress telling you that a PHP fatal error stopped the page from loading — and, deliberately, hiding the technical detail from public view.
This message replaced the old White Screen of Death in WordPress 5.2. The good news is that WordPress also introduced a built-in recovery system at the same time, and in most cases it hands you the answer directly. This guide walks through what the error means and the systematic, no-guessing way to fix it.
Key Takeaways
• “There has been a critical error on this website” means a PHP fatal error halted page rendering; WordPress hides the detail for security.
• Your fastest clue is the admin email — WordPress sends a “Your Site is Experiencing a Technical Issue” message with a Recovery Mode link that usually names the offending plugin or theme.
• The second fastest clue is `WP_DEBUG_LOG` in `wp-config.php`, which records the exact PHP error and file in `debug.log`.
• Common causes: plugin or theme conflicts, PHP version incompatibility, exhausted memory limit, corrupted `.htaccess`, and bad code in `functions.php`.
• The reliable method: read the log, deactivate plugins, switch theme, raise memory, check PHP version — in that order.
What Does “There Has Been a Critical Error on This Website” Actually Mean?
WordPress runs on PHP. When PHP encounters something it cannot recover from — a missing function, a fatal incompatibility, a call to undefined code, or an exhausted resource limit — it throws a fatal error and stops executing. Because a half-rendered page can leak sensitive paths, database details, or code, WordPress catches that fatal error and replaces it with the generic message instead of printing the raw PHP output to every visitor.
So the message is intentionally vague to the public. Behind the scenes, WordPress knows exactly what went wrong. Two channels expose that hidden detail to you, the administrator: the admin recovery email and the debug log. Your whole job is to read those two sources before changing anything.
The single most important thing to understand: the generic message is hiding the cause *on purpose*, but it is not hiding it from *you*. The recovery email that lands in your admin inbox almost always names the specific plugin or theme that triggered the crash, and `WP_DEBUG_LOG` records the exact PHP fatal error, the file, and the line number. Ninety percent of the time-wasting people experience with this error comes from guessing — disabling random plugins, swapping themes blindly — when the answer is sitting in their inbox and their `debug.log`. Read those first; act second.
Why Does WordPress Send a Recovery Email?
When the fatal error happens, WordPress emails the address set as the site admin email (Settings → General). The subject is usually “Your Site is Experiencing a Technical Issue.” Inside, it typically states which plugin or theme caused the failure and includes a special Recovery Mode login link.
Recovery Mode is a protected admin session that loads your dashboard with the broken plugin or theme paused, so you can log in even when the front end is down. From there you can deactivate the culprit, update it, or replace it. This is the cleanest fix and should always be your first move.
A few practical notes:
- Check spam/junk folders — the email sometimes lands there.
- If you never receive it, the site may have no working mail configured, or the admin email is wrong. In that case, move on to the debug log.
- The Recovery Mode link expires, so use it promptly.
How Do You See the Real Error With WP_DEBUG?
If there’s no email, or you want the exact PHP message, enable WordPress debugging. Edit `wp-config.php` (in your site’s root folder) and find the line that says `/* That’s all, stop editing! */`. Above that line, add or modify:
“`php // Turn on the WordPress debugging system define( ‘WP_DEBUG’, true );
// Write errors to wp-content/debug.log instead of showing them on screen define( ‘WP_DEBUG_LOG’, true );
// Keep the error messages hidden from public visitors define( ‘WP_DEBUG_DISPLAY’, false ); @ini_set( ‘display_errors’, 0 ); “`
Reload the broken page once, then open `/wp-content/debug.log` via FTP or your hosting File Manager. The most recent lines will show something like:
“` PHP Fatal error: Uncaught Error: Call to undefined function acme_helper() in /wp-content/plugins/some-plugin/init.php:42 “`
That tells you the file (and therefore the plugin or theme) and the line. Now you are no longer guessing. When you finish troubleshooting, set `WP_DEBUG` back to `false` so you are not logging on a live production site indefinitely.
What Are the Most Common Causes and Fixes?
Most critical errors trace back to a short list of culprits. Use this table to match the symptom in your debug log to the fix.
| Likely cause | How to recognize it | Fix |
|---|---|---|
| Plugin conflict / bug | Log points to a file in `/wp-content/plugins/…`; error started after installing or updating a plugin | Deactivate the plugin (Recovery Mode, or rename its folder via FTP/File Manager) |
| Theme conflict / bug | Log points to a file in `/wp-content/themes/…` | Switch to a default theme (e.g. Twenty Twenty-Four) |
| PHP version incompatibility | “Uncaught Error”, “syntax error, unexpected”, or deprecated-function fatals; happened right after a PHP upgrade | Switch PHP version in your hosting panel; update the plugin/theme |
| Exhausted memory limit | “Allowed memory size of X bytes exhausted” | Increase `WP_MEMORY_LIMIT` or `php.ini` `memory_limit` |
| Corrupted `.htaccess` | Error appears site-wide, often after a permalink or security-plugin change | Regenerate `.htaccess` |
| Bad `functions.php` snippet | Happened right after pasting code into the theme’s `functions.php` | Remove the snippet via FTP/File Manager |
| Corrupted core file | Log references a `/wp-includes/` or `/wp-admin/` file; rare | Re-upload fresh WordPress core files |
How Do You Deactivate Plugins Without Dashboard Access?
If you can’t reach the dashboard at all, deactivate plugins through your file system. Using FTP or your host’s File Manager, navigate to `/wp-content/` and rename the `plugins` folder — for example to `plugins_old`:
“` /wp-content/plugins → /wp-content/plugins_old “`
WordPress can’t find any plugins, so it deactivates them all, and your site usually loads again. Rename the folder back to `plugins`, then reactivate plugins one by one from the dashboard, reloading the site after each. The plugin that brings the error back is your culprit. (To isolate a single suspect, rename just that one plugin’s subfolder instead of the whole directory.)
How Do You Switch to a Default Theme?
If the debug log points at your theme, the same idea applies. In File Manager/FTP, go to `/wp-content/themes/` and rename your active theme’s folder. WordPress will fall back to the most recent default theme (such as Twenty Twenty-Four). If the site recovers, the problem is in your theme — often a recent customization or a `functions.php` snippet you can remove.
How Do You Increase the PHP Memory Limit?
A common fatal error is “Allowed memory size of X bytes exhausted.” Raise WordPress’s memory ceiling by adding this to `wp-config.php` (above the “stop editing” line):
“`php define( ‘WP_MEMORY_LIMIT’, ‘256M’ ); “`
If the limit is enforced at the server level, you may also need to raise it in `php.ini`:
“`ini memory_limit = 256M “`
Some hosts let you set this directly in the control panel. After raising the limit, reload the page. If memory was the cause, the site returns.
How Do You Fix a Corrupted .htaccess File?
A broken `.htaccess` can trigger errors across the whole site, often after a permalink or caching/security change. Back up the existing file, then replace its contents with the WordPress default:
“`apache
“`
If the site recovers, visit Settings → Permalinks and click Save to regenerate a clean `.htaccess`.
What Is the Systematic Way to Diagnose a Critical Error?
Resist the urge to change things at random. Work this checklist in order:
- Check the admin email for the “technical issue” message and use the Recovery Mode link if present.
- Enable `WP_DEBUG_LOG` and read `debug.log` to find the exact error, file, and line.
- Deactivate all plugins (rename the `plugins` folder), confirm the site loads, then reactivate one at a time.
- Switch to a default theme if the log or testing implicates your theme.
- Increase the memory limit if you see a memory-exhausted error.
- Check your PHP version — an old plugin on new PHP (or vice versa) is a frequent cause. Switch PHP versions in your hosting panel and update the component.
- Regenerate `.htaccess` if the error is site-wide and recently appeared.
Following the log first turns a frustrating afternoon into a five-minute fix.
Hosting That Makes WordPress Errors Easy to Fix
A fatal error is far less stressful when your hosting gives you the tools to diagnose it quickly. **** is built so you can act on everything in this guide without friction:
- Easy access to `wp-config.php` and `debug.log` through an intuitive File Manager and SFTP, so enabling debugging and reading the log takes seconds.
- One-click PHP version switching to resolve incompatibilities between plugins, themes, and PHP — without contacting support.
- Generous PHP memory limits, so “memory exhausted” fatals are rare in the first place.
- Staging environments to reproduce and fix errors safely before touching your live site.
- Automatic daily backups so you can roll back instantly if a plugin or theme update breaks the site.
- 24/7 expert support ready to help you read a debug log and pinpoint a fatal error fast.
If you’re tired of fighting your host every time WordPress throws an error, **** built for WordPress reliability.
Frequently Asked Questions
Will visitors see the actual error details? No. WordPress deliberately shows the public only the generic message to avoid leaking file paths or code. The real detail goes to the admin email and, when enabled, the `debug.log` — never to ordinary visitors.
I didn’t get the recovery email. What now? The email may be in spam, or your site may have no working mail setup or a wrong admin address. Skip it and enable `WP_DEBUG_LOG` instead, then read `/wp-content/debug.log` for the exact error.
Is the critical error the same as the White Screen of Death? Essentially yes — it’s the modern replacement. Since WordPress 5.2, instead of a blank white screen, you get the worded message plus a recovery email, which makes the cause much easier to find.
Can a PHP version change cause this error? Frequently. An outdated plugin or theme may use code removed in a newer PHP version, or rely on functions not yet available in an older one. Check your PHP version in your hosting panel and update or downgrade the component, or switch PHP versions.
Will I lose my content while fixing this? No. Deactivating plugins, switching themes, and editing `wp-config.php` don’t delete posts or pages — those live in your database. Still, take a backup before major changes so you can roll back safely.
Final Thoughts
“There has been a critical error on this website” looks alarming, but it’s just WordPress safely catching a PHP fatal error. The message is generic on purpose, yet the cause is rarely a mystery: the admin recovery email usually names the offending plugin or theme, and `WP_DEBUG_LOG` records the exact error and file. Read those two sources first, then work the checklist — log, plugins, theme, memory, PHP version — and you’ll resolve it methodically instead of by guesswork.
