hreflang: the invisible tag behind every multilingual site

If you run a multilingual site, this scenario probably sounds familiar: your English pages rank fine in the US, but someone searching from Germany sees the same English page instead of your German one. Or worse — your Spanish page outranks your English page in the UK, and the visitor bounces within a second. The culprit, more often than not, has a name: hreflang, either missing entirely or implemented wrong.

hreflang is a tag that lives in your page's source code and that no visitor ever sees. Its entire job is to tell Google: "the French version of this page is here, the English version is there — show people the one in their language." For such a simple job, it gets botched remarkably often. And when it's botched, you get no error message. The site keeps working. The wrong page just quietly goes to the wrong audience.

What hreflang does — and what it doesn't

Let's fix expectations first, because there are two persistent myths about this tag.

What it does: it links the different language and regional versions of the same content together. Google uses that signal when deciding which version to show in a given search. It also prevents your translated pages from being mistaken for duplicate content of each other.

What it doesn't do: improve your rankings. hreflang is not a ranking signal; it's a matching signal. If your German page is weak, correct hreflang won't strengthen it — it will only make sure the right people see it. That's usually the answer to "we added hreflang, why didn't traffic go up?" The tag doesn't create visibility. It routes the visibility you already have.

One more honest caveat: if you run a small two-language brochure site and both languages target the same country, life goes on fine without hreflang. Google is reasonably good at telling languages apart on its own. The tag becomes critical when the same language serves different regions (US vs UK English is the classic case) or when the number of languages grows.

The hreflang mistakes everyone makes

Anyone who has built multilingual sites for a while will tell you the same thing: very few teams get hreflang right on the first attempt. The failures cluster into a handful of patterns.

Missing return links: the one-way handshake

hreflang is a handshake. If the English page points to the German page, the German page must point back to the English one. When the link is one-way, Google ignores the annotation entirely — not partially, entirely. This is the sneakiest failure mode, because it's so easy to add tags to half the pages and call it done.

Wrong language and region codes

The format is language-REGION: en-US, en-GB, de-DE. Common mistakes: confusing country codes with language codes (writing en-UK for Britain — the correct code is en-GB), using a bare region code where a language code belongs, or inventing combinations that don't exist. An invalid code is treated as if the tag weren't there.

Forgetting x-default

x-default tells Google which page to show a user who matches none of your listed languages. A visitor from Japan — do they get English or German? Leave it out and Google decides for you, and not always the way you'd want. The usual rule: make your most globally useful version (for most sites, English) the x-default.

Skipping the self-reference

Every page must include itself in its own list of alternates. The English page's hreflang set needs an en entry pointing to its own URL. The spec explicitly requires this, but it feels counterintuitive, so it gets skipped constantly.

Pointing at redirected or broken URLs

Every URL an hreflang tag points to must return a clean 200. Pointing at a URL that 301-redirects elsewhere, returns a 404, or carries a noindex invalidates the annotation. Sites that migrate and change URLs but leave hreflang pointing at the old addresses fall straight into this trap.

Automatic geo-redirects: the well-meaning disaster

This isn't strictly an hreflang issue, but it comes up in the same conversation every time: sniffing the visitor's IP and force-redirecting them to "their" language. On paper it's polite. In practice it creates two serious problems.

First, Google's crawler mostly arrives from US IP addresses. If you force-redirect every visitor by location, Googlebot may never see your non-English pages at all. Second, you take the decision away from the user: the German speaker living in France wants the German page, and you keep throwing them at the French one.

The better pattern: redirect no one. Get hreflang right, optionally show a small banner — "This page is available in German. Switch?" — and remember the user's choice once they make it.

Where the tags actually go

You have three placement options; they're equivalent, and the only rule is to pick one and stay consistent:

• <link> tags in the HTML <head>. The most common approach. Perfectly manageable with a few languages; with 20+, every page's head starts to bloat.
• HTTP headers. The only option for non-HTML files like PDFs.
• The XML sitemap. The cleanest option for large multilingual sites: all the pairings live in one file, page markup stays clean, and auditing is easy.

Our own preference is usually this: the relationship between language versions is stored once in the CMS — "these two entries are translations of each other" — and the hreflang tags are generated from that relationship at build time. Every hand-maintained hreflang setup eventually breaks the day someone updates a page and forgets its counterpart. That's not a discipline problem; it's an architecture problem. Any SEO setup that depends on human memory is fragile by design.

How to check your implementation actually works

The most unnerving thing about hreflang is its silence: when it's broken, nothing visibly fails. A few concrete ways to check:

• Look at Search Console. Report names change over the years, but the Performance report will always show you which countries click which pages. If most clicks on your German pages come from the US, something is off.
• Read the source by hand. Pick three random pages, find the lines containing hreflang, and check: are the links reciprocal, is the self-reference there, do the URLs return 200?
• Search from another country. Use a VPN, or change the region in Google's search settings, search for your own brand, and see which version comes up.

Treat this as a recurring check, not a one-time setup: every time the URL structure changes, a language is added, or pages are removed, the hreflang set needs to move with it.

The question that comes before translation

One last honest note: hreflang is the technical but small part of international SEO. The real question is whether you actually have something to offer in that language. A machine-translated English section that nobody maintains will produce nothing, even with flawless hreflang. Decide first which markets you genuinely serve, produce real content in those languages — then let's talk about tags. Two real languages beat five half-hearted ones every time.

If you're building a multilingual site, or wondering why your current language setup isn't working, get in touch at vucod.com — we reply to every inquiry within 48 hours.