WordPress Error Code Field Guide: 500, 502, 503, 504, 404 Decoded

Why error codes matter

Every WordPress emergency starts with a number on a browser screen. 500. 502. 503. 504. 404. Most owners panic, search the number, and pile on five different "fixes" they read in random forums. By the time we get the call, the site is in worse shape than when it broke.

The five HTTP status codes covered here account for roughly 85% of every "my WordPress site is down" ticket we receive. Learning to read them correctly is the single highest-leverage skill in WordPress operations.

HTTP 500 — Internal Server Error

A 500 is a catch-all: the server tried to handle the request and something fatal stopped it. In WordPress, the fatal usually lives in PHP — a syntax error, a memory exhaustion, a function call to something that no longer exists.

Most common WordPress causes

• Corrupted .htaccess after a plugin or migration
• PHP fatal error in functions.php, a plugin, or wp-config.php
• Memory exhaustion (PHP memory_limit hit during a heavy admin task)
• Wrong file permissions (777 on files trigger many shared-host security rules)
• Database connection failure during bootstrap

How to read it

The browser shows nothing useful — that's by design (debug info would leak). The real story is in the server error log. On cPanel: Errors → see the last 300 entries. On a VPS: tail -f /var/log/php-fpm.log and reload the broken page.

If you see "Allowed memory size of X bytes exhausted", bump WP_MEMORY_LIMIT in wp-config.php. If you see "Parse error: syntax error", a file was edited and broken — revert from backup. If you see "Call to undefined function" the issue is a plugin/theme expecting something WordPress no longer offers.

HTTP 502 — Bad Gateway

A 502 is a routing failure. Your visitor talks to a proxy (Nginx, Cloudflare, a load balancer). The proxy tries to talk to the WordPress upstream (PHP-FPM, Apache). The upstream returned garbage, or didn't respond, or closed the connection mid-reply.

Most common WordPress causes

• PHP-FPM out of workers (pm.max_children exhausted)
• A single PHP request timing out (heavy admin export, slow plugin API call)
• PHP segmentation fault (rare, usually a buggy PHP extension)
• Wrong fastcgi_pass socket path in Nginx after PHP version upgrade
• Cloudflare → origin TLS handshake failure

How to read it

Check whether the 502 is from Cloudflare (their branded page) or your origin (plain text). For Cloudflare, log into the dashboard and check the "Reachability" graph. For origin, the Nginx error log (/var/log/nginx/error.log) explicitly names the failure: "upstream prematurely closed connection", "no live upstreams", or "connect() failed (111: Connection refused)".

If PHP-FPM is the culprit, increase pm.max_children after measuring real per-worker memory use. The right value is (available RAM ÷ avg worker RAM) × 0.8, never the "more workers is better" myth.

HTTP 503 — Service Unavailable

A 503 is the polite "I'm temporarily down" status. WordPress itself returns it when the .maintenance file is present (during updates). Hosting providers return it when your account exceeds resource quotas. Load balancers return it when they have no healthy backends.

Most common WordPress causes

• WordPress maintenance mode stuck (.maintenance file never deleted after a failed update)
• Hosting throttling because of CPU/IO quota breach
• Cloudflare rate-limit triggered by a brute-force attack
• Origin behind a load balancer with all backends marked unhealthy

How to read it

Look at the response body. The literal text "Briefly unavailable for scheduled maintenance" means WordPress itself is in maintenance mode — delete .maintenance from the site root and you're back online in seconds.

If you see a hosting-branded page ("Resource limit reached"), the problem is quota. Identify the cron job, plugin, or brute force attack consuming resources and stop it before adding more capacity.

A 503 with a Retry-After header is actually the correct, SEO-safe way to signal maintenance to Google. Don't worry about brief 503s — they only hurt SEO when they persist for hours.

HTTP 504 — Gateway Timeout

A 504 is a 502's slower cousin. The proxy waited for the WordPress upstream to respond, the response never came in time, the proxy gave up. The difference matters: 502 means a broken response, 504 means no response within the time budget.

Most common WordPress causes

• A long-running PHP request (huge import, heavy report)
• A slow MySQL query blocking the request
• An external HTTP call from a plugin to a slow third-party API
• Cloudflare's 100-second timeout on origin requests
• A blocking lock in the database

How to read it

The 504 always comes from the proxy layer. Check timestamps and durations in the proxy log to see exactly how long it waited. Then on the upstream, identify what was running at the same time.

Common fixes: increase fastcgi_read_timeout to 300s, move slow operations to background jobs (Action Scheduler, WP-CLI), and add MySQL query optimization for the offending pages.

HTTP 404 — Not Found

A 404 says the server received the request but found no resource to serve. In WordPress this is almost always a permalink or rewrite problem — except when it's intentional (someone deleted the page) or vindictive (a security plugin hiding URLs from attackers by returning 404 instead of 403).

Most common WordPress causes

• Permalink structure broken after migration or plugin reactivation
• Custom post type or taxonomy rules not flushed
• .htaccess missing or wrong rewrite rules
• Nginx try_files directive wrong
• WPML/Polylang language definitions out of sync
• A security plugin masking legitimate URLs

How to read it

If the homepage works but inner pages 404, it's almost certainly permalinks. Go to Settings → Permalinks → Save (don't change anything) — this regenerates rewrite rules.

If custom post types 404, the plugin that registered them was deactivated/reactivated without flushing rewrites. Same fix.

If WPML translated URLs 404, the language definitions in WPML's tables drifted from WordPress's options. Re-sync via WPML's troubleshooting page.

A decision tree for the next 5 minutes

When the next emergency lands, do this in order:

1. Open the broken URL with curl -I — what's the actual status code? Browsers can be misleading because of caching and CDN intermediates.
2. If 5xx, check the origin error log first. Don't touch WordPress files until you've read at least 10 recent error log entries.
3. If 4xx, check .htaccess and permalink settings. These cause 90% of WordPress 404s.
4. If the issue started after a deploy or update, your first move is rollback, not diagnosis. Diagnose what broke from a stable baseline.
5. If the issue is intermittent, set up a monitor (UptimeRobot, BetterStack) before debugging — patterns matter more than single samples.

When to call a specialist

A pattern we see weekly: an owner spends 8 hours chasing a 502, swaps hosting, ends up on a "better" provider, the 502 returns within a week because the root cause was a slow plugin that no host can paper over.

If you've tried the basics and the error returns, the problem is structural. We diagnose at every layer — Nginx config, PHP-FPM tuning, MySQL slow log, WordPress profiling — and fix the root cause once.

Need an emergency fix? We respond within minutes for active outages. For a deep audit, see WordPress speed recovery or malware removal depending on the symptom.