WordPress Critical Error Fix: Get Your Site Back Online

Seeing “There has been a critical error on this website” on a plain white screen is frightening. Your site is down. Visitors see nothing. You may be locked out of your dashboard. Take a breath first. A wordpress critical error is almost always caused by one broken plugin, one broken theme, or a memory limit that is too small. Since WordPress 5.2, the software even emails you a way back in. Work through the quick checks below first. Then follow the eight fixes in order, simplest first. Most site owners are back online within the hour.

Table of Contents

• Quick Checks — Do These First
• Diagnose Table: Symptom, Cause and Fix
• 1. Use the Recovery Mode Email WordPress Sent You
• 2. Turn On Debugging to Find the WordPress Critical Error Cause
• 3. Deactivate All Plugins Through FTP
• 4. Switch to a Default WordPress Theme
• 5. Increase the PHP Memory Limit
• 6. Check Your PHP Version
• 7. Reinstall the WordPress Core Files
• 8. Contact Your Hosting Provider
• What to Avoid
• FAQ
• Conclusion

Quick Checks

Run through these before you touch any files. They take five minutes and solve a surprising number of cases.

• Check your admin email inbox first. WordPress sends a recovery link to the address in Settings > General. That email is your fastest way back in. Search for the site name and check spam.
• Rule out a browser cache problem. Open the site in a private or incognito window. If it loads there, clear your browser cache instead of panicking about the server.
• Note exactly when the error started. Right after a plugin update? After installing something new? After your host sent a maintenance notice? The timing usually points straight at the cause.
• Write down anything unusual on screen. A plain white screen with the critical error message is the standard sign. Any extra text or a partial page load is a clue — copy it exactly.
• Make a backup before you change anything. If you can reach the site through FTP or your host’s file manager, download a copy of wp-content and export the database first. Fixes are safe, but backups make them stress-free.
• Keep calm about your content. A critical error breaks code, not data. Your posts, pages and media live in the database and are almost always untouched.

Diagnose Table

Match your symptom to the likely cause, then jump to the fix.

Symptom	Likely cause	Go to fix
White screen saying “There has been a critical error on this website”	PHP fatal error, usually from a plugin or theme	Fix 1, Fix 3, Fix 4
Error appeared right after a plugin update or install	Incompatible or broken plugin code	Fix 3
Error appeared after a theme update or an edit to theme files	Broken theme or bad code in functions.php	Fix 4
Debug log shows “Allowed memory size exhausted”	PHP memory limit is too low	Fix 5
Error appeared after your host changed the PHP version	Plugin or theme incompatible with the PHP version	Fix 6
Whole site broken after a failed WordPress update	Corrupted core files	Fix 7
Error returns with default theme and no plugins active	Server-level problem, such as PHP settings or host limits	Fix 8

1. Use the Recovery Mode Email WordPress Sent You

This is the simplest fix and the one WordPress itself wants you to try first. When a plugin or theme triggers a fatal error, WordPress pauses the offending code and emails the site administrator a special login link. That link opens recovery mode, a stripped-back dashboard where the broken extension stays paused while you work.

Start by finding the email. Open the inbox for the address set as the admin email under Settings > General, and look for a message whose subject says the site is experiencing a technical issue. It always contains a special login link. Check spam too — automated emails land there often.

If the email never arrives, do not assume recovery mode is unavailable. Some hosts block the mail function WordPress uses, or the admin email on file is an old address you no longer check. If you suspect your email itself is the problem, see our guide on fixing emails that never arrive to sort out delivery first. You can still fix the site with the remaining steps below — recovery mode is convenient, not required.

Once you have the link, the steps are short:

1. Click the recovery link in the email. It logs you into a special recovery session.
2. You will see a notice that recovery mode is active and which extension caused the problem. WordPress often names it for you.
3. Go to Plugins or Appearance > Themes and deactivate the named extension.
4. Visit your site in a new tab. If it loads, the paused extension was the cause.
5. Click “Exit Recovery Mode” in the admin bar when you are done.
6. Keep the broken plugin or theme deactivated until you have a fixed version. Check for an update from its author, or find an alternative.

Recovery mode does not repair anything by itself — it gives you a working dashboard so you can remove the cause safely. If there is no email at all, move to Fix 2 and find the culprit yourself.

2. Turn On Debugging to Find the WordPress Critical Error Cause

When there is no recovery email, you become the detective. WordPress can write the exact PHP error to a log file, including the file name and line number that crashed. That one log entry often names the guilty plugin or theme outright. Turning on debugging takes two minutes and requires only a small edit to wp-config.php.

You need file access: an FTP client such as FileZilla, or the file manager in your hosting panel. Find wp-config.php in the site root, next to wp-admin, wp-content and wp-includes. Download a copy first, so you can restore it if anything goes wrong.

