How Google Detects the Language of a Page, and Why It Matters

Short answer: Google determines the language of a page mainly from its visible content, the words readers actually see, rather than from the lang attribute or other markup. hreflang tells Google which alternate versions exist, but the language of each page is still judged by its text. That is why pages should use one main language, with menus, headings and body all translated, and why mixed or half-translated pages often show up in the wrong searches.

What Google says about language detection

Google’s documentation on multi-regional and multilingual sites states that Google uses the visible content of a page to determine its language, and that it does not use code-level information such as the lang attribute for this. It also recommends using a single language for content and navigation on each page and avoiding side-by-side translations.

This has practical consequences. You cannot turn an English page into a German page for search purposes by changing its markup. If the words are English, Google treats the page as English. Likewise, a well-translated German page with a wrong lang attribute will still be recognised as German, although the wrong attribute causes other problems, especially for accessibility.

Other search engines may weigh signals differently. Bing, for example, has said it considers the content-language meta tag and HTML language attributes alongside the text. But for Google, the text is what counts.

Why the visible text is a sensible signal

Relying on text rather than markup is a deliberate choice. Markup is often wrong: themes hard-code lang=”en” on every page, plugins output outdated locales, and many sites never set the attribute at all. Text, on the other hand, is what readers experience. If a page is written in Lithuanian, a Lithuanian reader can use it, whatever the markup says.

Language detection from text is also robust for most pages. A few paragraphs of content are usually enough to identify a language reliably. Problems arise only when pages contain very little text, mix several languages, or consist mostly of names, numbers and codes.

Where language detection goes wrong

In audits, the same situations repeatedly lead to pages being treated as the wrong language or as a confusing mix:

• Half-translated pages. The body text is translated, but menus, sidebars, footers, buttons and cookie banners remain in the original language. On pages with short content, the untranslated template text can outweigh the translated body.
• Side-by-side translations. A page shows the same text in two languages, one after the other. Google recommends against this; it makes the page less useful for either audience.
• Thin pages. Product pages with a title, a price and a table of specifications contain very little language. Detection becomes uncertain, especially when the product name is in English.
• Fallback content. When a translation is missing, some systems show the original text on the translated URL. The URL is in the /de/ folder, but the page is in English.
• User-generated content. Reviews or comments in many languages on one page can dilute its main language.

How this interacts with hreflang

hreflang and language detection work at different levels. hreflang says: “these URLs are versions of each other, and this one is intended for German speakers.” Language detection says: “this page is actually in English.”

When the two agree, everything works smoothly: Google sees a German page annotated as German, with an English alternate annotated as English, and shows each to the right audience. When they disagree, for example a URL annotated as de that contains English text, the annotation is contradicted by the content. Google may still index the page, but it is unlikely to be a good result for German searchers, and it duplicates the English version in practice.

That is why fixing hreflang errors is only part of international SEO. The pages must also actually be in the language their annotations claim.

One main language per page

The simplest rule is that each URL should have one main language, and everything a reader sees should be in that language:

• Title tag, meta description and H1.
• Body content, headings and image captions.
• Navigation, breadcrumbs, sidebars, footers and buttons.
• Forms, error messages, cookie and consent banners.
• Image alt texts and structured data text fields.

Short passages in another language are fine where they naturally belong: a quotation, a product name, a brand slogan, a list of language names in the switcher. They can be marked with a lang attribute on the element for accessibility. What matters is that the main content clearly belongs to one language.

Handling missing translations

On most multilingual sites, not every page is translated into every language. How the site handles gaps affects language detection directly. The options, from best to worst, are:

1. No page. The translated URL does not exist, the language switcher hides or disables the language for that page, and hreflang lists only existing versions.
2. A clear notice and a link. If a visitor follows a link to a missing translation, show a short message in their language with a link to the available version, and return a 404 or keep it out of the index.
3. Fallback content on the translated URL. The page shows the original language under the translated URL. This creates pages whose URL, hreflang and content disagree, and it should be avoided or at least kept out of the index with noindex and out of hreflang.

Short, data-heavy pages

Pages with little natural text, such as product listings, specification sheets and pricing tables, deserve extra attention. Their language is harder to detect, and small amounts of untranslated template text can tip the balance.

• Add a short, useful introduction in the page’s language to category and product pages.
• Translate specification labels, not just values.
• Translate units and formats where they differ.
• Make sure filters, sorting labels and “add to cart” buttons are translated.

These improvements help visitors first, and they also make the page’s language unambiguous.

A fix order when pages show up in the wrong language

If Search Console or customer feedback shows that pages appear for the wrong language, work through the causes in this order. The first steps are the cheapest and most common fixes.

1. Look at the page itself. Open the URL in a private window, without cookies, and read it top to bottom. Is the main content really in the intended language? Are menus, footers and banners translated? Many problems end here.
2. Check what search engines receive. Use URL inspection in Search Console to see the rendered HTML Google fetched. Caching or cookie-based language switching can serve crawlers a different language than you see.
3. Check hreflang and canonicals. Confirm that the page is annotated with the right code, that all alternates return the link, and that the canonical points to the page itself rather than another language.
4. Check for fallback content. Find translated URLs that display the original language because a translation is missing, and remove them from the index and from hreflang until the translation exists.
5. Strengthen thin pages. Add translated introductions, labels and descriptions to short, data-heavy pages so their language is clear.
6. Recrawl and monitor. After changes, request indexing for key URLs and watch the performance report by country and folder over the following weeks.

Most of the time, the cause is one of the first three steps. Deeper investigation is only needed when the content, the served HTML and the annotations are all correct and the wrong version still appears.

Checking the language of your pages

A quick manual check is to open a sample of pages in each language, scroll through the whole page and look for anything in the wrong language, including the footer and pop-ups. Search Console’s performance report, filtered by country and page folder, shows whether pages are appearing for queries in the expected language; English queries driving impressions to your /de/ folder can be a sign that those pages are not really German.

A crawl adds a site-wide view. Site SEO AI Audit checks the Languages area on every crawled page, including lang attributes, hreflang return links and broken language versions, and flags duplicate titles and descriptions across the site, which often reveal untranslated templates. Issues are weighted by how many pages they affect. The first audit is free.

Related reading

• The HTML lang attribute: what it does for SEO and users
• Translation vs localization for SEO: what actually changes
• Machine translation and SEO: what is safe to publish

The bottom line

Google decides a page’s language by reading it. Markup such as lang and hreflang helps with accessibility and with choosing between versions, but it cannot make a page count as a language it is not written in. Give every page one main language, translate templates and metadata along with the content, avoid fallback content on translated URLs, and add real text to thin pages. Then hreflang and content tell the same story.

الأسئلة الشائعة

Does Google use the lang attribute to determine language?

Google has said it uses the visible content of a page, not the lang attribute, to determine its language. The attribute still matters for accessibility and some other tools.

Can I put two languages on one page?

You can, but Google recommends against side-by-side translations. A page with one main language is clearer for readers and for language detection.

What happens if my translated URL shows English content?

Google will treat the page as English, regardless of the URL or hreflang. It then duplicates the English version and is unlikely to rank for searches in the intended language.

Do English product names confuse language detection?

Occasional English names are normal and rarely a problem. Detection becomes uncertain only when a page has very little other text, so add translated descriptions and labels.

Should missing translations fall back to the original language?

It is better not to publish a translated URL until the translation exists. If you use fallbacks, keep those pages out of hreflang and out of the index.