Every WordPress Error Message Explained and How to Fix Them

Your WordPress site is broken. You're staring at a white page, a 500 error, a database connection message, or that dreaded line: "There has been a critical error on this website." You need it fixed before your visitors notice, ideally before your coffee goes cold.

This is the complete reference guide to every common WordPress error you're likely to meet. The diagnostic workflow comes first, because most errors get solved in that workflow before you even need to look up the specific message. Then the error catalogue, 25 messages across 7 categories, each with the exact symptoms, causes, and fix steps. Every section has a direct anchor so you can share the link with the person fixing it.

A quick note on scope. We've been running WordPress hosting at 365i since 2002. Roughly 80 to 90 per cent of the errors that land in our support inbox trace back to one of three things: a plugin conflict, a PHP memory limit, or a corrupted configuration file. If you fix those, the rest of this guide becomes optional reading.

The guide has three parts. Part 1 is the diagnostic workflow, use this on every error. Part 2 is the creative table of contents, use it to jump to the exact error category you're hitting. Part 3 is the complete error catalogue with specific fixes.

Part 1: The Universal WordPress Diagnostic Workflow

Before you touch a specific error, work through this. It's the same triage order our support team uses on every ticket. Nine times out of ten you won't need the error catalogue at all. You'll find the problem during the diagnostic.

Before You Touch Anything

Step 1: Take a backup before anything else

Your site is already broken. What you want to avoid is breaking it more while trying to fix it. Before you edit a single file, take a backup.

If you can still reach wp-admin, use your hosting control panel's one-click backup or a plugin like UpdraftPlus. If you can't reach the admin, use your hosting control panel to snapshot the files and the database directly. Most decent hosts (including 365i) have a "Restore Point" button that takes a full snapshot in seconds.

Step 2: Write down exactly what changed before it broke

Before you start troubleshooting, answer these four questions on paper (or a sticky note):

• What did you do last? Updated a plugin? Switched theme? Changed hosting? Edited functions.php?
• When did the error first appear? Before an auto-update overnight, or right after you clicked something?
• Is the error site-wide, or only on one page, or only in the admin?
• What's the exact error message? Copy it verbatim. "Something broke" won't help you Google.

This answers the single most useful diagnostic question: what's the last thing that changed? WordPress rarely breaks itself. Something changed, and that something is almost always the culprit.

Find Out What's Actually Broken

"Even in the case where a fatal error would commonly have made the backend completely inaccessible (for example through a so-called 'white screen of death'), administrators will now still have the chance to log in and do something about the issue."

-- Felix Arntz, Core Committer at WordPress.org, introducing Fatal Error Recovery Mode in WordPress 5.2, 16 April 2019

Felix Arntz was describing the Recovery Mode feature that's been in WordPress core since 5.2. When a fatal PHP error brings your site down today, WordPress catches it and emails the site admin a magic recovery link. That link lets you log in to a special admin mode where the offending plugin or theme is disabled, just for your session, so you can actually deactivate it. Before checking anything else, check the email address set in Settings > General. The recovery link may already be waiting in the inbox.

Step 3: Enable WP_DEBUG (safely, without showing errors to visitors)

WordPress ships with a built-in debug mode. By default it's off, so fatal errors produce the infamous white screen instead of a message you can actually read. You turn it on by editing wp-config.php, but you must do it carefully. Never display errors on a live site, they leak file paths and database details to attackers.

Open wp-config.php via FTP or File Manager and find the line define( 'WP_DEBUG', false );. Replace it with this block, above the /* That's all, stop editing! */ line:

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

That configuration writes every PHP warning, notice, and fatal error to wp-content/debug.log, but shows nothing to the visitor. This matches the official WordPress debugging documentation. Reload the page that was throwing the error once you've saved the file.

Step 4: Read wp-content/debug.log and your host's PHP error log

Navigate to wp-content/debug.log via FTP and open it. The most recent entries are at the bottom. The line you want looks something like this:

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

Three things matter: the error type (Fatal error, Warning, Notice), the function or file that failed, and the exact line number. That filepath tells you which plugin or theme is broken. Nine times out of ten, the broken file lives inside wp-content/plugins/[plugin-name]/ or wp-content/themes/[theme-name]/. You now know what to disable.

Also check your hosting control panel for a "PHP Error Log" or "Server Error Log". Your host's log sometimes catches things WordPress can't log itself, like .htaccess syntax errors or Apache-level crashes.

Step 5: Scope the failure

Now that you have an error to work with, scope it:

• Does it happen on one post, or every post?
• Does it happen on the front end, the admin, or both?
• Does it happen for logged-out visitors as well as you?
• Does it happen on mobile, desktop, or both?
• Does it happen for every browser, or just yours?

