Hreflang Explained: How to Target Languages and Countries

Hreflang is an annotation that tells Google which language or regional version of a page to show to which searchers. If you have an English page for the US, another for the UK and a Spanish page for Mexico, hreflang links them so a searcher in London gets the UK version instead of the US one. Each version must list itself and every other version, the codes must be valid (a language such as en, optionally with a region such as en-GB), and you should add an x-default version for everyone else. Google says the three ways to add it, in HTML, in HTTP headers or in a sitemap, are equivalent.

This guide explains when you need hreflang, how to write it correctly, the mistakes that make Google ignore it, and how to check it.

Do you need hreflang?

Hreflang solves a specific problem: several URLs that are versions of the same content for different audiences. Without it, Google may show the wrong version, or treat same-language regional pages as duplicates and pick one to show everywhere.

If your site is in English for a US and global audience, like CodeNexon, you do not need hreflang. A single version with a canonical tag is the right setup. Canonical Tags Explained covers that.

How hreflang works

Each version of a page declares every version that exists, including itself, with the language and optional region it is meant for. Google uses these annotations to choose which URL to show in results for a searcher's language and location.

Three important points:

1. It is a signal, not a redirect. Hreflang does not send visitors anywhere. It influences which URL appears in search results.
2. It does not replace canonical tags. Each version should still have a self-referencing canonical.
3. It must be reciprocal. Google's documentation says: "If two pages don't both point to each other, the tags will be ignored."

Language and region codes

Google requires a language code in ISO 639-1 format, with an optional region code in ISO 3166-1 Alpha 2 format.

The en-UK mistake is especially common, because people expect the country code to match the common abbreviation. Google notes that if you use a code reserved for something else, it ignores that part of the annotation.

x-default: the fallback

x-default names the page to show when no other version matches the searcher's language or location. Google describes it as "used when no other language/region matches the user's browser setting."

Typical choices for x-default:

• A language selection page.
• Your main international version, often English.
• A page that detects location and lets the visitor choose.

Three ways to add hreflang

Google says "the three methods are equivalent from Google's perspective". Choose one per site and use it consistently.

1. HTML link elements

Add <link> elements in the <head> of every version. Each page lists all versions, including itself.

On https://example.com/en-us/pricing, and identically on the other two versions:

<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="es-mx" href="https://example.com/es-mx/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

This is the most common method and the easiest to inspect. It adds lines to every page, which becomes heavy if you have many languages.

2. HTTP headers

For files without an HTML head, such as PDFs, send the annotations in a Link header:

Link: <https://example.com/en-us/guide.pdf>; rel="alternate"; hreflang="en-us",
      <https://example.com/en-gb/guide.pdf>; rel="alternate"; hreflang="en-gb"

3. XML sitemap

List each URL with its alternates. Every URL entry includes the full set:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en-us/pricing</loc>
    <xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/en-us/pricing"/>
    <xhtml:link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/pricing"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
  </url>
  <url>
    <loc>https://example.com/en-gb/pricing</loc>
    <xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/en-us/pricing"/>
    <xhtml:link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/pricing"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
  </url>
</urlset>

The sitemap method keeps your pages light and puts everything in one place, which suits sites with many languages. It is harder to spot errors by eye. XML Sitemaps and Robots.txt Explained covers sitemaps generally.

How to structure international URLs

Hreflang works with any URL structure, but the structure affects how clearly you signal the audience and how much work it is.

For most small and medium businesses, subdirectories on one domain are the practical choice. They are cheaper to run, and every version benefits from links to the main domain. Country-code domains make sense when you are building strong separate businesses in each country. How to Choose a Domain Name covers country-code extensions and their prices.

Common hreflang mistakes

The canonical mistake deserves emphasis. If the UK page's canonical points to the US page, you are telling Google the UK page is a duplicate to be dropped. Hreflang then has nothing to point at. Each language or regional version must canonicalize to itself.

Do not force visitors by location

Automatically redirecting visitors based on their IP address seems helpful but causes problems. Travelers get the wrong version, people using a VPN cannot reach the version they want, and search engine crawlers may only ever see one version. Show a small banner suggesting the visitor's local version, and let them choose. Remember the choice in a cookie.

Same language, different countries

A US and UK English site might differ only in spelling, prices and currency. That is a valid use of hreflang, and it matters for two reasons:

1. Without it, Google may see the pages as near-duplicates and show only one in both countries.
2. With it, UK searchers see prices in pounds and UK spelling, and US searchers see dollars.

