Common WordPress Errors and How to Fix Them (Without Panic)

A large share of my inbox is WordPress errors. Not exotic ones – the same ten problems, over and over: a white screen where the site used to be, “error establishing a database connection”, a 500 error after an update, a wall of 404s after a migration, a padlock that will not turn green. After 12+ years and more than 500 WordPress projects, I can tell you the most reassuring thing about these errors: they are boring. The same causes produce the same symptoms, the fixes are well understood, and in most cases the site is back within the hour – often within minutes.

The panic comes from not knowing that. When your site disappears and you have a launch, a campaign or simply customers arriving, a blank screen feels like data loss. It almost never is. This guide walks through the errors I fix most, in the order a careful non-developer can safely attempt them: what to do before touching anything, how to actually see the error instead of guessing, the fix for each common failure, when the problem is your host and not you, and – just as important – the point where you should stop and hand the problem to a professional. Keep it bookmarked for the bad morning; that is what it is for.

Table of contents

• Before you fix anything: backup, recovery mode, and seeing the real error
• The white screen of death: find the culprit by bisection
• Error establishing a database connection
• 500 internal server error
• “There has been a critical error” and recovery mode emails
• 404 errors after a migration: the permalink flush
• Mixed content warnings after moving to SSL
• Memory exhausted, stuck maintenance mode and failing updates
• When it is the host, not you
• The escalation rule: what to try and what to leave alone
• Prevention: how sites stop breaking
• Frequently asked questions

Before you fix anything: backup, recovery mode, and seeing the real error

Every bad outcome I have been called in to rescue – the broken site that became a lost site – happened because someone started changing things at random while stressed. So the first aid routine matters more than any individual fix. It has three parts, and they come before everything else in this guide.

• Take a backup, even of the broken site. A broken site still contains your content, your orders, your settings. Before you change a single file, back up both the files and the database – from your hosting control panel (most have a one-click backup or a file manager plus phpMyAdmin export), or confirm that last night’s automatic backup actually exists and is downloadable. A broken site can always get worse; a backed-up broken site cannot get much worse. If you have never set this up, my WordPress backup and disaster recovery guide covers it properly – read it on a calm day, not today.
• Check your email for a recovery mode link. Since version 5.2, WordPress detects fatal errors and emails the site admin a special login link. That email names the plugin or theme that caused the crash and the link lets you into the dashboard with the broken component paused, even when the normal login shows the error too. It is the single most useful thing WordPress does for you in a crisis, and half the site owners I work with did not know to look for it. Search your inbox for “Your Site is Experiencing a Technical Issue”. The link expires after a day or so, but a new fatal error triggers a new email.
• See the actual error before guessing. A blank screen is not information; the error text underneath it is. There are three places to look. First, the hosting error log: almost every control panel has an “Errors” or “Logs” section showing the most recent PHP errors with file names and line numbers – that line usually names the guilty plugin directly. Second, WordPress debug mode: add these lines to wp-config.php (via the hosting file manager or FTP), above the line that says stop editing:
  define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
  Errors are then written to wp-content/debug.log where you can read them without showing them to visitors. Third, the recovery mode email itself, which quotes the error. Turn debug mode off again when you are done.

With a backup taken and the real error in front of you, most of the fixes below take minutes. Without those two things, the same fixes are gambling.

The white screen of death: find the culprit by bisection

The famous one: the site (or just the admin) is a blank white page, no message, nothing. The cause is almost always a PHP fatal error – one plugin, the theme, or a PHP version mismatch – with error display switched off, so you see nothing instead of the message. On modern WordPress you will often get the “critical error” screen instead, but plenty of hosts and configurations still produce pure white.

The fix is a process of elimination called bisection, and it is the most useful troubleshooting skill a site owner can learn:

