Six language versions can multiply your reach or compete with each other. The difference is a handful of hreflang and structure decisions that most multilingual sites quietly get wrong.
Hreflang mistakes in short
The most common hreflang mistakes are tags that are not reciprocal, pages that do not reference themselves, wrong language codes, and annotations that point to redirected or non-canonical URLs. Each one weakens the signal search engines use to choose a language version, so your German page ends up competing with your English one instead of replacing it for German searchers.
Hreflang does not lift rankings on its own. According to Google's documentation, it tells Google which version of a page suits which language or region so that the right one is shown. It is plumbing, and it fails quietly, which is why a six-language site needs to check it on purpose.
Why a multilingual site ends up competing with itself
When a search engine cannot tell that the /de/ page is the German twin of the English page, it sees two similar pages competing for the same queries. One may outrank the other in the wrong country, or one may be folded into the other as a duplicate. The visitor in Berlin lands on English, leaves, and that behaviour reinforces the wrong choice. The translation is rarely to blame. The cause is the plumbing around it: URLs, canonical tags and annotations that disagree with one another.
Scale makes it worse. Six languages mean six versions of every page, and each new page has to be tied into the set of the others. Sites usually get this right at launch and then drift: a page published in four languages leaves two siblings pointing at nothing, and the loop breaks without any visible error.
The five errors behind most hreflang problems
The first is missing return tags: the English page lists the German page, but the German page does not list the English one. Google's documentation says annotations must be reciprocal, and without the return link they may be ignored. The second is a missing self-reference, since every page should list itself as well as its alternatives. The third is wrong codes. Hreflang takes an ISO 639-1 language code, optionally followed by an ISO 3166-1 region, so ms, ar and zh work, while an invented value such as en-uk, or a country code used as a language, such as cn instead of zh, does not. The fourth is pointing at the wrong address: annotations need absolute URLs that return a 200 status and are the canonical version, not a redirect or a parameter variant. The fifth is a canonical tag on the German page that points at the English page, which tells search engines the German page is a copy and cancels the hreflang entirely.
One omission is worth fixing too. The x-default value names the page to show when no language matches, usually your language selector or the English root. It is optional, but across six languages it keeps unmatched visitors from landing on the wrong one.
How to find hreflang mistakes before they cost you traffic
Start by listing what each URL claims. Crawl the site with a tool that reports hreflang, export every page's annotations, and check four things for each: the page lists itself, every alternative links back, every address returns a 200 status without a redirect, and the canonical tag points to the page itself. A spreadsheet pivot of language against page makes the gaps obvious within minutes.
Then look for the symptoms in Google Search Console. Pages reported as 'Duplicate, Google chose different canonical than user' in the page indexing report often mean a language version is being treated as a copy of another. Finally, test like a customer: search for your own brand and services in German, Malay, Arabic, Chinese and Turkish in a normal browser and see which version appears. If the English page leads in every language, the annotations are not doing their job.
Choose one place to declare hreflang, whether the HTML head, HTTP headers or the XML sitemap, and keep it consistent. On our own site every page carries a self-reference, one tag for each of the other five languages and an x-default, all generated from one list in the build, so the set cannot drift when a page is added.
Six rules for one brand in six languages
- Generate the tags from one source. Never write hreflang by hand. Produce every annotation from a single list of language versions, so adding a page or a language updates all of its siblings at the same time.
- Give each language its own URL. A subfolder such as /de/ or /ar/ lets crawlers reach every version. A page that switches language by cookie or browser setting shows crawlers only one.
- Canonicalise every page to itself. A German page whose canonical points at the English original tells search engines it is a copy, and cancels the hreflang you added.
- Localise titles, descriptions and headings. A German page under an English title is a weak match for a German query. Write each title for what people in that language actually type, not as a literal translation.
- Annotate only pages that exist. If a page has no Arabic version, leave Arabic out of that set instead of redirecting to the homepage. A false alternative is worse than a missing one.
- Suggest a language, never force one. Google's documentation warns that automatic redirects based on location or browser language can stop crawlers from seeing every version. Offer a banner and let the visitor choose.
Hreflang mistakes: common questions
- Does hreflang improve search rankings? — Not directly. It helps the right language version appear for the right searchers, which improves relevance and reduces the chance that your own pages compete with each other.
- Do I need hreflang if every language already has its own URL? — Yes. Separate URLs are the foundation, but annotations tell search engines which pages are translations of one another. Without them the engine has to guess, and it sometimes guesses wrong.
- Should I use zh-Hans or ar-SA rather than just zh and ar? — Use the plain language code when you publish one version per language. Add a script or region, such as zh-Hans or ar-SA, only when you publish genuinely different versions for different audiences.
- Where should hreflang go: the page head, an HTTP header or the sitemap? — According to Google, any of the three is valid. Pick one method and use it everywhere. For a static site, tags in the HTML head are the simplest to generate and to check.
Keep reading
Build something
worth trusting.
Tell us what's slowing your business down. We'll show you the system that fixes it — and how fast.