How to Set Up Hreflang Tags for Multilingual SEO

Key takeaways

Every page needs a self-referencing hreflang tag plus one for each translated variant, and they must all point back to each other — a missing return tag makes Google discard the entire set, not just the broken link.
Use a language code (ISO 639-1, like fr or en) optionally paired with a region code (ISO 3166-1 Alpha-2, like us or gb), joined with a hyphen — en-us, never en_US.
Pick one implementation method — HTML tags, HTTP headers, or sitemap — per site and don't mix them; conflicting signals from two methods get silently dropped rather than merged.

What hreflang actually does (and what it doesn't)

Hreflang is a targeting signal, not a ranking signal. It doesn't translate anything, doesn't boost a page's position, and doesn't consolidate duplicate-content signals the way rel="canonical" does. What it does is tell a search engine "if this searcher's language and location match this variant, serve them this URL instead of the default." Google's own documentation is explicit that hreflang affects which URL gets shown, not whether the domain ranks well overall.

The part founders get wrong most often: they assume hreflang prevents Google from treating /en/ and /de/ as duplicate content. It doesn't. If your "German" page is a machine-translated clone that's 90% identical in structure to the English one, hreflang just tells Google which duplicate to show German searchers — it does nothing to fix thin or duplicate content underneath. That's a content problem, and no annotation solves it.

The three implementation methods — pick one

You implement hreflang one of three ways, and mixing methods on the same site is a common source of silent failures.

HTML <link> tags in the <head> — the most common approach for sites under a few hundred pages. Simple to audit by viewing source.
HTTP headers — required for non-HTML files like PDFs, since you can't inject a <link> tag into a PDF's head.
XML sitemap entries — better once you're past roughly 50 URL variants, because keeping hundreds of <link> tags in every page's head bloats HTML weight and makes manual edits error-prone.

Here's the scaling problem nobody mentions upfront: each page needs one hreflang entry per variant, including itself. Five languages means six tags per page (five variants plus x-default). At 200 base pages across five languages, that's 1,000 URLs each carrying six tags — 6,000 individual references that all have to stay in sync every time a page is added, renamed, or removed. This is exactly the kind of repetitive, rule-based maintenance that breaks down under manual editing and is a better fit for a programmatic SEO tool that generates and updates the tag set automatically whenever the underlying page set changes.

Exact syntax and the codes you're allowed to use

A correct implementation looks like this:

<link rel="alternate" hreflang="en-us" href="https://example.com/en-us/pricing" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/pricing" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

The language part is always an ISO 639-1 two-letter code — en, fr, de, ja. The optional region part is an ISO 3166-1 Alpha-2 code — us, gb, ca. Separate them with a hyphen, not an underscore; the syntax follows the IETF BCP 47 language tag standard, and browsers and search engines will not normalize en_US into a valid tag for you. Region-only codes without a language prefix (hreflang="US") are invalid — region always has to follow a language, never stand alone.

Mistakes that silently break hreflang

Hreflang fails quietly. There's no error message on your page — Google just ignores the annotation and falls back to its own signals. The failure modes that come up constantly:

Missing return tags. If /en/ links to /fr/ via hreflang but /fr/ doesn't link back to /en/, Google treats the whole set as unconfirmed and disregards it.
Hyphen vs. underscore. en_US is not a valid tag and gets dropped rather than corrected.
Pointing to a redirected or noindexed URL. If the target of an hreflang tag 301s somewhere else or carries a noindex, the annotation is ignored.
No x-default. Without it, a searcher whose language doesn't match any of your variants gets an unpredictable fallback decided by other ranking signals instead of your explicit choice.
Copy-pasted tag blocks with the wrong self-reference. This is the single most common bug we see in the wild: someone templates the hreflang block once and pastes it across every page without swapping the self-referencing URL, so every page on the site claims to be the homepage's en-us variant.

Running a periodic crawl that flags hreflang return-tag errors and orphaned references catches most of this before it costs you international traffic — it's the kind of check a general-purpose SEO audit tool will surface alongside your other technical issues rather than something you need a dedicated multilingual crawler for.

How to test and validate hreflang after deployment

Google removed the dedicated International Targeting report from Search Console a while back, so validation now happens through a combination of methods rather than one dashboard:

URL Inspection tool in Search Console shows you which version Google actually indexed for a given URL — useful for confirming Google picked up the variant you expect.
View source or a header check (curl -I for HTTP-header implementations) confirms the tags are actually being served, not just present in your CMS templates.
Search from a VPN or a region-set browser profile to see which variant actually surfaces for a searcher in that location — this is the closest thing to ground truth.
Rank tracking segmented by location tells you whether the right regional page is ranking for the right regional queries at all, which matters more than whether the tags validate technically. If you're tracking this yourself rather than paying for enterprise tooling, a free rank tracking setup that lets you set search location per keyword is enough to catch cases where Google is showing your /en-gb/ page to US searchers despite correct hreflang.

Reprocessing isn't instant. There's no published SLA — pages that already get crawled frequently reflect updated hreflang faster; low-priority pages can take weeks to reprocess even after the tags are technically correct.

Hreflang and AI answer engines

Hreflang barely matters for how ChatGPT, Perplexity, or Google's AI Overviews decide what to cite, because those systems generally aren't segmenting by searcher location and language the way traditional search does — they're pulling from whatever version of a page their crawler or index happens to have. But the underlying problem hreflang exists to manage — near-duplicate content across language variants — is exactly what causes a generative engine to cite the wrong regional page or blend claims from two variants into one answer. If your French and English pages differ only in UI strings while the actual claims, pricing, and specifics are supposed to differ by market, an AI engine has no reliable way to know that and may attribute a fact from one market to the other. At Seolyn we treat each locale as a genuinely distinct source document rather than a translated clone for this exact reason — it's less about the hreflang tag itself and more about giving each language variant enough real, non-duplicate substance that a citation pulled from it is actually correct for that market.

Frequently Asked Questions

Q: Does hreflang help SEO rankings?

No. Hreflang is a targeting signal that determines which URL variant is shown to which searcher — it doesn't influence whether your domain ranks higher overall.

Q: Do I need hreflang if I only have one language but multiple currencies?

No. Hreflang addresses language and regional content differences, not currency; if the content is otherwise identical, a currency switcher on a single URL avoids the duplicate-content problem hreflang can't solve anyway.

Q: Can I use hreflang without separate URLs per language?

No. Hreflang requires each variant to live at its own crawlable URL — it can't be applied to content that changes dynamically on one URL based on browser language settings.

Q: What happens if I forget the x-default tag?

Nothing breaks outright, but searchers whose language doesn't match any of your listed variants get no explicit fallback, so Google decides which version to show them using other signals — which is unpredictable for international traffic.

Q: How long does it take Google to pick up new hreflang tags?

There's no fixed timeline; it depends on normal recrawl frequency. Pages Google already crawls often reflect updated hreflang within days, while low-priority pages can take considerably longer.