Hreflang Tags for International SEO

If your website has pages for different countries or languages, search engines need to understand which version belongs to which audience.

Hreflang tags help with that. They connect equivalent international pages and show search engines which language or region each version is intended for.

This guide explains what hreflang tags are, when to use them, how to add them and how to check they are working properly.

 

 

What are hreflang tags?

Hreflang tags tell search engines which language or regional version of a page to show to users. They are used when you have multiple versions of the same, or very similar, content for different audiences. For example, you might have one version of a page for UK users and another for US users. The content may be mostly the same, but the spelling, currency, delivery information or product availability could be different.

A hreflang tag looks like this:

<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/page/" />

Here’s what each part means:

• rel="alternate" tells search engines this URL is an alternate version of the current page.
• hreflang="en-gb" tells search engines the page is for English-speaking users in the UK.
• href="https://example.com/uk/page/" tells search engines where that alternate page is located.

Without hreflang, Google may show the wrong version in search results, such as a US page appearing for UK users.

Hreflang is a signal, not a directive. It does not guarantee that Google will show a specific URL, and it will not improve rankings on its own. Its job is to help search engines choose the most relevant version when several equivalent pages exist.

Hreflang is different from the HTML lang attribute. The lang attribute tells browsers and screen readers what language the page content is written in, which helps with accessibility and rendering. Hreflang tells search engines which language or regional version of a URL should be shown in search results. For most multilingual websites , you need both: lang for the page itself, and hreflang for search engines.

 

When to use hreflang tags

Use hreflang tags when you have equivalent versions of the same page for different languages or regions. For example, a common use case is when you have translated versions of a page, such as an English category page with French, German and Spanish versions.

You can (and should) also use hreflang tags when you have regional versions in the same language. A UK page and a US page may be very similar, but they might use different spelling, pricing, delivery details, returns information or product availability.

For ecommerce sites, this is especially important. If one page shows prices in pounds and another shows prices in dollars, search engines need a clear signal about which version belongs to which market.

Hreflang can also work across different site structures. Your alternate pages might sit in subfolders, subdomains or separate domains, such as:

• example.com/uk/
• example.com/us/
• fr.example.com/
• example.de/

The setup just needs to be consistent, reciprocal and based on pages that are genuine alternatives.

 

When not to use hreflang tags

You usually do not need hreflang if your site only targets one language or one country. If there are no alternate versions, there is nothing for hreflang to connect.

You also do not need it for city-level targeting where the language and country are the same. There are no hreflang codes for cities, so pages for Manchester, Birmingham and Leeds should not use hreflang unless they also have different language or regional variants.

Do not use hreflang to connect unrelated content. A UK product page should not point to a French blog post just because the topic is similar.

You should also avoid hreflang on pages that search engines cannot properly use. That includes pages that are:

• Non-canonical
• Noindexed
• Blocked by robots.txt
• Redirected
• Broken
• Unavailable
• Returning a non-200 status code

 

Hreflang syntax, codes and x-default

A hreflang tag needs the right URL and the right language or region code. Here is a simple example:

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

In this example, en-gb is for English-speaking users in the UK, en-us is for English-speaking users in the US, and x-default is the fallback page.

Hreflang codes follow a set format. The language code comes first, with the region code coming second.

Language codes use ISO 639-1. These are two-letter codes such as:

• en = English
• fr = French
• de = German
• es = Spanish

Region codes use ISO 3166-1 Alpha 2. These are two-letter country or region codes, such as:

• gb = United Kingdom
• us = United States
• mx = Mexico
• br = Brazil

The region code is optional. If you want to target all Spanish-speaking users, you can use:

<link rel="alternate" hreflang="es" href="https://example.com/es/" />

If you need to target Spanish speakers in a specific country, you can add the region:

<link rel="alternate" hreflang="es-mx" href="https://example.com/mx/" />

