How to fix a WordPress fatal error

The front of the site shows one line, “There has been a critical error on this website,” and wp-admin won’t load either. Don’t start deleting plugins. The screen hides a PHP error message that usually names the file, the line and the plugin or theme responsible. Fixing the site is mostly a matter of finding that message.

What the critical error screen is actually telling you

It tells you PHP hit something it couldn’t recover from and stopped running that request. Since WordPress 5.2, core catches many of these errors, shows the generic message and may email the site admin a Recovery Mode link. Before 5.2 you got a blank page, which is why people still call it the white screen of death. Our guide to fixing a WordPress white screen covers that version of the problem.

The screen looks the same for every cause, whether that’s a plugin update, a PHP version change, a typo in functions.php or a memory limit. So the screen can’t tell you what to do. The error text can.

Two things people often get wrong at this stage:

• Warnings are not the fatal. Logs fill up with “Warning” and “Deprecated” lines that did not stop anything. You want the line that begins PHP Fatal error.
• A fatal-error email does not always mean the site is down. The failing code may only run on one page or one admin screen. Visitors can sometimes keep using the rest of the site.

If a request returns a bare 500 with no WordPress message, start with our guide to fixing a server error 500. Some of those are PHP fatals and some are server problems.

Where to find the line that names the cause

Check these in order and stop when you find a fatal line:

1. The recovery email. WordPress sends it to the admin address in Settings, General. It names the plugin or theme and includes the error.
2. Your host’s PHP error log. It’s usually in the control panel under Logs or Metrics. Look at the entries from the time the site broke.
3. The WordPress debug log. If the host log is empty or you can’t reach it, turn on logging yourself.
4. WooCommerce logs. On a store, go to WooCommerce, Status, Logs and open the fatal-errors log.

To turn on the debug log, open wp-config.php over SFTP or the host’s file manager. Add these lines 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 );

Load the broken page once, then open wp-content/debug.log. WordPress’s debugging handbook documents these constants. The display setting matters most: WooCommerce’s PHP troubleshooting doc warns that showing debug output on a live site can expose sensitive information. When you’re finished, set WP_DEBUG back to false.

A fatal line looks like this:

PHP Fatal error: Uncaught TypeError: ... in /wp-content/plugins/plugin-slug/includes/class-x.php:214

Pay more attention to the path than to the wording. The folder after plugins/ or themes/ is your suspect. Use the first fatal line at the time of failure, because the lines after it are often other code failing as a result. With a parse error, the mistake is often a line or two before the one named, such as a missing semicolon or bracket.

How to get back into wp-admin

If the recovery email arrived, use its link. WordPress’s Recovery Mode documentation explains that it pauses the plugin or theme behind the error for your logged-in session only. You get a working dashboard and can deactivate, update or roll back the component. Pausing it is not a fix. Leave Recovery Mode and check the site again afterwards.

The same documentation lists the limits. Recovery Mode does not start for errors in cron or background tasks. The email can be filtered or blocked, and it goes to whatever admin address is on file, even if nobody reads it anymore.

With no email, use file access instead:

• Known plugin: in wp-content/plugins, rename its folder, for example plugin-slug to plugin-slug-off. WordPress deactivates a plugin when it can’t find the plugin’s files.
• Unknown plugin: rename the whole plugins folder. If the site comes back, rename the folder back, then reactivate plugins one at a time and test after each.
• Theme: rename the active theme’s folder so WordPress falls back to a default theme. This only works if a default theme is installed.

Rename folders. Don’t delete them. Deleting a plugin can remove its settings, and renaming is undone in one step.

The causes, most commonly reported first

WordPress’s Advanced Administration Handbook lists the usual causes: plugin conflicts, theme problems, PHP incompatibility, memory limits and corrupted core files. Nobody publishes measured figures for how often each one happens. The order below follows how often each shows up in support threads.

A plugin, usually right after an update

One example from WordPress.org’s forums: updating Ultimate Addons for Elementor to 1.6.29 produced a fatal error and a white screen. Disabling it in the host’s file manager and rolling back to 1.6.28 fixed it. Your options are the same each time. Roll back, wait for the author’s fix, or replace the plugin, and report the error line to the author either way. Don’t reactivate the broken version, because the crash comes straight back.

The plugin named in the error is not always the root cause. In another forum thread, disabling plugins after a failed MonsterInsights update didn’t help. The site came back only when the host manually finished updating two Avada plugins. If the named plugin depends on another plugin, check that both are on versions that work together.

A PHP version mismatch

