WordPress Errors: The Complete Reference Guide

WordPress errors come in dozens of forms — white screens, 500 errors, database connection failures, fatal PHP exceptions, plugin conflicts, slow loading pages, broken media libraries, and authentication lockouts. WordPress errors complete diagnostic knowledge means being able to identify which type of error is occurring, trace it to its root cause, and apply a targeted fix rather than trying fixes at random. This WordPress errors complete reference covers diagnosing and fixing WordPress errors across every category — from critical site-breaking failures to subtle configuration issues that degrade performance or accessibility over time.

WordPress Errors Complete — Critical Site-Failure Errors

WordPress errors complete investigation starts with critical errors that take the site offline. They require immediate diagnosis and resolution because every minute the site is down, visitors see failures instead of content.

White Screen of Death (WSOD) — The page loads blank with no visible error. Cause: a PHP fatal error in a plugin, theme, or WordPress core file is being suppressed by production error display settings. Fix: enable WordPress recovery mode (visit /wp-login.php → look for the recovery mode link that WordPress emails on fatal error detection) or add define('WP_DEBUG', true); to wp-config.php temporarily to surface the error. Once the error is visible, it points to the specific plugin or theme causing the failure — deactivate it, restore the default theme if the theme is the cause, and update to a version that fixes the fatal error.

Error Establishing a Database Connection — WordPress cannot connect to MySQL. Causes: incorrect database credentials in wp-config.php, MySQL service is stopped, or the database is corrupted. Fix: verify DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST in wp-config.php match the values in the hosting control panel’s MySQL section. If credentials are correct, check whether MySQL is running (hosting control panel → databases → MySQL status). If MySQL is running and credentials are correct, navigate to /wp-admin/maint/repair.php to run the built-in WordPress database repair tool.

500 Internal Server Error — The server encountered an error it cannot describe. Causes: exhausted PHP memory limit, corrupted .htaccess file, PHP errors in WordPress code. Fix path: check the server error log (cPanel → Logs → Error Log) for the specific PHP error. Increase PHP memory limit (define('WP_MEMORY_LIMIT', '256M'); in wp-config.php). Rename .htaccess to .htaccess.bak and regenerate from Settings → Permalinks → Save. Deactivate all plugins via FTP by renaming the plugins folder.

WordPress site lockout — Admin login fails or admin access is blocked. Fix paths: reset password via phpMyAdmin by updating the user_pass field with an MD5-hashed new password, create an emergency admin via FTP by adding code to functions.php, or use WP-CLI to create a new admin user. For plugin-caused admin lockouts, rename the plugins folder via FTP to deactivate all plugins, restoring admin access.

PHP and Server Configuration Errors

PHP configuration limits produce a predictable class of WordPress errors — the environment is too constrained for the operations WordPress needs to perform. Each limit has a clear error message and a direct fix.

Maximum execution time exceeded — PHP script runs longer than the configured time limit (typically 30 seconds). Common causes: complex plugin operations, slow database queries, external API timeouts. Fix: add set_time_limit(300); or @ini_set('max_execution_time', 300); to wp-config.php for a temporary increase. Investigate which operation is slow using Query Monitor — the underlying cause (slow query, slow API) should be addressed rather than continuously increasing the time limit.

Allowed memory size exhausted — PHP ran out of memory. Fix: increase the WP_MEMORY_LIMIT constant in wp-config.php. 256M covers most WordPress operations; resource-intensive plugins (page builders, WooCommerce with large catalogues, import operations) may need 512M. Check the hosting plan’s PHP memory limit — shared hosting plans often cap PHP memory at 128M or 256M regardless of wp-config.php settings.

Max input vars exceeded — Forms with many fields (large navigation menus, many widgets, WooCommerce products with many variations) silently truncate data when the form field count exceeds the PHP max_input_vars limit (default: 1000). Symptom: menu items disappear after saving, widget settings reset, product variations vanish. Fix: increase max_input_vars to 3000–5000 via cPanel MultiPHP INI Editor, .htaccess (php_value max_input_vars 5000), or php.ini.

Upload file size too large — WordPress rejects file uploads exceeding the PHP upload_max_filesize or post_max_size limits. Fix: increase both limits to at least 64M (or higher for video) via the same configuration methods as max_input_vars. WordPress displays the current limit below the media upload area — verify the increase took effect by checking this value after configuration changes.

WordPress Errors Complete — URL and Permalink Errors

URL errors in the WordPress errors complete framework affect specific pages, archives, or the entire site navigation. They usually trace back to the WordPress rewrite rule system that converts clean URLs to WordPress’s internal query parameters.

