Hreflang explained for multilingual and multi-region sites

The short answer

Hreflang is an annotation that tells search engines which language and, optionally, which country a page version is meant for, and where the other versions live. Each version lists itself and all its alternatives, and every link must be returned from the other side. Google treats it as a hint, not a command.

What hreflang does

Imagine a business with one page for customers in the UK, another for the USA and another for Australia. The wording is almost the same, only prices, spellings and delivery details differ. Without guidance, a search engine may treat them as near-duplicates and show the wrong one to the wrong person.

Hreflang is a label you add that says: this page is for English speakers in the UK, this one is for English speakers in the USA, and here is where to find each. Search engines use that information to show the version that suits the searcher's language and, where relevant, location.

It does not boost rankings by itself, and it does not translate anything. It only helps the correct existing version appear. Google describes it as a signal it may use, so treat it as a hint, and read the current documentation on localised versions of pages for the finer points.

When you need it, and when you do not

You need hreflang when the same or very similar content exists in more than one language, or in the same language aimed at different regions. Examples written for illustration: a French and an English version of a service page, or separate English pages for Singapore and the UAE that differ in currency and contact details.

You probably do not need it if your whole site is in one language and serves everyone the same way. You also do not need it for a page that has been machine-translated by a browser plug-in, because that translation never lives on a separate address of yours.

If you are still deciding on structure, our guide to planning a multilingual website covers the earlier choices, such as how many languages to launch and who writes the translations.

How the code is written

An hreflang value has two parts. The first is a language code, such as en, fr or ja. The second, optional part is a region code, such as GB, US or AE. They are joined by a hyphen, so en-gb means English for Great Britain and ja means Japanese for anyone.

Two details cause trouble. You cannot give a region without a language, so "GB" alone is wrong. And the region code is for a country, not a currency or a city. Check the official lists of language and country codes before you write them out by hand.

There is also a special value, x-default, for visitors who match none of your listed versions. It is often used for a language-selector page or for your main international version.

Three ways to add hreflang

Pick one method and stick with it. Mixing methods raises the odds of two sets of instructions disagreeing. For most small business sites, the HTML link tags in the head are the simplest to understand and check.

Always use full web addresses, including the https part, rather than short relative paths.

The rule that trips most people: return links

Hreflang works in both directions. If your UK page points to your US page, the US page must point back to the UK page. If the return link is missing, search engines may ignore the annotation.

Each page should also list itself. So with three versions, every one of the three pages carries three entries: itself and the other two. Add x-default as a fourth line if you use it.

When you add a new language later, you must edit every existing version to include it. This is why hreflang often goes stale: someone launches a new region and forgets to update the older pages. A sitemap-based set-up can be easier to keep consistent for this reason.

A worked example

This is an illustration, not a real site. Suppose a company has three versions of its pricing-request page: one for the UK, one for the USA and a Japanese one.

• The UK page lists en-gb pointing to itself, en-us pointing to the US page and ja pointing to the Japanese page.
• The US page lists the same three entries, with its own address in the en-us line.
• The Japanese page lists the same three entries again.
• All three pages may also carry an x-default line pointing to a page where the visitor can pick a country.

Every page carries the same complete list. That uniformity is the point. If you can copy one block of annotations into all versions and only the page's own content changes, you have probably set it up correctly, and the block is easy to maintain when a fourth version arrives.

Keep a simple table in a spreadsheet with one row per version: language, region, address and the date you last checked it. Add a column for who owns the translation, so that when a page is updated in one language the others are reviewed as well. A set of pages that tell different stories in different languages is a trust problem, whatever the tags say.

Common mistakes to check

• Missing return links, as above.
• Wrong codes, for example "en-uk" instead of "en-gb".
• Pointing to redirected or broken addresses. Every address in the set should return a normal page. See HTTP status codes explained for what to look for.
• Pointing to a noindex page. If a version is blocked from search, it should not be in the set.
• Canonical tags that disagree. Each version should usually be canonical to itself, not to another language version.
• Using it as a redirect. Do not force visitors to a version based on location alone; let people choose and let search engines see every version.

Where an old language folder has moved, redirect chains can quietly break the set, so test the final addresses.

How to check your set-up

1. List every language and region version with its exact address.
2. For each page, confirm it names itself and every alternative.
3. Pick two versions at random and confirm each points to the other.
4. Look at Search Console for any international-targeting or indexing messages, and check the current documentation for which reports are available.
5. Use a crawler that reports hreflang errors across the whole site.

Remember that the page language attribute in the HTML is a separate matter. It helps browsers and screen readers, and it is good practice to set it correctly on every version, but it does not replace hreflang.

Finally, think about mobile: search engines index the mobile version of a page, so the annotations must be present there too. Our note on mobile-first indexing explains why.

Related guides

• SEO services
• URL Structure Best Practices for SEO
• Redirect Chains and Loops: How to Find and Fix Them
• International seo basics for a growing business
• Url structure for seo
• Website redesign seo checklist

Questions and answers

Does hreflang improve my rankings?

Not directly. It helps the right version appear for the right searcher, which can reduce the wrong page showing up, but it is not a ranking boost.

Do I need hreflang for the same language in different countries?

If the pages are near-identical, you may not, but if currency, spelling or contact details differ, hreflang helps. Check the current documentation for guidance.

What is x-default?

A fallback value for visitors who do not match any listed version, often pointing to a language-selector page or a general version.

Can I use hreflang with a country-code domain?

Yes. Hreflang works across separate domains, subfolders and subdomains, as long as the pages reference each other with full addresses.

Do all search engines read hreflang?

Google documents it. Other search engines may use different signals, so check their current documentation if they matter to your market.