This can happen in either direction. Old code can break on newer PHP. New code can also break on older PHP: Cision Block 3.0.0 threw syntax error, unexpected 'Trait' on PHP 7.4.33 until the author released 3.0.1. If the site broke after hosting work, check the PHP version before you blame anything else.

WordPress.org recommends PHP 8.3 or greater. Update your plugins and themes first, then switch PHP, on staging if you have it. Dropping back to an older PHP version can get the site running again, but it’s only a stopgap. The lasting fix is code that runs on a supported version.

A theme or a functions.php edit

A parse error naming functions.php almost always comes from a hand edit with a missing semicolon or bracket. Undo the edit, or rename the theme folder to get back in, then correct the file. Switching themes gets you back in but leaves the broken theme as it was. Put custom code in a child theme or a snippets plugin, not in the parent theme.

Memory exhausted

Allowed memory size of 268435456 bytes exhausted means the request hit a 256 MB limit. Raising the limit is a reasonable test. Kinsta’s PHP docs say to raise memory per PHP request, not the number of PHP threads. They also say a very high limit lets badly behaved scripts use too many resources. Your host may set a cap that overrides WordPress. If the error persists at the maximum, WP Engine’s support docs suggest testing plugins and themes on staging and contacting the developer of the heavy one.

Database, server or incomplete files

Messages like “Error establishing a database connection” or “Failed opening required” point at the server, so ask your host. Errors about missing core functions or classes after a WordPress update usually mean the update didn’t finish copying files. Re-upload the core files over SFTP and leave wp-content and wp-config.php alone.

Why a store needs a different approach

Switching off every plugin on a live WooCommerce site can stop checkout for every customer while you test. WooCommerce’s conflict-testing guide says to take a backup and use staging where you can. Keep WooCommerce and the affected extensions active, reproduce the exact failing action, and reactivate one component at a time. Results become useless when people turn several things off without reproducing the error, or turn everything back on at once.

The Health Check & Troubleshooting plugin switches plugins and themes off for your session only, so customers aren’t affected. Its WordPress.org page currently says it hasn’t been tested with the latest three major WordPress releases, so try it on staging first.

How to tell it’s actually fixed

The site isn’t fixed just because the message has gone. Repeat the exact action that failed, whether that’s the product page, the checkout or the form. Then log in and save something small. Set WP_DEBUG back to false, and delete debug.log once you no longer need it.

Google’s crawling documentation says a large number of 500, 503 or 429 responses lowers Google’s crawl rate for the whole hostname. A short outage is not worth worrying about. If the site failed for days, check Crawl Stats in Search Console afterwards.

When to stop and get help

Many fatals can be fixed by following the log. Stop and hand it over in these situations:

• You have no file or hosting access. One r/Wordpress poster had no FTP login, and their backup plugin was only reachable through the broken dashboard. They rebuilt the site. Get the hosting login back first. Our explainer on what a backup plugin covers explains why backups should be stored outside WordPress.
• The evidence points at the server: database errors, a host-enforced memory cap or “Failed opening required.”
• The fix needs a code change you can’t test somewhere other than the live site.
• It’s a store or a client site where a wrong step costs money.

Whoever takes it on should keep a snapshot, read the log, make one change you can undo, test the action that failed and tell you the cause. If you’d rather not do it yourself, SiteSelf fixes broken WordPress sites when you ask in chat, using hosting access for the file and code work.

Frequently asked questions

Why didn’t I get a recovery email?

The error may have happened in cron or a background task, where Recovery Mode doesn’t start. The email may also have been filtered, or the admin address in Settings, General may be out of date. Check your host’s PHP log instead.

Is my content gone?

Almost never. A fatal error stops PHP partway through a request. It doesn’t delete posts or orders. Your content stays in the database while you fix the code.

Should I restore a backup or roll back the plugin?

If the log names the plugin, rolling back that one plugin keeps everything written since your last backup. Restoring a backup makes more sense when you can’t find the cause and the backup is recent. On a store, a restore can wipe out orders placed since the backup was taken.

Why does admin-ajax.php just return a 500?

A fatal inside an AJAX or REST request has no page to display, so the browser only gets a 500 response. The fatal line is still in the PHP log or debug.log. Our guide to plugins that stop working covers features that fail without crashing the whole site.

Does raising the memory limit fix it?

It fixes it when a task genuinely needs more memory. When a plugin leaks memory, a higher limit only delays the crash and hides the real cause. If the error comes back at the higher limit, find the component using the memory.