Google Detects Wrong Language: html lang Errors and the Translate Prompt

Google detects wrong language: what does it mean and what do you do first?

In short, it means your page is written in one language, but Google or the browser treats the text as another. You usually notice it through a translate prompt or a title and snippet in the wrong language. First, compare the language of the text people read with the lang value on the html element.

This article covers only this single situation, so we keep it focused. Linking language versions together is a separate topic, and we explain it in our hreflang guide, so we will not repeat it here.

When Google detects wrong language on your pages, stay calm, because the cause usually sits in a few template files. However, changing things before you find the cause only wastes time. The sections below then take you from symptom to cause to fix.

1. Open the page in a private window and see whether a translate prompt appears.
2. Note which language most of the visible text uses.
3. Find the lang value on the html element in the page source.
4. Check the shared parts: menu, footer and cookie notice.
5. Inspect the address in Search Console and write down what you see.

These five steps also reveal the cause in most cases. Next, we go through each one in detail.

How does Google decide the language of a page, and does it read the lang attribute?

Google says in its Search Central documentation that it uses the visible content of a page to determine its language. The same document also states that Google does not use code-level language information such as lang attributes, or the URL. So the html lang value is not what Google relies on for its language decision (source: Google Search Central, managing multi-regional and multilingual sites).

At first glance this makes lang look unimportant. In practice the picture is more nuanced. Because Google reads the text itself, mixed text can lead to a wrong decision.

Moreover, other systems do use the lang value. Browsers, screen readers and translation tools may read it. So writing the right value still matters for people, even when it does not steer Google.

• Google relies on: the visible text of the page.
• Google does not use for language: the lang attribute and the URL.
• Other systems care about: a correct and consistent lang value.

In short, you have two goals. You keep the text in one language for Google, and you write the right lang value for everything else.

Why does Chrome ask "Translate this page?"

A browser works out the page language with its own detection, and it offers translation when that language differs from the language you set in the browser. The Chrome Help page explains how to use translation. However, it does not explain how the language detection works. So we do not state a hard rule here and share only what we see in the field.

Our observation is that, in practice, the prompt tends to appear in two situations. First, a large part of the page text is in another language. Second, the lang value contradicts the real language.

The wording in the heading above is only an approximation of a common translate prompt. The interface text can change by version and language, so exact wording is not reliable. Therefore we say "a similar translate prompt" and do not rely on exact wording.

The key point is simple: the prompt is a warning sign. Your page may also contain a language mix that confuses the browser. Treat it as a situation that could also turn into a wrong language signal on the search side.

How does a mixed language template cause a wrong language signal?

For example, suppose one part of your template is in one language and the content is in another. The page then carries mixed text. Also, menu labels, footers, product attribute headings and form messages can stay in the wrong language. As a result, the overall language of the page becomes unclear, especially on pages with little content.

Google's documentation names this risk, because it harms users. Translating only the boilerplate text while keeping the bulk of the content in one language can create a bad user experience, because the same content may appear several times in search results with different boilerplate languages. The document also recommends one language for content and navigation on each page, and no side-by-side translations.

In practice, mixed language usually comes from these sources:

• English menu and button text from a ready-made theme or plugin.
• An untranslated footer, cookie notice and form error messages.
• Auto-generated category and tag headings in a default language.
• A short product description next to a long technical table in another language.
• Side-by-side texts that repeat the same content in two languages.

So this list shows that the problem is often in the template, not in the content. So start with the template files.

What happens when the html lang value is wrong?

A wrong lang value does not directly damage Google rankings, because Google does not rely on it. However, it can change the browser translate prompt, the pronunciation of screen readers and the behavior of some tools. In other words, the harm mostly shows up on the user side.

First, the W3C recommends declaring the default language of the page on the html element. If part of the page uses another language, you add a separate lang value to the element around that part (source: W3C, language declarations in HTML). Language codes follow BCP 47, so English uses en.

The most common wrong values look like this:

• A leftover value from the theme that does not match the content.
• An empty or missing lang value.
• A placeholder value left over from development.
• A typo or a language code that does not exist.

