Hreflang explained for multi-region sites

if you run a site that exists in more than one language, or more than one country, you will hit this problem sooner or later. someone in Sydney searches for your product and lands on your US page with prices in dollars and shipping rules that do not apply to them. or someone in Singapore gets the Chinese version when they read English. hreflang is the fix for that.

i am based in Singapore, where a single audience reads English, Mandarin, Malay and Tamil, so i have had to think about this more than most. this explainer is for someone who has never touched hreflang. by the end you should know what it is, how the annotations are written, and which mistakes cause most of the damage.

What it is

hreflang is an annotation you add to a page to tell search engines which other versions of that page exist, and which language and region each one is meant for. it is not a redirect and it does not block anything. it is a hint that says “this page has siblings, and here is who each sibling is for.”

the name is short for “href language.” each annotation pairs a URL with a language code, and optionally a region code:

• en: English, for any English speaker
• en-sg: English for people in Singapore
• en-gb: English for people in the United Kingdom
• zh-Hans: Chinese in simplified script
• x-default: the fallback page for anyone who does not match the other versions

the language part uses ISO 639-1 codes, which the Library of Congress maintains a reference list for. the region part uses ISO 3166-1 alpha-2 country codes. the W3C has a clear primer on how these language tags are built if you want the full grammar.

one detail that trips people up: you can give a language alone, but you cannot give a region alone. “sg” by itself is not valid. it has to be language first, then region.

How it works

the mechanism has three parts. you list every version of a page, you put that list on every version, and each version points back at the others.

here is a simple example. say you have one product page in three versions:

• https://example.com/en-us/widget/
• https://example.com/en-sg/widget/
• https://example.com/zh-sg/widget/

in the head of each page you would add this set of tags:

<link rel="alternate" hreflang="en-us" href="https://example.com/en-us/widget/" />
<link rel="alternate" hreflang="en-sg" href="https://example.com/en-sg/widget/" />
<link rel="alternate" hreflang="zh-Hans-SG" href="https://example.com/zh-sg/widget/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en-us/widget/" />

the same four lines go on all three pages. that is the part people miss. the US page lists itself too, and the Singapore pages list the US page. this is called a self-referencing annotation plus reciprocal links, and Google’s own documentation on localized versions of pages says that if page A points to page B, page B must point back to page A or the annotations may be ignored.

there are three places you can put the annotations. you only need to pick one:

• html head: link tags like the ones above. easiest for small sites and the one i use by default.
• http headers: a Link header sent with the response. this is the only option for non-HTML files such as PDFs.
• xml sitemap: each url entry carries xhtml:link children listing its alternates. for large sites this is easier to maintain because you generate it from a database rather than editing templates.

mixing methods is allowed but creates two places to be wrong. i pick one and stick to it.

what does the search engine do with it? when Google has several versions in its index and understands they are alternates, it swaps in the one that fits the searcher’s language and location. the important word is swaps. hreflang does not boost rankings. it changes which of your already-ranking URLs gets shown. if none of your versions rank, hreflang will not make them rank.

Why it matters

here are the cases where i have seen it earn its keep.

• right page for the right currency and shipping. an Australian who lands on a US checkout bounces. hreflang gets them to the AU version before they ever see the wrong price.
• duplicate-looking content across regions. an en-us page and an en-gb page can be nearly identical, with only spelling and prices differing. without hreflang, Google may pick one as the main version and quietly hide the other. with it, both can serve their own audience.
• same language, different intent. Spanish in Mexico and Spanish in Spain use different words, different brands and different payment methods. region targeting lets you serve each properly instead of one watered-down Spanish page.
• cleaner reporting. when the right version is shown, impressions and clicks land on the page you meant them to. if you have ever wondered why your numbers look off across regions, my piece on search console numbers that do not add up covers some of the reasons, and wrong-version serving is one of them.

if you are still deciding whether to even build separate regional versions, i wrote about the trade-offs in running one site for two countries. hreflang is the plumbing, but the bigger decision is whether you need the extra versions at all. a single English site with clear pricing often does the job for a small business.

Common misconceptions

these come up constantly, including from people who have done SEO for years.

“hreflang is a ranking boost.” it is not. it is a switching signal between pages that already exist in the index. i have seen people add it hoping a thin German page would suddenly rank in Germany. it will not. the page still needs to be good enough to rank on its own merits.

“hreflang and canonical tags do the same job.” they do not, and they can fight each other. a canonical tag says “this is the main version of this content.” hreflang says “these are equal alternates for different audiences.” if your en-sg page has a canonical pointing at the en-us page, you are telling Google to ignore the Singapore page, and the hreflang pair gets dropped. each regional page should canonical to itself.

“any country code works, including the ones people use informally.” the classic one is en-uk. the correct code for the United Kingdom is en-gb, because ISO 3166 assigns GB. en-uk is not valid and will be ignored. another common one is using a country where you meant a language, such as “cn” for Chinese. Chinese is zh, and cn is a region. check every code against the lists linked above before you ship.

“i can add it once and forget it.” hreflang is brittle because it depends on many pages agreeing with each other. delete one regional page and every other page that pointed to it now has a broken reference. launch a fourth region and you need to update the other three. i treat the annotations as generated output, not hand-edited, for exactly this reason. if you are moving domains or restructuring URLs, the annotations need rebuilding too, which is a big part of what goes wrong in what happens to rankings after a site migration.

Where to go from here

once you have the basics, these are the follow-ups worth your time:

• running one site for two countries: the planning decision that comes before any tag. subfolders, subdomains and separate domains each have costs.
• what happens to rankings after a site migration: what to expect when URLs change, including how broken hreflang sets show up.
• how to migrate a site without losing rankings: a practical checklist you can follow if your regional rebuild involves moving URLs.
• search console numbers that do not add up: useful for checking whether the right version is being shown once you are live.

if you want to automate some of the grind, for example generating the annotation sets from a spreadsheet of URLs, the sister site AI Tool Gazette covers AI tools that can help with that sort of repetitive work. check their output before you publish. a generated annotation set that is slightly wrong is worse than none, because it looks correct at a glance.

for a first test, pick one page, make two versions, add the annotations to both, and use the International Targeting and URL Inspection reports in Google Search Console to check that Google sees them. get that one pair working before you scale it to the whole site. the full list of articles is on the blog index.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-10-06.