Hreflang and Lang Attributes: What Each One Actually Does

If you've ever opened your site's HTML and spotted both lang="es" on the <html> tag and a pile of hreflang links sitting in the <head>, you've probably wondered whether you're looking at two names for the same thing. That confusion is reasonable. Hreflang and lang attributes both live in your HTML, both take language codes that look almost identical, and both usually show up around the same time your site goes multilingual. But they answer two completely different questions for two completely different audiences, and mixing them up is exactly how audit tools like Ahrefs or Sitebulb start throwing "mismatch" warnings that leave people guessing at what to actually fix.

This article sorts out who reads which attribute, why Google says (in writing) that it ignores one of them, and what that does and does not mean for your site.

Two Attributes, Two Different Questions

Here's the short version, and it's worth pinning to the top of your mental model before anything else: lang answers "what language is the text on this page written in?" and hreflang answers "where do the other language versions of this page live?"

Picture a hotel with rooms in six languages. The lang attribute is the sign on the door of the room you're standing in: it tells you, and anyone with you, what language the furniture instructions and room service menu are written in. Hreflang is the directory in the lobby that lists every room and points you to the one in your language.

One describes where you are. The other points you somewhere else. They're both useful, they just don't do each other's job, and a directory sign in the lobby doesn't help you read the menu once you're inside the room.

Here's what that looks like in real markup, both attributes on the same page:

<html lang="es">
<head>
  <link rel="alternate" hreflang="es" href="https://example.com/es/" />
  <link rel="alternate" hreflang="en" href="https://example.com/en/" />
  <link rel="alternate" hreflang="x-default" href="https://example.com/" />
</head>

The lang="es" on the <html> element describes the text on this one page. The three hreflang links in the <head> describe the relationship between this page and its siblings. They can both be present, they can both be correct, and they can still be doing entirely separate jobs.

Who actually reads each one

The mismatch confusion usually comes from assuming there's one audience for "language signals" on a page. There isn't. Different consumers look at different attributes, and some ignore both in favor of something else entirely.

Yandex is reported by some SEO audit vendors to read hreflang in a way similar to Google, though that claim doesn't appear in Yandex's own published documentation, so treat it as secondhand rather than confirmed. Everything else in that table comes straight from the source docs cited below, and it's the reason a "mismatch" between lang and hreflang isn't automatically a search problem. It might be an accessibility problem, a search problem, both, or neither.

What the lang attribute is for

The lang attribute exists mainly for accessibility, and its job is more concrete than "SEO signal." A screen reader uses lang to decide which pronunciation rules to apply. Get it wrong and the results aren't subtle.

Web developer Todd Libby documented this in the HTMHell advent calendar: with a German voice profile reading untagged English text, the word "The" comes out sounding roughly like "Tee-hay." Braille displays have the same problem in reverse: Grade 2 braille uses different contractions per language, so the wrong lang value can turn a page into gibberish for a braille reader, not just an awkward accent.

It's not only about speech, either. Hyphenation rules differ by language, so the CSS property hyphens: auto depends on lang being set correctly to break words in the right places. Browsers also render quotation marks differently depending on declared language: English gets straight double quotes, German gets „low-high" marks, French gets « guillemets ». None of that happens correctly with a missing or wrong lang value.

This is a bigger issue than most site owners realize. The WebAIM Million 2026 report, which analyzes the home pages of the top one million sites, found missing document language on 13.5% of them. That's down from 15.8% the year before, so the trend is improving, but more than one in ten major home pages still ships without a document language.

The Web Content Accessibility Guidelines address this directly: WCAG 2.2 Success Criterion 3.1.1 requires that "the default human language of each web page can be programmatically determined," and setting lang on the <html> element is the standard way to satisfy it. Bing also factors lang into how it interprets a page's language, alongside the older Content-Language meta tag or HTTP header, which is a detail worth knowing if your site ever shows up oddly in Bing results despite looking fine in Google.

What hreflang is for

Hreflang exists for a completely different reason: it tells search engines that a page has equivalents in other languages or regions, so the right version can be shown to the right searcher. A shopper in Mexico searching in Spanish should land on your /es-mx/ page, not your /es-es/ page written for Spain, even though both pages are technically "in Spanish." Hreflang is how you make that distinction explicit rather than hoping the search engine guesses correctly. The rule set for writing hreflang correctly, covering reciprocal return links, the x-default fallback, and one attribute per alternate, is its own topic with enough detail to fill a separate walkthrough, so if you haven't set up hreflang yet, our guide to hreflang tags covers the full rule set step by step.

Does Google use the lang attribute?

No, and Google says so plainly in its own documentation, which is about as clean an answer as you'll get in SEO. Google's own "Managing multi-regional and multilingual sites" guide states plainly: "Google uses the visible content of your page to determine its language. We don't use any code-level language information such as lang attributes, or the URL." Google instead reads the actual text on the page and runs it through its own language-detection algorithms.

