The html lang attribute: 27 of 27 declare one, Google ignores it
Every homepage in this panel sets an html lang attribute, and Google documents that it does not use one. On 2026-08-21, 27 of 27 declared a language and two declared one we never asked for.
FIELD TEST · 2026-08-21 · 27 homepages · one request each · exit in Osaka, Japan
Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-21 with a browser user agent sending Accept-Language: en-US,en;q=0.9. The opening <html> tag was parsed for lang, xml:lang and dir, and the head counted for rel="alternate" links carrying hreflang.
Every homepage in this panel sets an html lang attribute — 27 of 27. Google's own documentation says it does not use that attribute to work out what language a page is in. Two of the 27 declared a language nobody asked for, which is the part worth looking at.
How we measured it
One HTTP request per site, no rendering, no retries. The exit IP was 23.106.140.215, geolocated to Osaka, Japan on the day of the crawl. That detail matters twice below.
Three of the 30 failed the inclusion rule fixed before the run — status 200, body at least 10,000 bytes, body containing <body — and are excluded from every count: stackoverflow.com and medium.com returned 403, www.reddit.com returned an 8,393-byte shell.
One attribute, six spellings
All 27 declare a language. They do not agree on how to write it, and two of them are not describing English at all.
| Declared value | Sites | Who |
|---|---|---|
en | 19 | most of the panel |
en-US | 4 | mdn, wired, techcrunch, theverge |
en-GB | 1 | www.bbc.com |
en-us | 1 | www.notion.com |
en-JP | 1 | stripe.com |
ja-JP | 1 | slack.com |
Notion's lowercase en-us is valid — the tag is case-insensitive, and the convention of writing the region in capitals is a convention. It is still the only site in 27 that does it, which is the sort of detail that survives for years because nothing ever complains about it.
What the html lang attribute is actually for
It tells the browser and assistive technology which language the document is in. It does not tell Google. From "Managing multi-regional and multilingual sites" on Google Search Central, read 2026-08-21: "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."
So a correct value earns you nothing in search, and a wrong one costs you nothing there either. Screen readers are the consumer that acts on it — pronunciation and voice selection come from this attribute — and that is reason enough to keep it right.
Two sites handed us a language we never requested
Slack returned a homepage declaring ja-JP. Stripe returned one declaring en-JP. Our request said Accept-Language: en-US; our IP said Osaka. The IP won both times.
This is the fourth crawl in this panel where the exit location changed what came back, after the canonical values in August and the redirect chains measured in the redirect chain survey. The same Google page is blunt about the practice: "Don't use IP analysis to adapt your content. IP location analysis is difficult and generally not reliable. Furthermore, Google may not be able to crawl variations of your site properly."
And the reason it matters for one visit from one country is on the same page: "Google crawls the web from different locations around the world. We do not attempt to vary the crawler source used for a single site in order to find any possible variations in a page." A crawler arriving from one place gets one version and moves on. It does not shop around.
The lang attribute records what your server decided to serve. It does not record what the visitor asked for.
The neighbouring attributes almost nobody sets
The lang attribute is the one that is always there. Everything else on that tag is close to absent.
| Signal | Sites | Note |
|---|---|---|
lang | 27 / 27 | universal |
dir | 4 / 27 | canva, shopify, substack, wired |
xml:lang | 0 / 27 | nobody |
| hreflang links | 11 / 27 | 107 at the top, 0 for 16 sites |
Canva declares 107 hreflang alternates, stripe 89, shopify 71. Sixteen sites declare none. That gap is measured properly in the hreflang survey; here it is context for one point — a site can be scrupulous about hreflang and still hand a fixed-exit crawler the wrong single version, because those are two separate mechanisms.
What this crawl cannot tell you
One request from one country is not a map of what these sites serve. Stripe and Slack may well return en to a crawler arriving from Iowa, and we have no way to test that from here. What we can say is what a client in Osaka received on 2026-08-21.
We did not verify what any engine does with the attribute in practice. Google documents ignoring it. Whether an answer engine reads it, and whether any of them act on it, is a limitation of this measurement rather than a finding, and we are not going to guess.
And a declared language is not a verified one. Nothing here checks whether the visible text on a page declaring en is in fact English. Twenty-seven declarations are twenty-seven claims.
What to check on your own site
Two minutes, three checks.
- View source on your homepage and confirm the opening
<html>tag carries alangvalue that matches the visible text. - Fetch your own homepage from a country you do not sell into and compare the
langvalue with what you get at home. A difference means an IP rule is deciding for you. - Do not expect the attribute to fix a language problem in search. Google says it reads the visible content instead, so the fix lives in the text.
If the version a crawler receives is the open question, checking what actually comes back for each user agent is what the AI crawler accessibility check is for.
Common questions
How did you measure this?
One homepage request per site on 2026-08-21 with an English Accept-Language header from a Japanese exit IP, then the opening <html> tag parsed for its attributes. No rendering, no retries.
Does the html lang attribute affect SEO?
Google states it uses the visible content of the page and not code-level language information such as lang attributes. The attribute serves browsers and assistive technology.
Should I write en or en-US?
Both are valid. Nineteen of 27 sites here write en and four write en-US; the region subtag only earns its place if you also serve a different regional variant.
Why did a site return Japanese when I asked for English?
Because it routed on IP rather than on the Accept-Language header. Slack did exactly that to us on 2026-08-21, returning a page declaring ja-JP.
