Skip to content
Back to the guides
Guide Last checked: October 2026 5 min read

Translating your website: URLs, hreflang and review

A translated website needs more than translated text: one address per language, hreflang, the lang attribute, a glossary and a review before you publish.

One address per language

Give every language version of a page its own URL, for example example.com/de/ and example.com/pl/. Google recommends separate URLs instead of switching the language on the same address with cookies or browser settings. Subfolders, subdomains or country domains all work; URL parameters such as ?lang=de are not recommended. Google works out the language of a page from its visible content, so keep the text and the navigation of one page in one language.

hreflang: connect the versions

With hreflang you tell search engines which pages belong together: with link elements in the head of the page, an HTTP header or the sitemap. For Google the three ways are equivalent, so one is enough. An example for a page in English, German and Polish:

<link rel="alternate" hreflang="en" href="https://example.com/en/prices/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/preise/" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/ceny/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/prices/" />
  • The same block goes on all three pages. Every version lists itself and all the others; if B does not point back to A, Google ignores the tags.
  • Use full addresses with https://, not just /de/preise/.
  • The language code follows ISO 639-1 (de, pl), optionally with a region in ISO 3166-1 Alpha 2, such as de-AT. A country code on its own is not valid.
  • x-default names the page for visitors whose language matches none of your versions. Google designed it for language selection pages; many sites use their main version.

The lang attribute

Set the language of the page on the html element, for example lang="en". A passage in another language gets its own lang attribute on the element around it. According to the W3C, speech output, braille translation, spell checkers, font choice and hyphenation use this information. Google, on the other hand, writes that it does not use hreflang or the lang attribute to detect the language of a page. So the attribute serves browsers and assistive technology, and the visible text has to be in the right language.

What must not be translated

  • HTML tags and attributes: a translated class name or href breaks the layout or the link.
  • Placeholders such as {name}, {{count}}, %s or %1$d. They stay exactly as they are and appear exactly once.
  • URLs, file names, e-mail addresses, code and shortcodes such as [contact-form].
  • Keys in language files, such as checkout.button.pay. Only the values are translated.
  • Brand and product names, unless you have chosen a local name on purpose.
One broken placeholder is enough
If %s turns into % s or {name} gets translated, the page shows raw code or an error. Check the placeholders after every translation.

Language files: .po, JSON and XLIFF

Apps, themes and plugins keep their texts in language files. In gettext .po files every entry has a msgid (the source) and a msgstr (the translation); the Plural-Forms header says how many plural forms the language has. Polish needs three, English two. In i18n JSON files the keys stay and only the values change. XLIFF keeps source and target side by side, with ids and notes that must stay.

A glossary for brand and product terms

Before the first translation, decide which terms stay as they are (brand, product and plan names) and which always get the same translation. Add the form of address: du or Sie in German, ty or Pan/Pani in Polish. This keeps buttons, product pages and emails consistent.

Machine translation: a draft, then a native speaker

Machine translation gives you a quick first draft, not a finished text. Google's spam policies name scraped content turned into many pages by automated translating, with little value for users, as one example of scaled content abuse. The problem there is mass-produced pages without value, not translation as such. Google also writes that translating only menu and footer while the main content stays in one language makes a bad experience. Plan a review by a native speaker:

  1. 1Read the text on the page, not only in a table. Context changes meaning.
  2. 2Check numbers, dates, prices, units and contact details.
  3. 3Check the glossary terms and the form of address.
  4. 4Check short texts: buttons, menu entries and error messages often get longer or ambiguous.

Do not redirect visitors automatically

Google advises against automatic redirects based on the assumed language or location of a visitor, such as IP address or browser language: they can stop people and search engines from seeing all versions. Put a visible language switcher on every page that links to the same page in the other languages, and let people choose.

Work with Do4U

Translate HTML keeps tags, links, attributes and placeholders unchanged and then checks the structure; the glossary of your account keeps brand and product names as you want them. The Language files tool does the same for .po, JSON and XLIFF files and builds the plural forms of the target language. The Translate tool handles plain text and lists unclear passages as notes.

Do4U builds the draft, you check and decide. Have a native speaker read it before you publish. A translation is no promise of more visitors.

Sources