HTTP 415 Unsupported Media Type
HTTP 415 Unsupported Media Type is returned when the origin refuses a request because its payload is in a format the target resource does not support — for example sending XML to an endpoint that only accepts JSON, or omitting the Content-Type header. It is a request-format error on the write path, so read-only page crawling does not normally produce it.
What 415 means
415 Unsupported Media Type, defined in RFC 9110, indicates the server is refusing the request because the payload format is unsupported for the target resource. This is usually about the Content-Type (and sometimes Content-Encoding) the client declared, or a missing Content-Type altogether.
A typical example: an API endpoint that only consumes application/json receives a request with text/xml or no Content-Type, and answers 415 rather than attempting to parse it.
415 versus 406 and crawling
Do not confuse 415 with 406 Not Acceptable. 415 is about the format the client sent (the request body); 406 is about the format the client is willing to receive (the Accept header). They sit on opposite sides of negotiation.
Search crawlers requesting HTML pages do not normally trigger 415, because GET requests have no body to reject. When 415 appears, look at API clients and their Content-Type headers, not at your indexable content.
- 415 = the request's payload format is unsupported
- Often a missing or wrong Content-Type header
- Distinct from 406, which concerns the Accept header
How it appears in analytics and logs
A 415 means the server understood the request but rejected the body's format or its declared Content-Type. It points to a client/endpoint format mismatch on POST/PUT/PATCH, not to a page-indexing issue.
Diagnostic use case
Diagnose API calls failing with 415 by sending the Content-Type the endpoint expects, and confirm that page crawling is unaffected by media-type negotiation.
What WebmasterID can help detect
WebmasterID surfaces status codes for traffic, helping you separate API media-type errors (415) from the page-fetch traffic that drives indexing.
Common mistakes
- Omitting the Content-Type header on a POST and getting 415.
- Confusing 415 (request format) with 406 (response format the client accepts).
- Assuming a crawler caused 415 when its GET requests carry no body.
Privacy and accuracy notes
A 415 is a content-format status with no personal data. WebmasterID records the status without storing the request payload.
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 422 Unprocessable Entity
HTTP 422 Unprocessable Entity (originally from WebDAV, RFC 4918, and listed in the IANA registry) means the server understood the request's content type and syntax but cannot process the contained instructions due to semantic errors — for example a valid JSON body that fails business-rule validation. It is widely used by APIs to signal validation failures, sitting between syntactic 400 and successful processing.
- 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.
- Website observability
Separate API media-type errors from page-crawl traffic, 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.