1. Check the error log first. If the log names the plugin, you can skip the search: deactivate that one plugin and you are done. Bisection is for when you cannot see a log.
2. Deactivate all plugins at once. If you can reach the dashboard (via recovery mode), do it there. If you cannot, connect with the hosting file manager or FTP and rename the folder wp-content/plugins to plugins-off. WordPress silently deactivates everything it can no longer find. If the site comes back, a plugin is guilty.
3. Halve your way to the culprit. Rename the folder back, then deactivate half the plugins. Site works? The culprit is in the deactivated half. Site broken? It is in the active half. Repeat, halving each time. Even with 30 plugins this takes five rounds, not thirty – a few minutes of clicking.
4. If plugins are innocent, test the theme. Rename your theme’s folder inside wp-content/themes; WordPress falls back to a default theme like Twenty Twenty-Four (if one is installed – most sites have one). Site back? The theme, or something in its functions.php, is the problem – often an edit someone made recently.
5. Fix the culprit properly. Usually that means updating it (the crash often comes from an old plugin meeting a new PHP version), replacing it, or rolling back a recent update. Reactivate everything else and confirm the site is healthy.

A note from experience: the white screen appears “out of nowhere” far less often than people think. In nine cases out of ten, something happened in the previous 24 hours – an auto-update, a PHP version change by the host, an edit to the theme. Ask yourself “what changed?” before you ask “what is broken?”.

Error establishing a database connection

This message means exactly what it says: WordPress (the PHP files) could not talk to MySQL (the database where all your content lives). It sounds catastrophic and is usually trivial. There are only three broad causes, and you can check them in order:

• Wrong credentials. The database name, username, password and host are defined in wp-config.php. If anything changed them – a migration, a hosting panel password reset, a move to a new server – the connection fails. Compare the four DB_ lines in wp-config.php against what your hosting panel says the database credentials are. After migrations this is the number one cause; a copied site pointing at the old server’s database host is a classic. Note that DB_HOST is not always localhost – some hosts use a specific address, and they list it in the panel.
• The database server is down or overloaded. If the credentials are right and unchanged, and especially if the error comes and goes, the MySQL server itself is struggling – common on cheap shared hosting under load, or during host maintenance. Check the hosting status page and open a support ticket. This one is not yours to fix; more on host-side errors below.
• Corrupt tables. Rarer, usually after a server crash mid-write. The tell: the front end shows the database error but wp-admin shows “one or more database tables are unavailable”. WordPress has a built-in repair tool: add define( 'WP_ALLOW_REPAIR', true ); to wp-config.php, visit /wp-admin/maint/repair.php, run the repair, and then remove that line immediately – the repair page needs no login, so leaving it enabled is a security hole.

What not to do: reinstall WordPress, restore a week-old backup as a first move, or start editing credentials at random. The database is where your content is; be conservative with it. If the three checks above do not resolve it, this is a good early escalation.

500 internal server error

A 500 is the server saying “something went wrong and I will not tell you what” – it is the least informative error on the web, which is why the error log matters so much here. On WordPress sites the usual suspects, in order of frequency:

• A corrupt or over-clever .htaccess file. The .htaccess file in your site root controls URL rewriting, and plugins (security, caching, redirect plugins) love writing to it. One malformed line takes down the whole site. The test is safe and quick: rename .htaccess to .htaccess-old and reload the site. If it comes back, log in and go to Settings > Permalinks and press Save – WordPress writes a fresh, clean file. Then re-add anything you know was intentional, one block at a time.
• PHP memory exhausted. If the log mentions “allowed memory size exhausted”, jump to the memory fix below.
• PHP version mismatch. Hosts upgrade PHP, sometimes automatically. Old plugin or theme code that ran fine on PHP 7.4 can fatal on modern PHP 8 versions. The log will show the error type; the fix is updating the offending code or, as a temporary measure, selecting a slightly older PHP version in the hosting panel while you update things properly. Treat that downgrade as a bandage, not a solution – old PHP is slower and eventually unsupported.
• A broken plugin doing something at server level – the same bisection routine from the white screen section applies.

One subtlety worth knowing: a 500 that appears only on specific actions – saving a large post, running an import, loading a huge page – while the rest of the site works is usually a limit (memory, execution time, upload size) rather than broken code. Limits are raised in the hosting panel or php.ini, and your host’s support can do it in minutes if you cannot see the setting.

“There has been a critical error” and recovery mode emails

