HTTP 411 Length Required
HTTP 411 Length Required is returned when the server refuses to accept a request that does not define a Content-Length header. It applies to requests with a body — typically POST or PUT — where the server insists on a declared length rather than a chunked or undefined one. GET requests from crawlers have no body, so crawlers essentially never see a 411 on normal page fetches.
What 411 means
411 Length Required, defined in RFC 9110, lets a server decline a request whose body length is undefined — that is, one without a Content-Length header. The server is saying it will only accept the request if the client states how many bytes the body contains.
This matters for methods that carry a body, such as POST and PUT. A client that streams a body without declaring its length, and without using a transfer encoding the server accepts, can be met with 411.
Why it rarely affects crawling
Search crawlers fetch pages with GET requests, which have no body and therefore no Content-Length expectation, so they do not normally encounter 411. When you see 411s, the source is almost always an API integration, an upload endpoint, or a script sending POST/PUT without a length.
The fix is on the client: send a Content-Length header, or use a transfer encoding the server supports. It is not a robots.txt or canonical concern.
- 411 applies to body-bearing requests (POST/PUT), not GET
- Crawler page fetches use GET and are unaffected
- Fix on the client: send Content-Length
How it appears in analytics and logs
A 411 means the server rejected a body-bearing request for lacking Content-Length. It is a client-side framing problem on writes, not an indexing signal for read-only page crawling. If it appears in logs, look at API clients, not search bots.
Diagnostic use case
Diagnose API or form-submission failures returning 411 by ensuring the client sends a Content-Length, and confirm normal crawler GETs are unaffected.
What WebmasterID can help detect
WebmasterID surfaces the status codes traffic receives, helping you separate body-framing errors like 411 on API endpoints from the GET-based crawling of your indexable pages.
Common mistakes
- Looking for an SEO cause for 411 when it is an API/client framing issue.
- Assuming a search crawler triggered 411 — its GET requests carry no body.
- Stripping Content-Length in a proxy and then seeing the origin reject the request.
Privacy and accuracy notes
A 411 is a request-framing status with no personal data. WebmasterID records the status without inspecting or storing request bodies.
Related pages
- HTTP 400 Bad Request for crawlers
400 Bad Request means the server refused to process the request because it appeared malformed — bad syntax, invalid headers, or a request the server cannot interpret. Seeing 400s for crawlers usually points at malformed URLs, encoding issues, or a misbehaving edge layer rather than the crawler itself.
- HTTP 413 Content Too Large
HTTP 413 Content Too Large — renamed from Payload Too Large in RFC 9110 — is returned when the request body is larger than the server is willing or able to process. It commonly appears on upload endpoints and large POST bodies. The server may include a Retry-After header if the condition is temporary. Read-only crawler GETs carry no body, so this status does not affect normal page indexing.
- HTTP 405 Method Not Allowed
405 Method Not Allowed means the server recognises the request method but the target resource does not support it — for example a POST to a GET-only page. For crawlers, which issue GET (and sometimes HEAD), a 405 usually means the route does not allow GET, often a misconfiguration on a URL that should serve a page.
- Website observability
Tell API framing errors apart from page-crawl status codes, recorded server-side.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.