Multilingual Websites: URLs, hreflang and Translation

Multilingual or multi-regional?

Google's guide to managing multi-regional and multilingual sites separates two things:

• Multilingual: the site offers content in more than one language, such as a Canadian business with English and French versions. Google tries to match the language of the searcher.
• Multi-regional: the site explicitly targets users in different countries, such as a manufacturer that ships to both Canada and the United States. Google tries to find the right page for the searcher's locale.

Some sites are both. A translation project and a set of country sites with different prices and terms are different amounts of work.

One URL per language version

Google recommends a different URL for each language version of a page, rather than using cookies or browser settings to change the language on the same URL. If the content changes dynamically by language, Google says it might not find and crawl all the variations, because Googlebot usually crawls from the USA and sends requests without an Accept-Language header.

Google's guide lists four ways to structure those URLs:

• Country-specific domain, such as example.de. Clear geotargeting, but more infrastructure, sometimes strict requirements, and one country per domain.
• Subdomain, such as de.example.com. Easy to set up and can use different servers, but users might not recognise from the URL whether "de" means a language or a country.
• Subdirectory, such as example.com/de/. Easy to set up and low maintenance on the same host, with the same ambiguity.
• URL parameter, such as ?loc=de. Google does not recommend this.

For many small businesses adding a second language, subdirectories on the existing domain are the simplest to run. Moving an existing site into a new structure is a migration; our redesign SEO guide covers redirects and checks.

Telling Google about translations with hreflang

Google's page on localized versions of a page explains how to mark pages as translations or regional variants of each other. There are three equivalent methods: <link rel="alternate" hreflang="..."> elements in the page's <head>, an HTTP Link header (useful for PDFs), or entries in an XML sitemap. Google says using more than one brings no benefit, so pick one.

The rules that catch people out:

• Every version lists itself and all the others. The set of links is identical on every version.
• Links must be two-way. If two pages do not both point to each other, Google ignores the tags.
• Use full URLs, including https://, not relative paths.
• Use the right codes. The first code is the language (ISO 639-1), optionally followed by a region (ISO 3166-1 Alpha 2), as in en-GB. A country code cannot be used on its own: Google's example is that be means Belarusian, not Belgium. Codes outside those standards, such as es-419, are not supported.
• Add x-default for the page people should see when no version matches their language, typically a language selector page.

Google states that it does not use hreflang or the HTML lang attribute to detect a page's language; it uses the visible content. That is why each page should use one language for its content and navigation, and Google advises against side-by-side translations. Google says localised versions count as duplicates only if the main content remains untranslated.

Automatic redirects and language detection

It is tempting to send visitors straight to the language you think they speak. Google advises against automatically redirecting users from one language version to another based on a guess, because it can stop users and search engines from seeing all the versions. It also says not to use IP location to adapt content, since IP analysis is difficult and generally not reliable.

The W3C's article on helping users find the right language version takes a slightly different view: server-side language negotiation, based on the browser's language preferences, can help guide people to a page in a language they prefer. It too warns against guessing language from location. Both agree that visitors must always be able to switch. A gentle banner suggesting another language is safer than a forced redirect.

Translation quality and Google's spam policies

Machine translation is quick, but publishing it unchecked at scale carries risk. Google's spam policies define scaled content abuse as generating many pages mainly to manipulate rankings rather than help users. Their examples include scraping content and generating many pages "through automated transformations like synonymizing, translating, or other obfuscation techniques" where little value is provided to users.

Translating your own pages for real customers is not the problem; low-value, unreviewed output is. In practice:

• translate only pages that serve customers in that language, not every page by default;
• have a fluent speaker review the text, especially legal pages and anything about prices or delivery;
• localise the details too: currency, dates, addresses, titles and form messages.

Our helpful content guide covers what Google looks for in pages more broadly.

A language switcher people can find

Google suggests adding links to the other language versions of each page so users can choose. The W3C gives detailed advice on how to present them:

• Link from every page, near the top, not hidden. A visitor who lands on a page in a language they cannot read must be able to spot the way out.
• Write each language name in its own language: "Français", "Deutsch", "日本語", not "French" or "German".
• Avoid flags for languages. Some countries have several languages and some languages are spoken in many countries. The W3C says flags may suit country-specific sites but not plain translations.
• Prefer visible links to a drop-down when there are only a few languages. The W3C's article on using select menus for localised content notes that users cannot see the options straight away and that a text label such as "Select language" may not be understood by the people who need it.
• Link to the same page in the other language, not back to its home page, where a translation exists.
• Offer to remember the choice when someone switches, as the W3C suggests, so later pages stay in that language.

Declaring the language in the page

Although Google detects language from content, browsers and assistive technology rely on the markup. The W3C's guidance on declaring language in HTML says to always put a lang attribute on the <html> element, such as <html lang="fr">, add lang to any passage in another language, and use the dir attribute for right-to-left scripts such as Arabic and Hebrew. Use UTF-8 throughout.

This is also an accessibility requirement. WCAG success criterion 3.1.1, Language of Page, exists so that screen readers load the right pronunciation rules and browsers display characters correctly, and 3.1.2, Language of Parts, extends that to passages in another language. Our accessibility basics guide covers the rest.

Your CMS makes much of this easier or harder. Our guide to choosing a CMS suggests testing this before you commit.

A checklist

• Each language version has its own URL, in one consistent structure.
• hreflang is set by one method, with self-references, two-way links, full URLs, valid codes and x-default.
• No forced redirects by IP or browser language; every version is reachable.
• Translations are reviewed by a fluent speaker and localised, including titles and form messages.
• Every page links to its counterparts, with language names in their own language and no flags for languages.
• lang is set on <html> and on passages in other languages, with dir where needed.

Frequently asked questions

Do I need hreflang if my site has only one language?

No. hreflang tells Google which pages are language or regional versions of each other, so it only applies when you have more than one version of a page. Google also notes it may find alternate versions without it, but recommends marking them explicitly.

Should I use a separate domain for each country?

Not necessarily. Google lists country domains, subdomains and subdirectories as options, each with pros and cons. A country domain gives clear geotargeting but needs more infrastructure and targets one country; subdirectories on one domain are easy to set up and maintain. Google does not recommend URL parameters.

Can I automatically send visitors to their language?

Google advises against automatically redirecting users to another language version based on a guess, and against adapting content by IP location, because users and search engines may then not see all versions. Let people choose, and make the switcher easy to find on every page.

Is machine translation against Google's rules?

Translating pages is not in itself a problem. Google's spam policies treat it as scaled content abuse when many pages are generated, including through automated translation, mainly to manipulate rankings with little value to users. Have a fluent speaker review translations before publishing.

Should I use flags in the language menu?

The W3C advises against flags for languages, because some countries have several languages and some languages are spoken in many countries. Write each language name in its own language instead, such as Deutsch or Français. Flags may suit country-specific sites.

Planning a site in more than one language, or adding a language to an existing one? See our website development service and all our services, or email info@creahive.com.