Country-only codes do not work. For example, gb on its own does not mean “English for the UK”. Search engines read the first code as the language, so the language must always come first.

You can also use broad language tags alongside regional tags. This is useful when you have a general language version as well as market-specific versions. For example:

<link rel="alternate" hreflang="es" href="https://example.com/es/" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es-es/" />
<link rel="alternate" hreflang="es-mx" href="https://example.com/es-mx/" />

This tells search engines there is a general Spanish page, a Spanish page for Spain, and a Spanish page for Mexico.

Script codes can also be used where writing systems matter. These use ISO 15924. Most sites will not need them, but they can be useful for languages that can be written in more than one script.

The x-default value does not target a language or region. It points to the fallback page when no other version is the right match. Use x-default for fallback pages, global homepages or language selector pages. For example:

<link rel="alternate" hreflang="x-default" href="https://example.com/" />

This helps search engines understand which page to show when a user does not clearly match one of your specified language or regional versions.

 

How to add hreflang tags to your website

There are three places you can add hreflang tags: the HTML <head>, your XML sitemap or the HTTP header. The right option depends on your site size, setup and content type.

For most standard web pages, hreflang tags are added to the <head> section of the HTML. For larger international sites, they are often managed through XML sitemaps. For non-HTML files, such as PDFs, they need to be added through HTTP headers.

HTML tags

HTML tags are usually the simplest option for smaller sites. With this method, you add hreflang tags directly into the <head> section of each page. This works well when you only have a manageable number of alternate pages. For example:

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

The downside is maintenance. As soon as you add or remove a language version, you need to update the tags across every page in that hreflang set. On large sites, this becomes slow, messy and easy to get wrong.

XML sitemaps

XML sitemaps are usually better for larger international sites. With this method, hreflang relationships are managed in the sitemap rather than in the page HTML. This keeps everything in one place, which makes updates easier across large sets of URLs, subfolders, subdomains or international domains.

This is often the cleaner option when you have lots of language or regional variants. It also reduces the risk of bloated page templates and inconsistent tags across markets.

However, if you use XML sitemaps, they need to stay accurate. Any new page, removed URL, changed canonical or added market version should be reflected in the sitemap.

HTTP headers

HTTP headers are mainly used for non-HTML files, such as PDFs. These files do not have a normal HTML <head> section, so hreflang needs to be sent through the HTTP header instead. This helps search engines understand which version of a non-HTML asset should be shown to users in different languages or regions.

In most cases, stick to one implementation method per page. Mixing HTML tags, XML sitemap annotations and HTTP headers for the same URLs can make errors harder to spot and harder to fix.

 

Hreflang best practices and common mistakes

Hreflang works best when every signal points in the same direction. The aim is simple: help search engines understand that a set of pages are equivalent alternatives for different languages or regions.

Most hreflang problems come from inconsistent setup. One missing return tag, one invalid code or one non-indexable URL can weaken the whole cluster.

Keep hreflang and canonicals aligned

Hreflang and canonical tags do different jobs. Hreflang tells search engines which language or regional version of a page to show. Canonical tags, on the other hand, tell search engines which URL should be treated as the main version for indexing.

Do not canonicalise all international pages to one market and then expect hreflang to work. For example, a UK page should usually canonicalise to the UK page, while a US page should canonicalise to the US page. Both pages can still reference each other with hreflang.

If canonicals and hreflang tags contradict each other, search engines may ignore the hreflang setup.

Make every hreflang relationship reciprocal

Hreflang links should work both ways. If your UK page references your US page, your US page should also reference your UK page. This confirms that both pages are part of the same international set.

Missing return links are one of the most common hreflang issues. They make it harder for search engines to trust the relationship between pages.

Include a self-referencing hreflang tag

Each page should include a hreflang tag that points to itself. For example, your UK page should reference the US page, any other alternate versions and the UK page itself.

This gives search engines a complete view of the hreflang cluster and reduces ambiguity.

Reference every equivalent alternate version

