Skip to content
pageinspection

When the declared language and the actual language disagree

A page that declares German, serves an English navigation, a German article and an English cookie notice is not in one language. Every mechanism that reads a language declaration is now working from a claim the page does not honour.

The short answer

A half-translated page declares one language and shows another, usually because the template was translated and the content was not, or the reverse. Search engines read the words on the page rather than the declaration, so the page competes in a language it half speaks, and the mismatch undermines every hreflang annotation pointing at it.

ImportantAudit check · Language consistency

Two stories on one page

The declaration is a single value: this document is in German. The page is not a single thing. It has a header, a navigation tree, body copy, form labels, error messages, a footer, a legal paragraph and a set of dates and numbers, and each of those is translated by a different mechanism at a different time.

So partial translation is the normal state rather than an unusual failure. What varies is which parts are missing, and the pattern is remarkably consistent across sites:

what-gets-translated.txt
translated first    the article body, the page title, the H1
translated later    navigation labels, buttons, form fields
translated last     error messages, empty states, validation text
often never         legal text, cookie notices, transactional email,
                    404 pages, date and currency formatting,
                    alt text, image captions inside graphics

The bottom two rows are where this check finds things. Error and empty states are the ones nobody reviews because nobody reaches them during a translation pass, and legal text is the one everybody decides to leave in the original language on the grounds that it is legally safer, which may be true and is still a page in two languages.

Where half-translated pages come from

  • A translation file with missing keys. The framework falls back to the default language for anything unset, which is the correct engineering decision and produces a page in two languages with no error anywhere. The fallback is invisible by design.
  • A new feature shipped ahead of its copy. The English string goes in, the translation ticket is filed, and the ticket outlives the sprint. This is the single most common cause and it accumulates.
  • Content managed separately from interface. Articles are translated by a content team in a CMS, interface strings by engineers in a repository. Two processes, two schedules, and no single place where somebody sees the assembled page.
  • A language folder created for SEO reasons. The worst case: a /de/ path stood up with the English content copied in, on the theory that having the structure is a start. It is not a start, it is a duplicate of your site in a folder that claims to be German, and it is a duplication finding at the same time.
  • Machine translation applied unevenly. Some pages translated automatically, some by hand, some not at all, with no marker distinguishing them. The inconsistency is worse than any single approach applied throughout.

Notice that four of the five are process failures rather than technical ones. That is the useful conclusion: this check finds a symptom whose cause is almost always an organisational seam, and fixing the pages without fixing the seam means fixing them again next quarter.

Which half of the page matters most

Given limited translation budget, the priority is not what most teams choose. The instinct is to translate the interface, because it is visible everywhere and it is a finite list of strings. The better order is close to the opposite.

The body copy matters most, because it is what the page is for and what any search engine or model reads to work out what the page is about. A page with a German article and English buttons is usable by a German speaker. A page with German buttons and an English article is not a German page at all.

Then the title and description, because those are what appear in a result and decide whether anybody arrives.

Then anything that carries a consequence: form labels, validation messages, checkout copy, error states. Somebody who cannot understand a validation message cannot complete the thing they came to do, which makes these worth more than their word count suggests.

Then the rest of the chrome. A navigation label in the wrong language is a small friction, especially when the labels are short nouns whose meaning is guessable from position.

The exception worth building in: mark what you have not translated.

The lang attribute works on any element, not just on html. A block of untranslated English inside a German page can carry lang="en", which tells a screen reader to switch voice and tells anything reading the page that the mixture is deliberate rather than broken.

It costs one attribute and it converts an inconsistency into a declaration. That is genuinely better than either extreme, and it is what the attribute guide means by marking a passage.

A declaration compared against the words on the page

This is a comparison between two things: what the page says its language is, and what language its text is actually in. The second requires reading the text and identifying it, across the regions of the page separately, and doing it consistently across every page in a language set.

This one needs the full crawl

The finding compares what a page declares against what its text is actually in, across every page in a language set, which needs the pages side by side.

The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.

Run the full audit, free

What you can check on one page in ten seconds is the declaration itself, which is a separate check with an analyzer.

Why a half-translated page rates above a missing tag

This is Important, and so is the attribute check next to it, which invites the question of why they are not ranked against each other. The distinction worth drawing is that a missing attribute is a page that has not said anything, and a mismatch is a page that has said something untrue.

Untrue is worse in a specific way: it survives review. A missing lang is caught by any accessibility tool. A page declaring German while serving English navigation passes every mechanical check there is, because each individual piece is well formed. Only a human reading the assembled page notices, and nobody reads the assembled page in a language they do not speak.

It stays below Critical because the page works. It is crawled, indexed and served, and a visitor who reads either language can use it. Nothing is excluded, which is the line the top band is drawn at. What is lost is the reliability of every language signal on the site at once, and that is worth a place in the plan rather than in the polish list.

Questions this check raises

Which matters more, the html lang attribute or the visible text?
The visible text. Search engines detect language from the content and treat the attribute as a hint, so a page declaring de while showing English is understood as English with a wrong declaration. The attribute still matters for screen readers and translation tools, which do trust it.
How do half-translated pages happen?
A translation workflow that covers one layer and not another. Common shapes: the theme is translated and the posts are not, the posts are translated and the navigation is not, a fallback silently serves the source language when a string is missing, or user-generated content stays in whatever language it was written in.
Is a page with an untranslated navigation menu a problem?
It is a smaller problem than untranslated body content, because the body is what the language detector weighs and what the reader came for. It is still worth fixing: a reader who cannot read the menu cannot navigate, which costs more than the ranking effect does.