Fixing 405 Method Not Allowed

A 405 is unambiguous in a way that a 403 is not. The server found something at that path, and it will not accept the method you used. The resource exists; your verb is wrong.

That makes it one of the easier errors to fix, once you know the causes.

What the status means

The HTTP specification defines a set of methods, and servers declare which are permitted for a given resource by returning 405 with an Allow header listing the accepted values.

HTTP/1.1 405 Method Not Allowed
Allow: POST

The Allow header is the single most useful piece of information here, and it is frequently overlooked. Look at the response headers before doing anything else.

Two related statuses get confused with it:

• 404 Not Found means no resource at that path. A 404 is not a method problem.
• 501 Not Implemented means the server does not support the method at all, anywhere. Different from a 405, which is resource-specific.

Cause 1: the endpoint is POST-only

The most common cause in scraping. Many modern APIs use POST for reads, particularly where the query is a JSON body rather than URL parameters, or where the payload would make a long URL.

curl -X POST https://example.com/api/search \
  -H "Content-Type: application/json" \
  -d '{"query": "shoes", "page": 1}'

If you found this endpoint in the browser's Network tab, check the method column before reproducing it. It is easy to copy a request and assume it was a GET.

Cause 2: the resource expects a different verb by design

REST conventions are not always followed. Two cases that appear in the wild:

• PUT or PATCH for updates that a site uses for actions you might reasonably read, such as fetching a saved view.
• DELETE for removal, which occasionally doubles as a status change.

Read the API documentation where it exists. If there is no documentation, the Network tab is your reference.

Cause 3: a WAF or proxy rewriting methods

This is the cause people miss. A web application firewall, a reverse proxy or a CDN in front of the application can reject a method it considers unusual, or rewrite it.

Two common patterns:

• OPTIONS and TRACE blocked as a security measure, which is reasonable but means preflight behaviour differs from a plain request.
• HEAD rejected even where GET is allowed, because the proxy does not forward it.

If a direct request works and a proxied one returns 405, the proxy layer is rewriting method handling. That is worth testing explicitly.

Cause 4: a preflight or CORS interaction

For browser-based requests, an OPTIONS preflight may be sent first, and if the server or an intermediary rejects it, the request never proceeds. If you are driving a browser and seeing 405 on an OPTIONS request, that is the mechanism.

The fix is usually to make the actual request simpler: avoid custom headers that trigger preflight, or use a form-encoded body instead of JSON, which browsers treat as a simple request.

Cause 5: you are hitting the wrong path

Sometimes the path you assembled is a valid route for one method and the method you sent belongs to a sibling path. A trailing slash is the classic example: /api/products and /api/products/ can be different routes with different allowed methods.

Test both. It takes seconds and resolves this case entirely.

A diagnostic sequence

1. Read the Allow header            -> often tells you the verb directly
2. Check the browser's method       -> confirm what the site itself uses
3. Try POST with a JSON body        -> resolves most read-endpoint cases
4. Test with and without trailing / -> resolves path/route mismatches
5. Test direct vs through the proxy -> separates proxy rewriting from server behaviour
6. Check OPTIONS in a browser       -> confirms preflight issues

Work down that list before speculating. Each step is cheap, and together they cover almost every case.

Why this is rarely an anti-bot signal

It is worth saying plainly: a 405 is usually a straightforward API contract mismatch rather than bot detection. Do not reach for proxies or fingerprints.

If, however, you see 405s appearing only after a certain number of requests, and they correlate with other responses such as 429s, then behaviour is in play. Log the status alongside the request count and exit IP so you can see the correlation. The broader distinction is in Rate Limiting vs Blocking.

Instrument it

The reason 405s consume time is that people do not record enough to see the pattern. Log the method, the full URL including query string and trailing slash behaviour, and the Allow header when present. With those fields, a 405 is self-explaining.

That logging discipline applies to every status code, and the broader approach is in Monitoring Scraper Health. For the neighbouring cases, Fixing 403 Forbidden Errors When Scraping covers the rejection you cannot read this directly, and The 499 Status Code Explained covers the one that means something entirely different.