Accept-Language header

Accept-Language is a header a browser sends with every page request to say which languages its user would like to read, in order of preference. A server can use it to pick a language version of the page, a process called content negotiation, and report its choice in the Content-Language response header.

What the header looks like#

The value is a list of language tags, the same BCP 47 tags hreflang uses. Each one after the first can carry a weight, its q-value, between 0 and 1. MDN's reference gives this example:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

The user prefers Danish, will take British English next, and any English after that. An asterisk, *, stands for any language.

Browsers fill the header in for the user. MDN notes that it follows the browser's interface language plus any languages added in its settings, and usually lists the same locales as navigator.languages in JavaScript. For privacy, some browsers send less: Safari, and Chrome in incognito mode, list a single language.

What servers should do with it#

MDN's guidance is that a server should treat the header as a hint and never let it override a language the user chose explicitly, for example by following a link to a URL for that language. The header says what a browser is set to, which can be the language of a computer someone was given at work, and not necessarily the language they want for your site.

Search engines add a second reason. Google's documentation on locale-adaptive pages says Googlebot sends its requests without an Accept-Language header, and that its crawler addresses appear mostly to be in the United States. A site that chooses the language from the header therefore shows Googlebot the default version only. Google's recommendation is a separate URL for each locale, annotated with hreflang.

A worked example#

A visitor in Antwerp sends nl-BE, nl;q=0.9, en;q=0.8 to a site with English and Dutch versions. A negotiating server would answer the homepage request with the Dutch page. If that visitor follows a shared link to an English article, a server that still negotiates could switch them to Dutch against their choice, and Googlebot, sending no header at all, would only ever see English at that address.

How LangRelay handles it#

LangRelay never uses Accept-Language to decide what a URL returns. On WordPress, every language has its own address under its prefix, such as /nl/, so the same URL returns the same language to every visitor and to every crawler. Visitors change language with the switcher, and the hreflang set, including x-default, tells search engines which version is meant for whom.

The visitor's preference can still be offered as a hint. From plugin 2.10.0, a script in the visitor's browser reads the browser's own list of languages, navigator.languages, rather than the header. On the first page of a visit, if that page is also live in a language the visitor prefers, LangRelay offers the visitor, in their language, the page in that language. The site owner can turn this off, or choose to take such visitors to their language before the page appears, with a notice and a link back. Crawlers are never redirected, nobody is sent to a page without a translation, and the visitor's answer stays in their browser for a year. The x-default entry covers that fallback, and language switcher best practices covers the switcher itself. For how tags such as nl-BE are built, see locale.