If-None-Match

ETag-based cache revalidation is the primary mechanism for avoiding redundant downloads. The HTTP If-None-Match request header makes a request conditional, asking the server to return the resource only if none of the provided ETag values match the current version.

Table of Contents

Usage

The If-None-Match header enables cache revalidation based on entity tags. The client includes one or more ETag values received on a previous response. If any listed ETag matches the current resource, the server returns a 304 Not Modified response with no body, and the client reuses its cached copy. If no ETag matches, the server sends a normal 200 response with the updated content.

For safe methods like GET and HEAD, this is the primary cache revalidation mechanism. For unsafe methods like PUT, If-None-Match with the wildcard * prevents overwriting an existing resource, avoiding the lost update problem. The server returns 412 Precondition Failed when a match is found on an unsafe request.

When both If-None-Match and If-Modified-Since appear in the same request, If-None-Match takes precedence. ETag-based comparison is more reliable than date-based comparison because entity tags are opaque identifiers tied to the exact content, while timestamps have one-second resolution and are subject to clock skew.

When the server returns 304, the response includes headers from the original successful response: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

Values

ETag value

One or more ETag values, each enclosed in double quotes. Multiple values are comma-separated. Both strong and weak ETags (prefixed with W/) are valid.

* (wildcard)

The wildcard * matches any current entity. Used with PUT to make the request create-only: when a representation already exists, the condition fails and the server answers 412 instead of overwriting.

Example

A client revalidates a cached resource using a single ETag. The server returns 304 if the resource still matches the given entity tag.

If-None-Match: "abc123"

A client holding multiple cached versions sends all known ETags. The server checks each against the current resource. If any match, the server returns 304.

If-None-Match: "abc123", "def456"

A weak ETag comparison. Weak validators indicate semantic equivalence rather than byte-for-byte identity. The W/ prefix signals weak comparison.

If-None-Match: W/"v2.6"

A PUT request using the wildcard to prevent overwriting. The server returns 412 Precondition Failed if a resource already exists at the target URL.

PUT /api/resource HTTP/1.1
If-None-Match: *

Crawlers and If-None-Match

Googlebot sends If-None-Match when recrawling a URL, carrying the ETag value from the previous visit. A server recognizing the value answers 304 with no body, which conserves bandwidth on both sides and leaves crawl budget for URLs holding new content.

Google recommends ETag validation ahead of Last-Modified dates, describing entity tags as less prone to error. Servers answering every recrawl with 200 and a full body spend budget re-transferring content the crawler already holds. Setting the max-age field of the Cache-Control response header to the seconds the content stays unchanged additionally helps crawlers decide when to recrawl a URL.

Verified crawler probe

Probe data from verified crawler traffic (September 2026 snapshot) shows which bots send If-None-Match when requesting pages. Yes marks the header on at least nine of ten sampled requests from the bot, Sometimes marks a smaller share, and No marks absence.

Crawler Sends If-None-Match
Amazonbot No
Applebot No
Baiduspider No
Bingbot No
ClaudeBot No
DuckDuckBot No
GPTBot No
Googlebot No
Googlebot (smartphone) No
Googlebot-Image No
Meta-ExternalAgent No
Meta-WebIndexer No
OAI-SearchBot No
SeznamBot No
YandexBot No
YandexFavicons No

See also

Last updated: September 21, 2026