Languages

The HTML lang Attribute

What the HTML lang attribute does, why Google ignores it for language detection but Bing uses it, how it differs from hreflang, and why it still matters for accessibility and the browser auto-translate prompt.

First published: Jul 2, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #2 in Html Seo#25 in On-Page#110 in Technical SEO#146 on the site
AIAuthored byAI v2
1 evidence signal on this page

The HTML lang attribute — set on the root as <html lang="en"> (or a region variant like en-US) — declares the natural language of THIS document's content using a BCP 47 tag. It is not the same as hreflang: lang describes the page it's on; hreflang declares alternate-language URLs for other pages. Google is blunt that it ignores lang for language detection ('we don't use that at all… almost always wrong' — Mueller); it uses content algorithms instead. Bing is the opposite: its 2011 Webmaster Blog names <html lang> as a fallback document-location signal, behind the content-language meta tag. Regardless of search weight, lang is a required accessibility attribute (WCAG 3.1.1) — it drives screen-reader pronunciation and the browser's auto-translate prompt, and 'missing document language' is still a top-six WebAIM Million failure. The one Google carve-out: labeling machine-translated blocks with lang="es-x-mtfrom-en". Set a valid value, keep it consistent with hreflang, and don't leave a boilerplate lang="en" on non-English content.

TL;DR — lang declares the natural language of this document (<html lang="en">, or a region variant like en-US) using a BCP 47 tag. It is a different mechanism from hreflang, which declares alternate-language URLs — Google’s own docs group the two together as things it does not use to detect a page’s language. Mueller: “we don’t use that at all… almost always wrong.” Regardless of search weight, a programmatically determinable page language is a WCAG 3.1.1 Level A requirement, and the HTML lang attribute is the standard technique. It supports screen-reader pronunciation and the browser auto-translate prompt, and “missing document language” is still a top-six WebAIM Million failure. The one Google carve-out: labeling machine-translated blocks with lang="es-x-mtfrom-en". Set a valid value, keep it consistent with hreflang, and kill the boilerplate lang="en" on non-English pages.

What the lang attribute actually declares

The HTML lang attribute is a global attribute — it can technically go on any element — but the one that matters most sits on the root: <html lang="en">. Its value is a BCP 47 language tag, either a language subtag on its own (en, es, de) or a language-plus-region pair (en-US, en-GB, pt-BR, zh-Hans).

What it declares is narrow and specific: the natural language of the text content on the document it’s set on. Not the language of your alternate pages, not the country you’re targeting — just “the words on this page are in this language.”

Evidence for this claim The HTML lang attribute specifies an element's language using a valid BCP 47 language tag; on the root html element it establishes the document's default language. Scope: WHATWG HTML language semantics and IETF BCP 47 tag syntax. Confidence: high · Verified: WHATWG: The lang attribute IETF RFC 5646 Evidence for this claim WCAG 2.2 success criterion 3.1.1 requires the default human language of a page to be programmatically determinable, and W3C lists lang on the html element as a sufficient HTML technique. Scope: WCAG 2.2 Level A language-of-page requirement for HTML documents. Confidence: high · Verified: W3C: Understanding Language of Page

Three precision points worth internalizing, drawn from the MDN reference:

  • Valid values only. A BCP 47 tag — not a made-up three-letter code (eng), not a full language name, and not en-UK (the region subtag for the United Kingdom is GB). Invalid values get treated as no value. Syntactically well-formed isn’t the same as correct, either: lang="en" is a perfectly valid tag that’s still wrong on a French page. Validity is a floor, not a guarantee the value actually matches the content (more on that in the boilerplate-default trap below).
  • Empty is not the same as absent. An explicit lang="" means “unknown language” — a deliberate state. A genuinely missing attribute is a different failure mode, and accessibility tools flag it as absent rather than explicitly-unknown.
  • The root value is a default, not a lock. <html lang> sets what every descendant inherits unless it’s overridden — reset lang locally on any element containing a real language change (see “Set it on the element that changes, too” below). Don’t confuse this in-document declaration with the HTTP Content-Language response header: that header describes transport metadata about the response, not the parsed document, and it isn’t a substitute for lang when it comes to element-level inheritance or accessibility.

lang vs. hreflang: the confusion, resolved

If you landed here from a hreflang question, this is the section you want. These two get conflated constantly because they’re both language-related, both live at or near the top of the document, and both use similar-looking codes. But they do unrelated jobs.

The cleanest articulation comes straight from Google’s own documentation on localized versions of your pages, which groups the two together precisely to say it uses neither for detection:

“Google doesn’t use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.”

Read that carefully. Google names both lang and hreflang in one breath — as two separate things it does not use to figure out what language a page is in. It detects language from the rendered, visible content instead.

So what’s the actual difference?

  • lang is a self-description: one value, on <html> (or any element), saying “this document’s content is in this language.” Read by browsers, screen readers, spell-checkers; used by Bing; ignored by Google for detection.
  • hreflang is a cross-page map: a set of <link rel="alternate"> annotations (or the sitemap/header equivalent) listing the other URLs that are alternate language/region versions of this page, and which language each targets. It’s a routing signal Google does use — to serve the right URL variant in results — not a detection signal.

They can and often should coexist. A Mexican-Spanish page carries <html lang="es-MX"> describing its own content and a set of hreflang tags pointing to its en-US, en-GB, and other siblings. The full implementation of hreflang — the three methods, the reciprocal-linking rule, the self-referential rule, and the scale of how often it breaks — is its own deep dive; this article deliberately doesn’t re-derive it. The one thing to carry across: lang is the simple half of this pair (one value, one element, no reciprocity) precisely because it doesn’t carry hreflang’s cross-page relationship complexity — which John Mueller once called “one of the most complex aspects of SEO.” Easy to set, though, is not the same as commonly correct.

`lang` describes this document for browsers and assistive technology; hreflang maps alternate URLs for search-result routing. Source: Google Search Central

The root lang attribute gives one page a BCP 47 language self-description used by browsers and screen readers. Hreflang is a reciprocal cross-page map between alternate URLs, such as en-US and es-MX versions. Google detects a page's language from visible content rather than either annotation, but the lang value should remain accurate and consistent with the hreflang entry for the same URL.

© Patrick Stox LLC · CC BY 4.0 ·

Is the lang attribute a Google ranking factor?

Short answer: no, and Google has been unusually blunt about it. The definitive statement is John Mueller’s, reported by Barry Schwartz at Search Engine Roundtable in Google: We Ignore The HTML lang Attribute. Asked how important it is to declare a page’s language in the HTML, Mueller said:

“We don’t use that at all. So we use the hreflang links if you have that if you have different language versions. But the language attribute within the HTML markup is something we don’t use at all. We’ve found that this language markup is something that is almost always wrong. So we tend to ignore that.”

That “almost always wrong” is the key phrase. Google’s reason for ignoring lang isn’t “it’s unimportant” — it’s that the signal is unreliable at web scale. People leave boilerplate lang="en" defaults in place after localizing content; CMS and framework templates ship a default that never gets updated (Vue CLI’s generated boilerplate, for instance, hard-codes lang="en" regardless of what you build with it). When a signal is wrong that often, the sane engineering move is to stop trusting it and detect language from the content directly — which is exactly what Google says it does. That 2016 quote is old, but the current (2026) Search Central doc quoted above independently restates the same policy, so treat it as long-standing, unretracted guidance rather than a stale one-off.

The one exception: machine-translated content

There’s a single, narrow place where Google’s docs do care about a lang-style value. If you publish machine-translated content, Google’s translated-results guidance asks you to mark those blocks with a special value format — lang="<target>-x-mtfrom-<source>", e.g. lang="es-x-mtfrom-en" for content machine-translated from English into Spanish. That’s the exception that proves the rule: Google ignores lang for general language detection, but this specific labeling convention is one it defined and reads. (The related lever, if you want to opt out of translation features entirely, is the notranslate rule — “To opt out of all translation features in Google Search, use the notranslate rule, which can be implemented as a meta tag or an HTTP header,” per the same doc.)

Does Bing use the lang attribute?

Yes — and this is where lang gets genuinely more consequential than the “Google ignores it” story suggests. Bing’s stance is the opposite of Google’s, and it’s under-covered almost everywhere.

In its 2011 Webmaster Blog post How To Tell Bing Your Website’s Country and Language, Bing lays out a priority order of “document location” signals it uses for relevance. The order, top to bottom:

  1. The content-language meta tag in the <head> (<meta http-equiv="content-language" content="en-us">).
  2. The <html lang="en-us"> attribute, then the <title lang="en-us"> attribute, as fallbacks — “the priority order for these tags is: <meta>, <html>, <title>.”
  3. ccTLD.
  4. Reverse-IP lookup — used only when the higher signals are inconclusive.

Bing’s advice is to pick one and be consistent: “It’s best that you use one option, instead of multiple options here.” So unlike Google, Bing explicitly uses <html lang> as a real (if lower-priority) targeting signal. For a site with meaningful Bing traffic, that changes the recommended action: set lang correctly, and consider a matching content-language meta tag on top.

Caveat: this is a 2011 post, now delisted from Bing’s current blog archive. I’m citing it via the Wayback Machine capture; no newer Bing statement supersedes it that I could find, so I treat the mechanism as still current — but its age is worth flagging honestly rather than presenting it as fresh guidance.

This also closes the loop with the hreflang side of things: Bing barely uses hreflang the way Google does — content-language plus lang is Bing’s parallel mechanism.

Why the lang attribute matters anyway: accessibility

Even setting search aside entirely, lang earns its place. It is a required accessibility attribute — WCAG Success Criterion 3.1.1 (Level A) requires the default human language of each page to be programmatically determinable, which in practice means a valid <html lang>. A separate criterion, 3.1.2, covers marking language changes within a page.

Evidence for this claim WCAG 2.2 success criterion 3.1.1 requires the default human language of a page to be programmatically determinable, and W3C lists lang on the html element as a sufficient HTML technique. Scope: WCAG 2.2 Level A language-of-page requirement for HTML documents. Confidence: high · Verified: W3C: Understanding Language of Page

The downstream effects are concrete and well-documented (Adrian Roselli’s On Use of Lang Attribute catalogs many): screen readers use lang to pick the correct pronunciation engine and voice (JAWS’s phonetic engine, VoiceOver’s automatic voice switching), CSS hyphens: auto depends on it, spellcheck behavior keys off it, quotation-mark rendering and default CJK font selection follow it, and Braille displays behave differently with it. Exactly how each of these plays out varies by screen reader, browser, and installed voice — Roselli’s own tests show JAWS and VoiceOver don’t behave identically — so treat a correct lang value as enabling the right behavior, not guaranteeing an identical experience across every assistive-technology stack.

And it’s not a solved problem. Per the current WebAIM Million report, “missing document language” sits at 13.5% of home pages — the sixth most common automated accessibility failure on the web. The rate is improving (down from 15.8% the prior year, and 17.1% and 18.6% before that), but “a large, shrinking problem” is still a problem. Google’s own tooling reflects the framing: Lighthouse’s html-has-lang and html-lang-valid checks live under its Accessibility category, not its SEO category — a nice tell that even Google’s developer tools bucket lang as an a11y concern, not a ranking one. Those checks are built on Deque’s axe-core rule of the same name, which classifies a missing lang as a WCAG 2.0/2.1 Level A “Serious” issue.

Browser behavior: the auto-translate prompt

There’s one more visible behavior lang governs: the browser’s “Translate this page?” prompt. Chrome (and others) weigh lang alongside actual visible-text analysis when deciding whether to offer translation. A wrong or missing value can misfire in both directions — falsely offering to translate a page that’s already in the reader’s language, or failing to offer it on a genuinely foreign one.

The vivid real-world example is Manuel Matuzovic’s the lang attribute: browsers telling lies, telling sweet little lies: the Austrian broadcaster ORF.at shipped German content with lang="en", so Chrome’s auto-translate treated the German text as English and “translated” it, turning the Vienna district name “Liesing” into the English word “lies.” That’s the boilerplate-default trap producing a user-facing bug — the exact class of problem Mueller’s “almost always wrong” was describing.

How to set it correctly

  • Use a valid BCP 47 tag. Language subtag alone (en, es, fr) if you don’t need regional distinction; language-region (en-US, en-GB, pt-BR) if you do. Pull codes from the IANA Language Subtag Registry; don’t invent them, and remember GB, not UK.
  • Set it on the element that changes, too. For an embedded foreign phrase in an otherwise single-language page, reset lang locally: <span lang="fr">c'est la vie</span>. Unset descendants inherit the nearest ancestor’s lang, so the root value covers everything you don’t override.
  • Kill the boilerplate default. The lang="en" your template or CMS shipped with is only correct if your content is actually in English. This is the failure Mueller called out and the ORF.at bug in miniature — audit for it.
  • Keep lang and hreflang consistent. If a page’s lang says es-MX but its hreflang annotation for that same URL says en, that’s a mismatch. It’s exactly the “Hreflang and HTML lang mismatch” issue I documented in Ahrefs’ hreflang guide — where I put it plainly: “Google doesn’t use the HTML language attribute, but other search engines and browsers do. It’s important to keep these two attributes consistent with one another.” Google ignores the lang half of that comparison, but a mismatch still signals that something is misconfigured — which is why site audit tools flag it.

Common myths

  • “Correct lang will improve my Google rankings.” No. Google states it doesn’t use lang for language detection at all. It can matter for Bing and indirectly help via accessibility and translation behavior, but a direct Google ranking benefit isn’t supported.
  • “lang and hreflang are basically the same.” No — lang describes the page it’s on; hreflang points to other URLs. A page can have a correct lang and no hreflang, or correct hreflang and a wrong lang.
  • “No search engine cares about lang.” Bing explicitly does (as a fallback behind content-language). For any site with real Bing traffic, this isn’t a “nobody cares” situation.
  • “Leaving the default lang="en" is harmless if my content isn’t English.” It’s close to word-for-word the failure Mueller called “almost always wrong,” and it’s what triggers wrong translate prompts and wrong screen-reader pronunciation.
  • “Correct lang gives a 22% CTR lift” / “AI crawlers process lang-tagged pages 40% faster.” These specific figures circulate on a handful of SEO marketing blogs with no traceable study, methodology, or primary source. I couldn’t corroborate either against any official statement or first-party data — treat them as the kind of confident-sounding, baseless folklore that accretes around low-scrutiny technical topics.
  • “An empty lang="" is the same as not having one.” No — an explicit empty value means “unknown language,” a distinct state from a genuinely absent attribute.

Where this fits

This is the attribute-level deep dive of the HTML SEO subcluster — the sibling to the element-level treatment of <article>, <nav>, and <main> in the semantic HTML article, and to the broader HTML-SEO hub above them. For the full cross-page targeting story — the three implementation methods, reciprocal rules, and how often clusters break at scale — the hreflang deep dive is the place to go; this article’s job is just to keep the two straight in your head.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin an expert quote first.