HTTP 412 Precondition Failed
HTTP 412 Precondition Failed is returned when one or more preconditions in the request headers — such as If-Match or If-Unmodified-Since — evaluate to false against the current resource. It is the negative outcome of conditional requests used to avoid lost updates. It is distinct from 304 Not Modified, which is the cache-validation outcome for conditional GETs that crawlers rely on.
What 412 means
412 Precondition Failed, defined in RFC 9110, is returned when a precondition header in the request is false for the target resource's current state. The classic case is If-Match with an ETag for optimistic concurrency: the client says 'update this only if it still has this version'; if the version changed, the server answers 412 instead of overwriting newer data.
If-Unmodified-Since works the same way with a timestamp. The point is to prevent the lost-update problem when several clients edit the same resource.
412 versus 304 for crawlers
Crawlers commonly send conditional GETs with If-None-Match (an ETag) or If-Modified-Since. When the resource is unchanged, the server returns 304 Not Modified and the crawler reuses its cached copy, saving bandwidth and crawl budget. That is the healthy, expected conditional outcome on the read path.
412 lives on the write path. If you see 412 in logs tied to GET page fetches, something is sending the wrong precondition header; for API writes, 412 is the correct way to reject a stale update.
- 412 = a precondition (If-Match / If-Unmodified-Since) failed
- 304 = conditional GET found the resource unchanged
- Crawlers use 304 for caching; 412 is for write concurrency
How it appears in analytics and logs
A 412 means a precondition the client set was not satisfied, so the server refused to perform the request. For crawling specifically, the related signal is usually 304, not 412; a 412 typically points to an API write using If-Match for concurrency control.
Diagnostic use case
Distinguish 412 on conditional writes (optimistic concurrency) from the 304 cache responses crawlers use, so you debug the correct conditional flow.
What WebmasterID can help detect
WebmasterID surfaces status codes including conditional outcomes, helping you separate cache-validation traffic (304) crawlers use from precondition failures (412) on your write endpoints.
Common mistakes
- Confusing 412 with 304 — one rejects a write, the other confirms an unchanged cache.
- Using If-Match on read requests and being surprised by 412.
- Ignoring 412 on write APIs, then overwriting newer data when you remove the precondition.
Privacy and accuracy notes
A 412 is a request-level conditional outcome with no personal data. WebmasterID records the status without storing entity tags or visitor identity.
Related pages
- HTTP 304 Not Modified and crawl efficiency
304 Not Modified is the response to a conditional request when the resource has not changed since the client last fetched it. The server returns no body, so the crawler reuses its cached copy. Correct conditional-request support with ETag or Last-Modified saves bandwidth and crawl budget.
- HTTP 409 Conflict
409 Conflict means the request could not be completed because it conflicts with the current state of the target resource — for example a concurrent edit or a version mismatch. It arises in write and API workflows, not in the GET fetches crawlers issue, so a 409 in crawler logs usually points at an action endpoint being reached.
- 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.
- Website observability
Separate cache-validation (304) from precondition failures (412) in crawler 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.