What Are HTTP Status Codes
When a browser or client sends a request to a server, the server responds with a 3-digit status code indicating the result. HTTP status codes are defined in RFC 9110 and are the foundational language of web communication. Understanding them is essential not only for debugging but also for SEO and user experience.
Category Overview
| Category | Meaning | Typical Scenario |
|---|---|---|
| 1xx | Informational | Request received, continuing |
| 2xx | Success | Request successfully processed |
| 3xx | Redirection | Further action needed |
| 4xx | Client error | Malformed request, server can't process |
| 5xx | Server error | Server failed to process |
1xx Informational
100 Continue
The client sent Expect: 100-continue; the server confirms the request body can be sent. Used for pre-checks before large uploads.
101 Switching Protocols
The client requested a protocol switch and the server agrees. The classic case is the WebSocket handshake: HTTP upgrades to a WebSocket persistent connection.
In practice, 1xx codes are rarely handled manually; frameworks and browsers manage them automatically.
2xx Success
200 OK
The most common code. The request succeeded and the response body contains the resource. GET returns data; POST returns the creation result.
201 Created
The request succeeded and the server created a new resource. Typically after POST or PUT; the response should include a Location header pointing to the new resource URI.
204 No Content
Success with an empty response body. Common after successful DELETE or PUT with nothing to return. In Axios, response.data is empty.
206 Partial Content
The server processed a range request (Range header). Used for video streaming, chunked downloads, resume. The response includes Content-Range.
3xx Redirection
301 Moved Permanently
The resource has permanently moved. Search engines transfer ranking weight to the new URL—the SEO-friendly permanent redirect. Use for domain migration or URL restructuring.
302 Found
Temporary redirect. Search engines do not transfer weight. Historically inconsistent across browsers; modern usage prefers 307.
304 Not Modified
The client sent a conditional request (If-Modified-Since or If-None-Match); the resource is unchanged, use the cached version. No response body—saves significant bandwidth.
307 Temporary Redirect
Temporary redirect that preserves the original HTTP method (302 in practice may turn POST into GET; 307 does not). Modern web recommends 307 over 302.
308 Permanent Redirect
Permanent redirect preserving the method. The method-safe version of 301, suitable for API endpoint migration.
Redirect Selection
| Need | Recommended Code |
|---|---|
| Permanent page migration (SEO) | 301 |
| Permanent API endpoint migration | 308 |
| Temporary page redirect | 307 |
| HTTP to HTTPS | 301 |
| www to non-www | 301 |
4xx Client Errors
400 Bad Request
Malformed request syntax the server can't understand. Common causes: bad parameter format, JSON parse failure, missing required fields.
401 Unauthorized
Not authenticated. The request lacks valid credentials. The response usually includes WWW-Authenticate. Note: the name says "Unauthorized" but the semantics are "Unauthenticated."
403 Forbidden
The server understands the request but refuses to act. Difference from 401: 401 is "Who are you?"; 403 is "I know who you are, but you don't have permission."
404 Not Found
The resource doesn't exist. The most common client error and an SEO killer—large numbers of 404s reduce crawl efficiency.
405 Method Not Allowed
The HTTP method is not allowed. E.g., POST to a GET-only endpoint. The Allow header should list supported methods.
408 Request Timeout
The client didn't send a request within the server's wait time. Common with unstable networks.
409 Conflict
The request conflicts with the server's current state. E.g., concurrent updates causing a version conflict.
413 Payload Too Large
The request body exceeds the server's limit. Common with file uploads. Nginx defaults to 1MB; adjust via client_max_body_size.
429 Too Many Requests
Rate limit exceeded. The response should include Retry-After. A core mechanism of API gateways.
5xx Server Errors
500 Internal Server Error
Generic server error, usually an uncaught exception. Check server logs to debug.
501 Not Implemented
The server doesn't support the requested functionality. Rare; usually means the server doesn't recognize the method.
502 Bad Gateway
A gateway/proxy received an invalid response from upstream. Common when Nginx reverse-proxies to a crashed or unstarted backend.
503 Service Unavailable
Temporarily unavailable, usually due to overload or maintenance. The Retry-After header advises when to retry. Search engines retry later rather than penalize—ideal for planned maintenance.
504 Gateway Timeout
The gateway timed out waiting for the upstream. Difference from 502: 502 got a bad response; 504 got no response at all.
511 Network Authentication Required
Network authentication needed. Common with public Wi-Fi captive portals.
SEO Impact In Detail
Status codes directly affect crawler behavior and rankings:
| Code | SEO Impact | Recommendation |
|---|---|---|
| 200 | Normal indexing | Ensure high-quality content |
| 301 | Weight transfer, preserves ranking | Use for permanent URL changes |
| 302 | No weight transfer, may be seen as temporary | Avoid long-term use |
| 404 | Crawler removes from index | Configure custom 404 page, submit dead links |
| 410 | Explicitly tells crawlers the resource is gone | Use for intentional content removal |
| 500 | Crawler may retry short-term, penalize long-term | Monitor and fix immediately |
| 503 | Crawler retries later, no penalty | Use during maintenance with Retry-After |
SEO Best Practices
- Use 301 (not 302) for domain migration
- Return 410 (not 404) for deleted pages to speed up index removal
- Return 503 +
Retry-Afterduring maintenance to avoid penalties - Regularly check crawl errors via Google Search Console or Baidu Webmaster
- Avoid soft 404s (returning 200 with a "not found" page body)
Troubleshooting Cheat Sheet
| Symptom | Likely Cause | Check |
|---|---|---|
| 400 | Malformed body | Check Content-Type and JSON format |
| 401 | Token expired or missing | Check Authorization header |
| 403 | Insufficient permissions or IP blocked | Check user roles and firewall rules |
| 404 | Wrong route or deleted resource | Check routing config and resource existence |
| 429 | Rate limit triggered | Reduce frequency, check Retry-After |
| 500 | Code exception or config error | Check server logs and stack traces |
| 502 | Backend service crashed | Check if backend process is running |
| 503 | Overloaded or under maintenance | Check load balancer and server resources |
| 504 | Backend response timeout | Check DB queries and external API calls |
Monitoring & Alerting
- Monitor 5xx error rate; alert above 1%
- Track 429 trends to decide on scaling
- Log 404 Referers to find internal dead links
- Use APM tools (Sentry, Datadog) to trace error sources
- Configure health check endpoints with load balancers to auto-remove unhealthy nodes