404 on category archives and post archives — Common after WordPress migration, theme change, or plugin activation. The permalink structure is correct but the rewrite rules are stale. Fix: Settings → Permalinks → Save Changes without making any other changes. This regenerates the .htaccess rewrite rules. If 404s persist after flushing, check that mod_rewrite is enabled on the server and that .htaccess has the correct WordPress rewrite rules block.

Redirect loop (ERR_TOO_MANY_REDIRECTS) — The browser gets stuck in an infinite redirect cycle. Causes: WordPress home URL and site URL set to different values causing mutual redirect, HTTP/HTTPS mismatch, Cloudflare or reverse proxy forwarding conflicts. Fix: verify Settings → General → WordPress Address and Site Address are identical. For HTTPS, ensure both use https://. For reverse proxy setups, add to wp-config.php: define('FORCE_SSL_ADMIN', true); and configure the is_ssl() function to correctly detect the proxy’s HTTPS forwarding.

Pagination 404 (page 2 returns 404) — Archive page 2+ returns 404 despite page 1 loading correctly. Cause: rewrite rules not accounting for the /page/N/ URL structure. Fix: flush permalinks. For custom WP_Query instances, ensure the paged query variable is passed: 'paged' => get_query_var('paged') ?: 1. On static front page setups, use ‘page’ (without ‘d’) rather than ‘paged’ for the blog index page.

Plugin and Theme Conflict Errors

Plugin conflicts account for a large proportion of WordPress errors complete reports in production — two plugins modifying the same WordPress functionality, a plugin incompatible with the current PHP version, or a theme and plugin both hooking the same filter with incompatible outputs.

Diagnosing plugin conflicts — A core WordPress errors complete workflow: Isolate the conflict systematically: deactivate all plugins → test if the error resolves → reactivate one plugin at a time until the error returns — the last reactivated plugin (or its interaction with the previously reactivated plugin) is the conflict source. The Health Check & Troubleshooting plugin provides an in-session safe mode that deactivates plugins only for the current logged-in admin session, allowing troubleshooting without affecting live site visitors.

JavaScript errors and broken admin interfaces — A plugin or theme that loads conflicting JavaScript causes admin interface breakage: the block editor fails to load, metaboxes do not function, or buttons do not respond. Diagnose: browser DevTools → Console → any red error messages identify the conflicting script and the specific line causing the failure. jQuery conflicts (multiple jQuery versions loading, code using jQuery 1.x APIs on jQuery 3.x) are a common cause. Fix: dequeue the conflicting jQuery version using wp_dequeue_script(‘conflicting-jquery-handle’) and ensure all scripts declare their jQuery dependency correctly.

Theme child theme issues — A child theme that incorrectly references parent theme files, or a parent theme updated with changed file names, causes PHP warnings or white screens on the front-end. Fix: verify the child theme’s style.css header contains the correct Template field matching the parent theme’s directory name. Verify all get_template_part() and require_once(get_template_directory()) calls in the child theme reference files that exist in the parent theme. After a parent theme update, check the child theme for any files that override parent files and ensure the override files remain compatible with the updated parent.

Email and Communication Errors

Email failures in the WordPress errors complete context are silent — the site generates and attempts to send emails, but they never arrive. The failure leaves no visible error on the front-end, making email delivery problems some of the hardest WordPress errors to diagnose without specifically testing email functionality.

WordPress not sending emails — the most common WordPress errors complete email issue: wp_mail() fails silently when the hosting server’s PHP mail() function is unreliable, blocked, or when the site’s email domain lacks SPF and DKIM authentication. Fix: install WP Mail SMTP → configure with an SMTP service (Gmail, SendGrid, Mailgun, or the hosting provider’s SMTP) → send a test email from the plugin’s diagnostic screen. SMTP bypasses the unreliable server PHP mail() function entirely and routes email through authenticated channels that major email providers trust. Add SPF and DKIM DNS records for the sending domain to prevent legitimate WordPress emails from landing in spam.

Registration emails not arriving — New user registration emails are sent but not received. Causes: the same email delivery issues as above, plus spam filtering at the recipient’s provider. After configuring SMTP, test registration email delivery to multiple email providers (Gmail, Outlook, Yahoo) to confirm deliverability across different spam filtering systems. Ensure the From email address in WP Mail SMTP matches a valid mailbox on the sending domain — using a [email protected] address that does not have a matching DNS record increases the spam score of outgoing emails.

Security and Access Errors

Security errors are part of the WordPress errors complete spectrum — plugins, firewalls, and permissions that legitimate users encounter alongside any genuine threat blocking the security layers were designed to provide.

