5 Common WordPress Errors and How to Fix Them (2026)

Five common WordPress errors are the “critical error” screen, the 500 internal server error, “Error establishing a database connection”, posts that return a 404, and the memory exhausted error. Almost every one traces back to a plugin, a theme, a server setting or a recent change. So start with the question nobody likes: what changed last?

The short answer

• Most WordPress errors follow a change: an update, a new plugin, a PHP upgrade or a hosting move. Undo or isolate the last change first.
• When a plugin or theme causes a fatal error, WordPress attempts to email the site admin a recovery link with the faulty code paused; mail delivery can fail. Check that inbox before anything else.
• The debug log shows the real error message. Switch it on for diagnosis, and never display errors to visitors on a live site.
• Take a backup before you fix anything, and test the fix on a staging copy if you have one.

What are the most common WordPress errors?

The five errors covered here are the critical error screen, the 500 internal server error, the database connection error, 404 errors on posts and pages, and memory exhausted errors. Behind them sit a short list of causes: plugin or theme conflicts, server and PHP settings, wrong database details, broken rewrite rules and plugins that use too much memory.

Error	What you see	Most likely cause	First fix
Critical error	“There has been a critical error on this website”, or a blank white page	A plugin, theme or custom code crashing PHP, often after an update	Use the recovery mode email, or rename the plugins folder
500 internal server error	A generic server error page with no detail	A broken .htaccess file, a plugin, a PHP limit or corrupted core files	Rename .htaccess, then check the server error log
Database connection error	“Error establishing a database connection”	Wrong details in wp-config.php, or the database server is down	Check the database name, user, password and host
404 on posts	The homepage works, but posts and pages show “not found”	Rewrite rules lost after a move, theme change or plugin change	Re-save Settings, Permalinks
Memory exhausted	“Allowed memory size of … bytes exhausted”	A plugin or process needing more PHP memory than allowed	Raise WP_MEMORY_LIMIT within your host’s limit, then find the cause
Stuck in maintenance	“Briefly unavailable for scheduled maintenance”	An update was interrupted and left a .maintenance file	Delete the .maintenance file in the site root

The fixes in this guide follow WordPress’s own documentation on common errors. The order is mine: the steps that are safest and most often right come first.

How do you fix “There has been a critical error on this website”?

To fix the WordPress critical error, open the email WordPress sends to the site admin address and use its recovery mode link to log in with the faulty plugin or theme paused. Then update, replace or remove that plugin or theme. If no email arrives, disable all plugins by renaming the plugins folder, then switch to a default theme.

Recovery mode arrived in WordPress 5.2. When a plugin or theme causes a fatal error, WordPress pauses it for the person using the recovery link, so you can get into the dashboard while visitors still see the error. The email only helps if the admin address is one somebody actually reads. If a previous developer set the site up, check it isn’t still theirs.

1. Check the admin email inbox, including spam, for the recovery mode link.
2. No email? Connect with SFTP or your host’s file manager and rename wp-content/plugins to plugins_old. If the site comes back, rename it back and switch plugins on one at a time to find the culprit.
3. Still broken? Confirm a compatible default WordPress theme is installed before switching away from the active theme. Keep a backup of that theme; renaming its folder without an available fallback can leave the site broken.
4. Read the real error. Log it to a file with display switched off, using the four lines below. Do this on a staging copy if you have one.

Setting WP_DEBUG and WP_DEBUG_LOG on their own is not enough. WP_DEBUG_DISPLAY defaults to true, so WordPress will print errors, file paths included, to anyone who loads the page. WordPress’s debugging guide gives the safe version. Add it to wp-config.php above the line that says to stop editing:

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

With WP_DEBUG_LOG set to true, the log goes to wp-content/debug.log, which anyone can open in a browser unless your server blocks it. Safer: set WP_DEBUG_LOG to a full file path outside the public web folder instead of true. Once you have the message, roll back: set WP_DEBUG to false, remove the extra lines and delete the log file. The same guide says these tools don’t belong on live sites, so leave them on for minutes, not days.

PHP upgrades are a common trigger. WordPress.org recommends PHP 8.3 or greater, and PHP 8.2 stops receiving security fixes on 31 December 2026, according to PHP’s supported versions page. Plenty of sites will move in the next few months, and an older plugin that isn’t ready will throw exactly this error. My team tests PHP upgrades on a copy of the site first. If you’re wondering why PHP updates matter at all, my piece on the PHP2Shell flaws explains why they can’t wait.

How do you fix the 500 internal server error in WordPress?

A 500 error says the server failed, not why. Read the host’s error log and identify the last change first. On Apache, a broken .htaccess file is one candidate; preserve a copy before testing a replacement. Nginx does not use that file. Use the log to decide whether to investigate a plugin, PHP memory or damaged core files, rather than applying every fix in sequence.

1. Check .htaccess. On Apache servers, rename .htaccess to .htaccess_old and reload. If the site works, go to Settings, Permalinks and click Save to write a fresh file. Hosts running nginx don’t use .htaccess, so skip this step there.
2. Read the server error log. Most hosts show it in the control panel. The log usually names the file and line that failed, which turns guesswork into a diagnosis.
3. Deactivate plugins. Rename the plugins folder as described above, then reactivate one by one.
4. Check memory. If the log mentions memory, see the memory section below.
5. Replace core files. Take a backup first. Check which version you run (it’s in wp-includes/version.php), download that same version from the WordPress.org release archive, and upload its wp-admin and wp-includes folders over yours. A different version can break things in new ways. If your host gives you WP-CLI, wp core verify-checksums lists which core files were changed before you replace anything. Never overwrite wp-content or wp-config.php, which hold your themes, plugins, uploads and settings.

How do you fix “Error establishing a database connection”?

