The Ultimate Guide to Common HTTP Error Codes

Every WordPress site owner runs into an HTTP error code eventually: a 404 that shouldn’t be there, a 403 locked out of nowhere, a 500 that shows up after a plugin update, or a mysterious code you’ve never seen before. Some of these can be fixed in a few clicks. Others are server-side, hosting-side, or increasingly, coming from a layer in front of your host entirely. This guide breaks down the HTTP error codes a WordPress site actually throws, what each one means in plain language, and where to look first when you see it.

Redirect Codes: 301, 302, And 308

Not technically errors, but you’ll run into these constantly. All three tell a visitor’s browser that the page they asked for lives somewhere else now.

301 (Moved Permanently) means the page has moved for good, and search engines transfer the old page’s ranking signals to the new URL. 302 (Found) means the move is temporary, so the original URL stays the “real” one in search engines’ eyes. 308 (Permanent Redirect) is functionally equivalent to a 301, except it preserves the original request method. A 301 on a form submission can get silently converted to a GET request by some clients; a 308 won’t. Most WordPress redirect plugins and CDNs default to 301s, but you’ll increasingly see 308s from stricter HTTPS-enforcement rules.

If you’re on WordPress, setting up redirects is straightforward with any of a number of solid redirect plugins. Outside WordPress, it’s a matter of editing your .htaccess file directly.

Our guide on 301 and 302 redirects covers the decision between them in more detail.

Err_Too_Many_Redirects

Redirects are useful right up until they loop. Two rules that are each correct on their own can end up pointing at each other, and the browser gives up with ERR_TOO_MANY_REDIRECTS. Two versions of this cover most WordPress cases. The first is a mismatch between your WordPress Address and Site Address settings: one includes www, and the other doesn’t. The second is Cloudflare’s Flexible SSL mode, fighting your host’s own HTTP-to-HTTPS rule. Flexible sends every request to your origin over plain HTTP, your host redirects it straight back to HTTPS, and around it goes. Here’s how to track down and fix a redirect loop. Also, here’s context on www vs non-www domains.

Client-Side Errors (4xx)

The 4xx range means the server understood the request but has a problem with it, usually something about the request itself. As a WordPress admin, though, you’re often the one who has to fix the server side of that problem, not just the visitor.

Error 400 (Bad Request)

The server can’t make sense of the request at all: it’s malformed or corrupted somewhere between the browser and the server, not missing or forbidden. This is one of the more fixable 4xx errors, and often clears with a cache/cookie clear on the visitor’s end. Our guide to fixing HTTP 400 walks through the rest.

Error 401 (Unauthorized)

A 401 means the server requires authentication and didn’t receive valid credentials. That is not the same as a wrong password prompt, which WordPress usually handles with its own login screen rather than a raw 401. When you see a 401 on the page itself, look at things sitting in front of WordPress’s own login: a DNS-level auth rule, a corrupted session cookie, or server-level password protection left on by accident. Our guide to the HTTP 401 error covers troubleshooting on both the client and server sides.

Error 403 (Forbidden)

One of the more common WordPress errors. The server understood the request and is refusing it outright, usually a file permissions or security rule issue, not something the visitor did wrong. Tracking down which permission or rule is blocking the request is generally the harder part; fixing it is usually quick once you’ve found it. Our full write-up on the 403 Forbidden error can help.

Error 404 (Not Found)

The most common HTTP error code by far. The server understood the request, but it couldn’t find anything at that URL. Roughly a coin flip whether a given 404 is visitor error (bad link, typo) or site error (deleted page, broken permalink, migration gone wrong). Our 404 troubleshooting guide covers both.

A 404 is also the one error on this list that you can design rather than just fix. Some of them are unavoidable, so the question becomes what the visitor sees when it happens. Divi’s Theme Builder treats the 404 page as a template like any other. You can build it visually, with your own header, footer, search field, and links back into the site, instead of shipping the theme’s default. And you don’t have to start from a blank canvas: there are eight free 404 section designs built for Divi 5, styled and unstyled, ready to import into your Divi Library and drop straight into the template.

Error 405 (Method Not Allowed)

Less common on the front end, frequent if you touch the WordPress REST API, XML-RPC, or a custom login flow. It means the URL exists, but the request used an HTTP method (GET, POST, PUT) that the endpoint doesn’t accept. A typical WordPress trigger is a security plugin or firewall rule blocking POST requests to wp-json or xmlrpc.php. That breaks the Block Editor’s autosave or a plugin’s REST endpoint. If a 405 shows up right after tightening a firewall or security plugin, that’s the first place to look.

Error 410 (Gone)

Don’t confuse this with a 404. Both mean missing content, but a 410 says it’s gone on purpose and isn’t coming back. You can set this deliberately when you delete a page for good, and search engines will drop it from their index faster than they would a plain 404. Think of a 404 as misplaced keys and a 410 as keys thrown off a pier — both gone, one on purpose. Our write-up on 410 covers when and how to use it.

Error 413 (Payload Too Large)

The request body is bigger than the server will accept. This is almost always a WordPress admin hitting it, not a site visitor. Common triggers: uploading a large image or video to the media library, importing a large XML file, or installing a theme/plugin ZIP that exceeds the size cap. The fix lives in three possible places, and it’s usually one of them: PHP’s upload_max_filesize and post_max_size directives, or, if those already look generous, your host’s or Nginx config’s client_max_body_size limit, which sits lower than PHP’s. Many managed WordPress hosts deliberately cap this, so raising PHP’s limits alone sometimes isn’t enough. A support ticket to the host may be the actual fix.

Error 429 (Too Many Requests)

One of the easier HTTP errors to reason about: something is hitting your server faster than it can keep up, so it throws a 429 while it catches its breath. Could be a DDoS attack, or just a traffic spike from a viral link. Either way, our guide to HTTP 429 covers rate limiting and fixes on both the client and server sides.

Server-Side Errors (5xx)

The 5xx range means the request was fine — the server failed to handle it. Visitors generally can’t fix these themselves; they’re yours (or your host’s) to solve.

Error 500 (Internal Server Error)

The catch-all server failure. Something in your site’s file system or code isn’t parsing, and WordPress can’t be more specific than “something broke.” Common causes include a corrupted .htaccess file, a PHP memory limit that’s too low, or a plugin conflict. Disabling plugins one at a time is still the fastest way to isolate the issue. Our HTTP 500 guide has the full troubleshooting order.

Error 501 (Not Implemented)

Purely server-side: there’s nothing a visitor can do but report it to the site owner. A 501 means the server doesn’t recognize the request method, or (less commonly) doesn’t have the capability the request needs. On WordPress, malware and misconfigured server-level rules are the usual causes, not a site being fully offline. That’s more often a 503 or a straight connection failure. Check our HTTP 501 guide, and while you’re in there, it’s worth confirming your site isn’t compromised: here’s how to scan WordPress for malware.

Error 502 (Bad Gateway)

Something between the visitor and your actual server (a proxy, load balancer, or CDN node) got an invalid response and passed the failure along. A traceroute can help narrow down where in the chain it’s failing. Fixes range from a browser cache/DNS flush to purging your CDN cache. Our 502 troubleshooting guide covers the full list.

Error 503 (Service Unavailable)

Unlike most server errors, a 503 often resolves itself. It means the server is temporarily unable to handle requests (due to planned maintenance, a script that ran too long, or a memory spike), and it usually resolves on its own within a few minutes. If it doesn’t, the next steps are to restart the server, reset the firewall, or check whether a node further up the chain is down for maintenance. Our HTTP 503 guide covers both the wait-it-out case and the ones that need real troubleshooting.

Error 504 (Gateway Timeout)

Browsers often just show this as “this page isn’t working,” which makes it easy to miss that it’s a specific error: something upstream of your site (usually the host or a CDN) tried to reach the origin server and gave up waiting for a response. The fix is rarely on the visitor’s end. As the admin, check proxy settings and confirm your domain’s nameservers are actually pointed where you think they are. Our 504 guide covers the rest.

Error 508 (Loop Detected / Resource Limit Reached)

Two different things share this number, and which one you’re dealing with matters. The official HTTP 508 (a WebDAV extension) indicates that the server detected an infinite loop while processing the request, which is rare and not what most WordPress admins encounter. What actually shows up on WordPress hosting, especially on cPanel-based hosts, is a non-standard “Resource Limit Is Reached” page, using the same 508 number for something else entirely: your hosting account has hit its CPU, memory, bandwidth, or inode quota. If your host is showing you this, it’s an account-limits problem, not a WebDAV loop. After ruling out a malware infection or a DDoS attack, driving usage up, our 508 guide covers how to get back under the limit.

Cloudflare Edge Errors (520-526)

These aren’t standard HTTP codes; Cloudflare defines them. They belong in a WordPress error-code guide anyway, because so many WordPress sites now sit behind Cloudflare’s network, whether the owner set that up on purpose or not. Cloudflare puts its own reporting at more than 20% of global Internet request traffic, and W3Techs’ most recent survey has it serving roughly a quarter of all websites. A meaningful share of that is WordPress. Rocket.net is the clearest example, a managed WordPress host built entirely on Cloudflare’s Enterprise network by default. Plenty of others offer it as an add-on or integration: WP Engine, Cloudways’ Cloudflare Enterprise option, SiteGround’s built-in toggle. A large number of self-managed WordPress sites are proxied directly through Cloudflare’s free plan, too, often set up once and forgotten.

The distinction that actually matters: a 5xx code from your own server means WordPress or your host has a problem. A 520-526 code means Cloudflare’s edge and your origin server can’t agree on something, which is a different fix, and one your WordPress admin dashboard won’t tell you about because WordPress never sees the failure. It happens before the request even reaches your server.

Error 520 (Web Server Returned An Unknown Error)

The origin server responded, but with something Cloudflare couldn’t interpret: an empty response, oversized headers, or a malformed reply. It’s the catch-all in this range; if none of the more specific codes below fit, this is usually what you’ll see.

Error 521 (Web Server Is Down)

Cloudflare tried to connect to your origin server and got refused outright. The server itself is either down or actively blocking Cloudflare’s IP ranges. A firewall rule that’s too aggressive is a common self-inflicted cause here.

Error 522 (Connection Timed Out)

Cloudflare attempted to connect to your origin server, but the TCP handshake timed out. This is a connection-level failure, not a slow page: the server never even started talking back.

Error 523 (Origin Is Unreachable)

Cloudflare can’t route to your origin server at all, usually due to a DNS misconfiguration: the origin IP Cloudflare has on file either doesn’t resolve or no longer exists. Commonly, after a server migration, the DNS record pointing to Cloudflare at the new origin never gets updated.

Error 524 (A Timeout Occurred)

Unlike a 522, Cloudflare connected to the origin server successfully, but the server took too long to return a complete HTTP response. A slow database query, an overloaded server, or a long-running PHP process are the usual WordPress-side causes.

Errors 525 And 526 (SSL Handshake Failed / Invalid SSL Certificate)

Both are certificate problems between Cloudflare and your origin, not visitor-facing certificate errors. A 525 means Cloudflare couldn’t complete the SSL/TLS handshake with the origin server. A 526 means the handshake completed, but the origin’s certificate is invalid, expired, or self-signed. Cloudflare’s SSL mode (usually “Full (Strict)”) rejects anything but a valid one. An expired origin certificate after Cloudflare’s own edge certificate auto-renewed is a common cause of this. The origin cert doesn’t renew just because Cloudflare’s did.

Wrapping Up With HTTP Error Codes

That’s the rundown of the HTTP error codes a WordPress site is actually likely to throw, plus the Cloudflare edge codes that increasingly sit in front of one. It’s not every code that exists; for the full, exhaustive list, see the Mozilla Developer Network’s HTTP status documentation.

But if you just landed here because your site (or someone else’s) is throwing one of these right now, find the matching heading above and follow the link to the fix.

Which error code do you run into the most — one of the classics, or is it a Cloudflare edge error now?