Hreflang Tags: What They Are and How to Use Them

Hreflang is an SEO annotation that connects equivalent webpages written for different languages or regional audiences. It helps search engines determine which URL best matches a user’s language, country, or both.

It makes sense when a website has separate URLs for equivalent content, such as US English, UK English, and Canadian French versions of the same service or product page. A single website that serves visitors from several countries usually doesn’t need hreflang if everyone uses the same page.

Hreflang does not translate content, guarantee rankings, or force Google to show a particular URL. It supports a broader international SEO setup that also includes accessible pages, accurate localization, canonical URLs, internal links, and a structure that makes sense to visitors.

What is an hreflang tag?

An hreflang tag is an HTML <link> element that identifies an alternate version of the current page for a particular language or region.

<link rel="alternate" hreflang="en-US" href="<https://example.com/en-us/>" />
<link rel="alternate" hreflang="en-GB" href="<https://example.com/en-gb/>" />
<link rel="alternate" hreflang="fr-CA" href="<https://example.com/fr-ca/>" />

This example connects three equivalent versions:

• en-US identifies English content for the United States.
• en-GB identifies English content for the United Kingdom.
• fr-CA identifies French content for Canada.

Each annotation has three important parts:

• rel="alternate" identifies another version of the current page.
• hreflang="en-US" identifies the language and region.
• href provides the full URL of that version.

The current page should reference itself and its alternatives. The relationship should also be reciprocal. If the US page points to the UK page, the UK page should point back to the US page and list the same set of equivalent alternatives.

Hreflang annotations can be added to HTML pages, XML sitemaps, or HTTP response headers. HTML is usually easiest for smaller sites. Sitemaps can be easier to manage when a large website has thousands of localized URLs.

When does a website need hreflang?

Hreflang is appropriate when a website has separate, crawlable URLs for equivalent pages that serve different languages or regional audiences. The differences should affect the visitor’s experience, not just the URL folder name.

Multilingual websites

A multilingual website provides equivalent content in more than one language. For example, a business might have English, French, and Spanish versions of the same service page:

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

These pages do not have to be word-for-word translations. They may use different examples, terminology, calls to action, or legal information. They should still serve the same underlying purpose for different language audiences.

Multi-regional websites

A multi-regional website has separate pages for markets that use the same language but operate differently. A retailer might maintain US, UK, Canadian, and Australian versions with different:

• Currencies and prices
• Shipping options
• Product availability
• Measurements and spelling
• Contact details
• Legal or regulatory information

A consultant with one English-language website probably does not need separate en-US, en-GB, and en-AU pages simply because visitors arrive from those countries. Maintaining copied pages would add complexity without giving visitors a meaningfully different experience.

A retailer with country-specific inventory, pricing, tax information, and delivery options has a stronger reason to create regional URLs and connect them with hreflang.

When hreflang is unnecessary

Hreflang is usually unnecessary when:

• The website serves one language and one market.
• Each page has one global version.
• Regional differences are minor or nonexistent.
• There are no equivalent localized URLs.
• The language changes dynamically without separate URLs.
• Pages were duplicated only to target additional countries.

International traffic alone is not a reason to add hreflang. First ask whether the site has separate pages that users and search engines could reasonably confuse with one another.

Hreflang can also be applied selectively. A business might connect country-specific product and service pages while leaving a global blog, company history page, or other content outside the setup. If there are no genuine alternatives to connect, hreflang is not the solution.

Why does hreflang matter?

Hreflang tells search engines which URLs belong to the same localized page group. This matters when several pages are similar enough to be confused with one another but different enough that visitors should not always see the same version.

For example, a visitor in the United Kingdom may find a US product page that uses dollars, quotes US shipping times, or lists products unavailable in the UK. Hreflang helps search engines understand that the UK page is the intended alternative for that audience.

Annotations work best when they match the rest of the site. Page language, regional content, URL structure, internal links, canonical tags, and visible language or region selectors should all support the same relationships.

