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 10 most common 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 — 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 — 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 — 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.

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” — 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.

Note on Nginx: Nginx doesn’t read .htaccess — 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 — 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 yes, 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!', '[email protected]' );
        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, not the cause.

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.

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. Most WordPress error diagnosis can be done remotely with server log access — usually resolved in one session.