405 vs 501: Method Not Allowed vs Not Implemented
405 and 501 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 405 — Method Not Allowed | HTTP 501 — Not Implemented |
|---|---|---|
| Definition | 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. | 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. |
| Plain-language summary | 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. | HTTP 501 Not Implemented means the server does not support the functionality required to fulfill the request. |
| When to use | 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). | HTTP 501 Not Implemented means the server does not support the functionality required to fulfill the request. |
| Client behavior | Do not retry with the same method. Read the Allow header to determine which methods are supported and retry with a valid method. | Client handles 501 according to server-errors semantics. |
| Caching behavior | Not cached. | See 501 caching spec. |
| SEO / crawler impact | Search crawlers interpret 405 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 501 (server-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 405 expect Method Not Allowed semantics. | API clients branching on 501 expect Not Implemented semantics. |
| Safe to retry? | Only after fixing the underlying cause | Yes, with backoff — server may recover |
Common real-world scenarios
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.
When you see HTTP 501
501 appears in production when: Unhandled server-side exception; Upstream service failure.
Decision rule
Use 405 when the response should communicate method not allowed behavior; use 501 when not implemented is the accurate protocol signal.
A frequent mistake is swapping 405 and 501 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 405 when the correct protocol signal is Method Not Allowed. Use 501 when the correct signal is Not Implemented. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 405 and 501?
405 communicates Method Not Allowed, while 501 communicates Not Implemented. Choosing the right one keeps clients and intermediaries predictable.
Do 405 and 501 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 405 instead of 501?
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 405 Method Not Allowed — full guide · HTTP 405 status reference · HTTP 501 Not Implemented — full guide · HTTP 501 status reference · All comparisons