Modern WordPress replaced many white screens with a politer message: “There has been a critical error on this website.” Behind that sentence, the mechanics are the same – a PHP fatal error – but WordPress now does two helpful things: it shows visitors the calm message instead of raw errors, and it emails the admin address a report with the error details and a recovery mode link.

Treat that email as your map. It typically tells you:

• What crashed: “an error of type E_ERROR was caused in plugin X” or “in the theme Y” – which is exactly the answer bisection would have taken twenty minutes to find.
• Where: the file path and line number, which is what a developer needs if you forward the email – please do forward it rather than paraphrasing; the exact text saves a whole diagnostic round.
• How to get in: the recovery mode link opens your dashboard with the broken component paused. From there, deactivate or update the named plugin, switch the theme if the theme is named, and exit recovery mode.

Two gotchas. First, the email goes to the admin address configured under Settings > General – on many sites that is an old address nobody reads, or the developer who built the site years ago. Check today whose inbox it is, and change it if needed. Second, if the named plugin is something essential – the store, the booking system – do not just leave it deactivated and walk away; the site is “up” but the business is not. Deactivating is triage. The follow-up (update, rollback or replacement) is the actual fix, and it should happen the same day.

404 errors after a migration: the permalink flush

The pattern: the site moved – new host, new domain, or restored from backup – and the homepage works, but every other page and post is a 404. Nothing is lost, and this is the single easiest fix in this whole guide. The content is in the database; what is missing is the rewrite rules that translate pretty URLs like /about/ into database queries.

• The fix: log in to wp-admin (which works, because it does not use pretty permalinks), go to Settings > Permalinks, change nothing, and press Save. That one click regenerates the rewrite rules and, on Apache servers, rewrites .htaccess. In most migrations the 404s vanish immediately. The habit is worth internalising: permalink flush is the first move for any widespread-404 situation.
• If the flush does not stick: on Apache, WordPress may lack permission to write .htaccess – the permalinks screen will show you the rules to paste in manually via the file manager. On nginx there is no .htaccess at all; the rewrite rules live in the server configuration, and on a new server that block may simply be missing. That is a two-line fix for the host’s support or your developer, not something to attempt from a tutorial if you have never touched nginx config.
• If only some URLs 404: that is a different problem – usually a changed permalink structure (the old URLs genuinely no longer exist and need redirects) or a custom post type that was registered by a plugin which is not active on the new site. Check the plugin list against the old site before hunting deeper.

Migrations cause a second classic error too – mixed content – which gets its own section next, because it also appears on sites that never moved anywhere but switched to HTTPS.

Mixed content warnings after moving to SSL

You installed the SSL certificate, the site answers on https://, and yet the browser shows “not secure”, a broken padlock, or images and styles fail to load. This is mixed content: the page itself is secure, but some resources on it – images, stylesheets, scripts – are still being requested over plain http://, and browsers block or flag them.

The causes are layered, so fix them in this order:

1. The WordPress address settings. Settings > General has two URL fields – WordPress Address and Site Address. Both must say https://. If they still say http://, everything WordPress generates keeps pointing at the insecure version.
2. Old URLs stored in content. Every image you ever inserted was saved into the post content with its full URL – the http:// one. Those thousands of stored links need a search-and-replace: the free Better Search Replace plugin does it (search http://yourdomain.com, replace https://yourdomain.com), and it has a dry-run mode – always run the dry run first, and always with a fresh database backup. WP-CLI users do the same with wp search-replace.
3. Hardcoded URLs in the theme or widgets. A logo or script URL typed into a theme option, customiser field or widget does not live in post content and survives the search-replace tools that only touch posts (Better Search Replace covers all tables, which is why I recommend it). The browser console (right-click, Inspect, Console tab) lists every blocked resource with its exact URL – that list is your remaining to-do.
4. Redirect http to https. Once the content is clean, add a site-wide redirect so old links and bookmarks land on the secure version. Many hosts have a toggle for this; otherwise it is a standard .htaccess rule your host’s support will happily provide.

What I advise against: “SSL fixer” plugins that rewrite URLs on the fly on every page load, forever. They are fine as a same-day bandage, but they hide the problem rather than fixing it and add work to every request. The search-replace approach fixes the data once and you are done.

