Hreflang and Multi-Language Sites: A Plain-English Guide for Companies Selling Across the EU
A Tallinn software company translates its site into Finnish, German and English. Three months later, a prospect in Helsinki searches for the service in Finnish and lands on the English page, while a buyer in Munich is shown the Estonian one. Nothing is broken. The pages exist, they are translated, they are even indexed. What is missing is a clear signal about which version belongs to which reader.
That signal is called hreflang. This guide explains, without any code knowledge, whether your company needs it, which site structure it depends on, what Google documents as the rules, and what to ask your developer or plugin. It leans on Google’s own documentation throughout, and it says plainly where something is our judgement rather than a rule.
Do you actually need hreflang?
Not every multi-language plan does. Use this table before spending any time on it.
| Your situation | Do you need hreflang? | Why |
|---|---|---|
| One language, one site | No | There are no alternate versions to link |
| One English page used for every country | No | One URL, one version |
| The same content in two or more languages on separate URLs, for example /et/ and /en/ | Yes | These are alternates, and Google should know it |
| An English page for the UK and a different English page for the US, with different prices or spelling | Yes, if both matter to you | These are regional variants |
| A language switcher that changes the text but keeps the same URL | Fix this first | Google recommends a separate URL for each language version |
| Dozens of machine-translated pages added automatically | Fix this first | See the translation section below |
Google’s documentation on localised versions makes one point worth knowing early: localised versions of a page are only considered duplicates if the main content stays untranslated. So hreflang is not a shield against a duplicate-content penalty. It is a way of telling Google which of your translated pages suits which user. Google also says it may find alternate versions without any annotations, which is why a small site with two clear language folders is not in crisis if it has none. It is simply leaving the decision to Google.
Choose the URL structure first
Hreflang links pages together. If the pages are not separate and stable, there is nothing to link. Google’s guide to managing multi-regional and multilingual sites lists the main options:
| Structure | Example | What Google lists in its favour | What Google lists against it |
|---|---|---|---|
| Country domain | example.de | Clear geotargeting, easy to keep sites separate | Can be costly or unavailable, needs more infrastructure, targets only one country |
| Subdomain | de.example.com | Easy to set up, allows different server locations | Visitors may not know whether “de” means a language or a country |
| Subdirectory | example.com/de/ | Easy to set up, low maintenance on one host | Geotargeting is less obvious from the URL, harder to separate sites |
| URL parameter | example.com?loc=de | Not recommended | Hard to segment, unclear to users |
For a small company, one domain with a folder per language is usually the easiest to run, and that is a judgement, not a Google rule. A country domain makes sense when you genuinely run separate operations per country. If your main address is a .ee domain, it points clearly to Estonia. That suits Estonian searches, but it is a less natural fit for a site mostly aimed at Finnish or German buyers, and Google itself lists “targets only one country” as a drawback of country domains.
Whatever you pick, keep one language per page for content and navigation. Google advises against side-by-side translations on one page, and warns that translating only the boilerplate while leaving the main content in one language creates a poor experience.
What hreflang does, and what it does not
It does one job: it tells Google which pages are alternates of each other, so the most appropriate version can be shown to a user by language or region.
It does not detect language. Google says it does not use hreflang or the lang attribute to work out what language a page is in; it uses its own algorithms for that. It does not translate anything. It does not rescue weak pages. And Google presents it as a way to point users to the right version, not as a ranking boost, so the sensible expectation is “the right page appears for the right person”, not “more traffic overall”.
That expectation matters when you decide how much to spend. For many companies the benefit is cleaner: a Finnish prospect sees the Finnish page, and the sales conversation starts in the right language.
How RankMaster works with multi-language sites
RankMaster is a Brazilian SEO and GEO agency, with its site at rankmaster.com.br, that works remotely and in British English with e-Residency and Estonian companies. When a company sells in several languages, we usually begin by mapping which language versions exist, which are worth keeping, and which searches each one should answer. Only then do we look at the tags. The work is delivered in three recurring parts:
- Monthly plan. A written plan before each month: which language versions to build or improve, how the pages link together, and the technical fixes that come first, each with the reason.
- Monthly report. What was published, what Google Search Console shows for each language, and how the company appears in AI answers, including what did not change.
- Daily monitoring. Ongoing checks for pages leaving the index, alternate pages that now redirect or return errors, and robots.txt changes that could hide a language folder.
We do not promise rankings or citations, because no one can guarantee them. You can read our guide to SEO for e-Residency companies, learn more about RankMaster or ask for a free analysis through the contact section.
The four rules, with a worked example
Imagine a service page that exists in Estonian, English and Finnish. Every one of those three pages carries the same block of tags in its head section:
Google documents these requirements for all methods:
- Every version lists itself and all the others. The Estonian page has a tag for Estonian too. The set of tags is identical on each version.
- Return links are required. Google states that if two pages do not both point to each other, the tags are ignored. If the English page names the Finnish one but the Finnish page does not name the English one, the pair does not count.
- URLs must be fully qualified. Include the https:// part. Root-relative paths such as /en/services/ are not accepted.
- Codes must be valid. The format is a language code (ISO 639-1), optionally followed by a region code (ISO 3166-1 Alpha 2), separated by a dash. A country code cannot stand alone. Google’s troubleshooting notes list reserved codes such as EU and UK as ignored, so for the United Kingdom the valid code is GB.
| Right | Wrong | Why |
|---|---|---|
| en | en-eu | EU is not a valid region code |
| en-gb | en-uk | The code for the United Kingdom is GB |
| et | ee | A country code cannot stand alone |
| fi | fi_FI | Use a dash, not an underscore |
On x-default: Google describes it as the fallback for users whose language matches none of your versions, and best suited to a language selector page. If you have no selector, pointing it at your English page is a common and reasonable choice, but it is a choice, not a rule.
Use language-only codes (en) unless you really have different versions for different countries, such as a UK page with prices in pounds and an Irish page with prices in euros. Splitting without a reason only creates more pages to keep in sync.
Three ways to add the tags
Google accepts HTML tags in the head, HTTP headers, or an XML sitemap, and treats them as equivalent. Using all three gives no extra benefit in Search and makes mistakes more likely, so choose one. HTTP headers are mainly for files that have no HTML, such as PDFs. For most small sites the choice is between tags added by your CMS or translation plugin and entries in the sitemap. Ask which one your set-up produces and check that it follows the four rules above.
Translation: where multi-language sites usually go wrong
Translate the pages that sell first. Services, pricing or enquiry information, about, contact and your two or three strongest guides. A site with eight excellent Finnish pages beats one with eighty thin ones.
Be careful with automated translation at scale. Google’s spam policies list translating among the automated techniques used in scaled content abuse, meaning many pages produced to manipulate rankings with little value for users. A reviewed translation of your real service pages is a different thing. The safe practice is to have a fluent person read what goes live.
Do not translate keywords literally. A Finnish buyer may use a different phrase from the one a translation tool gives you. Look at what people actually type in that language, and use your Search Console queries as a guide.
Localise the facts. Currency, VAT wording, delivery times, opening hours, phone format and legal details can differ by market. A well-translated UK page that still shows euro prices and an Estonian phone format is a poor page.
Do not redirect people by language or location
It is tempting to send each visitor automatically to “their” version. Google advises against it: it says to avoid automatically redirecting users from one language version to another, because the redirects can stop users and search engines from seeing every version. Google’s crawler also usually visits from the United States and does not send language headers, so it may never see the versions you hid behind a redirect. A visible language link, or a small banner that suggests another version and lets the visitor decide, avoids the problem.
If you sell to consumers across the EU, there is also a separate legal topic. The European Commission explains that unjustified geo-blocking means discrimination between EU customers to segment markets along national borders. That is not an SEO rule and this guide is not legal advice, so ask your adviser whether your set-up affects you.
How to check your set-up without a developer
- Open one page in each language, view the page source and search for “hreflang”. Compare the lists. They should be identical.
- Click every URL in the list. Each one should open the right page directly, not redirect or show an error.
- Confirm each language version is indexed using the URL Inspection tool in Google Search Console.
- Look for pairs that do not point back to each other. This is the most common fault and the easiest to miss.
- If you use a third-party validator, treat it as a helper: Google says it does not maintain or verify those tools.
Common mistakes
- No return links between versions.
- Invalid codes, such as en-uk, a country code alone, or underscores.
- Tags pointing to redirected or broken URLs.
- Different sets of languages on different pages, without a reason.
- Mixing methods and ending up with conflicting information.
- A language switcher on one URL, so there are no separate pages to annotate.
- Automatic redirects by location, which hide versions from users and crawlers.
Frequently asked questions
Do I need hreflang if I only translate the homepage?
If the translated homepage lives on its own URL, link it with its original. The rest of your site stays single-language, and the tags only need to cover the pages that have alternates.
Should I use en or en-gb?
Use en if the same English page serves everyone. Use en-gb, en-us or others only if you have separate versions for those markets.
Does hreflang improve rankings?
Google’s documentation presents it as a way to point users to the most appropriate version and does not promise ranking gains. Expect the right page for the right user, and no promise beyond that.
Can the language versions sit on different domains?
Yes. Google says alternate URLs do not need to be in the same domain.
How long until it works?
It depends on how often Google crawls your pages. Any exact timeline given without seeing your site is a guess.
Five questions to ask your developer this week
- Does every language version have its own URL?
- Which method adds our hreflang tags: the head, the sitemap or a plugin?
- Does each page list itself and all its alternates, with full URLs?
- Are all our language and region codes valid?
- Does anything redirect visitors by country or language?
If the answers come back unclear, a second opinion costs little. You can ask for a free analysis through the RankMaster contact section.