It was a cold winter night last year. I had just finished a long blog post, hit “Publish,” and watched the page spin. Then—white screen. And that cold, robotic line:
“There has been a critical error on this website.”
Front end: dead. Back end: unreachable. Even the login screen gave me nothing but white. My hands went clammy. Was the site hacked? Database corrupted? Months of writing, gone?
If you’re staring at the same message right now, take a breath. This is not your fault, and it absolutely does not mean your site is gone. After going through this myself and helping friends dig out of the same hole more than a dozen times, I’ve developed a calm, step‑by‑step routine. Let me walk you through it—so the next time this happens, you’ll know exactly where to start.
What That Error Really Means: WordPress Is Protecting You
A lot of people see “critical error” and assume the worst. Actually, this is a protection mechanism WordPress introduced in version 5.2.
Before that, a fatal error would just give you a white screen of death—no explanation, no way in. Now, when WordPress hits a fatal error, it does two things:
It sends an email to your site’s admin address with the subject “Your Site is Experiencing a Technical Issue.” Inside that email is a recovery mode link—a secret door that bypasses the broken login process.
It temporarily disables the plugin or theme code that caused the error—for your admin session only. Regular visitors might still see a cached, working version of your site.
That night, I panicked because I didn’t know about that email. Later I learned: often, just clicking that link is enough.
Why Does This Happen? Four Likely Culprits
Before we fix it, let’s understand what usually breaks. In my experience, the causes rank like this:
Plugin conflicts or corruption (70%+)
A recent plugin update, a corrupted download, or just a poorly coded free plugin—this is by far the most common trigger.Theme‑related issues (about 20%)
You edited your theme’sfunctions.php, installed an outdated theme, or used a nulled theme from an untrusted source. Those are ticking time bombs.PHP version incompatibility (about 5%)
WordPress 6.0+ needs PHP 7.4 or newer. Running an older version—or jumping to PHP 8.2 before your plugins are ready—can cause fatal errors.Corrupted WordPress core files (<5%)
A failed update, accidental file edits, or a security breach can damage the core files themselves.
Step‑by‑Step: From Panic to Recovery
Each solution below starts with a short conclusion so you know immediately what the step accomplishes.
Start with your email inbox.
Before you touch any files, check the admin email address associated with your WordPress installation. If WordPress could send the error email, you’ll see:
Which plugin or theme caused the error.
A recovery mode link—click it and you’ll enter a special admin area. The offending plugin or theme will already be paused. You can delete or deactivate it right there, then click “Exit Recovery Mode.” Your site should be back.
No email? Three possibilities: your server lacks proper SMTP, the email went to spam, or the error happened before the mail function could run. Move to the next step.
Try the recovery mode link directly.
Even without an email, you can attempt to trigger recovery mode manually. Paste this into your browser:
https://yourdomain.com/wp-login.php?action=entered_recovery_mode
If it works, you’ll be logged in and see a notice: “This plugin has been paused during recovery mode.” Deactivate or delete it from there.
If even this link gives you a white screen, go to the next step.
Deactivate all plugins via FTP.
When recovery mode is unreachable, FTP (or your hosting control panel’s file manager) is your best friend.
Connect to your server using an FTP client (FileZilla is free and reliable).
Navigate to
/wp-content/.Rename the
pluginsfolder to something likeplugins_old.
This instantly deactivates every plugin because WordPress can’t find the folder. Refresh your site. If it loads normally, the problem is definitely a plugin.
Now rename the folder back to plugins, log into your admin dashboard (you should be able to now), go to Plugins, and reactivate them one by one. Refresh your site after each activation. When the error returns, you’ve found the culprit. Delete it and look for an alternative.
Switch to a default theme.
If disabling all plugins didn’t help, the theme is the next suspect.
Through FTP, go to /wp-content/themes/. Find your active theme folder and rename it (e.g., append -old).
WordPress has a fallback mechanism: when it can’t find the current theme, it automatically switches to a default theme like Twenty Twenty‑Four. If your site recovers, the theme was the problem.
If you bought the theme, contact the developer for an update.
If you modified it yourself, review recent changes.
If it’s a free theme from an untrusted source, replace it with one from the official WordPress theme directory.
Enable WordPress debugging.
If you’re still stuck—or you want to know exactly what broke—turn on WordPress’s built‑in debug log. It’s like giving WordPress a voice to tell you where it hurts.
Edit wp-config.php in your site root. Look for define('WP_DEBUG', false); and replace it with—or add before the “stop editing” line:
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);
Refresh the page that triggered the error. Then open the /wp-content/ folder—you’ll see a new file: debug.log. Download it and scroll to the bottom. You’ll see something like:
[13-Feb-2026 22:35:11 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted in /wp-content/plugins/xxx/xxx.php on line 42
Or:
PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product() in /wp-content/themes/mytheme/functions.php:88
Now you know the exact file and line number. No more guessing.
Address specific error types.
If the log says “Allowed memory size exhausted”
Add this to wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
Sometimes 512M is needed. But if a plugin has a memory leak, raising the limit is only a temporary fix—replace the plugin.
If you see “_load_textdomain_just_in_time was called incorrectly”
This is new in WordPress 6.7+. Some plugins try to load translation files too early. Update the plugin, or temporarily disable its localization features.
If the error is “Error establishing a database connection”
Check your database credentials in wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). If they’re correct and the problem persists, your database server may be down—contact your hosting provider.
Reinstall WordPress core files.
If you’ve ruled out plugins, themes, memory, and the database, the core WordPress files might be corrupted.
Download a fresh copy of WordPress from wordpress.org. Extract it, then upload and overwrite the wp-admin and wp-includes folders, plus all PHP files in the root directory—except wp-config.php. This is like reinstalling the operating system; your content, settings, and media stay intact.
My Own Recovery Timeline
That night, here’s how it actually played out:
22:15 – Site crashed. Heart rate spikes.
22:20 – Checked email. Nothing (no SMTP configured).
22:25 – Tried the recovery mode link directly. It worked.
22:30 – Recovery mode showed a caching plugin as the culprit. Deactivated it.
22:35 – Site loads, but styling is broken.
22:45 – Cleared browser cache and CDN. Everything normal.
23:00 – Deleted the bad plugin, installed a better alternative, tested all functions.
45 minutes from panic to full recovery. The hardest part wasn’t the technical work—it was the initial panic. Stay calm, follow the steps.
After the Fire: Three Habits That Keep Me Sane
That crash changed how I maintain sites. Here’s what I do now—and what I recommend you adopt:
1. Automate backups.
I use UpdraftPlus (or any reliable backup plugin) to send full backups to cloud storage (Google Drive, Dropbox) weekly. If disaster strikes again, I can restore in minutes, not hours.
2. Take a snapshot before risky moves.
Updating a critical plugin, editing a theme file, or changing the PHP version? I spend one minute creating a manual backup first. It buys total peace of mind.
3. Update plugins one at a time.
Never click “Update All.” Update one, test, then update the next. Stick to plugins from the official WordPress repository—avoid those that haven’t been updated in two years or have poor ratings.
Final Thought
“There has been a critical error on this website” is not a death sentence. It’s your circuit breaker tripping—annoying, but designed to prevent real damage.
The next time you see it, remember this sequence:
Email → Recovery mode → FTP (plugins) → FTP (theme) → Debug log → Core reinstall.
I’ve run this playbook more than twenty times now. What once made my heart race is now a fifteen‑minute chore.
You don’t need to be a developer. You just need to know where WordPress leaves its clues.
Have you ever faced this error? What was your fix? Drop your experience in the comments—we’ve all been there.
