HTTP error codes tell you where to start, not what to change blindly. A 400-series response usually means the request cannot be accepted as sent, while a 500-series response means a server or gateway could not complete an apparently valid request. On a WordPress site, the failing layer might be the browser, a form or REST client, WordPress, PHP, the web server, a reverse proxy, a CDN, or the hosting platform.
This guide groups the common WordPress HTTP errors by failure type so you can diagnose the request path before changing plugins or server settings.
Quick diagnosis
- Record the exact HTTP code and failing URL.
- Check which request failed. A post page, wp-admin, REST API request, upload, checkout, or AJAX request can point to very different causes.
- Inspect the response headers and server/CDN logs. Identify whether the response came from the origin server, a proxy, CDN, WAF, or application.
- Change one layer at a time. Do not change PHP, plugins, DNS, CDN, and server rules together.
What 4xx and 5xx mean
HTTP semantics define 4xx responses as client-error class responses and 5xx responses as server-error class responses. That does not mean a human visitor personally caused every 4xx error, or that WordPress itself caused every 5xx error. Security layers, proxies, malformed integrations, uploads, and application state can all affect the response.
4xx errors: request, authentication, policy, size, and state
| Code | Meaning | WordPress checks to prioritize |
|---|---|---|
| 400 | Bad Request | Malformed request, cookies, request body, proxy/WAF behavior, REST or AJAX payload. |
| 401 | Unauthorized | Authentication credentials, Basic Auth, REST authentication, application passwords, protected staging sites. |
| 403 | Forbidden | WAF/security rule, file permissions, access rules, hotlink/security policy, hosting firewall. |
| 405 | Method Not Allowed | Wrong HTTP method, REST route, server rule, form endpoint, proxy restriction. Check the Allow header when present. |
| 406 | Not Acceptable | Content negotiation, ModSecurity/WAF rules, security filtering, request headers. |
| 408 | Request Timeout | The server did not receive the complete request in time. Check slow uploads, network, proxy and request-size conditions. |
| 409 | Conflict | Resource state conflict, REST update collision, duplicate operation, stale revision or integration conflict. |
| 413 | Content Too Large | Upload/request body exceeds a server, PHP, proxy or CDN limit. |
| 422 | Unprocessable Content | The syntax can be valid while the submitted values fail application validation. Inspect REST/form/WooCommerce validation details. |
| 429 | Too Many Requests | Rate limiting from CDN, WAF, host, security plugin or external API. Respect Retry-After when supplied. |
| 431 | Request Header Fields Too Large | Oversized cookies, repeated headers, proxy headers, long authentication/session data. |
5xx errors: PHP, application, upstream, overload, and gateway failures
| Code | Meaning | WordPress checks to prioritize |
|---|---|---|
| 500 | Internal Server Error | PHP fatal error, plugin/theme conflict, .htaccess/server configuration, permissions, corrupted files, logs. |
| 502 | Bad Gateway | A gateway or proxy received an invalid upstream response. Check PHP-FPM, web server, reverse proxy, CDN and origin logs. |
| 503 | Service Unavailable | Temporary overload, maintenance, exhausted workers/resources, application unavailable. |
| 504 | Gateway Timeout | A proxy or gateway did not get a timely upstream response. Check slow PHP, database queries, external calls and origin capacity. |
| 507 | Insufficient Storage | Server/storage layer cannot complete the request because required storage is unavailable. Check disk, quota, inodes and temporary space. |
| 508 | Resource Limit Is Reached | Common hosting-platform response for account resource exhaustion. Check CPU, RAM, entry processes, I/O and plan limits. |
Start with the failing request, not the title of the error
A code alone is not enough. The same 403 can mean a WAF rule on one site and a filesystem permission problem on another. The same 500 can come from a PHP fatal error, a broken server directive, or a plugin update. Capture the exact URL, method, time, response headers, and what changed immediately before the failure.
Use browser Developer Tools for request-level problems
For REST API, AJAX, uploads, forms, and editor failures, open your browser’s Developer Tools and inspect the Network panel. Select the failed request and record:
- Request URL
- Request method
- Status code
- Response headers
- Response body
- Request payload or form data
- Initiator
This often tells you whether the failure is a WordPress route, an external API, admin-ajax.php, a form endpoint, or an upstream service.
Use WordPress logs for PHP and application failures
When the evidence points to WordPress or PHP, enable logging carefully rather than displaying errors publicly. WordPress supports WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY. On a production site, log errors without exposing them to visitors, reproduce the failure once, inspect the log, and then return debugging to the appropriate production setting.
Before editing configuration files or changing plugins on a production site, verify that you have a current backup or staging environment.
How to separate WordPress from the web server or proxy
- Error occurs before PHP runs: inspect CDN, WAF, reverse proxy, web server and DNS/routing layers.
- PHP fatal error appears in logs: inspect the plugin, theme, PHP version, memory, or code path named in the error.
- Only one REST/AJAX route fails: inspect that route, method, payload, authentication and the plugin that owns it.
- Only uploads fail: check body-size limits, PHP upload limits, disk/temp space and security filtering.
- Only logged-in sessions fail: inspect cookies, authentication, cache exclusions and security controls.
- Gateway errors appear: identify which upstream service the gateway was waiting for.
400 vs 422: malformed request or valid syntax with invalid instructions?
A 400 response means the server cannot or will not process the request because it considers the request invalid. A 422 response means the content type and syntax can be understood, but the application cannot process the instructions. For WordPress integrations, that distinction can help you decide whether to inspect the raw request format or the submitted field values and application rules.
401 vs 403: authentication or refusal?
401 indicates missing or unacceptable authentication credentials for the target resource. 403 indicates the server understood the request but refuses to fulfill it. If a WordPress REST request returns 401, check credentials and authentication. If it returns 403, inspect permissions, WAF rules, security plugins, user capabilities, and access policy.
408 vs 504: who timed out?
408 means the server did not receive a complete client request within the time it was willing to wait. 504 means a gateway or proxy did not receive a timely response from an upstream server. Slow uploads can produce request-side timeout symptoms, while slow PHP/database/upstream processing can produce gateway timeout symptoms.
429: find the system enforcing the rate limit
Do not assume WordPress generated a 429. The limit might come from Cloudflare, another CDN, a WAF, your host, a security plugin, or an external API. Check the response headers, security events, host logs, and any Retry-After header. Repeatedly retrying can extend the block.
500, 502, 503 and 504: a practical order
- Check whether the public site and wp-admin fail in the same way.
- Check PHP and web-server error logs at the exact time of the failure.
- Check recent plugin, theme, PHP, server or deployment changes.
- Check hosting resource graphs and PHP workers.
- Check reverse proxy/CDN/origin health for 502 and 504.
- Check maintenance and overload conditions for 503.
Do not use generic “disable everything” troubleshooting as the first step
Disabling all plugins can be useful when logs or a controlled test indicate an application conflict, but it should not be the first response to every HTTP code. A 413 caused by an Nginx request-body limit will not be fixed by disabling unrelated plugins. A 429 from an external API requires rate-limit handling, not a theme switch. A 502 from a failed upstream connection requires gateway/origin diagnosis.
Official references
- RFC 9110: HTTP Semantics
- WordPress: Debugging in WordPress
- WordPress: Common errors
- WordPress: Troubleshooting FAQ
Bottom line: Diagnose WordPress HTTP errors by request path and responsible layer. The code narrows the problem, but the failing URL, request method, headers, logs, and recent changes tell you what to fix. That approach is faster and safer than applying the same eight generic steps to every error.