405 Method Not Allowed 4xx

What does 405 mean?

A 405 Method Not Allowed response means the server recognizes the requested URL and resource, but the specific HTTP method used (GET, POST, PUT, DELETE, etc.) isn't supported for that resource. The resource itself isn't missing (that would be 404) — it's that this particular way of interacting with it isn't allowed.

A classic example: an API endpoint /users/123 might support GET (fetch the user) and DELETE (remove the user), but not POST — sending a POST to that URL would return 405, since the URL is valid but POST isn't one of the supported methods for it.

How a 405 behaves

• It should include an Allow header listing the methods that are supported for this resource (e.g., Allow: GET, DELETE) — this is one of the most useful things a 405 response can provide
• It can carry a body, often explaining which methods are supported
• It's not cacheable in a meaningful sense — though the set of allowed methods for a resource is often static, so a client could reasonably remember this for a given URL
• It implies the URL routing itself succeeded — the server found a matching resource/route, it just doesn't support the method used; this distinguishes it from 404, where the URL itself doesn't match anything

Common causes

If you're building the API or website:

• An endpoint is correctly restricting which methods it accepts (e.g., a read-only endpoint rejecting POST/PUT/DELETE), and 405 is the system working as intended
• A routing configuration error — a route is defined for some methods but not others, and a client is using a method that was never implemented
• A typo or outdated client is using the wrong method for an endpoint (e.g., using PUT when the API expects PATCH for partial updates)

If you're calling an API:

• You're using the wrong HTTP method for an endpoint — check the API documentation for the exact method expected (PUT vs PATCH is a particularly common point of confusion)
• An endpoint that used to support a method (e.g., in an older API version) no longer does in the current version
• You're sending a request to a URL pattern that's correct, but with a method that endpoint genuinely doesn't support (e.g., trying to DELETE a read-only resource)

If you're a website visitor:

• Rare to encounter directly — 405 is primarily an API/development concern. If it surfaces in a browser, it's often due to a misconfigured form (e.g., a form's method attribute doesn't match what the server-side route expects)

How to fix it

As an API/website builder:

• Always include the Allow header on 405 responses, listing the methods that are actually supported — this turns a confusing error into actionable information
• Double-check routing configuration — make sure all intended methods are registered for each endpoint, and that unintended methods are deliberately rejected (rather than accidentally falling through to a 404 or, worse, being handled by an unrelated route)
• If an endpoint's supported methods have changed between API versions, document this clearly in changelog/migration guides

As an API consumer:

• Check the Allow header in the 405 response — it tells you exactly which methods are valid for this URL
• Cross-reference the API documentation for the correct method — pay particular attention to PUT vs PATCH (full replacement vs partial update) and POST vs PUT (create vs update) distinctions, which are common sources of 405s
• If you recently upgraded to a new API version, check the changelog for method support changes on endpoints you use

As a website visitor:

• If you encounter this on a form submission, it's a site-side configuration issue (the form's method doesn't match what the server expects) — not something fixable from your end beyond reporting it to the site

404 vs 405 vs 403

A useful way to think about the order: the server first checks if the URL matches anything (404 if not), then if the method is supported for that URL (405 if not), then if the requester is authorized (403 if not).

Real-world examples

REST APIs that strictly enforce method semantics — read-only endpoints that only support GET, or endpoints that support GET and POST but not PUT/DELETE — commonly return 405 with an Allow header when a client uses an unsupported method, helping API consumers quickly identify and correct method-related mistakes during integration development.

SEO implications

405 is primarily relevant to API endpoints and form submissions rather than standard page navigation (which uses GET, almost universally supported). It has minimal direct SEO impact, though a misconfigured server that returns 405 for GET requests to pages that should be accessible would be a significant — if unusual — crawlability issue worth investigating immediately.

FAQ

What's the difference between 404 and 405?

404 means the URL itself doesn't match any resource on the server. 405 means the URL does match a resource, but the specific HTTP method you used isn't supported for it — the resource exists, just not for this kind of request.

What is the Allow header for?

It lists the HTTP methods that are supported for the requested resource, helping the client understand what it should have used instead. For example, Allow: GET, POST tells the client this URL supports GET and POST, but not whatever method it tried.

Why am I getting 405 when I'm sure the endpoint exists?

Double-check the exact HTTP method required — PUT vs PATCH and POST vs PUT are common mix-ups. Also verify you're not accidentally hitting a different (but similarly-named) route that supports different methods than the one you intended.

Can 405 happen even with valid authentication?

Yes — method support is typically checked independently of (and often before) authorization. You can have perfectly valid credentials and still get a 405 if the method itself isn't supported for that endpoint, regardless of who's asking.

Is 405 common in regular website browsing?

Rarely — normal page navigation uses GET, which is virtually always supported. 405 is far more common in API development and testing, where developers are more likely to experiment with different HTTP methods against various endpoints.

Fun fact

405 is one of the clearest examples of HTTP's layered design — it exists specifically to separate "does this URL exist?" (404's job) from "is this kind of request valid for it?" (405's job), allowing a single URL to mean different things depending on the method used, which is the foundation of how REST APIs represent multiple operations (read, create, update, delete) through a single, consistent URL structure.