In short. Conditional HTTP requests let clients check stored responses using validators and reuse content when revalidation returns 304 Not Modified.

Definition: Conditional HTTP requests carry header fields that specify conditions to test before applying the requested method. For repeated fetching, these conditions can use a validator, a value describing a previously retrieved version, to check whether stored content remains usable.

Key facts

RFC 9110, HTTP Semantics defines two validator forms: modification dates and entity tags, which identify versions of a resource's representation.
RFC 9111, HTTP Caching specifies that a 304 Not Modified response lets a cache update and reuse a stored response.
As of June 2026, Google's crawler documentation documents support for the ETag/If-None-Match and Last-Modified/If-Modified-Since header pairs.

Which headers carry validators?

RFC 9110's validator definitions describe ETag as an opaque quoted string. Last-Modified supplies the date and time when the server believes the selected representation last changed. Examples from the specification are:

ETag: "xyzzy"
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

A strong validator changes whenever the representation data changes. A weak validator can group versions considered equivalent for reuse; a weak ETag carries the prefix W/. The specification permits weak tags for cache validation through If-None-Match, which uses weak comparison.

On a later GET request, the client can send the stored tag in a request header, using the specification's example:

If-None-Match: "xyzzy"

The corresponding date condition is If-Modified-Since.

How does revalidation work?

A cache stores responses for reuse. RFC 9111's freshness rules allow a fresh response, one still within its freshness lifetime, to satisfy later requests without contacting the origin server. Cache-Control's max-age directive or the Expires header can provide an explicit expiration time.

When a cache has a stored response it cannot serve directly, for example because it is stale, it can send a conditional request containing stored validators. This process is called revalidation. A 304 response allows the cache to update stored metadata and reuse the content. A full response containing content replaces the nominated stored response for that request, and caching rules determine whether the replacement can be stored.

Under RFC 9110, a 304 response contains no content or trailers: the client uses its stored representation.

What does this change for crawler fetching?

Google's overview of crawlers and fetchers states that Googlebot supports caching when recrawling URLs for Google Search. Individual crawlers and fetchers use caching according to their product's needs.

The documentation recommends setting both ETag and Last-Modified. When both are present, Google's crawlers use ETag; Google recommends it because it avoids date formatting issues. For implementation, the documentation directs website owners to their hosting or content management system provider.

FAQ

What happens if you send both conditions?

RFC 9110 requires the recipient to ignore If-Modified-Since when If-None-Match is present. The entity tag condition takes precedence.

Can you require validation before each reuse?

Under RFC 9111, a response carrying Cache-Control: no-cache without an argument requires forwarding for validation and a successful response before reuse. A successful validation can allow reuse of stored content.

Sources

Check how a page reads to answer engines. Open the GEO score analyzer