How to Fix “There Has Been a Critical Error on This Website” in WordPress

"There has been a critical error on this website" means PHP hit a fatal error while loading your site and stopped. WordPress hides the technical details from visitors and shows this short message instead.

In most cases the cause is a plugin, the theme, or a PHP setting such as the memory limit or PHP version. The fix is to find the exact error, then disable or repair whatever caused it. This guide goes through each step in order, from the quickest to the most involved.

Quick fix checklist

If you're in a hurry, work down this list and stop when the site comes back:

1. Check the admin email for a recovery mode link and use it to log in.
2. Turn on WP_DEBUG_LOG and read the error in wp-content/debug.log.
3. Disable all plugins by renaming the plugins folder, then re-enable them one by one.
4. Switch to a default theme by renaming your theme's folder.
5. Check .htaccess and wp-config.php for broken lines.
6. Raise the PHP memory limit, or change the PHP version back.
7. Re-upload the WordPress core files, or restore a backup.
8. Only one page broken? Rebuild that page from a duplicate or a saved template.
9. Using a paid theme? Disable its bundled plugins and update any Pro plugins.

Each step is explained below.

What does the critical error message mean?

Since WordPress 5.2, a fatal PHP error no longer gives a blank white screen. WordPress catches it, shows visitors the critical error message, and emails the site admin a link to recovery mode.

The message itself never says what broke. Behind it is a line like this, which you will find in the error log:

PHP Fatal error: Uncaught Error: Call to undefined function some_function()
in /home/user/public_html/wp-content/plugins/some-plugin/some-plugin.php:42

That line tells you the error type, and the file and line number where it happened. The folder in the path (plugins/some-plugin above) is usually the culprit.

What causes the critical error in WordPress?

The most common causes are:

• A plugin that conflicts with another plugin, your theme, or your PHP version. It often happens right after installing or updating one.
• The theme, or code added to its functions.php file.
• PHP memory running out ("Allowed memory size exhausted").
• A PHP version change. Old plugins can break on PHP 8, and new ones can break on old PHP.
• Corrupted core files, for example after an update was interrupted.
• A broken line in wp-config.php, or a leftover drop-in file such as db.php.
• Server problems: a full disk, a crashed database table, or, less often, a hacked site.

What do you need before you start?

You need access to your site's files, because the dashboard is usually locked out. Any of these will do:

• cPanel File Manager, or the file manager in your host's own panel (hPanel, Plesk, DirectAdmin and so on);
• FTP or SFTP with a client like FileZilla or WinSCP;
• phpMyAdmin, for the database methods. This is optional.

Step 1: Check your email for the recovery mode link

When the fatal error happens, WordPress sends an email to the site's admin email address, with a subject like "Your Site is Experiencing a Technical Issue". It names the plugin or theme that failed and contains a special login link.

1. Search your inbox, and the spam folder, for that email.
2. Open the recovery mode link and log in.
3. WordPress pauses the faulty plugin or theme for you only. Go to Plugins (or Appearance > Themes) and deactivate it, update it, or replace it.
4. Click Exit Recovery Mode in the admin bar.

The email is sent at most once a day, and the link expires after about a day. If no email came, your host may not be sending mail from WordPress. Move on to step 2.

Step 2: How to find the real error (turn on debug.log)

This is the most useful step. Instead of guessing, you read exactly what failed.

Open wp-config.php in the root folder of your site (usually public_html). Find the line define( 'WP_DEBUG', false ); and replace it with these lines. They must go above the line that says /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Save the file, then reload the broken page once. WordPress writes the errors to wp-content/debug.log. Open that file and look at the last lines for one that starts with PHP Fatal error.

Don't see debug.log? Check your host's error logs too:

• in cPanel, the Errors page under Metrics;
• an error_log file in public_html or wp-admin;
• the "Logs" section in other hosting panels.

What does the error mean?

Step 3: How to disable plugins without the dashboard

If the error path contains wp-content/plugins/plugin-name, you already know the culprit. Rename only that folder, for example to plugin-name-off, and reload the site.

If you don't know which plugin it is, disable all of them:

1. In File Manager or FTP, open wp-content.
2. Rename the plugins folder to plugins-off.
3. Reload your site. If the critical error is gone, a plugin caused it.
4. Log in to the dashboard and open the Plugins page. WordPress deactivates every plugin, because it can't find their files.
5. Rename plugins-off back to plugins. All plugins are still there, now inactive.

