Common WordPress Errors and How to Fix Them

WordPress errors divide into two categories: errors with a visible message (500, 404, database connection, redirect loops) and errors with no visible output at all (white screen of death). The diagnostic approach is the same in both cases: enable debug logging first, then isolate variables methodically. This guide covers the 15 most common errors, from the white screen of death to 502s, memory limit errors and PHP syntax errors, with specific diagnosis steps and the fix sequence that actually works.

Enable debug mode before anything else

Before diagnosing any WordPress error, add this to wp-config.php (above the “stop editing” line):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

This captures all PHP errors and warnings to wp-content/debug.log without displaying them to visitors. Most errors name the specific plugin file or line number causing the problem, and that alone resolves half the diagnostic work. Remove these lines after fixing the issue.

1. White screen of death (WSOD)

A blank white page with no error message is a PHP fatal error where PHP died before it could output anything. The three most common causes: PHP memory exhaustion, a syntax error in a plugin or theme file, or a plugin update that introduced a PHP compatibility issue.

Diagnose: check wp-content/debug.log after enabling WP_DEBUG. If the log is empty or the file doesn’t exist, PHP ran out of memory before it could write, so check your hosting control panel’s error log directly.

Fix sequence:

1. Increase PHP memory in wp-config.php: define( 'WP_MEMORY_LIMIT', '256M' );
2. If memory isn’t the cause: rename /wp-content/plugins/ to /wp-content/plugins-disabled/ via FTP. If the site loads, a plugin is responsible. Rename the folder back to plugins, then activate plugins one at a time until the blank screen returns.
3. If plugins aren’t the cause: rename your active theme folder in /wp-content/themes/. WordPress falls back to a default theme automatically.

For a full walkthrough including PHP version mismatches and multisite-specific WSOD causes, see the dedicated WordPress white screen of death guide.

2. Error establishing a database connection

WordPress can’t reach MySQL. This has three distinct causes, and which one applies changes the fix entirely.

Diagnose first: try accessing /wp-admin/ directly. If wp-admin also fails with the same error, the database credentials in wp-config.php are wrong or the database server is down. If only the frontend fails, you likely have table corruption.

Fix by cause:

• Wrong credentials: open wp-config.php and verify DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST match what your hosting panel shows. DB_HOST is usually localhost but some hosts require a specific value.
• Database server down: check your hosting panel for server status or MySQL service alerts. This is a hosting-side issue, so contact support.
• Corrupted tables: add define( 'WP_ALLOW_REPAIR', true ); to wp-config.php, visit /wp-admin/maint/repair.php, run the repair, then remove that line immediately.

If none of those three causes fits, my database connection error guide covers the less common ones, such as a full disk or a MySQL user that lost its privileges after a migration.

3. 500 Internal Server Error

A 500 is a server-side error with no specifics: it could be .htaccess, PHP memory, or a plugin conflict. The fix sequence isolates which.

Step 1: .htaccess. rename .htaccess to .htaccess_old in your site root via FTP. Reload the site. If it works, go to Settings > Permalinks and click “Save Changes”, and WordPress regenerates a clean .htaccess.

Step 2: plugins. rename /wp-content/plugins/ to /wp-content/plugins-disabled/. If the site loads, reactivate plugins individually.

Step 3: memory. add define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php.

Step 4: core files. If the error survives all three steps, a core file may be corrupted. Download a fresh copy of WordPress from wordpress.org and replace the wp-admin and wp-includes folders on the server. Leave wp-content and wp-config.php alone. The longer version of this sequence is in my 500 Internal Server Error fix guide.

Note on Nginx: Nginx doesn’t read .htaccess, so 500 errors on Nginx are almost always PHP errors. Check the PHP-FPM log (usually in /var/log/php-fpm/) and your Nginx error log.

4. 404 errors on posts and pages

The homepage loads but individual posts return 404. This is almost always a permalink rewrite rule problem: the rules are either missing from .htaccess or haven’t been flushed after a server migration.

Fix: go to Settings > Permalinks in wp-admin and click “Save Changes” without changing anything. WordPress rewrites .htaccess with fresh rewrite rules.

Apache prerequisite: mod_rewrite must be enabled (a2enmod rewrite) and your Apache config must have AllowOverride All for the site directory. Without that, .htaccess rules are silently ignored.

Nginx: doesn’t use .htaccess, so it requires try_files $uri $uri/ /index.php?$args; in the server block. If you’ve migrated from Apache to Nginx, this is the most likely cause of site-wide 404s.

5. WordPress stuck in maintenance mode

“Briefly unavailable for scheduled maintenance”: WordPress creates a .maintenance file in the site root at the start of every update and deletes it when the update completes. If the update was interrupted mid-process, the file stays and the site stays in maintenance mode indefinitely.

Fix: delete the .maintenance file from your site root via FTP or your hosting file manager. The file is in the same directory as wp-config.php.

