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.
What 413 means
413 Content Too Large indicates the request body exceeds limits the server enforces. RFC 9110 renamed the older 'Payload Too Large' phrase to 'Content Too Large', but the code and meaning are unchanged. The limit may come from the web server, an application framework, or a proxy in front of the origin.
If the oversized condition is temporary — for example a rate or quota that will reset — the server can send a Retry-After header telling the client when to try again.
Where it shows up and the fix
413 typically appears on file-upload endpoints, image or document submission, and large JSON POST bodies. The fix is to align the client and the full server chain: raise the body-size limit at every hop (web server, app, proxy/CDN), or have the client chunk or compress the payload.
Because search crawlers fetch pages with bodiless GET requests, they do not hit 413 during indexing. Treat a 413 in logs as an application or infrastructure limit, not an SEO problem.
- Renamed from 'Payload Too Large'; same 413 code
- Raise size limits across server, app, and proxy/CDN
- GET-based page crawling does not trigger 413
How it appears in analytics and logs
A 413 means the server rejected a request because its body was too big. It is a write-path limit, typically on uploads or APIs, not a signal about page indexability. Search crawler GETs do not trigger it.
Diagnostic use case
Diagnose failing uploads or large form posts returning 413 by raising body-size limits or chunking the upload, and confirm page crawling is unaffected.
What WebmasterID can help detect
WebmasterID surfaces status codes for traffic, helping you isolate upload/API size-limit errors (413) from the GET-based crawling of indexable pages.
Common mistakes
- Raising the limit on the app but not on the front proxy/CDN, so 413 persists.
- Treating 413 as an indexing issue when it only affects body-bearing requests.
- Ignoring a Retry-After on a temporary 413 and hammering the endpoint.
Privacy and accuracy notes
A 413 is a request-size status with no personal data. WebmasterID records the status without inspecting or storing the oversized request body.
Related pages
- HTTP 414 URI Too Long
HTTP 414 URI Too Long is returned when the request-target URI is longer than the server is willing to interpret. It often comes from query strings that have grown unbounded — for example a GET form that should have been a POST, parameters appended in a loop, or a redirect that keeps stacking parameters. For crawling, over-long parameterised URLs can both waste crawl budget and trip 414s.
- 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.
- 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.
- Website observability
Separate upload size errors 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.