Hreflang is a signal, not a command. It can help search engines select a more relevant localized URL, but it does not guarantee rankings, traffic, or leads. If the pages are poorly translated, inaccessible, or nearly identical apart from a country folder, adding hreflang will not solve the underlying problem.

Hreflang language and region codes

Hreflang values use a language code followed by an optional region code:

language-region

Use a language-only value when the page serves speakers of a language generally:

• en for English
• fr for French

Add a region when the page is intended for a defined market:

• en-US for English speakers in the United States
• en-GB for English speakers in the United Kingdom
• fr-CA for French speakers in Canada

The language comes first. A region cannot stand alone, so US is not a valid hreflang value. The United Kingdom uses GB, even though UK is common in ordinary writing.

Use a region code only when the page has a genuine regional purpose, such as different pricing, availability, shipping, terminology, or legal information. A country folder by itself does not justify a separate regional version.

The URL structure does not have to match the hreflang value exactly. A site can use /uk/ while correctly identifying the audience with en-GB. The hreflang value describes the intended audience; the URL identifies the page.

How to use hreflang tags

Start implementation with a page map. The annotations should describe real page relationships, not be added separately by guesswork.

1. Map equivalent pages

List the URLs that represent the same page, service, or product in each language or market.

For example:

• US English: /en-us/physical-therapy/
• UK English: /en-gb/physical-therapy/
• Canadian French: /fr-ca/physical-therapy/

The pages should serve the same underlying purpose. A US service page can connect to the equivalent UK and Canadian service pages, but not to a regional homepage or unrelated article. Pages without genuine alternatives can be left out of the group.

2. Assign the audience codes

Choose the language or language-region value that matches each page’s content and intended audience. In this example, the values are en-US, en-GB, and fr-CA.

Use a language-only value such as en when the page serves English speakers generally rather than one defined country.

3. Check the URLs

Before adding annotations, confirm that every alternate URL:

• Loads the intended page
• Uses the final HTTPS address
• Returns a successful response
• Can be crawled and indexed
• Does not redirect to another market
• Is the URL that should appear in search

Hreflang cannot repair a blocked, redirected, or unavailable page. Resolve those problems first.

4. Add the complete relationship

Each page should reference itself and every equivalent alternative:

<link rel="alternate" hreflang="en-US" href="<https://example.com/en-us/physical-therapy>" />
<link rel="alternate" hreflang="en-GB" href="<https://example.com/en-gb/physical-therapy>" />
<link rel="alternate" hreflang="fr-CA" href="<https://example.com/fr-ca/physical-therapy>" />

The same set of references should appear on the US, UK, and Canadian pages. If you add a new market, update the full group rather than adding the new URL to only a few pages.

For HTML pages, place the annotations inside the document’s <head>. On WordPress, a multilingual plugin, SEO plugin, theme, or custom function may generate them. Whichever method you use, the relationships should come from one reliable page map so they remain consistent when URLs or translations change.

Where can you add hreflang annotations?

Hreflang can be published in HTML, XML sitemaps, or HTTP response headers. The right method depends on the site size and the type of files being connected.

For most smaller WordPress sites, HTML <link> elements are the simplest option:

<link rel="alternate" hreflang="en-US" href="<https://example.com/en-us/service/>" />
<link rel="alternate" hreflang="en-GB" href="<https://example.com/en-gb/service/>" />
<link rel="alternate" hreflang="fr-CA" href="<https://example.com/fr-ca/service/>" />

A multilingual plugin, SEO plugin, theme, or custom function may generate these tags. The important question is whether the output comes from a reliable page map and stays consistent across the localized pages.

XML sitemaps can be easier to manage for large sites with thousands of localized URLs because you can generate relationships centrally. HTTP response headers are mainly relevant to non-HTML files, such as localized PDFs.

Choose one primary implementation method unless there is a clear reason to use more than one. If you use multiple methods, the relationships should match. Review the setup after URL changes, migrations, new translations, or updates to multilingual plugins and templates.

What is x-default?

x-default identifies the fallback URL for visitors who do not match one of the listed language or regional versions.

A site might send those visitors to a country selector:

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