Open wp-config.php in a plain text editor — not WordPad or Word, which can add hidden formatting. Look for the line that says /* That's all, stop editing! Happy publishing. */. Just above it, add these three lines:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Each line does one job. WP_DEBUG switches error reporting on. WP_DEBUG_LOG writes errors to wp-content/debug.log. WP_DEBUG_DISPLAY set to false keeps errors off the public screen, so visitors never see your server paths.

Save, upload, and reload the broken site once or twice. Each reload writes fresh entries to the log. Then open wp-content/debug.log and read it.

Look for “PHP Fatal error” lines. A typical entry ends with a path like wp-content/plugins/some-plugin/some-file.php — the folder name is your answer. A path under wp-content/plugins/ means a plugin; under wp-content/themes/ means the theme; under wp-includes or wp-admin means damaged core files (skip to Fix 7).

The official WordPress debugging handbook documents every debugging constant if you want the full reference. For this job, the three lines above are all you need.

Always turn debugging off when you finish. Leaving it on exposes server paths and slows the site. Set WP_DEBUG back to false and delete debug.log from wp-content afterwards.

3. Deactivate All Plugins Through FTP

Plugins cause most critical errors. One update can introduce code that clashes with your PHP version or another plugin, and the whole site falls over. The fastest test is to deactivate every plugin at once — by renaming one folder, since the dashboard is locked.

Connect via FTP or your host’s file manager, open wp-content, and rename the plugins folder to plugins-disabled. Any name works, as long as it is not “plugins”.

The moment you rename it, WordPress can no longer load any plugin. Reload your site. If the white screen is gone, you have your answer: one of the plugins was crashing the site. If the error persists, plugins are innocent — rename the folder back to plugins and move on to Fix 4.

If the site loads, find the guilty plugin:

1. Rename plugins-disabled back to plugins.
2. Log into your WordPress dashboard. WordPress will show every plugin as deactivated. That is expected.
3. Reactivate your plugins one at a time.
4. After each activation, reload the site in another tab.
5. When the critical error returns, the plugin you just activated is the culprit. Deactivate it again.
6. Continue with the rest so everything else is back to normal.

Once you know the culprit, check for an update — many critical errors come from plugins that have not kept up with newer WordPress or PHP. If none exists, contact the author via its WordPress.org support forum; the official critical error support threads recommend this same deactivation process. As a last resort, replace it with an actively maintained alternative rather than leaving it deactivated forever.

4. Switch to a Default WordPress Theme

If plugins are innocent, the theme is next. Themes run code on every page load, and a bad update or a careless edit to functions.php can crash the whole site. Same test as Fix 3: take the theme out and see if the site recovers.

Open wp-content/themes via FTP or file manager, find your active theme’s folder, and rename it — mytheme becomes mytheme-disabled.

WordPress notices the active theme has vanished and falls back to a default theme, such as Twenty Twenty-Four, if one is installed. Reload your site. If it loads, your theme was the problem. If the error stays, rename the folder back and continue to Fix 5.

A recovered site points to one of three things: a theme update with incompatible code (check for a further update or roll back), a recent manual edit to functions.php (restore it from backup), or a child theme clashing with its updated parent (test the parent alone, then ask the child theme’s developer).

Note which theme was active before renaming — widgets, menus and customiser settings are tied to it, and you will want to return once the cause is fixed.

5. Increase the PHP Memory Limit

Some critical errors are not caused by broken code at all. They happen because a plugin or theme needs more memory than your hosting plan allows PHP to use. The debug log gives this away clearly: the fatal error says “Allowed memory size exhausted”. If you saw that line in Fix 2, this fix is very likely your answer.

WordPress sets its own memory limit in wp-config.php, and the default is often too low for a busy site. Add this just above the “stop editing” line:

define( 'WP_MEMORY_LIMIT', '256M' );

Save, upload and reload. 256M suits most small and medium sites; heavy sites with page builders or large catalogues sometimes need 512M. Increase in steps — if 256M does not help, a plugin probably has a memory leak, and more memory only delays the crash.

Your host sets a server-level ceiling that wp-config.php cannot exceed. If raising the limit changes nothing, ask your host to raise it — a routine request on shared hosting. If they refuse and your site genuinely needs more, the plan no longer fits the site.

Treat repeated exhaustion as a symptom: a healthy site should not need ever-larger allocations. If the error keeps returning, use the Fix 3 plugin test to find the memory hog, then update or replace it.

6. Check Your PHP Version

Everything on your site runs on PHP, and PHP keeps evolving. When your host upgrades it — or you install a plugin built for a newer PHP than your server runs — the mismatch can cause fatal errors. Nothing on your site changed; the server changed under it.

Find your PHP version in the hosting panel’s PHP settings, or in recovery mode under Tools > Site Health > Info > Server. Compare it with what your plugins and theme expect — plugin pages on WordPress.org list supported PHP versions.

If the host moved to newer PHP and an old plugin broke, update or replace the plugin — old code uses functions newer PHP removed. If a new plugin broke on old PHP, upgrade PHP in the hosting panel instead; most hosts offer a simple version dropdown.