To fix “Error establishing a database connection”, check that the database name, username, password and host in wp-config.php match what your hosting account shows. If they match, the database server itself may be down or overloaded, and that’s a job for your host. This error appears often straight after a migration or a password change.

WordPress’s documentation says this error is usually caused by a mistake in wp-config.php. In practice I look at what changed first. A site that worked yesterday and fails today after a hosting move usually has the old database host or password in its config. If nothing changed on your side, ask the host whether the database server is down or the account has hit a resource limit.

Why do WordPress posts return a 404 error?

If a post returns 404, first confirm the intended URL, slug and publication status. Missing content, changed slugs and routing rules can all produce the symptom. If the homepage works and many existing posts broke after a move or update, re-saving Settings, Permalinks can rebuild WordPress rewrite rules. If that fails, ask the host to inspect the relevant server routing configuration; do not redirect every missing page to the homepage.

Not every broken URL announces itself with a 404. When a redirect rule is ignored, I check what WordPress resolves before adding another rule. An attachment with a slug such as “contact” can claim the address, and an SEO plugin may send that attachment page to the homepage first. Search the Media Library for a matching slug and inspect that route. A page returning 200 in the wrong place is still a broken journey.

How do you fix the WordPress memory exhausted error?

To fix the WordPress memory exhausted error, raise the memory WordPress asks PHP for by adding define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php. That only works up to the limit your host allows, so if the error stays, ask your host to raise PHP’s memory_limit. Then find out what is using the memory, because raising the limit treats the symptom.

By default, WordPress tries to allocate 40MB of PHP memory on a single site and 64MB on multisite. Two corrections to advice that still circulates, including in an earlier version of this article:

• The PHP setting is memory_limit, written as memory_limit = 256M in php.ini. A line such as memory=64MB does nothing.
• Memory isn’t the same as the upload limit. If large files won’t upload, the settings to raise are upload_max_filesize and post_max_size, usually through your host.

If one plugin keeps running out of memory, it is usually doing too much on every request. My guide to how many WordPress plugins is too many covers how to find the heavy ones.

What are the common WordPress theme customisation errors?

The common WordPress theme customisation errors are a “missing stylesheet” message when uploading a theme, a homepage that doesn’t match the theme demo, a menu that doesn’t appear, and sliders or tabs that stop working. Each one usually comes down to the wrong file being uploaded, a missing setting or required plugin, or an old cached file.

• “The package could not be installed. The theme is missing the style.css stylesheet.” You uploaded the whole download, which often contains documentation and the actual theme zip. Unzip it and upload only the theme’s own zip file.
• The homepage doesn’t look like the demo. In Settings, Reading, set a static page as your homepage. Demos also rely on demo content and the theme’s own templates, so import the demo content or rebuild the layout. In block themes, the homepage layout lives in the Site Editor under Appearance, Editor.
• The menu doesn’t show. In classic themes, assign the menu to a location under Appearance, Menus. In block themes, menus are Navigation blocks edited in the Site Editor.
• Sliders, tabs or accordions stop working. Check the theme’s required plugins are installed, clear every cache (plugin, host and browser), then look for a JavaScript error in the browser console.

Why does the same WordPress error keep coming back?

The same WordPress error keeps coming back when the fix treated the symptom and not the cause: memory raised instead of the heavy plugin replaced, a site restored without finding out what broke it, or updates applied on the live site with no testing. Recurring errors are a maintenance problem, and they usually cost more than the maintenance would have.

An online education business my team works with was losing subscribers and revenue because its site kept going down at weekends. The cause turned out to be a redirect problem on the website itself. Once my team diagnosed and fixed it, the weekend outages stopped. The expensive part wasn’t the fix. It was the lost weekends before it.

Plugins deserve most of your attention. Patchstack’s State of WordPress Security in 2026 found that 91% of the 11,334 new WordPress vulnerabilities reported in 2025 were in plugins, and only 6 were in WordPress core. The report concerns reported security vulnerabilities, not a measured share of every WordPress outage. A backup you have tested and a routine of WordPress maintenance with updates tested on staging can reduce recovery work, though neither removes every failure risk.

What to do next

1. Check that your WordPress admin email goes to a monitored inbox, so recovery mode emails reach someone.
2. Open Tools, then Site Health, and note your PHP version and any critical issues.
3. Make sure you have SFTP or file manager access and a recent, tested backup before you need either.
4. Plan the move to PHP 8.3 or newer before 31 December 2026, tested on a staging copy.
5. If an error keeps coming back, see how my team handles website support and maintenance, or book a free call.

Frequently asked questions

What causes most WordPress errors?

Most WordPress errors come from plugins and themes, especially after an update or a PHP upgrade, followed by server settings such as memory limits and rewrite rules, and wrong database details after a move. The fastest diagnosis is to ask what changed last, then read the error log rather than guessing.

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

A white screen is a symptom, not a diagnosis. A fatal PHP error is one possible cause, but WordPress’s common errors documentation also identifies database errors. Check the server or PHP error log and the timing of the failure before applying a fix.

Should I turn on WP_DEBUG on a live site?

Not with errors displayed. WordPress’s documentation recommends against using debug tools on live sites, because error messages can reveal file paths and other details. If you must diagnose on a live site, log errors to a file with display switched off, then turn debugging off as soon as you have the message.

Can a WordPress update break my site?

Yes, although core updates rarely do on their own. Breakages usually come from a plugin or theme that isn’t compatible with the new WordPress or PHP version. Take a backup before updating, update on a staging copy first for any site that earns money, and keep the old versions available so you can roll back quickly.

When should I call a developer?

Call a developer when you don’t have file or database access, when the error log points to custom code, when the site takes orders or bookings and every hour offline costs money, or when the same error keeps returning. A developer should fix the cause and tell you what it was, not just get the site back up.