Memory exhausted, stuck maintenance mode and failing updates

Three smaller errors that generate a lot of panic mail, each with a two-minute fix:

• “Allowed memory size exhausted”. PHP hit its memory ceiling – common on shared hosting with a heavy page builder, a big import, or an image-heavy WooCommerce site. First aid: raise the WordPress limit by adding define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php. If the error persists, the server-level PHP limit is lower than that – raise memory_limit in the hosting panel’s PHP settings, or ask support. If a site needs more than 256M for normal pages, that is not a limit problem, it is a “something is wasteful” problem worth a developer’s look.
• Stuck in “Briefly unavailable for scheduled maintenance”. During updates WordPress creates a hidden file called .maintenance in the site root and deletes it when done. If the update is interrupted – timeout, connection drop, you closed the tab – the file stays and the site shows the maintenance message forever. The fix really is this small: open the file manager or FTP, show hidden files, delete .maintenance. Then check whether the interrupted update actually completed and re-run it if not.
• Updates failing repeatedly. Usually one of three things. Disk space: a full hosting account has no room to unpack update zips – check usage in the panel, clear old backups stored on the server. File permissions or ownership: WordPress cannot write to its own folders, often after a manual migration – the error mentions “could not create directory”; your host can reset ownership in one command. Timeouts: slow shared servers give up mid-download – try updating one plugin at a time rather than fifteen at once, and update at a quiet time of day.

Here is the cheat sheet version of this whole guide – the errors, their usual causes, the first fix to try, and the moment to stop:

When it is the host, not you

A meaningful share of “WordPress errors” have nothing to do with WordPress. Before you spend an evening bisecting plugins, check the signs that the problem is on the hosting side:

• Errors that come and go on their own. A site that shows a database error at 9pm and is fine at 9:15 did not fix itself – a shared database server was overloaded and recovered. Intermittent is the host’s signature; your configuration does not change by itself.
• 503 errors or “resource limit reached” pages. Shared hosts cap CPU seconds, concurrent PHP processes and database connections. Hit the cap – a traffic spike, a bot crawl, a heavy plugin – and the host serves errors until usage drops. The panel usually has a resource usage graph; if the errors line up with the peaks, that is your answer.
• Everything broke at once with no change on your side. If you updated nothing and touched nothing, and the site broke overnight, suspect a host-side change: an automatic PHP version bump, a server migration, a security module (mod_security) new rule blocking legitimate requests. Ask support directly: “did anything change on the server for my account in the last 48 hours?” – a specific question gets a real answer where “my site is broken” gets a canned reply.
• Slow everything, always. Not an error exactly, but chronic slowness on a busy shared server produces timeouts that look like random errors. If your site has outgrown its hosting, no amount of plugin fixing changes the arithmetic.

When you contact support, send evidence: the exact error text, the time it happened, the error log lines, what you already ruled out. It moves you past the first-line script instantly. And if a host repeatedly causes incidents and blames your site without evidence, that pattern is itself diagnostic – the cheapest hosting is rarely cheap once you price your own panic hours.

The escalation rule: what to try and what to leave alone

Everything in this guide so far is safe for a careful non-developer: reading logs, renaming folders, resaving permalinks, deleting a .maintenance file, adding a documented line to wp-config.php. Each step is reversible and none touches your content. But there is a boundary, and knowing it is worth more than any individual fix.

• Safe to try yourself: everything above – backup, recovery mode, log reading, plugin bisection, theme fallback, permalink flush, fresh .htaccess, memory limit, search-replace with a dry run and a backup, deleting .maintenance.
• Leave to a professional: editing PHP inside plugins or themes (beyond the config lines shown here), any direct database surgery in phpMyAdmin beyond the built-in repair tool, server configuration (nginx rules, PHP compilation settings), and anything on a site you do not have a current backup of. The cost of a mistake in these areas is not “still broken” – it is “differently and worse broken”.
• Escalate immediately, do not troubleshoot: any sign of hacking – unfamiliar admin users, spam pages in Google results, redirects to other sites, security plugin warnings about changed core files. A hacked site is not an error, it is an incident, and the cleanup discipline is different; I wrote up the full process in my step-by-step hacked site recovery guide. Fixing symptoms on a compromised site just alerts the attacker.