All of these are one line fixes. Still, if you have more than one template, you must check each version separately.

Which symptom points to which cause?

Symptoms can look alike, because their roots differ. The table below pairs common symptoms with likely causes. So treat it as a diagnostic guide, not a verdict.

When you use the table, start with the cheapest check. Often a single lang value or a menu label solves the problem.

How do you diagnose the problem step by step?

You do not need advanced tools. In fact, a browser and Search Console are usually enough. First, find out whether the issue affects the whole site or only certain pages.

1. Pick three affected pages and three healthy pages.
2. Open the page source on each and compare the lang values.
3. Copy the visible text and weigh the language share, including menu and footer.
4. Open the page Google sees in the Search Console URL inspection tool.
5. Check which language the title and description use in search results.
6. Write the differences in a table and identify the shared template.

This comparison then quickly shows whether the error belongs to one page or to the template. For Search Console basics, read our Search Console guide.

It also helps to understand how Google fetches your page. For that, see our Googlebot guide.

If you cannot find a panel section at this stage, the interface name may have changed. Do not get stuck on menu names, because the goal is to see the page the way Google sees it.

What should you do if your menu is in one language and the content in another?

First, bring the menu into the same language as the rest of the page. This is the most effective and also the safest fix. On a site written in English, the menu, buttons, form labels and error messages should be in English too.

If your theme or plugin ships translation files, use them. If it does not, then you can edit the strings in the admin panel by hand. The work often takes an afternoon, though it depends on the size of the site.

You do not need to translate brand names or product names. For example, a software name can stay as it is. The text around it, however, should match the page language.

• Translate the menu and submenu labels.
• Write footer, copyright and privacy links in the page language.
• Translate the cookie notice and form error messages.
• Check auto-generated category and tag headings.
• Keep image alt text in line with the page language.

These fixes also help both Google and your visitors. As a result, the language of the page looks single and clear.

How do you fix a wrong lang value?

First, find out which file produces the lang value. For instance, some sites have one main template. Others have a separate template for each language or page type. Fixing the value in only one place may therefore not be enough.

For an English page, use en. If you want to signal a region, a form such as en-US is also valid. If a section is a quote in another language, give the element around it the code of that language.

On dynamic sites the value comes from a setting. For example, if the site language setting in your content management system is wrong, every page carries the wrong value. So changing the setting fixes all pages at once.

1. Record the current value and where it comes from.
2. Change the value to the right language code in the template or site setting.
3. Clear the cache and confirm the new value in the page source.
4. Open one page of each template type and repeat the check.
5. Note the change date and request a fresh inspection in Search Console.

These steps need no code block, because the work is only about changing a value. If your setup is complex, work with your developer.

What is notranslate, and when should you use it?

The notranslate directive tells Google that you do not want it to provide a translation for the page. According to Google, when it recognizes that a page is not in the language the user likely wants to read, it may provide a translated title link and snippet in search results. The directive switches that behavior off (source: Google Search Central, special tags).

There is a critical distinction here. Specifically, the directive is not a fix for language detection. It does not correct a wrong detected language, and it only turns off the translated presentation.

A good use, for example, is a part that would lose its meaning if translated, such as a brand name or a technical term. A bad use, however, is applying it to the whole page to hide the real cause.

• Use it for brand or technical terms that must stay as written.
• Use it with care on a whole page, because it also removes the translation option for foreign visitors.
• Do not use it to cover up a mixed language problem.

Fix the root cause first. Then, if you really need it, apply notranslate in a targeted way.

How do screen readers react to a wrong lang value?

A screen reader can load the right pronunciation rules from the lang value while it reads the text aloud. If the value is wrong, text in your language may be read with another language's rules and become hard to understand. The WCAG explanation states this point clearly (source: W3C, understanding the language of page criterion).

This matters most for blind visitors and for people who use text to speech. It also affects readers with cognitive or learning disabilities who rely on speech tools.