Each page in the cluster should reference every equivalent version. If you have UK, US, German and French versions of a page, each version should reference all four. Do not only link to the default version or the nearest regional match.

Partial hreflang setups create gaps. Search engines may still process some signals, but you are making the setup harder to interpret than it needs to be.

Use valid codes and absolute URLs

Use ISO 639-1 language codes and ISO 3166-1 Alpha 2 region codes. The language comes first, then the optional region. For example, use en-gb, not en-uk or gb-en.

Use full absolute URLs, including the protocol:

<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/page/" />

Avoid relative URLs such as:

<link rel="alternate" hreflang="en-gb" href="/uk/page/" />

Absolute URLs are clearer for crawlers and reduce the risk of errors on large or complex sites.

Use x-default when you have a genuine fallback page. This might be a global homepage, an international landing page or a language selector page. It tells search engines which URL to use when no specific language or region is the right match.

Do not add x-default without thinking. It should point to the page that makes most sense for users who fall outside your targeted markets.

Keep alternate pages equivalent

Hreflang should connect equivalent pages, not loosely related content. A UK product page should connect to the same product page in France, Germany or the US. It should not connect to a blog article, a category page or a different product.

You also need to keep pages aligned over time. If one market updates product copy, metadata, availability or key content, check whether the other versions need updating too. If the pages drift too far apart, search engines may stop treating them as true alternatives.

Avoid duplicate or conflicting language assignments

Each language or regional version in a hreflang cluster should have one clear URL. Avoid assigning one URL to multiple languages. For example, do not mark the same URL as both fr and de.

Also avoid assigning multiple URLs to the same language in the same cluster. If two different URLs are both marked as de, search engines may not know which German page to show.

Keep hreflang consistent with other language signals

Hreflang is not the only language signal search engines and browsers can use. Where possible, keep hreflang consistent with the HTML lang attribute, page copy, metadata and internal links. If hreflang says a page is German but the HTML lang attribute says English, you are creating unnecessary confusion.

Do not mix implementation methods inconsistently

You can implement hreflang through HTML tags, XML sitemaps or HTTP headers. In most cases, use one method per page and keep it consistent. Mixing methods can work, but it often creates maintenance problems. If the HTML says one thing and the sitemap says another, troubleshooting becomes slower and more expensive.

A clean hreflang setup gives search engines one clear message: these pages are equivalent, each one serves a specific audience, and every technical signal supports that relationship.

 

How to audit hreflang tags

Hreflang should not be treated as a one-off task. International pages change often, and small errors can stop search engines from trusting the setup. Start with a manual check on a sample of key pages:

• Check the page references itself
• Check it includes the right alternate versions
• Check the language and region codes are valid
• Check the URLs are absolute
• Check the URLs return a 200 status code
• Check the pages are indexable and canonical

Then crawl the site with SEO tools. This is the quickest way to find issues at scale, including missing return links, invalid codes, broken URLs, non-indexable pages and hreflang pointing to redirected or non-canonical URLs.

You can also use dedicated hreflang validators to test specific pages or templates before rolling changes out across the site.

Where relevant, use Google Search Console to inspect important international URLs. Check whether Google can crawl and index the page, and whether the selected canonical matches what you expect.

Finally, review international traffic and rankings by country. If your UK folder is getting significant visibility in the US, or your German pages are ranking outside German-speaking markets, that may point to hreflang, canonical or localisation issues.

Tools such as Screaming Frog, Sitebulb, Ahrefs Site Audit, SE Ranking Website Audit and dedicated hreflang validators can all help identify issues faster.

Hreflang is not difficult because the tag is complicated. It becomes difficult because international websites change, with pages being added, removed, redirected, canonicalised, localised and relaunched. If your hreflang setup does not keep up, search engines can lose confidence in the signals.

Keep it simple: use hreflang for equivalent international pages, point only to clean indexable URLs and check the setup regularly.