How to find the faulty plugin one by one

Now activate the plugins one at a time. After each one, open the site in another tab and reload it. When the critical error returns, the last plugin you activated is the cause.

Start with the plugin you installed or updated most recently. Then:

• update it if a newer version exists;
• check its support forum for the same error;
• replace it with a different plugin if it's abandoned.

Disable plugins from phpMyAdmin

If you can reach the database but not the files:

1. Open phpMyAdmin and the wp_options table (the wp_ prefix may be different on your site).
2. Find the row where option_name is active_plugins.
3. Copy its current value somewhere safe, then change it to a:0:{}.

This deactivates all plugins at once without deleting them.

Step 4: How to switch to a default theme

If disabling plugins didn't help, the theme may be the problem, especially if the error path contains wp-content/themes/.

1. Open wp-content/themes.
2. Rename your active theme's folder, for example astra to astra-off.
3. Reload the site.

WordPress falls back to an installed default theme, such as Twenty Twenty-Five. If no default theme is installed, download one from WordPress.org and upload it to wp-content/themes first.

Using a child theme? Rename the child theme's folder first. If you recently pasted code into functions.php, that code is the most likely cause, so remove it.

You can also do this in phpMyAdmin: in wp_options, set both template and stylesheet to the folder name of a default theme, like twentytwentyfive.

Using a paid theme? Check the plugins that came with it

This is a cause I've run into myself, and it's easy to miss. Premium themes, like most themes bought on ThemeForest, come with their own companion plugins: a "theme core" plugin, an extra Elementor widget pack, sliders and so on. They're made for one version of the theme.

The trouble starts when the theme isn't updated, for example because the license expired or the theme was never connected to its updates. WordPress, Elementor and PHP keep updating, but the theme's plugins stay old, and sooner or later they conflict.

What happened on my site

On one site, the problem first showed up in Elementor: the editor kept giving a "Server Error" and the page layout looked strange. A while later the whole site showed the critical error.

The cause was the plugin the theme had installed. Once I disabled that plugin, the site loaded again. But the page sections built with that plugin's widgets were gone, so those parts had to be rebuilt.

What to check

1. Disable the theme's companion plugin first. Rename its folder in wp-content/plugins. It usually has the theme's name in it, or "core", "addons" or "elements".
2. Update the paid theme and its plugins. Paid themes don't update from the dashboard without a license. Download the latest version from where you bought it (for ThemeForest: Downloads in your account), and upload it, replacing the old folder.
3. Check other Pro plugins too, like Elementor Pro or premium add-ons. If they have no active license, they've likely missed updates. Update them, or disable them to test.
4. If you can't update a plugin and the site works without it, leave it disabled and replace what it did.

My advice for future sites

If you use a paid theme, use its own custom widgets as little as possible. Build pages with Elementor's standard widgets, or the block editor's, wherever you can. Then if the theme's plugin ever breaks, you can turn it off and your pages still stand.

For important sites, like a business site or a store, I'd avoid relying on them completely. A redesign later, rebuilding every page that used those widgets, costs far more time and money than avoiding them at the start.

Step 5: Check the .htaccess file

A broken .htaccess file more often causes a "500 Internal Server Error". But PHP settings inside it, like php_value lines added by a plugin or by you, can also break WordPress.

1. In cPanel File Manager, open Settings and turn on Show Hidden Files (dotfiles).
2. Rename .htaccess to .htaccess-old.
3. Reload the site.

If the site works, create a new .htaccess with the default WordPress rules:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Or log in and go to Settings > Permalinks and click Save Changes. WordPress rewrites the file for you. Then copy back any rules you still need from the old file, one block at a time.

Step 6: Check wp-config.php for mistakes

wp-config.php is a PHP file, so one wrong character breaks the whole site. Look for:

• a missing semicolon ; or quote mark at the end of a define line;
• the same constant defined twice, such as two WP_MEMORY_LIMIT lines;
• code added below require_once ABSPATH . 'wp-settings.php'; that should be above it;
• spaces or blank lines before <?php at the top.

A quick way to spot changes is to compare your file with wp-config-sample.php, which is in the same folder, or with your backup. Paste both into a diff checker and it highlights every line that differs.

Also check the wp-content folder for drop-in files: db.php, object-cache.php and advanced-cache.php. Caching and security plugins add these. If a plugin was removed but its drop-in stayed, it can cause the critical error. Rename the file and reload.