So do not judge the lang value from an SEO angle alone. It is also a basic accessibility detail. If you want help with accessibility readiness, our team can work with you.

As a result, a correct lang value gives two gains: correct reading for the visitor and a correct translate decision for the browser. Both depend on one small change.

What if the title and snippet appear in the wrong language in search results?

Check the title and description fields of the page first. Because they often come from the template in another language, Google may use that text. Writing both in the page language is the first fix.

Google can build the title link and the snippet from several sources. So there is no guarantee that your text will appear exactly as written. Still, consistent signals in one language improve your chances.

To write the fields one by one, try our meta tag generator. For a quick overall view of the page, our SEO checker also helps.

Also, if you see a translated title, Google may have judged the page as content not in the user's language. In that case, first make the visible language of the page clear.

• Write the title in the page language and match the topic.
• Keep the description in the page language and in line with the content.
• Reduce mixed language wording in the title.
• Request a fresh inspection after the change.

The search result may not change right away, because Google has to process the page again.

How do you check in Search Console when Google detects wrong language?

First, Search Console is the most reliable source for how Google fetches and processes your page. Then open the affected address in the URL inspection tool and look at the page version Google saw. Then check which language the menu and the content appear in.

You can also review which queries bring each page. If your page does not show for queries in its own language, the language signal may be weak. However, this alone is not proof, because rankings depend on many factors.

Section names in the interface can change, so we do not give an exact menu path. Please check the official Search Console Help for current names. Your goal is to see how Google views your page and which text it brings forward.

• Inspect the affected address and open the processed version of the page.
• Check the language of the menu and footer text.
• Review the pages that receive queries in your own language.
• Inspect the same address again after the fix.

This way you compare the before and after with your own eyes. It also gives your team or client a clear piece of evidence.

Why are short pages more exposed to a wrong language signal?

In practice, a short page has little content text, while the menu and footer text stays constant. As a result, foreign words in the menu take a big share of the total text. For example, thirty words of menu text on a hundred word page can blur the language.

This is an example calculation, not a fixed threshold. Instead, we use it to show why the ratio matters. On long pages, however, template text remains a small part of the whole.

Short pages include contact pages, thank you pages, category landing pages and brief product pages. Language consistency matters even more on these.

• Write form labels on the contact page in the page language.
• Keep a short but clear text on the thank you page.
• Add an introduction paragraph to category pages.
• Give technical tables on product pages headings in the page language.

That way the page language dominates even on short pages. Therefore the language signal becomes clear.

How do translation plugins and automatic translation affect language signals?

In-browser translation changes the screen of the visitor and does not touch your source. A translation plugin on your site, on the other hand, can change the page content on the server or in the browser. The second kind directly affects the language signal.

If a plugin translates only the menu and leaves the content untouched, you create the mixed page that the Google document warns about. So check which parts of the page your plugin translates.

Also, use a separate page for each language instead of side-by-side translations. This structure is also clearer for readers and for Google.

Read automatic translation output before you publish it. A badly translated menu lowers the language quality of the page and can hurt trust.

Which myths should you drop when Google detects wrong language?

Several common beliefs waste time. The list below sums up the assumptions we hear most often, along with the facts. Each item rests on official documents.

• Myth: fixing lang makes Google fix the language right away. Fact: Google looks at the text, and lang mainly serves other systems.
• Myth: notranslate solves everything. Fact: it only turns off translated presentation and does not repair detection.
• Myth: menu text does not matter. Fact: on short pages it takes a large share of the text.
• Myth: only the home page is affected. Fact: a template error spreads to every page.
• Myth: the translate prompt is a Google bug. Fact: the page usually carries a mixed language signal.

Once you drop these assumptions, diagnosis gets easier. So focus on data first and on the fix second.

Which tools help when Google detects wrong language?

You do not need expensive tools to diagnose this. A browser, the page source and Search Console are usually enough. A few free tools of ours still speed things up.

To prepare the title and description in the right language, use our meta tag generator. To scan the general SEO view of the page, try our SEO checker.

