In short. Content negotiation uses request information to select a representation, while response headers describe the chosen content and its cache dependencies.

Definition: Content negotiation is the HTTP process for selecting a representation, a transferable form of a resource's state, such as a particular format or language. In server-driven negotiation, the server uses information in the request, including preference headers, to choose among available representations.

Key facts

The IETF's RFC 9110, HTTP Semantics, published in June 2022, defines server-driven selection as proactive negotiation.
Under the IETF's RFC 9111, HTTP Caching, a cache, which stores responses for reuse, checks the request headers named in the response's Vary field before reuse without revalidation.
As of 17 October 2026, Google's locale-adaptive crawling documentation states that Googlebot sends requests without an Accept-Language header.

How do request headers guide selection?

A media type identifies a data format, such as text/html. In RFC 9110, Accept expresses preferences for response media types, Accept-Language expresses language preferences, and Accept-Encoding identifies acceptable content codings, such as gzip compression.

These request header examples come from the RFC:

Accept: text/plain; q=0.5, text/html,
       text/x-dvi; q=0.8, text/x-c
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Accept-Encoding: compress, gzip

The q parameter gives a relative preference weight. Its range is zero to one; zero means unacceptable, and an omitted weight defaults to one. In the language example, Danish has the highest preference, followed by British English and then other English variants.

The server compares these preferences with the representations it has available. A missing negotiation header expresses no preference on that dimension. If nothing available meets the stated preferences, the server can return 406 Not Acceptable or disregard the preference and send a fallback representation.

What do response headers and Vary describe?

The response describes the selected representation. RFC 9110 defines Content-Type for its media type, Content-Encoding for applied content codings, and Content-Language for the natural languages of its intended audience.

The RFC gives this response header example:

Vary: accept-encoding, accept-language

It signals that those request fields, including their absence, might have influenced selection. A cache stores responses for later reuse. Under RFC 9111, reuse without revalidation requires matching values for the fields named in Vary, allowing normalization that preserves their meaning. An absent field matches another absent field. The specification also identifies omitted Vary headers on default responses as a cause of less suitable cached responses being reused.

Why does language negotiation matter for crawling?

A locale-adaptive page changes its content according to a visitor's perceived country or preferred language. Google's documentation on these pages warns that Google might miss content for some locales. Its documented omission of Accept-Language makes the response to a request without that field relevant to a crawl review.

Google recommends separate URLs for locale versions, connected by alternate-language annotations using the hreflang attribute. Each locale version then has its own address.

How can a website's selection be checked?

A practical check follows the request and response fields defined in RFC 9110: compare requests to the same URL with different Accept, Accept-Language, or Accept-Encoding values, then compare the returned content and representation headers. Include a request without language preferences. For responses intended for selective cache reuse, check whether Vary names the request fields involved in selection.

FAQ

Does an Accept header force the server to send that format?

The server can honor your preference or disregard it. RFC 9110 permits a 406 Not Acceptable response when available representations fail the requested preferences, as well as a fallback response that ignores the preference.

Should I set Vary when serving different languages at one URL?

RFC 9110 recommends Vary on cacheable responses intended for selective reuse, including when Accept-Language determines the language. If your selection depends on that header, Vary: Accept-Language tells caches about the dependency.

Sources

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