Hreflang Errors: When Your Multilingual Site Competes With Itself

A multilingual site has one awkward property: the same content exists in several versions, and the search engine has to guess which one to show to whom. If you do not tell it, it decides on its own. The usual result is that someone in Austria lands on the German-from-Germany page, a visitor in Canada gets the US store, and you are left wondering why conversion on one market keeps sliding.

Hreflang is the markup that says: these URLs are the same page in another language or for another country, pick the right one. That sounds simple. In practice it is one of the most frequently misconfigured things on a website, because a broken hreflang setup is invisible. Pages render fine, nothing turns red, and something inexplicable just happens abroad.

What hreflang does and what it does not

Hreflang is not a ranking signal. It will not move you up the results page and it does not replace translation. It does two things:

1. Decides which language version is shown to a user in a given language and country.
2. Groups language versions together so the search engine does not treat them as competing duplicates.

The second point is the one that surprises people. If you have a UK and a US version of a product page and 80% of the text is identical (specs, model names, descriptions), without hreflang those two URLs genuinely compete with each other. It is the same mechanism as keyword cannibalization, only across languages and markets.

What a correct implementation looks like

Every language version needs links in <head> pointing to all versions, including itself:

``html <link rel="alternate" hreflang="en-GB" href="https://example.com/uk/product/" /> <link rel="alternate" hreflang="en-US" href="https://example.com/us/product/" /> <link rel="alternate" hreflang="de-AT" href="https://example.com/at/produkt/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/product/" /> ``

There are three places you can put it: tags in <head>, an HTTP Link header (useful for PDFs and other non-HTML files), or xhtml:link attributes in the XML sitemap. On a large site the sitemap is the practical option — you do not have to touch templates, and all changes live in one file.

Eight errors I find most often

1. Missing return links

Hreflang works both ways. If the UK page points to the US page, the US page has to point back. If it does not, Google ignores the whole relationship. This is the most common failure on sites where language versions were added one at a time — the new version links to the old ones, the old ones know nothing about the new one.

Typical trigger: a different person or a different plugin manages the translated version.

2. Invalid language and country codes

Language is ISO 639-1 (two letters), country is ISO 3166-1 alpha-2. The mistakes that keep repeating:

• en-UK instead of the correct en-GB
• cz used as a language — Czech is cs, cz is a country code
• en-GB is fine, GB-en is not — the order is language-country
• de-DE-AT — a combination of two countries does not exist
• a bare at or us with no language — country cannot be used on its own

One invalid code does not break the page. It breaks that one relationship, silently.

3. No self-referencing link

Every version must include an hreflang pointing at itself. Templates that output "other languages" routinely skip that line. Without it the cluster is incomplete and Google processes it unreliably.

4. Hreflang contradicting the canonical

The nastiest combination. The UK page has hreflang pointing to the US version, but its canonical points at the US version too. You are saying two things at once: "this is a standalone language version" and "this is not the main version, index the other one". Canonical wins and hreflang disappears.

The rule: the canonical of each language version points at itself. Canonicalise within one language if you need to (parameter URLs, for example), never between languages. More on when a canonical helps and when it hurts in the article on canonical tags and duplicate content.

5. Relative URLs

href="/us/product/" is not enough. Hreflang needs an absolute URL with protocol and domain. The www or non-www variant and https have to match too — if the site runs on https://www.example.com and hreflang points to http://example.com, you create a redirect chain that kills the relationship.

6. Hreflang pointing at a redirect, a 404 or a noindex page

The target URL has to return 200 and be indexable. This usually breaks after a URL structure or slug change: the English URLs get rewritten, hreflang keeps the old ones and now points at a 301. Or a language version gets temporarily switched to noindex while every other version still links to it. The same applies to targets that have quietly become 404s.

7. Missing or badly set x-default

x-default is the version for everyone who does not fall into any defined language or country. It is not mandatory, but without it the search engine picks for you. Pointing it at the English version or at a language-selection page makes sense. Pointing it at a local version a visitor from another market will not understand does not.

8. Two sources of truth at once

Hreflang in <head> and in the sitemap at the same time is allowed, but only if both say the same thing. When the plugin generates one set and the template another, you send contradictory signals. Pick one place. If you go with the sitemap, check the search engine actually reads it — the usual causes are in the article on robots.txt and sitemap errors.

Hreflang will not fix a bad translation

Two things hreflang does nothing about:

Machine translation nobody proofread. If the German version is English run through a translator with the errors still in it, hreflang makes sure a German visitor sees it — and leaves. A signal about the correct version is not a reason to stay.

Identical titles across all languages. Translation plugins often leave titles and meta descriptions in the source language or copy them verbatim. That is a separate problem, solved by fixing duplicate title tags. Hreflang has no effect on it.

How to verify hreflang

Search Console no longer has a dedicated hreflang report, so the check is on you. A process that works:

1. Open the source of any language version and find every rel="alternate" line.
2. Check that one of them points at the current URL.
3. Open each target URL and confirm it links back to the one you started from.
4. Check the status codes of the targets — they must be 200, not 301 or 404.
5. Compare the canonical of each version: it has to point at itself.
6. Run the language and country codes against the ISO lists.

With three languages and five pages this takes half an hour. With three languages and 400 pages it is work nobody finishes by hand.

What I can find for you

When I crawl a site, I check hreflang on every page where it exists: whether there is a self-reference, whether the relationships are reciprocal, whether the codes match valid ISO values, whether the target URLs return 200, and whether hreflang contradicts the canonical. You get the finding with the exact URL and the exact line, not a message saying "international targeting issue".

What I will not decide for you: which markets you want split at country level (de-DE vs de-AT, en-GB vs en-US) and which are fine at language level. That depends on whether you have different prices, shipping or product range for that market. If the content does not differ, splitting by country only multiplies the number of URLs you have to maintain.

If you have no idea what state hreflang is in on your site, start with a free audit — you will see the list of findings, including the ones touching language versions. Fixing hreflang is one of those changes with a well-measurable effect: the ratio of visits between countries shifts, not the total number. So measure the impact in segments by country, not in a single chart.