Step 7: How to increase the PHP memory limit

If the log says "Allowed memory size exhausted", give WordPress more memory. Add this line to wp-config.php, above the "stop editing" line:

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

By default, WordPress asks for 40 MB on a normal site and 64 MB on multisite. That's often not enough for WooCommerce, page builders like Elementor, or many plugins.

If the error only happens in the dashboard, also add:

define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WordPress can't go above the limit set by your server. If nothing changes, raise memory_limit in your hosting panel (in cPanel: Select PHP Version > Options, or MultiPHP INI Editor), or ask your host.

Step 8: Did the PHP version change?

Hosts upgrade PHP regularly, and many critical errors start the day it happens: an old plugin uses something PHP 8 removed, and the site falls over.

To test this, open your hosting panel. In cPanel that's MultiPHP Manager or Select PHP Version. Note your current version and switch to the one before it.

• If the site comes back, a plugin or the theme isn't compatible with the newer PHP. Update it or replace it, then switch PHP up again.
• Don't stay on an old version. WordPress recommends PHP 8.3 or newer. It still runs on PHP 7.4, but versions that old no longer get security fixes.

The opposite also happens. A brand-new plugin version may need a newer PHP than your server has. The plugin's page on WordPress.org lists the PHP version it needs.

Step 9: How to re-upload WordPress core files

If the error path points to wp-admin or wp-includes, the core files may be damaged. This often happens when an update was interrupted. Replacing them doesn't touch your posts, pages or uploads.

1. In the dashboard, or in wp-includes/version.php, check your WordPress version.
2. Download the same version from WordPress.org and unzip it.
3. Upload the wp-admin and wp-includes folders, replacing the old ones.
4. Upload the loose files from the root folder (index.php, wp-login.php, wp-settings.php and so on).

If an update stopped halfway, you may also find a .maintenance file in the root folder. Delete it. On its own it shows "Briefly unavailable for scheduled maintenance" rather than the critical error, but both often appear after the same failed update.

Step 10: Check disk space and the database

Two server problems can also cause the error:

• The disk or account quota is full. WordPress can't write files or sessions. Check disk usage in your hosting panel and delete old backups, logs or cache folders.
• A database table is damaged. Add define( 'WP_ALLOW_REPAIR', true ); to wp-config.php, then open yoursite.com/wp-admin/maint/repair.php and click Repair Database. Remove the line afterwards, because that page doesn't need a login.

Error on only one page? Rebuild that page

Sometimes the whole site works and only one page shows the critical error. This often happens with page builders like Elementor, when a widget or setting on that page is broken. Instead of hunting for the bad element, try rebuilding the page.

Try a duplicate of the page first

1. Go to Pages in the dashboard and hover over the broken page.
2. Click Duplicate or Clone. If you don't see it, install a duplicate plugin such as Yoast Duplicate Post.
3. Open the copy. If the copy loads fine, the problem was in the old page itself.

Or build a new page from a saved template

If you saved the page as a template earlier, you can rebuild it in a minute:

1. Create a new page.
2. In Elementor: open the page with Elementor, click the folder icon (Add Template), go to My Templates and Insert your saved template.
3. In the block editor: insert the saved pattern, or open the old page's Code editor (⋮ menu), copy everything and paste it into the new page.
4. Check the content and fix anything that's missing, then Publish.

Delete the old page and keep the same URL

Your new page will get an address like /about-2, because the old page still has /about. To keep the original URL, so links and Google rankings stay:

1. Move the old page to Trash.
2. Open Trash and choose Delete Permanently. The old address stays taken until you do.
3. Edit the new page, change its slug (URL) to the original one, and Update.

Then open the page in a private window to check it works.

Step 11: Restore a backup or ask your host

If nothing above worked, restore the most recent backup from before the error started. Many hosts keep daily backups you can restore from the panel.

Or open a ticket with your host. Include the exact PHP Fatal error line from the log. With that line, support can usually find the cause in minutes.

How other people fixed it: real cases from the WordPress forums

These cases are from the official WordPress.org support forums. They show how often the real cause is something the message doesn't hint at:

• Memory limit and PHP version. In one resolved thread, the poster's host fixed the site by raising the memory limit and changing the PHP version.
• Error on one page only. On a site using Ultimate Member, the error appeared only on the user profile page. debug.log showed an Uncaught TypeError inside the plugin, caused by one field on the profile form. Removing that field fixed it.
• After a PHP upgrade. A WooCommerce site broke on a single gallery page after the host moved PHP from 7.4 to 8.2. The log showed "Allowed memory size exhausted", and the suggested fix was a higher WP_MEMORY_LIMIT.
• A leftover drop-in. In another thread, the log pointed to wp-content/db.php, a drop-in file, not to a plugin. Disabling plugins and themes had no effect. The advice was to remove db.php and re-upload the core files.
• No error details at all. When someone only had phpMyAdmin access and no recovery email, forum moderators gave the same advice as this guide: get the real error from the host's log or debug.log first, then rename the theme and plugin folders.

The common lesson: read the log before changing things. Disabling plugins blindly can waste an hour when one line in debug.log names the file.

What if your WordPress site was hacked?

Be suspicious if the error appeared without any update or change on your part, if the log shows strange file names or code you don't recognise, or if new admin users appeared.

How to check your files for hacked code

Take a full backup before deleting anything. Then check these places:

• Plugins and themes folders. Open wp-content/plugins and wp-content/themes, and compare the folders with the list in your dashboard. Hackers often add folders with random names, like wp-xyz123 or cache-core, that don't appear as any plugin or theme you installed. Delete folders you can't match to something you use.
• mu-plugins. Look for a wp-content/mu-plugins folder. Files there run on every page and don't show in the normal plugin list. If you didn't add them, and your host didn't, remove them.
• Uploads. wp-content/uploads should only hold images and documents. A .php file in there is almost always malicious.
• wp-config.php. Compare it with wp-config-sample.php. Anything beyond your database details, keys and define lines is suspicious, especially at the very top or bottom of the file.
• .htaccess. Look for rules that redirect visitors to other domains, or lines like auto_prepend_file that load a file you don't recognise.
• The theme's functions.php. Scroll through it, especially to the end. Code you didn't add, or that doesn't belong to the theme, is a red flag.

Signs of hacked code in any PHP file:

• eval(, base64_decode(, gzinflate(, str_rot13( or assert(, often nested together;
• a very long line of random-looking letters and numbers;
• links or redirects to domains you don't know.

<?php eval(base64_decode('aWYoaXNzZXQoJF9QT1NU...')); ?>

A line like this at the top of a file is a classic sign. Don't run or decode it on your site. Delete it, or better, replace the whole file with a clean copy.

The Diff Checker helps here too. Paste a file from a fresh download of the plugin or theme next to your copy, and any added code stands out.

After cleaning up

1. Restore a clean backup from before the hack, or re-upload all core files.
2. Reinstall all plugins and themes from fresh copies.
3. Remove admin users you don't recognise, under Users.
4. Change every password: WordPress admins, hosting, FTP and the database. A password generator makes strong ones quickly.
5. Ask your host to scan the account, or run a security plugin scan.

How to stop the critical error from happening again

• Back up automatically, daily if possible, and keep copies off the server.
• Update one thing at a time, so you know what broke the site.
• Test big updates on a staging site first. Many hosts offer one-click staging.
• Remove plugins you don't use, and avoid ones that haven't been updated in a long time.
• Keep paid themes and Pro plugins licensed and updated, and don't build your pages on a theme's own widgets.
• Keep PHP current, and check plugin compatibility before your host upgrades it.

Frequently asked questions

Will I lose my posts or pages?

No. The critical error stops pages from loading, but your content is in the database and stays there. Disabling plugins or switching themes doesn't delete anything either.

Why does the critical error only appear on one page or in wp-admin?

Because only the code that runs on that page is failing. A plugin may load only on the checkout or profile page. A dashboard-only error often means the admin area needs more memory (WP_MAX_MEMORY_LIMIT) or an admin feature of a plugin is broken. If a single page stays broken, rebuild it as a new page and delete the old one (see "Error on only one page?" above).

I don't have cPanel. How do I fix the critical error?

Use whatever file access your host provides: its own file manager, FTP or SFTP. Some managed WordPress hosts also offer a "disable plugins" button or a staging copy. If you have no file access at all, ask your host's support to check the error log.

Can I turn the critical error message off?

You can set WP_DISABLE_FATAL_ERROR_HANDLER to true in wp-config.php, but it doesn't fix anything. Visitors then see a raw PHP error or a blank page instead. Fix the cause instead.

Is the critical error the same as the white screen of death?

They're the same problem. Before WordPress 5.2, a fatal error usually gave a blank white page. Now WordPress shows the critical error message and sends the recovery email.