501 vs 405: Not Implemented vs Method Not Allowed
501 and 405 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 501 — Not Implemented | HTTP 405 — Method Not Allowed |
|---|---|---|
| Definition | The server does not recognize the request method or lacks the capability to fulfill it. Unlike 405, the issue is not permissions — the functionality simply does not exist yet. | The server knows the resource but the HTTP method used (e.g., DELETE on a read-only endpoint) is not allowed. The Allow header lists the permitted methods. |
| Plain-language summary | HTTP 501 Not Implemented means the server does not support the functionality required to fulfill the request. | The HTTP method used in the request (GET, POST, DELETE, etc.) is not allowed on the target resource. The server knows the resource exists but does not support the requested action on it. The response includes an Allow header listing the permitted methods. |
| When to use | HTTP 501 Not Implemented means the server does not support the functionality required to fulfill the request. | Return 405 when the resource exists but the method is not supported. Must include an Allow header listing supported methods. Use 404 when the resource does not exist. Use 501 when the method is not implemented globally (rather than for a specific resource). |
| Client behavior | Client handles 501 according to server-errors semantics. | Do not retry with the same method. Read the Allow header to determine which methods are supported and retry with a valid method. |
| Caching behavior | See 501 caching spec. | Not cached. |
| SEO / crawler impact | Search crawlers interpret 501 (server-errors) for indexation and link equity accordingly. | Search crawlers interpret 405 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 501 expect Not Implemented semantics. | API clients branching on 405 expect Method Not Allowed semantics. |
| Safe to retry? | Yes, with backoff — server may recover | Only after fixing the underlying cause |
Common real-world scenarios
When you see HTTP 501
501 appears in production when: Unhandled server-side exception; Upstream service failure.
When you see HTTP 405
Common when API clients use incorrect HTTP methods (GET instead of POST, DELETE on a read-only endpoint). Also appears after API design changes that restrict previously-allowed methods. Spikes in 405 after a deployment indicate a breaking API change.
Decision rule
Use 501 when the response should communicate not implemented behavior; use 405 when method not allowed is the accurate protocol signal.
A frequent mistake is swapping 501 and 405 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 501 when the correct protocol signal is Not Implemented. Use 405 when the correct signal is Method Not Allowed. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 501 and 405?
501 communicates Not Implemented, while 405 communicates Method Not Allowed. Choosing the right one keeps clients and intermediaries predictable.
Do 501 and 405 have SEO or caching impact?
Yes. Search engines and caches interpret status classes differently. Use each code according to its semantics to avoid accidental indexing, stale responses, or crawl inefficiency.
Can APIs safely return 501 instead of 405?
Only when it matches contract semantics. API clients often branch logic by exact code, so swapping them can break retries, auth handling, or user-facing errors.
Full guides
HTTP 501 Not Implemented — full guide · HTTP 501 status reference · HTTP 405 Method Not Allowed — full guide · HTTP 405 status reference · All comparisons