What to Do With Untranslated Pages on a Multilingual Site

Short answer: The cleanest way to handle an untranslated page is to not create a URL for it in the other language until the translation exists. Its hreflang cluster lists only the versions that do exist, the language switcher hides or marks the missing language, and internal links in that language do not point to it. If your system shows the original text on translated URLs as a fallback, keep those URLs out of the index, out of sitemaps and out of hreflang, because they are duplicates in the wrong language.

Partial translation is normal

Very few multilingual sites translate everything. The usual pattern is a fully translated core, such as the home page, main product or service pages, pricing and legal pages, plus a selection of articles and help pages. The rest exists only in the original language. That is a sensible use of translation budgets, and search engines have no problem with it.

The problems arise from how the site treats the gaps. Multilingual systems handle missing translations in different ways, and some of those ways create pages whose URL, language signals and content contradict each other.

The choice is usually made once, in a plugin or platform setting, often by whoever installed the multilingual system years ago. Many site owners do not know which behaviour their site uses until they look. Checking it takes a few minutes and can explain puzzling symptoms, such as English queries bringing impressions to a German folder or duplicate titles across languages.

The three common approaches

The first approach is the cleanest. The second is the most harmful. The third can be acceptable in specific situations, such as old URLs that used to exist, as long as it is not used as a general substitute for translation.

Why fallback content causes problems

Fallback content, where a translated URL displays the original-language text, is offered by several multilingual systems as a convenience. It creates several issues at once:

• Duplicate content. The German URL contains the same English text as the English URL. Search engines have to choose which to index.
• Wrong language signals. The URL sits in the /de/ folder and may carry lang="de" and an hreflang code of de, while the text is English. Google judges language from visible text, so the page is effectively an English page in a German section.
• Diluted language sections. A German section with many English pages looks less like a real German site, to readers and to search engines.
• Poor experience. German visitors who click a German search result and see English text feel misled.

If your system uses fallbacks and cannot be changed quickly, at least add noindex to fallback pages, remove them from sitemaps and exclude them from hreflang clusters. Better still, switch the setting so untranslated pages do not get translated URLs at all.

hreflang for partially translated content

hreflang handles partial translation well, as long as clusters reflect reality:

• A page translated into three of five languages has a cluster with three entries (plus x-default if you use it).
• A page that exists only in English has no hreflang at all, or at most a self-reference, which is harmless.
• Never list a missing translation as an alternate, whether it would return 404, redirect or show fallback text.
• When a new translation is published, add it to the cluster on every version at the same time.

Most multilingual plugins generate clusters from translation links, so this happens automatically if untranslated pages have no linked translation. Problems usually come from templates that output an entry for every configured language regardless.

A quick test is to view the source of a page that exists only in English. If its head lists German, French and Spanish alternates, the template is generating entries without checking whether translations exist, and every one of those entries is broken.

The language switcher on untranslated pages

On a page without translations, the language switcher needs a sensible behaviour. Options include:

1. Hide missing languages for that page, showing only languages in which it exists.
2. Show missing languages as unavailable, greyed out with a short note.
3. Link to the closest relevant page in the other language, such as the parent section, with clear labelling.

Avoid silently linking to the other language’s home page. For a visitor, that feels like a broken link, and for search engines, it adds many links between unrelated pages.

Internal links within a language

Translated pages often contain links copied from the original. When the linked page has no translation, the link either points to the original-language page or to a non-existent translated URL. Decide on a rule:

• Link to the closest page in the same language where one exists.
• If you link to the original-language page, mark it, for example “(in English)”, so readers are not surprised.
• Never link to a translated URL that does not exist or shows fallback content.

Special cases: legal pages, outdated translations and user content

A few kinds of content need their own rules.

Legal and policy pages. Terms, privacy policies and imprints are sometimes legally required in the local language, and sometimes the original-language version is the binding one. If a legal page is not translated, say clearly on the translated site which language version applies and link to it. Do not display the original text under a translated URL without explanation.

Outdated translations. A page that was translated years ago and never updated can be worse than no translation: old prices, discontinued features and wrong instructions mislead readers. Treat severely outdated translations like missing ones. Update them, or remove them and redirect to the closest current page in the same language, and update hreflang on every version accordingly.

User-generated content. Reviews, comments and forum posts are written in whatever language users choose. They do not need translated URLs. If you show them on translated pages, mark their language with a lang attribute on the containing element, and consider showing reviews in the page’s language first.

Media and downloads. PDFs, manuals and videos often exist only in the original language. On translated pages, label links to them with their language, so visitors know what to expect before downloading.

In each case, the principle is the same as for regular pages: be honest about what exists in which language, and do not create pages that pretend to be something they are not.

Deciding what to translate next

Untranslated pages are also a to-do list. Use data to decide which gaps to close first:

• Search demand: local keyword research shows which topics people search for in each language.
• Existing traffic: Search Console shows original-language pages that already receive impressions from the target country, a sign of unmet demand.
• Internal search and support: what visitors in each language look for and ask about.
• Commercial value: pages close to conversion, such as feature, comparison and pricing pages, usually come first.

Translate in groups of related pages where possible, so new translations can link to each other and form a coherent section.

Keep a simple tracking sheet per language: pages translated, pages planned and pages deliberately left untranslated, with a reason. It prevents the same debate from recurring and shows at a glance how complete each language version is.

Checking how your site handles gaps

To see what your site does today, pick a page that exists only in the original language and request its would-be translated URL. Does it return 404, redirect or show fallback text? Then check its hreflang, the switcher and any sitemap entries. A crawl extends this to the whole site. Site SEO AI Audit reports broken language versions, hreflang return links, x-default and lang attributes in its Languages area, and duplicate titles and descriptions in its on-page area, which often reveal fallback pages. The first audit is free.

Related reading

• How Google detects the language of a page, and why it matters
• hreflang conflicts with noindex, robots.txt and redirects
• Language switcher best practices for SEO and usability

The bottom line

Partial translation is fine; misleading pages are not. Do not create translated URLs for pages that are not translated, keep hreflang to real translations, make the language switcher honest, keep internal links within each language where possible and keep any fallback pages out of the index, sitemaps and hreflang. Then use demand data to decide which gaps to fill next.

DUK

Is it bad SEO to have pages in only one language?

No. Most multilingual sites translate selectively. Pages without translations simply have no alternates, which is perfectly normal.

Should a missing translation redirect to the original page?

It is better not to create the translated URL at all. Redirects are acceptable for old URLs that used to exist, but they should not appear in hreflang.

What is wrong with showing the original text on a translated URL?

It creates duplicate content in the wrong language, contradicts language signals and disappoints visitors. If unavoidable, keep such pages out of the index and hreflang.

Should the language switcher show languages without a translation?

Either hide them or show them as unavailable. Do not silently send visitors to another language’s home page.

How do I decide which pages to translate next?

Use local search demand, existing impressions from the target country, internal search and support questions, and commercial value to prioritise.