For cases where the update itself failed and left WordPress in a partially updated state, the WordPress maintenance mode fix guide covers the recovery steps for broken core updates.

6. Too many redirects

“This page isn’t redirecting properly” means WordPress is sending a browser into a redirect loop. The most common cause: the siteurl and home values in the wp_options database table are mismatched. Typically one is http:// and the other is https://, or one has a trailing slash and the other doesn’t.

Fix: add these lines to wp-config.php temporarily to override the database values and regain access:

define( 'WP_HOME', 'https://yoursite.com' );
define( 'WP_SITEURL', 'https://yoursite.com' );

Once the site loads, go to Settings > General and confirm the URL values, then remove those lines from wp-config.php. If an SSL plugin (Really Simple SSL, etc.) is involved, check that it isn’t adding a redirect on top of an existing server-level HTTPS redirect.

7. Locked out of wp-admin

Three distinct causes, easiest-first fix order:

Security plugin blocking your IP: the most common cause of sudden lockouts after you’ve been logging in fine. Wordfence and similar plugins block IPs after repeated failed login attempts. Check if someone else can log in. If they can, it’s an IP block. Wait for the lockout to expire, or disable the plugin temporarily via FTP by renaming its folder.

Forgotten password: the “Lost your password?” link on the login screen sends a reset email. If email isn’t working, use WP-CLI: wp user update yourusername --user_pass=newpassword.

Admin account corruption: create a new admin user by adding this to functions.php temporarily, loading any page, then removing it immediately:

add_action( 'init', function() {
    if ( ! username_exists( 'tempAdmin' ) ) {
        $user_id = wp_create_user( 'tempAdmin', 'StrongPass123!', 'temp@yoursite.com' );
        wp_update_user( [ 'ID' => $user_id, 'role' => 'administrator' ] );
    }
} );

8. Plugin or theme conflict after update

A plugin update introduces a PHP error, a JavaScript conflict, or a breaking API change that affects another plugin. The challenge is that the error message (if visible) often points to the symptom. The cause is usually somewhere else.

Diagnose: enable WP_DEBUG and check debug.log. The log will name the specific file and line, usually pointing directly to the updated plugin or a dependency conflict between two plugins.

Fix sequence:

1. Deactivate the recently updated plugin from wp-admin. If you can’t access wp-admin, rename the plugin folder via FTP.
2. Use the plugin conflict isolation guide to identify which plugin is at fault when multiple updates happened simultaneously.
3. Install WP Rollback (free, WordPress.org) to revert the plugin to its previous version while waiting for a fix from the developer.

Before pushing any plugin updates to a live site, test them on a staging environment first. See the guide to setting up a WordPress staging site. A conflict that would take an hour to recover from on production takes five minutes on staging.

9. Changes not showing (cache)

You’ve updated something and the site looks the same. The fix depends on which cache layer is holding the stale version:

• Browser cache: Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (Mac) hard-refreshes without the cache.
• WordPress cache plugin: clear via the plugin’s dashboard. WP Rocket, LiteSpeed Cache, and W3 Total Cache all have a “Clear Cache” button in the admin bar.
• CDN cache (Cloudflare, etc.): purge from the CDN dashboard. Cloudflare’s free plan has a “Purge Everything” option under Caching.
• Server-level cache (Redis, Memcached): flush via hosting panel or WP-CLI: wp cache flush.

If you’re unsure which caching plugin is in use or how they layer together, the WP Rocket vs W3 Total Cache vs LiteSpeed Cache comparison explains the architecture of each.

10. Image upload HTTP error

The WordPress media uploader returns “HTTP error” mid-upload. Most common causes:

• PHP memory limit: large image files require memory to process. Increase memory_limit in php.ini or add php_value memory_limit 256M to .htaccess.
• Upload file size limit: upload_max_filesize and post_max_size in php.ini set the cap. On managed hosts, these are often configurable from the hosting panel.
• Wrong file permissions: the wp-content/uploads/ directory needs to be writable (755 is standard). Check via FTP file manager.
• GD or Imagick not installed: WordPress uses one of these PHP extensions to process images. If neither is installed, the media uploader fails on upload. Confirm via Tools > Site Health > Info > Media Handling.

One quick thing to try before any of these: rename the file. Apostrophes, semicolons and other special characters in a file name can make the upload fail, and a plain name like team-photo.jpg often goes straight through.

11. Missing stylesheet error when installing a theme

The “The package could not be installed. The theme is missing the style.css stylesheet” error means WordPress can’t find a valid style.css file at the top level of the theme you uploaded. It usually happens when the ZIP has an extra folder level, or when you upload the full vendor download instead of the installable theme ZIP inside it.

Every WordPress theme needs a style.css file with a header comment in its root folder. That is how WordPress recognises it as a theme (see the Theme Handbook on style.css).