If it happens on one post only, you're looking at a content or cache issue, not a core failure. If it happens only for logged-in users, it's probably a theme or admin plugin conflict. If it's cache-related, your browser or CDN is almost certainly involved. Scoping tells you where to look.

Isolate the Cause

Step 6: Rule out plugins (the fastest way)

Plugins are the cause of most WordPress errors. According to the Patchstack State of WordPress Security 2025 report, 96 per cent of the 7,966 WordPress vulnerabilities reported in 2024 came from plugins, with just 7 in WordPress core all year. That's 22 new plugin vulnerabilities a day. Compatibility breakage, while not technically a vulnerability, follows the same pattern. If something's wrong, start with the plugins.

If you can still reach wp-admin, go to Plugins and deactivate all of them with the Bulk Actions dropdown. If you can't reach wp-admin, FTP into the site and rename /wp-content/plugins to /wp-content/plugins_old. That deactivates every plugin at once, no database access needed. WordPress treats "plugin folder doesn't exist" as "plugin isn't installed".

Reload the site. If the error is gone, it was a plugin. Rename the folder back to plugins, then go to Plugins in the admin, where you'll now see them all deactivated. Reactivate one at a time, reloading the front page after each, until the error returns. The last plugin you activated is the culprit.

Step 7: Switch to a default theme

If deactivating plugins didn't fix it, your theme is next. Themes ship with their own functions.php, which is effectively a giant plugin. A bad theme update, a premium theme that stopped being maintained, or a child theme with a PHP error can take down the whole site.

Go to Appearance > Themes and activate Twenty Twenty-Four (or any core Twenty* theme). If you can't reach the admin, FTP into /wp-content/themes and rename your active theme folder to anything else. WordPress will fall back to the most recent default theme automatically.

If the site recovers after a theme switch, the fault was in your theme. Check whether the theme has an update available. If it doesn't, or if the update doesn't fix it, you need to contact the theme developer or look for a replacement. Don't go back to a broken theme hoping it'll fix itself.

Step 8: Reactivate one at a time to find the exact culprit

By this point, you know whether it's plugins or the theme. Now find the specific one. Reactivate plugins one at a time (or use the bisection trick above), reloading the front page each time. The plugin that reintroduces the error is your suspect.

When you find it, don't just delete and reinstall. First check if there's an update available. A plugin developer may have pushed a fix hours ago. Also check whether your WordPress core is up to date, because some plugins break when WordPress gets a major release, see our write-up of three popular plugins that broke on WordPress 6.9 for a worked example.

If the plugin is abandoned or the developer can't help, you may need a replacement. The WordPress plugin directory has good alternatives for most use cases.

Part 2: Jump to the Error Category You're Hitting

Seven categories. Twenty-five error messages. Tap a card to jump straight to the fix.

Part 3: The Complete Error Catalogue

Every error below has its own anchor link. If you find one that matches your problem, copy the URL and send it to whoever's helping you fix it.

Category 1: Site Is Totally Down

Category 2: PHP Resource Errors

Category 3: Login & Admin Access

Category 4: Stuck After an Update

Category 5: Permalinks, Redirects & SSL

Category 6: Media & Uploads

Category 7: PHP Code Errors

What Managed Hosting Actually Eliminates

We've mentioned "hosting angle" on every error. Let's be honest about which of these are hosting-solvable and which aren't.

Errors that properly configured managed WordPress hosting actually eliminates:

• Missing temporary folder (WP_TEMP_DIR configured at the server level)
• Failed to write to disk on NVMe storage with elastic scaling
• Most database connection errors (managed, monitored database instances)
• Stuck maintenance mode (auto-detection and cleanup)
• Pretty permalink 404s (rewrite rules at the server level)
• "Missing MySQL extension" (a modern stack is always compatible)

Errors that hosting helps with but doesn't eliminate:

• Memory exhausted (365i defaults to 128MB like most hosts, but a real human raises it on request without upselling you to a bigger plan)
• White screen of death and critical errors (caused by your plugins, not your host, but recovery is faster with one-click restore points)
• Plugin conflicts (staging environments catch them before live)
• Syntax errors (still a typing problem, but rollback is a click)
• Max execution time (we tune it higher than budget hosts but runaway scripts still hit limits)

Errors that hosting can't fix for you:

• Parse errors from your own theme edits
• Mixed content from hardcoded HTTP in your database
• "Are you sure you want to do this" nonce failures from badly-built plugins
• Custom post type 404s from slug conflicts

Be suspicious of any host that claims to "prevent WordPress errors". They can't. They can make them rarer, faster to diagnose, and faster to recover from. That's what good hosting actually does. If you want to see whether your current host is pulling its weight, start with our hosting-first speed diagnostic, it's a five-minute check.

Frequently Asked Questions