Change one thing at a time and test after each. Do not roll PHP back to keep one abandoned plugin alive — old PHP versions stop receiving security patches, and an unpatched server is a bigger problem than a broken plugin.

7. Reinstall the WordPress Core Files

Sometimes the problem is not an extension. An interrupted WordPress update — timeout, full disk, dropped connection — can leave core files half-written, and the site fails whatever the plugins and theme. Reinstalling core files replaces everything except your content and settings.

If you can reach the dashboard, even in recovery mode, use the built-in path: Dashboard > Updates, then the “Re-install version” button near the top. WordPress downloads fresh files and reinstalls them, leaving wp-content, the database and wp-config.php alone. Wait for the success message.

If the dashboard is completely unreachable, do it manually over FTP:

1. Download a fresh copy of WordPress from wordpress.org matching your current version.
2. Unzip it on your computer.
3. Delete the wp-content folder from the fresh copy. You must not overwrite your own.
4. Upload everything else, overwriting the existing wp-admin and wp-includes folders and the loose files in the root.
5. Do not touch your existing wp-config.php or anything inside your wp-content folder.

This is safe if you follow step 3: themes, plugins, uploads and the database live in wp-content and the database, which this never touches. After uploading, reload the site — then run Dashboard > Updates once more to confirm the version.

8. Contact Your Hosting Provider

If you have worked through all seven fixes and the white screen remains, the problem lives below WordPress — at server level. This is not a defeat. Some causes are simply outside your reach: a PHP process being killed for exceeding host limits, a misconfigured server module, a full disk on the hosting account, or file permission problems that FTP cannot fix.

Gather three things first: the exact error text or a screenshot, the “PHP Fatal error” lines from debug.log (paste, don’t retype), and a short list of what you already tried. Support helps faster when it can skip steps you have covered.

Ask them to check the server’s PHP error log, which records failures WordPress never sees; whether any resource limits are being hit on your account; and whether anything changed on the server — a PHP upgrade or security patch — around the time the error started. A timestamp match can crack the case in minutes.

Good hosts resolve most of these tickets the same day. If yours stalls, stalls again, or tells you to “just reinstall everything” without reading your log, take it as information about the host, not about you. A site that matters deserves hosting with competent support.

What to Avoid

• Never download nulled or cracked plugins, or any “critical error fixer” tool. Pirated extensions often contain malware, and they are a leading cause of the fatal errors they claim to repair.
• Never edit the database blindly without a backup. One wrong query in phpMyAdmin can destroy content that no file fix can bring back.
• Do not leave debugging switched on. A live debug.log exposes server paths to anyone who guesses its address. Turn WP_DEBUG off when you finish.
• Do not edit WordPress core files to work around the error. Core edits are wiped out by the next update and hide the real cause instead of fixing it.
• Do not delete the plugins or themes folder outright. Rename folders so you can restore them. Deletion loses settings you may want back.
• Do not ignore the recovery email. It is the fastest, safest route back in. Check spam and the correct inbox before doing file surgery.

FAQ

What does “There has been a critical error on this website” actually mean?

It means WordPress caught a PHP fatal error — code that crashed so badly the page could not be built. Since version 5.2, WordPress shows this message instead of a blank page, pauses the offending plugin or theme, and emails the administrator a recovery link.

Will I lose my posts, pages and images?

Almost certainly not. A critical error breaks code, not data. Your content lives in the database, and none of the eight fixes above touch your posts, pages or media library. Still, take a backup before you start. Backups turn a stressful repair into a routine one.

Why did I never receive the recovery mode email?

Usually a wrong admin email, a spam-folder delivery, or the host blocking WordPress’s mail function. Check Settings > General once you are back in, and consider an SMTP plugin so future site emails arrive. The other fixes here work fine without the email.

Can a critical error fix itself?

Rarely — occasionally a failed automatic update retries and completes. Do not count on it. A broken plugin or theme will sit there until removed, and every hour offline costs visitors and trust.

How long does it usually take to fix?

With the recovery email in hand, most people are done in ten minutes. Without it, the FTP-based steps — debugging, plugin tests, theme switch — typically take under an hour, even for a beginner. Only server-level problems that need the host tend to stretch longer, and that waiting time is on the host, not you.

How do I stop this happening again?

Update one thing at a time and check the site after each update, so you always know which change broke it. Remove plugins you no longer use, especially abandoned ones with no recent updates. Keep automated backups running, and test major updates on a staging copy of the site first. Most critical errors are preventable with boring, regular maintenance.

Conclusion

A wordpress critical error looks catastrophic but is usually a small problem wearing a scary mask. Start with the recovery email, read the debug log if there is no email, then work through plugins, theme, memory limit, PHP version and core files in order. Each step either fixes the site or rules out a cause, so you are always moving forward.

If you found this guide useful, there is more where it came from. Browse the TechSBSInfo homepage for our latest step-by-step guides, read more troubleshooting articles on the blog, and visit the About page to see how we test every fix before we publish it.