The fallback could also be a global homepage or an intentional default version of the content. It should be a real, accessible page that gives visitors an appropriate next step.

x-default is optional. Use it when the page group has a deliberate fallback, such as a selector that lets visitors choose their language or region. Avoid sending users to a URL that immediately redirects based on a cookie or IP address, since that can make the page difficult to access consistently.

What hreflang does not replace

Hreflang is one part of an international SEO setup. It should agree with the page’s canonical URL, visible content, HTML lang attribute, and language or region navigation.

A canonical tag identifies the preferred URL for the current page. Hreflang connects equivalent pages intended for different audiences. When regional pages differ meaningfully, each page will often use its own canonical URL while also listing the alternate versions.

For example, the US page might use:

<link rel="canonical" href="<https://example.com/en-us/physical-therapy/>" />
<link rel="alternate" hreflang="en-US" href="<https://example.com/en-us/physical-therapy/>" />
<link rel="alternate" hreflang="en-GB" href="<https://example.com/en-gb/physical-therapy/>" />
<link rel="alternate" hreflang="fr-CA" href="<https://example.com/fr-ca/physical-therapy/>" />

Do not automatically point every regional page’s canonical tag to one global or US URL. If the pages have different audiences, prices, service areas, or legal information, each page may need to remain the canonical version for its own audience.

The HTML lang attribute describes the language of the page currently being viewed:

<html lang="en-US">

Hreflang describes the relationship between that page and its alternatives. A page can use both signals, but neither one translates the page.

Localization may require changes to terminology, spelling, currency, availability, contact information, legal details, and calls to action. A translated page with incorrect pricing or service information is still a poor regional page, even when its hreflang code is correct.

Visitors should also be able to switch languages or regions themselves. Automatic detection can help, but each localized URL should remain accessible and offer a visible way to choose another version.

Common hreflang mistakes

Most hreflang problems come from incomplete page groups, incorrect URLs, or pages that do not actually serve different audiences.

Incomplete or one-way references

Every page in a hreflang group should reference itself and the other equivalent pages. If the US and UK pages reference a new Canadian page but the Canadian page references only itself, the relationship is incomplete.

Compare the full annotation set across every URL in the group. Order doesn’t matter, but the same relationships should be present.

Invalid language or region codes

The language comes first, followed by an optional region. Examples include en-US, en-GB, and fr-CA.

A region cannot stand alone. US, EU, and english are not suitable hreflang values. The United Kingdom uses GB, even though UK is common in ordinary writing.

Pairing unrelated pages

Hreflang connects equivalent pages, not pages that merely target the same market.

A US product page should point to the corresponding UK and Canadian product pages. It should not point to a regional homepage, category page, or unrelated article. If no genuine equivalent exists, leave the page out of the group.

Using outdated or inaccessible URLs

Annotations should point directly to the final URL that loads for visitors and search engines. Avoid old URLs, HTTP versions that redirect to HTTPS, tracking URLs, and pages that redirect to another market.

Also check that the alternate page is not blocked, marked noindex, behind a login, or returning an error. Hreflang cannot make an inaccessible page eligible for search.

Review the implementation after migrations, URL changes, new translations, or updates to multilingual plugins and templates.

Frequently Asked Questions

These questions cover the most common decisions after identifying localized page groups.

Summary

Hreflang is appropriate when a website has equivalent pages for different languages or regional audiences. It helps search engines interpret those relationships, but it does not translate content, guarantee rankings, or replace sound site structure.

Start with one group of equivalent URLs rather than applying hreflang across the entire site at once. Verify the codes, final URLs, reciprocal references, canonical tags, and visible language or regional differences before expanding the setup.

Work with TCB Studio

If your website serves multiple countries or languages, I can help you determine whether hreflang is needed, map equivalent pages, and identify whether the issue is in the content, URLs, plugin output, sitemap, or page templates. That work can be part of an international SEO project or focused consulting around a particular issue.

I also offer hourly and monthly consulting for businesses that need help beyond one hreflang review. Bring the markets you serve, the URLs you’re comparing, and any known indexing or redirect problems, and we can define the right level of support.