This isn't a recent policy change, either. Google's John Mueller said during a 2016 Search Central hangout that the language attribute in HTML markup is "something we don't use at all," a statement reported at the time by Search Engine Roundtable. He repeated the same position in 2022, telling a site owner on social media that "Google doesn't use these, but screen readers do." Consistent messaging across six years from the same company is about as strong a signal as you'll find that this isn't a gray area worth second-guessing.

Here's the part that trips people up, though: "Google doesn't use it" does not mean "you can delete it." The lang attribute still drives accessibility, still affects how browsers render your page, and still matters to Bing. Removing it to "clean up" your markup would fix nothing for Google and break something for everyone else.

Do you need both?

Yes, and the reasoning behind that answer is more straightforward than the mismatch warnings make it sound. Set lang on every single page you publish, regardless of whether that page has alternate language versions. It's the correct accessibility practice and it costs you one attribute on one HTML tag. Add hreflang only on pages that actually have alternates elsewhere, since hreflang without matching alternate pages doesn't accomplish anything.

Sometimes what looks like a mismatch between the two attributes isn't a language problem at all. A WPML user on the plugin's support forum in November 2024 reported hreflang and lang mismatch errors flagged by an Ahrefs audit, even though both tags were correctly set. The actual cause turned out to be a "Browser Language Redirect" feature bouncing visitors between language versions based on their browser settings, which confused the crawler's understanding of which page it was looking at.

Support's fix was to turn off the automatic redirect, not to touch either attribute. This lines up with Google's own advice in the multi-regional sites guide, which specifically warns against automatically redirecting users based on perceived language, since it can prevent both search engines and users from reaching the version they actually asked for.

Valid language codes for lang and hreflang

The two attributes overlap in format but don't share identical rules, and this is where a code that's perfectly valid for one can be rejected by the other. The lang attribute follows the BCP 47 standard, a broad specification that accepts values like en, en-GB, zh-Hant-TW, and even regional groupings such as es-419 (the UN numeric code for Latin America).

Google's hreflang implementation is narrower. It accepts an ISO 639-1 language code, an optional ISO 15924 script code, and an optional ISO 3166-1 alpha-2 region code, in that order. That means es-419, a perfectly valid lang value, isn't on Google's documented list of supported hreflang formats.

Region-only codes like hreflang="us" are invalid outright, since hreflang always needs a language first. And a common typo trips people up constantly: the correct region code for the United Kingdom is GB, not UK, so hreflang="en-UK" fails validation even though everyone types "UK" in casual conversation. The combinations get more detailed once scripts and less common regions enter the mix, but the same two-standard split (BCP 47 for lang, the narrower ISO trio for hreflang) holds throughout.

When an audit tool says they don't match

Once you understand that lang and hreflang serve different readers, fixing a "mismatch" warning gets a lot less confusing. The fix is always the same shape: figure out which value is actually wrong for the page's content, then change that one. If a page's visible text is in French but lang="en" is set, fix the lang attribute; hreflang isn't the problem there. If the hreflang set points to the wrong URL for a language, fix hreflang; the lang attribute on that page might be perfectly correct.

To check both at once without digging through view-source on every page, paste your URLs into the hreflang.tools checker. It reads canonical tags, hreflang links, and the <html lang> value for every page you submit, and shows them side by side in one report so you can compare what your pages actually declare against what they should declare. If a page ships an HTTP Content-Language header too (relevant for Bing, and something a tool like httpcheck.tools can also surface when you're checking response headers directly), the report flags that alongside everything else, so you're not chasing three separate tools for one answer.

Frequently Asked Questions

What is the difference between hreflang and lang?

The lang attribute, set on the <html> element, declares what language the visible text on that specific page is written in, and it's read by browsers, screen readers, and Bing. Hreflang, set as a link in the page's head, an HTTP header, or a sitemap entry, declares which other URLs are alternate-language versions of the current page, and it's read by Google (and reportedly Yandex) to decide which URL to show a searcher. One describes a single page's content; the other maps relationships between multiple pages.

Does Google use the lang attribute?

No. Google's own documentation states plainly that it determines a page's language from the visible text using its own algorithms, not from code-level signals like the lang attribute or the URL. Google's John Mueller confirmed the same thing in both 2016 and 2022. This doesn't mean the attribute is useless, since it still matters for accessibility and for Bing, just that it plays no role in how Google detects language.

Do I need both hreflang and lang?

Yes, for different reasons. Set lang on every page you publish because it's correct accessibility practice and it's read by browsers and assistive technology regardless of whether the page has translations. Add hreflang only on pages that have genuine alternate-language versions elsewhere on your site, since it exists specifically to map those relationships for search engines.

Which language codes are valid for lang and hreflang?

The lang attribute accepts any valid BCP 47 tag, a fairly permissive standard that includes language-only codes, region variants like en-GB, script variants like zh-Hant, and even grouped regions like es-419. Hreflang, per Google's documentation, is narrower: an ISO 639-1 language code, an optional ISO 15924 script code, and an optional ISO 3166-1 alpha-2 region code. A code can be valid for lang and unsupported for hreflang at the same time, which is exactly what happens with values like es-419 or incorrect region abbreviations like en-UK instead of the correct en-GB.