403 Forbidden errors — A common WordPress errors complete security issue where the server refuses to serve the requested resource. Causes: .htaccess rules blocking access to specific paths, incorrect file permissions (WordPress files should be 644, directories 755, wp-config.php 600), or a security plugin blocking the requesting IP. Fix: check the .htaccess file for rules that may match the failing URL. Verify file permissions via FTP or the hosting file manager. Check the security plugin’s activity log for blocked requests — if the blocking IP is legitimate, whitelist it in the security plugin’s settings.

XML-RPC attacks — Automated tools use WordPress’s XML-RPC endpoint (xmlrpc.php) for brute-force password attempts and DDoS amplification via the multicall and pingback methods. Fix: block xmlrpc.php via .htaccess (<Files xmlrpc.php>Order Deny,Allow; Deny from all</Files>) unless Jetpack or other legitimate services require it, in which case remove the pingback.ping method via filter while leaving other XML-RPC methods active.

Malware and site compromise — Infected files, database-injected content, or backdoor PHP files cause symptoms ranging from front-end spam content to admin access loss. Fix: scan with Wordfence or Sucuri SiteCheck → remove identified malware files and database injections → restore clean copies of infected theme and plugin files from the WordPress.org repository → change all credentials → close the identified vulnerability (usually an outdated plugin) → request malware review removal from Google Search Console. Detailed coverage in our guide on WordPress malware removal.

Performance and Database Errors

WordPress errors complete diagnosis includes performance errors that cause slow loading. They affect user experience, bounce rates, and search rankings but may not trigger clear error messages that draw immediate attention.

WordPress admin dashboard slow — In the WordPress errors complete performance category, admin loads take 5–30 seconds. Causes: no persistent object cache (every page load queries the database from scratch), excessive revision accumulation bloating wp_post_revisions, or uncached plugin data. Fix: enable Redis or Memcached object caching through the hosting provider or a plugin, limit revisions (define('WP_POST_REVISIONS', 10); in wp-config.php), run WP-Optimize to clean expired transients and post revisions from the database.

WordPress connection timed out — a WordPress errors complete category where pages hang for 30–90 seconds then return a 504 error. Causes: PHP execution time exceeded, slow database queries, external API timeouts, or Nginx/Apache timeout settings shorter than page generation time. Fix: identify the specific timeout layer using Query Monitor, increase max_execution_time for legitimate slow operations, optimise slow database queries by adding indexes, move long-running processes to WP-Cron background tasks.

WordPress out of memory — Specific pages fail with “Allowed memory size of X bytes exhausted.” Causes: a plugin generating large in-memory data structures, image processing on upload, or import operations. Fix: increase WP_MEMORY_LIMIT, identify the memory-intensive operation using a PHP memory profiler, and optimise the operation to process data in smaller chunks rather than loading the entire dataset into memory simultaneously.

Finding the Right Fix for Any WordPress Error

Systematic WordPress errors complete diagnosis follows a consistent process regardless of the specific error type: identify the error message or symptom precisely, check the debug log for the underlying PHP or database error, isolate the cause through safe mode or plugin deactivation, apply the targeted fix for that specific cause, and verify the fix resolves the error without introducing new ones.

Key diagnostic resources for any WordPress errors complete investigation: WordPress admin → Tools → Site Health (the fastest overview of configuration issues), /wp-content/debug.log (with WP_DEBUG_LOG enabled — the most detailed error record), the hosting control panel’s PHP error log (captures PHP errors that occurred before WordPress loaded), and browser DevTools console (captures JavaScript errors that occur after page load). Between these four diagnostic sources, the cause of any WordPress error is identifiable without external tools or advanced server access.

The WordPress errors complete coverage on this site spans every major error type in dedicated articles: diagnosing site down events, fixing fatal errors, resolving email delivery failures, malware removal, recovering from lockout, fixing timeout errors, resolving CORS errors, and dozens more specific error guides. Each covers the full diagnostic and fix workflow for that error category, turning any WordPress error — however mysterious its first appearance — into a solvable, documented problem with a clear resolution path. According to the WordPress support documentation, the combination of enabling WP_DEBUG_LOG and checking the Site Health tool resolves the majority of WordPress error diagnostic questions by surfacing the specific PHP or configuration issue that the visible error symptom obscures. The WordPress errors complete framework above; the linked specific articles provide the detailed step-by-step fixes for each error type in the complete WordPress errors reference for site owners and developers at every experience level.

More Guides in This Series

These additional guides in the same cluster cover specific scenarios and complementary topics: