Common Website Error Codes Explained Complete HTTP Status Code Guide
Website errors and site errors disrupt user experience, hurt search rankings, and cost revenue. HTTP status codes are the standard way web servers communicate the result of every request, from a successful page load (200) to a catastrophic server crash (500). This guide explains every common HTTP status code, what causes each error, and exactly how to fix it.
What Are HTTP Status Codes?
Every time your browser requests a web page, image, API endpoint, or any other resource from a server, the server responds with an HTTP status code , a three-digit number that tells the browser what happened. These codes are grouped into five classes based on the first digit:
Request received, processing continues
Request received, understood, and accepted
Further action needed to complete the request
The request contains bad syntax or cannot be fulfilled
The server failed to fulfill a valid request
You rarely see 1xx, 2xx, or 3xx codes as a user because the browser handles them silently. A 200 OK just means the page loaded. A 301 redirect quietly sends you to the new URL. But 4xx and 5xx errors are the ones that break things, they show error pages, block access, and tell search engines your site has problems.
Understanding website error codes is essential for anyone running a website, whether you are a developer debugging a deployment, a site owner investigating why pages are down, or an SEO professional diagnosing crawl errors in Google Search Console. The rest of this guide walks through each status code class with specific causes and fixes for every common error.
1xx Informational Codes
1xx status codes are provisional responses. The server sends them to acknowledge that it received the initial part of the request and the client should continue. You will almost never encounter these in normal browsing, but they are important in certain protocol negotiations.
100 Continue
The server received the request headers and the client should proceed to send the request body. This is used when a client sends a large POST request with an Expect: 100-continue header , the server confirms it is ready to accept the body before the client sends it, avoiding wasted bandwidth if the headers alone would cause a rejection.
101 Switching Protocols
The server is switching to the protocol the client requested via an Upgrade header. The most common use case is upgrading an HTTP connection to a WebSocket connection. The server responds with 101 and then the connection switches to the WebSocket protocol for bidirectional communication.
2xx Success & 3xx Redirection Codes
2xx codes mean the request was successfully received, understood, and accepted. 3xx codes indicate the client needs to take additional action (usually following a redirect) to complete the request. Both categories are handled automatically by browsers, but understanding them is critical for debugging and SEO.
OK
The standard success response. The request was fulfilled and the response body contains the requested resource (an HTML page, JSON data, an image, etc.). This is what you want every page on your site to return.
Created
The request was fulfilled and a new resource was created. Typically returned after a successful POST request to an API, for example, creating a new user account, adding a comment, or uploading a file. The response usually includes the location of the newly created resource.
No Content
The request was successful but there is no content to return in the response body. Common for DELETE requests or form submissions where the server processes the action but has nothing to send back. The browser stays on the current page.
Moved Permanently
The requested resource has permanently moved to a new URL. The browser automatically follows the redirect. Search engines transfer link equity (SEO value) to the new URL. Use 301 redirects when you change URL structures, migrate to a new domain, or merge duplicate pages. This is the most SEO-friendly redirect.
Found (Temporary Redirect)
The resource is temporarily located at a different URL. Unlike 301, this tells search engines to keep indexing the original URL because the redirect is not permanent. Use 302 for A/B testing, temporary maintenance pages, or geo-based redirects where the original URL should retain its ranking.
Not Modified
The resource has not been modified since the last request. The browser can use its cached version, saving bandwidth and load time. This is triggered by conditional headers like If-Modified-Since or If-None-Match. A well-configured server uses 304 responses extensively to speed up repeat visits.
4xx Client Errors
4xx status codes indicate the problem is on the client side, the request was malformed, the user is not authenticated, or the resource does not exist. These are the errors your users see most often. As a site owner, you should fix 4xx errors that appear in your server logs and Google Search Console because they signal broken links, poor UX, and wasted crawl budget.
400 Bad Request
The server cannot process the request because it is malformed or contains invalid data.
Common causes
- •Malformed URL with unsupported characters or encoding
- •Invalid JSON or form data in a POST request body
- •Missing required query parameters or headers
- •Request size exceeds the server's configured limit
- •Corrupted cookies sent by the browser
How to fix
Check the URL for typos, special characters, or double-encoded values. If you are submitting a form or API request, validate the request body against the expected schema. Clear browser cookies for the site. Check server logs for the specific validation error message.
401 Unauthorized
The request requires authentication and valid credentials were not provided.
Common causes
- •No authentication token or API key included in the request
- •Expired session token or JWT
- •Incorrect username or password
- •Missing or malformed Authorization header
- •API key has been revoked or regenerated
How to fix
Log in again to get a fresh session token. If using an API, verify your API key is correct and included in the Authorization header. Check if the token has expired and implement automatic token refresh. Ensure you are sending credentials to the correct endpoint.
403 Forbidden
The server understood the request and the user's identity but refuses to authorize access.
Common causes
- •Insufficient permissions (user role does not have access)
- •IP address blocked by a firewall or WAF rule
- •Directory listing disabled and no index file exists
- •File permissions on the server prevent access (chmod issue)
- •Hotlink protection blocking requests from external domains
- •Geographic restrictions (geo-blocking) in a CDN or firewall
How to fix
Verify the user has the correct role or permissions to access the resource. Check server file permissions (files should be 644, directories 755). Review firewall and WAF rules for accidental blocks. If you are being blocked by a CDN, check the CDN dashboard for rate limiting or geo-blocking rules.
404 Not Found
The server cannot find the requested resource at this URL.
Common causes
- •The page was deleted or moved without a redirect
- •Typo in the URL typed by the user or in an internal link
- •URL structure changed during a site redesign or CMS migration
- •Case-sensitive URLs on Linux servers (Page vs page)
- •Broken links from external sites pointing to old URLs
- •Trailing slash mismatch (/about vs /about/)
How to fix
Set up 301 redirects from old URLs to new ones whenever you move or rename pages. Audit internal links regularly. Use Google Search Console to find crawl errors and fix or redirect them. Create a helpful custom 404 page that guides users back to working content. For case-sensitivity issues, configure your server to handle URL normalization.
405 Method Not Allowed
The HTTP method used (GET, POST, PUT, DELETE) is not supported by this endpoint.
Common causes
- •Sending a POST request to a GET-only endpoint
- •Form action URL pointing to the wrong route
- •API route configured to accept only specific methods
- •Reverse proxy or WAF stripping or changing the HTTP method
How to fix
Check the API documentation for the correct HTTP method. Verify your form uses the right method attribute (method="POST" vs method="GET"). If building an API, ensure your route handler exports the correct method handlers. Check reverse proxy configuration for method restrictions.
408 Request Timeout
The server timed out waiting for the client to finish sending the request.
Common causes
- •Slow or unstable internet connection on the client side
- •Very large file upload on a connection that is too slow
- •Server's client timeout setting is too aggressive
- •Network interruption between client and server during the request
How to fix
If you are the user, check your internet connection and try again. If you are the server admin, increase the client body timeout value in your web server configuration. For upload endpoints, set longer timeouts specifically for those routes. Implement chunked uploads for large files.
429 Too Many Requests
The user has sent too many requests in a given time window (rate limiting).
Common causes
- •Automated scripts or bots hitting the API too frequently
- •Client-side code in an infinite retry loop
- •Shared IP address (NAT, VPN) causing multiple users to hit the same limit
- •Rate limit configuration is too restrictive for legitimate use
How to fix
Respect the Retry-After header in the response and wait before retrying. Implement exponential backoff in your API client. If you control the server, review rate limit thresholds and consider per-user rather than per-IP limits. Add caching to reduce the number of requests needed.
5xx Server Errors
5xx errors are the most critical website errors because they indicate a failure on the server side, the request from the user was valid, but the server could not fulfill it. Unlike 4xx errors where the client is at fault, 5xx errors mean something is broken in your infrastructure. Every 5xx error is a potential revenue loss and a signal to search engines that your site is unreliable.
500 Internal Server Error
The server encountered an unexpected condition that prevented it from fulfilling the request.
Common causes
- •Unhandled exception or syntax error in server-side code (PHP, Python, Node.js, Ruby)
- •Misconfigured .htaccess file (Apache) or server configuration (Nginx)
- •Database connection failure or query error
- •Exhausted PHP memory limit or execution time
- •Broken CMS plugin, theme, or module update
- •Missing environment variable or dependency
How to fix
Check your server error logs immediately (e.g., /var/log/nginx/error.log, Docker container logs, or your hosting panel's error log). The log will contain the specific error and stack trace. For CMS sites, try disabling recently updated plugins. For custom applications, deploy a recent working version while you debug. Increase PHP memory_limit if the error log shows exhausted memory.
502 Bad Gateway
A proxy or gateway server received an invalid response from the upstream server.
Common causes
- •The upstream application (Node.js, PHP-FPM, Gunicorn) crashed or is not running
- •The application process ran out of memory and was killed (OOM)
- •Firewall rules blocking traffic between the reverse proxy and the application
- •Misconfigured proxy_pass or upstream directive pointing to the wrong port
- •CDN (Cloudflare, AWS CloudFront) unable to reach your origin server
- •SSL certificate mismatch between proxy and upstream
How to fix
Check if your application process is running (e.g., docker ps, systemctl status, pm2 status). Check the reverse proxy error log (not the application log). Verify the upstream address and port in your proxy configuration match where the application is actually listening. If using a CDN, check the CDN's error logs for the specific upstream failure reason. Restart the application process.
503 Service Unavailable
The server is temporarily unable to handle the request, usually due to overload or maintenance.
Common causes
- •Server is under heavy traffic load and cannot accept more connections
- •Scheduled maintenance mode is active
- •Application worker pool is exhausted (all workers are busy)
- •Database connection pool is exhausted
- •Auto-scaling has not yet provisioned enough instances to handle the spike
- •DDoS attack overwhelming server resources
How to fix
If planned maintenance, ensure you return the proper Retry-After header so search engines know when to come back. For traffic spikes, scale horizontally by adding more application instances or upgrade server resources. Optimize your application to handle more concurrent requests (connection pooling, caching, async processing). If under DDoS, enable your CDN's DDoS protection or rate limiting features.
504 Gateway Timeout
A proxy or gateway server timed out waiting for a response from the upstream server.
Common causes
- •Slow database queries causing the application to respond past the proxy timeout
- •External API calls (payment gateways, third-party services) timing out
- •Application deadlock or infinite loop consuming all CPU
- •Network latency between proxy and upstream server
- •Proxy timeout configured too low for the application's response time
- •Upstream server overloaded and queuing requests beyond the timeout window
How to fix
Increase proxy_read_timeout (Nginx), TimeOut (Apache), or the equivalent setting in your reverse proxy. Optimize slow database queries by adding indexes and reviewing execution plans. Move long-running tasks to background job queues instead of handling them in the request cycle. Monitor application response times and set up alerts when they exceed healthy thresholds.
HTTP Status Code Quick Reference Table
Bookmark this table for quick lookups. It covers every status code discussed in this guide.
| Code | Name | Meaning |
|---|---|---|
100 | Continue | Server received headers, client should continue |
101 | Switching Protocols | Server is switching to a different protocol (e.g. WebSocket) |
200 | OK | Request succeeded, response body contains the data |
201 | Created | Resource was successfully created (POST) |
204 | No Content | Request succeeded but there is no body to return |
301 | Moved Permanently | Resource has permanently moved to a new URL |
302 | Found | Resource temporarily at a different URL |
304 | Not Modified | Cached version is still valid, no data transferred |
400 | Bad Request | Malformed syntax or invalid request parameters |
401 | Unauthorized | Authentication required but not provided or invalid |
403 | Forbidden | Authenticated but not permitted to access this resource |
404 | Not Found | Resource does not exist at this URL |
405 | Method Not Allowed | HTTP method (GET, POST, etc.) not supported for this endpoint |
408 | Request Timeout | Client took too long to send the request |
429 | Too Many Requests | Rate limit exceeded, try again later |
500 | Internal Server Error | Generic server-side failure |
502 | Bad Gateway | Proxy received invalid response from upstream |
503 | Service Unavailable | Server temporarily overloaded or in maintenance |
504 | Gateway Timeout | Proxy timed out waiting for upstream server |
Monitoring Your Website for Errors
Knowing what error codes mean is only half the battle. The other half is knowing when they happen, ideally before your users tell you. Website monitoring tools check your site continuously from multiple locations and alert you the moment something goes wrong.
Uptime monitoring catches 5xx errors
An uptime monitor sends HTTP requests to your site every 30 seconds to 5 minutes from servers around the world. When your server responds with a 5xx error, connection timeout, or DNS failure, the monitor triggers an alert via Slack, Discord, email, SMS, or WhatsApp. You find out about the outage in seconds, not hours.
Visual monitoring catches "invisible" errors
Here is a problem uptime monitoring alone cannot solve: your server returns a 200 OK status code, but the page is actually broken. Maybe a failed deployment rendered the page blank. Maybe a CDN is serving a stale error page. Maybe a JavaScript error hid all the content. The status code says everything is fine, but the page looks broken. Visual monitoring takes screenshots of your pages and compares them against a baseline, if the page looks different, you get alerted.
SSL and DNS monitoring prevents cascading failures
Expired SSL certificates cause browsers to show scary security warnings that drive users away. DNS failures prevent your domain from resolving entirely. Both issues can appear as website errors to your users even though the server itself is perfectly healthy. Comprehensive monitoring covers all layers: uptime, visual appearance, SSL certificates, and DNS records.
Catch Website Errors Before Your Users Do
Visual Sentinel monitors uptime, visual appearance, SSL certificates, and DNS records from multiple global locations. Get instant alerts on Slack, Discord, email, or WhatsApp when something breaks.
Start Monitoring Free7-day free trial · See all plans