On the accessibility side, a short test with a screen reader lets you hear the effect of the lang value directly. The built-in read aloud feature of your operating system is enough for this test.

Also ask a teammate to open the page with a different browser language. The translate prompt depends on the browser language, so you may see different behavior under different settings.

1. Open the page twice, once with each browser language.
2. Note whether the translate prompt appears in both.
3. Check the lang value in the page source.
4. Inspect the same address in Search Console.

If Google detects wrong language only under one browser setting, this mini experiment shows whether the problem belongs to the browser or to the content.

How do you keep language signals clean on a multilingual site?

On a multilingual site, each language version should carry its visible text in one language. Leaving the menu in one language on a page whose content is in another creates confusion. Google also recommends keeping content and navigation in a single language.

Connecting versions to each other is a different subject, and it is covered in our hreflang article. For the wider strategy, see our multilingual website SEO guide.

Here we stress only one thing: even with perfect hreflang, a language problem can continue if the visible text is mixed. Google reads the language from the content.

• Keep the menu, footer and content in the same language on every version.
• Write the language switcher entries in each language's own name.
• Use separate pages instead of side-by-side translations.
• Set the lang value of each version to its own language.

These rules look simple. Nevertheless, large sites need steady checks.

When do results change after the fix?

We cannot give an exact time, because Google crawls and processes pages on its own schedule. The time depends on the size of the site and the crawl frequency. You need some patience.

To speed things up, you can request indexing for the address in Search Console. It gives no guarantee, and it only tells Google that the page changed. A current sitemap also helps.

The browser translate prompt changes much faster. The browser re-evaluates the page when you open it again. So you get the first feedback on your fix in the browser.

Keep notes as you go. Then you can see later which change produced which result.

What brings the problem back after you fix it?

The problem can return after a fix. Most of the time the reason is a theme update, a new plugin or a template change. Run a short check after every update.

• A theme update can reset the lang value to a default.
• A new plugin can add interface text in another language.
• New page types with missing language files can stay untranslated.
• The site language setting in the admin panel can change by accident.
• Team members who enter content can paste text copied in another language.

So add a simple language check to your publishing routine. After each new template or plugin, open one sample page and look at the menu and the lang value.

If you want regular technical checks, take a look at our SEO consulting service.

How do you tell this problem apart from similar search problems?

A wrong language signal can be mistaken for other search issues. For instance, missing from a question box or being filtered by safe search are entirely different topics. Each has its own cause and fix.

For question box visibility, see our article on appearing in People also ask. If you suspect that your site is filtered by mistake, read our article on SafeSearch filtering.

These two topics are independent of language detection. Still, you may face several problems at once. In that case, handle each one separately.

The telling sign of a language problem is this: you see a translate prompt or a title in the wrong language. Other problems do not show this symptom.

How does our team approach this problem?

At Talha Aslan and team, we start with data in cases like this. We compare affected and healthy pages, find the shared template and fix it at one point. This way we avoid fixing pages one by one.

Example scenario: on a corporate site, the menu and footer stayed in one language while the content is in another. We translate the menu and the footer, check the lang value and review the title and description fields. Then we request a fresh inspection in Search Console.

We do not guarantee the result of this process, even when Google detects wrong language for clear reasons. Google makes language decisions with its own systems. However, cleaning up mixed language signals is a solid step that raises the chance of a correct outcome.

If you want support on your own site, you can contact us for a technical SEO review.

What is the final checklist for language problems?

Use the list below after every fix and after every major update. Going in order speeds up your work.

1. Is the visible text in one language, including menu and footer?
2. Does the lang value on the html element match the page language?
3. Are the title and description written in the page language?
4. Did you run the same check on different template types?
5. Is notranslate used only where you truly need it?
6. Did you run a short test with a screen reader?
7. Did you request a fresh inspection for the fixed addresses in Search Console?

When the whole list turns green, you have done everything you can. The rest depends on how Google processes the page again.

Remember that this article rests on Google and W3C documents. Interface names and behavior can change over time. So check the official help pages for exact details.