HTML lang 與 SEO：檢查網頁宣告的語言

Set the HTML lang attribute to describe the page’s actual predominant language. Then verify that the delivered page and its language label agree. This helps users and assistive technology; it should not be presented as a command that makes Google detect a language or target a country.

Google explicitly says it uses algorithms, rather than HTML lang or hreflang, to detect a page’s language. That makes the technical diagnosis more precise: a wrong language label is worth fixing, but an unwanted search-language result needs its own investigation. Do not promise that changing the attribute will resolve both.

Keep three observations separate

Take a fictional documentation page intended for French-speaking readers. Its route contains a French-looking path, most of its explanatory text is French, but a shared layout still declares English on the root HTML element. These are three different observations: route naming, visible language, and programmatic language.

The mismatch is not repaired by pointing at the URL and saying the language is obvious. A person can infer meaning from the page while a user agent receives a different label. Equally, a French label on an untranslated English page would not make that page French.

Before changing anything, record the exact public URL and what the page currently delivers. Keep regional audience requirements separate from language correctness. A page can be written in French for readers in several countries, or use the same language across regional variants with different commercial conditions.

Visible content: what language dominates the actual answer?
Declared language: what does the root HTML element identify?
Audience and variants: who is the page for, and which related versions exist?

Understand what the language label helps readers do

W3C’s Language of Page explanation describes identifying the default human language so user agents and assistive technologies can present content appropriately. Screen readers can use the correct pronunciation rules. This is a user-facing reason to provide an accurate label, independent of a ranking claim.

Apply that purpose to the fictional page. If its main answer is French, a default English label is a defect to investigate in the template or localization pipeline. Correcting it helps the programmatic description match what the reader receives.

A non-empty value alone is not a complete quality check. The label also needs to represent the content. A quick automated check can flag a missing attribute while missing a plausible but incorrect value inherited from another route. Include an editorial review of the visible language when verifying a translated page.

Inspect the document that actually reaches the browser

Open the public route directly, rather than reaching it only through an already localized session. In browser developer tools, inspect the root HTML element and read its lang value. Compare it with the main text, headings, navigation, and any important notices. Save the route and the observation date.

Then follow a normal internal navigation path to the same page. If the site changes content without loading a whole document, check the language label again after navigation. A correct initial document does not establish that the attribute stays correct during every route transition.

In the hypothetical docs site, direct loading might deliver the expected French label while a client-side transition leaves the previous page’s English value behind. That is a proposed failure case to test, not an observed result from a real site. If it occurs, the repair belongs in the route or layout behavior that owns the value.

Also review the state a new visitor receives. Do not let yesterday’s language selection stand in for the default experience. Record any visible preference or account condition that changes what is served. This turns the check into a reproducible observation rather than an unexplained screenshot of one session.

Handle mixed-language content deliberately

A translated article may retain a product name, a quoted phrase, or an original-language example. Those fragments do not necessarily change the predominant language of the document. Start with the main answer and consider what a reader is actually being asked to understand.

W3C’s guidance explains choosing the language used most when a page contains several languages, with the first used as the default when languages are used equally. Its related guidance addresses language changes within parts of a page. Keep document-level and passage-level labeling as separate review tasks.

For a practical handoff, identify the mixed-language passage and ask whether its treatment is intentional. A long untranslated warning is a different problem from a short product name. If a critical limitation remains in another language, adding a label does not substitute for translating the information the intended audience needs.

Use Google’s language guidance within its scope

Google’s localized-pages documentation says hreflang describes relationships among localized variations. It separately states that Google does not use hreflang or the HTML lang attribute to detect the language of a page. Avoid collapsing these jobs into a single “language tag” repair.

In the fictional site, fixing the English root label on the French page addresses a real mismatch. If search still shows an English version for a particular query, that is a separate observation. Inspect the actual result, relevant page content, and variant setup instead of repeatedly changing the root label.

The same caution applies to AI visibility. A correct lang value is not a documented universal requirement for being cited by ChatGPT, Claude, or Gemini. Do not generalize Google’s language-detection statement into a claim about every system either. State the engine, the behavior documented, and the limit of the evidence.

Review representative routes, not one successful screenshot

Build a small review set from the templates that can produce different language states. Include a directly loaded translated article, a page reached from another language, a fallback page, and an important error or access notice. Use the routes your product actually exposes.

For each case, record intended language, observed main-content language, declared root language, and relevant navigation state. Add whether the result was checked before and after client navigation. Keep expected and observed values in separate fields so the chosen implementation cannot quietly redefine the requirement.

Ask the responsible developer or localization owner to explain which component owns the value. A shared shell, server template, and route-level change can otherwise overwrite each other. The acceptance check should include the affected transitions, not just the single page used to discover the defect.

A representative sample still has limits. It does not prove that every route and language combination works. Record untested templates and prioritize ones that carry important buyer answers. The goal is a clear, bounded check that another person can repeat.

Verify the repair against the problem it was meant to solve

After the normal authorized release, reopen the public routes and repeat the recorded transitions. Confirm that the label agrees with the intended main-content language and that the content itself has not fallen back to an unexpected version. Keep evidence of the actual delivered state.

If the change also affects pronunciation or other assistive behavior, use an appropriate accessibility review rather than inferring the whole experience from one attribute. A corrected label is one part of a usable multilingual page.

Track search presentation and AI answers separately if those are part of the project. Save the question or query, surface, date, mode, and linked destination; repeat observations before claiming a stable change. The defensible immediate result is that a defined set of pages now declares the language it actually presents. That is useful technical work even when no discovery gain has yet been demonstrated.

Hey I'm Uriel Bitton. I write about SEO, AEO, GEO, and helping brands get found in AI answers.

Subscribe for practical ways to grow your brand's visibility in search and AI answers.

Explore HoneyWeRank for SEO and AI visibility.