Make the versions genuinely useful for their audience: local currency, local contact details, local shipping terms and local spelling. Two pages that differ only by the word "color" versus "colour" add little.

Translation quality matters

Google's broader guidance on helpful content applies to every language version. Machine translation without review often produces awkward text that reads poorly and earns little trust. Have translations reviewed by a fluent speaker, at least for your most important pages, and localize examples, prices and references rather than translating them word for word. E-E-A-T Explained covers why trust and quality matter here.

Adding hreflang in WordPress and other platforms

• WordPress: multilingual plugins such as WPML, Polylang and TranslatePress create the language versions and add hreflang automatically. Check the output, especially the x-default setting and the codes used. A multisite network with one site per language is another approach. WordPress Multisite Explained covers when that makes sense.
• Shopify and other store platforms: built-in markets and language features usually add hreflang for you.
• Frameworks such as Next.js: set alternates in each page's metadata, building the list from the same data that generates the pages, so every version always lists the full set.

How to check your hreflang

1. View the source of each version and confirm every version is listed, including itself, with valid codes and absolute URLs.
2. Check reciprocity across versions. If A lists B, B must list A.
3. Crawl the site with a crawler tool that reports hreflang errors: missing return links, invalid codes and links to redirects or errors.
4. Use Google Search Console. Inspect a URL to see its canonical, and check the Performance report filtered by country to see whether each version receives traffic from its intended country. How to Set Up Google Search Console explains the reports.

Expect changes to take a few weeks to show, since Google has to recrawl every version.

A worked example: one product in three markets

Suppose a small company sells a desk organizer to customers in the US, the UK and Mexico. It has three versions of the product page:

It also has a general page at example.com/desk-organizer with a short note and links to each country version, which serves as the x-default.

Each of the four pages carries the same five lines: a self-referencing canonical, then the full hreflang set.

<link rel="canonical" href="https://example.com/en-gb/desk-organizer" />
<link rel="alternate" hreflang="en-us" href="https://example.com/en-us/desk-organizer" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/desk-organizer" />
<link rel="alternate" hreflang="es-mx" href="https://example.com/es-mx/desk-organizer" />
<link rel="alternate" hreflang="x-default" href="https://example.com/desk-organizer" />

That example is the UK page. Only the canonical line changes from page to page. The four hreflang lines stay identical on every version, which is what makes the set reciprocal.

Searchers in London should then see the UK page with pound prices, searchers in Chicago the US page, and Spanish-speaking searchers in Mexico the Mexican page. Someone in Germany, which none of the versions target, should be shown the x-default page and can choose.

Frequently asked questions

What is hreflang?

Hreflang is an annotation that tells search engines which language or regional version of a page is intended for which audience. It links equivalent pages, such as an English page for the US and one for the UK, so Google can show each searcher the most appropriate version.

Does an English-only website need hreflang?

Usually not. If you have a single English version for a global audience, you do not need hreflang. It is needed when you have separate URLs for different languages, or separate same-language versions for different countries with different prices, currency or spelling.

What is x-default in hreflang?

x-default names the page to show when no other language or region version matches the searcher's browser settings. Google describes it as a fallback. It often points to a language selection page or your main international version.

Why is Google ignoring my hreflang tags?

The most common reason is missing return links. Google says if two pages do not both point to each other, the tags are ignored. Other causes are invalid language or region codes, links to redirected or missing pages, and canonical tags pointing to a different version.

Is it en-UK or en-GB?

en-GB. Hreflang uses ISO 3166-1 Alpha 2 region codes, and the code for the United Kingdom is GB. Using en-UK is a common mistake, and Google ignores region codes that are invalid or reserved for something else.

Should I use HTML tags or a sitemap for hreflang?

Either works. Google says HTML link elements, HTTP headers and sitemaps are equivalent. HTML tags are easiest to inspect on small sites. Sitemaps keep pages lighter and suit sites with many languages. Choose one method and use it consistently.

Should I redirect visitors to their local version automatically?

It is better not to force it. Automatic redirects based on IP address can send travelers and VPN users to the wrong version and may stop search engines seeing all versions. Suggest the local version with a banner and let visitors choose.

Sources

• Google Search Central: Tell Google about localized versions of your page
• Google Search Central: Managing multi-regional and multilingual sites
• ISO 639 language codes
• ISO 3166 country codes