The lang attribute on your <html> element tells browsers, search engines, screen readers and AI parsers which language your content is in. Missing or wrong lang doesn't crash anything but degrades accessibility (screen readers mispronounce), translation behaviour, and search-engine language detection. The fix is one attribute on one tag. This guide covers the right codes, multilingual patterns, and the hreflang connection.
en, fr, de) or language + region (en-GB, fr-CA, pt-BR). Rule: use the most specific code that genuinely matches your content.
lang="en"lang="en-GB"lang="en-US"lang="pt-BR"lang="pt"en-GB as the default just because the codebase is British. The lang should reflect what's in the content. Mislabelled lang confuses screen readers and translation tools.<!DOCTYPE html> <html <?php language_attributes(); ?>>
language_attributes() outputs lang="en-GB" (or whatever you set in Settings → General → Site Language). If your theme has a hardcoded <html lang="en">, replace it with language_attributes() so the value follows WP settings.
<html lang="{{ request.locale.iso_code }}">
request.locale.iso_code outputs the active locale (e.g. en, en-GB). For multi-locale stores via Shopify Markets, this automatically matches the visitor's locale.
export default function RootLayout({ children }) {
return (
<html lang="en-GB">
<body>{children}</body>
</html>
);
}
For internationalised routing, use the active locale from next-intl or the App Router's locale param.
Pages with mixed languages need lang attributes on the sections in different languages.
<html lang="en"> <body> <p>Welcome to our French bakery.</p> <p>Our signature: <span lang="fr">pain au chocolat</span>.</p> </body>Screen readers switch pronunciation mid-sentence based on the lang switch. Without it, "pain au chocolat" gets pronounced in English: "pain-aw-chock-o-lat" instead of the correct French pronunciation.
If you have separate URLs per language (most sites with proper i18n), link them with hreflang.
<head> of EVERY language variant:
<link rel="alternate" hreflang="en-GB" href="https://yourdomain.com/uk/page" /> <link rel="alternate" hreflang="en-US" href="https://yourdomain.com/us/page" /> <link rel="alternate" hreflang="fr-FR" href="https://yourdomain.com/fr/page" /> <link rel="alternate" hreflang="x-default" href="https://yourdomain.com/page" />Self-referencing (each variant links to itself plus all siblings) and
x-default for the fallback language are both required.
For full hreflang treatment see the hreflang fixes index.
curl -s https://yourdomain.com/ | grep -i '<html'Expected output:
<html lang="en-GB"> (or your chosen code).
Most guidance frames the lang attribute as an SEO fix, and that framing is both weak and misleading — it leads teams to skip it when the SEO benefit turns out to be small.
Google has said it determines the language of a page from the visible content, not from the lang attribute. A correct lang will not by itself improve how your page is understood or ranked, and a missing one will not by itself harm it. For international targeting, hreflang is the mechanism that matters, and it is a separate thing entirely.
So the real audience is elsewhere, and it is more important than the search engine:
SCREEN READERS Choose a pronunciation model from this attribute. Wrong lang = a French page read aloud in an English voice. Not a degradation — genuinely unusable. This is a WCAG requirement, with a compliance dimension in many jurisdictions. BROWSERS Translation prompts. Hyphenation. Font selection for some scripts. Spellcheck in form fields. AI PARSERS AND OTHER CLIENTS One clean, unambiguous statement of what language this document is in, available without inference.
That is a strong case, and none of it depends on a ranking argument. One attribute, on one tag, and a person using a screen reader can use your site. It is among the highest return-per-character changes available anywhere in a codebase.
The attribute is trivially easy to add, which is precisely why it is so often wrong. Somebody hardcodes lang="en" in a layout during setup, and it is never revisited — so the site now confidently asserts that its twelve French pages are in English, silently, indefinitely.
Mislabelled is worse than missing. A missing attribute leaves a screen reader to guess, and it will often guess from the content. A wrong one is an instruction, and it will be obeyed.
The rule is the same one that governs structured data, hreflang, canonical tags and every other machine-readable assertion on a page: derive it from the same source as the content. Never type it twice. WordPress gives you language_attributes(). Most template engines can render it from the page's own language field. Anything typed by hand in a layout will eventually contradict the page it wraps, and nothing will tell you when it does.
Setting html lang to the primary language and wrapping the exceptions in <span lang="..."> is the correct pattern, and it is worth knowing when it earns its keep, because applied indiscriminately it becomes noise.
It matters for anything a screen reader would mispronounce badly enough to obscure the meaning: a quoted passage in another language, a name, a technical term, a customer testimonial left in the original. It does not matter for a loanword that has been absorbed into the language and would be pronounced the same way anyway.
The test is not lexical, it is practical: would a screen reader reading this at speed produce something a listener could not follow? If yes, mark it. If no, leave it — a page peppered with span tags around every borrowed word is harder to maintain and helps nobody.
And the same applies to the code you choose. Use the most specific code that is genuinely true. en-GB because your codebase is British, on content written for a global audience, is a small lie told to every client that reads it — and lies of this kind are the reason machine-readable metadata across the web is trusted as little as it is.
These two get conflated constantly, and the confusion produces international sites that have configured one and believe they have configured both.
lang (on the html element)
- Says: THIS document is in this language
- Audience: screen readers, browsers, any parser
- Scope: this page only
- Ignored by Google for language detection
hreflang (link elements or sitemap)
- Says: alternative versions of this page exist,
for these languages and regions, at these URLs
- Audience: search engines
- Scope: a set of pages that mirror each other
- This is the international targeting mechanism
They answer different questions. A correct lang on a page with no hreflang tells Google nothing at all about your other language versions. Correct hreflang with a wrong lang still leaves a screen reader mispronouncing the page to an actual human being.
Set both, from the same source, and they cannot disagree. Hardcode either one and it will eventually contradict the page it describes — which is the failure mode that runs through every machine-readable assertion on a website, and the reason so few of them can be trusted.
It is one attribute on one tag, and it is a useful miniature of something larger.
A web page makes a series of claims about itself that no human ever sees: the lang attribute, the canonical, the structured data, the hreflang set, the robots directives, the Open Graph tags. Each is an instruction to a machine. Each is invisible in a browser. And each, when wrong, fails silently — nothing errors, nothing 404s, nobody complains, and the page renders perfectly.
That combination — consequential, invisible, silent on failure — is why this category of defect persists for years on otherwise well-maintained sites. There is no feedback loop. Nobody is ever told.
Which produces two habits worth adopting far beyond the lang attribute:
Use the most specific code that genuinely matches your content. en alone is fine for content that doesn't differ regionally. en-GB if you use British spellings and target UK audience. en-US for American spellings and US targeting. Don't use en-GB if your content is just generic English — it's misleading and doesn't help SEO.
Barely, and it is worth being precise. Google has said it determines page language from the visible content rather than from the lang attribute, so a correct lang will not by itself improve how your page is understood or ranked, and a missing one will not by itself harm it. What matters for international targeting is hreflang, which is a separate mechanism. The biggest real direct impact is accessibility: screen readers use lang to choose the right pronunciation model. A US screen reader reading 'Frankfurt' will mispronounce it without lang='de' on the relevant span.
Set html lang to the primary language of the page. Wrap sections in the secondary language with <span lang='xx'> or <div lang='xx'>. Example: an English page describing a French recipe might have html lang='en' but wrap French ingredient names in <span lang='fr'>ingredients</span>. Screen readers switch pronunciation accordingly.
In HTML5: use lang only. xml:lang is XHTML syntax — valid but redundant in HTML5. For pages served as application/xhtml+xml, use both. For normal HTML5 pages served as text/html, lang alone is correct and shorter.
Because search engines are not the audience that needs it. A screen reader uses the lang attribute to choose its pronunciation model — get it wrong and a French page is read aloud in an English voice, producing something between comedy and nonsense. It is a WCAG requirement for exactly that reason, with a compliance dimension in many jurisdictions. Browsers use it for translation prompts and for hyphenation. The SEO case for this attribute was always weak, and the accessibility case has always been strong enough on its own.
No, and confusing the two is common. lang describes the language of this document, to any client reading it. hreflang tells a search engine that alternative versions of this page exist for other languages or regions, and where they are. They answer different questions and neither substitutes for the other — a correct lang on a page with no hreflang tells Google nothing about your other versions, and correct hreflang with a wrong lang still has a screen reader mispronouncing the page to a real person.
Setting it once, globally, and forgetting it — which produces a site whose every page claims to be in English including the twelve that are not. The attribute is only useful if it is true, and it is only true if it comes from the same source as the content. Frameworks make this easy: WordPress has language_attributes(), most template engines will render the field from the page's own language data. Hardcoding a value in a layout is how a site ends up confidently mislabelling half of itself, silently, for years.
aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.