Fix sequence:

1. Unzip the download on your computer and look for style.css. If it sits one folder deeper, or the package contains documentation plus a second ZIP, the inner ZIP is the one to upload.
2. Install through Appearance > Themes > Add New > Upload Theme. The uploader puts the files in the right directory for you.
3. If you upload by FTP instead, the theme folder must sit directly inside /wp-content/themes/, with style.css at the top of that folder.

12. 502 Bad Gateway

A 502 Bad Gateway means a server in front of your site, such as a CDN, firewall or reverse proxy, asked your web server for the page and got an invalid response back. On WordPress hosting, the origin server is usually overloaded, timing out on a slow PHP request, or restarting.

A 502 that clears after a minute is often just a server restart. One that keeps coming back points to a real problem, and I work through it in this order:

1. Reload the page after a minute and hard-refresh to rule out a cached error page.
2. Pause your CDN or firewall (in Cloudflare, “Pause Cloudflare on Site” on the Overview screen) and load the site directly. If it works, the problem is in the CDN settings or in how the CDN reaches your server.
3. If you recently changed DNS or moved hosts, check that the DNS records point at the new server.
4. Check debug.log and your host’s PHP error log. A plugin running a heavy import or waiting on a slow external API can tie up every PHP worker, and the proxy gives up waiting.
5. If the site still fails with the CDN off and the logs are clean, contact your host. The PHP service or server resources are on their side.

13. Allowed memory size exhausted (memory limit error)

The “Allowed memory size of X bytes exhausted” error means a PHP process needed more memory than your limit allows, so WordPress stopped mid-task. Media uploads, plugin installs, page builder edits and large imports are where it shows up most. Raising WP_MEMORY_LIMIT in wp-config.php fixes it, as long as your host’s PHP limit allows the higher value.

Add this to wp-config.php:

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

Then check Tools > Site Health > Info > Server to see the PHP memory limit actually in effect. WP_MEMORY_LIMIT can’t go above the server’s PHP memory_limit. If your host caps PHP at 128M, you have to raise memory_limit in php.ini or the hosting panel too. The wp-config.php documentation covers both constants, including WP_MAX_MEMORY_LIMIT for admin tasks.

If you keep hitting the ceiling after raising it, a plugin is probably using far more memory than it should, or the site has outgrown its hosting plan. My guide to increasing the WordPress memory limit covers each method host by host.

14. Secure connection error (WordPress can’t reach WordPress.org)

The secure connection error appears in the dashboard when WordPress tries to contact WordPress.org for updates and the request fails. Your site keeps loading for visitors, but core, plugin and theme updates stop working. The cause is almost always on the server: blocked outbound connections, an outdated SSL setup, or DNS problems.

Tools > Site Health > Status will usually flag it as a failed connection to WordPress.org. Two things to check yourself before contacting anyone:

• Look in wp-config.php for define( 'WP_HTTP_BLOCK_EXTERNAL', true );. That constant blocks every outbound request unless the host is listed in WP_ACCESSIBLE_HOSTS, which includes update checks.
• If the error started right after you installed or changed a security or firewall plugin, deactivate it and run the update check again.

If neither applies, send your host the exact error text and ask them to confirm the server can make outbound HTTPS requests to api.wordpress.org and that cURL and OpenSSL are up to date.

15. Parse error: syntax error

A “Parse error: syntax error, unexpected…” message means PHP can’t read a file because the code in it is malformed, usually a missing semicolon, bracket or quote. It most often appears right after someone pastes a snippet into functions.php. The message names the file and line number, so you know exactly where to look.

Fix sequence:

1. Copy the file path and line number from the error message.
2. Open that file via SFTP or your hosting file manager. You can’t use the wp-admin editor here, because the error usually takes wp-admin down too.
3. Go to the line named in the error and the line just above it. The real mistake is often one line earlier than PHP reports.
4. Remove the snippet you just added, or correct the character, then save and reload the site.

Since WordPress 5.2, a fatal error in a plugin or theme often triggers an email to the site’s admin address with a recovery mode link. That link lets you log in with the broken plugin or theme paused. Check your inbox before reaching for FTP. To avoid the problem entirely, add custom code through a child theme, and test it on staging first.

Preventing recurring errors

Most recurring WordPress errors trace to three root causes: outdated plugins with PHP version incompatibilities, insufficient PHP memory for the plugin stack, or skipping staging before pushing updates to production. A maintenance routine that catches these before they become live-site incidents (scheduled plugin updates with pre-update backups, PHP version monitoring, and error log review) is covered in the complete WordPress maintenance guide.

If you’re dealing with a recurring error you can’t isolate, or if errors are appearing in a production store that needs to stay up, get in touch, or see how my WordPress bug fixing and rescue service works. Most WordPress error diagnosis can be done remotely with server log access, and it’s usually resolved in one session.