My practical rule for site owners: give yourself 30 focused minutes with this guide and the error log. If the site is not up by then, or if you find yourself about to try something not on the safe list, stop and get help – the state you preserve by stopping is exactly what makes the professional fix fast. For context on cost: diagnosing and fixing a typical single-cause error is one to two hours of developer time – at my rate of EUR 15 per hour, that is a very cheap alternative to an afternoon of stressed experimentation, and I have rebuilt more than one site where the experimentation cost far more than the original error would have.

Prevention: how sites stop breaking

Here is the pattern behind almost every emergency in my inbox: the error was the last link in a chain. An unmaintained site, updates applied all at once after months of neglect (or never), no staging, no tested backup, PHP three versions behind – and then one Tuesday the chain snaps. Sites that break rarely share a short list of habits:

• Updates little and often, not in batches. Ten pending updates applied together means ten suspects when something breaks. Weekly small updates mean one suspect, and the “what changed?” question answers itself.
• A staging copy for anything risky. Major plugin versions, PHP version bumps, theme changes – test on a copy first. Most managed hosts include one-click staging; even a cheap subdomain copy beats testing on the live site.
• Backups that restore, not just run. A backup you have never restored is a hope, not a backup. Once a quarter, prove the restore works.
• Current PHP. Staying within the supported PHP versions, and testing the bump on staging, prevents the largest class of “sudden” fatal errors.
• Fewer, better plugins. Every plugin is a future update and a future suspect. An annual cull of overlapping and abandoned plugins shrinks the surface where errors happen.
• Someone actually watching. Uptime monitoring (free tiers are fine) tells you the site is down before a customer does, and a monthly review catches the “orange flags” – a plugin abandoned by its author, disk filling up, error log noise – before they become red ones.

All of this fits in a modest routine; I published the exact rhythm I use for client sites as a daily, weekly and monthly maintenance checklist. The sites on that routine are, not coincidentally, the ones whose owners have never needed the rest of this article.

Want the errors handled for you?

I fix broken WordPress sites and, more usefully, keep them from breaking: my WordPress maintenance and security plans cover updates, tested backups, monitoring and priority error fixing – so the bad morning becomes my job, not yours. Have a look at the portfolio, or describe your error via the contact page – include the exact message and what changed recently, and I reply within 24 hours, usually much faster.

Frequently asked questions

What are the most common WordPress errors?

The white screen of death, “error establishing a database connection”, 500 internal server errors, the “critical error” message, 404s after a migration, mixed content warnings after SSL, memory exhausted errors and a site stuck in maintenance mode. Nearly all trace back to a plugin or theme conflict, a configuration line or a hosting limit.

How do I fix the WordPress white screen of death?

Check your email for the recovery mode link, read the hosting error log, and if needed deactivate all plugins by renaming the plugins folder, then reactivate in halves until the culprit shows itself. It is almost always one plugin or theme hitting a PHP error.

What causes “error establishing a database connection”?

Wrong database credentials in wp-config.php (especially after a migration), an overloaded or down database server at your host, or – rarely – corrupt tables, which WordPress’s built-in repair tool fixes.

Is it safe to fix WordPress errors myself?

The fixes in this guide – log reading, plugin bisection, permalink flush, documented wp-config lines – are safe if you back up first and change one thing at a time. Editing plugin code, database surgery and server configuration are not; hand those over.

How do I see what a WordPress error actually is?

Three places: the hosting control panel’s error log, the recovery mode email WordPress sends the admin address, and WordPress debug logging enabled via WP_DEBUG_LOG in wp-config.php, which writes errors to wp-content/debug.log.

What is WordPress recovery mode?

Since WordPress 5.2, fatal errors trigger an email to the site admin with the error details and a special login link that opens the dashboard with the broken plugin or theme paused, so you can deactivate or update it even when normal login fails.

When should I call a developer instead of fixing it myself?

After 30 focused minutes without progress, whenever the fix would mean editing code or the database directly, and immediately if you see signs of hacking. Preserving the site’s current state and the exact error text makes the professional fix faster and cheaper.