Hreflang Made Simple: International SEO Without the Errors

Is your English page showing up for searchers in Germany? Do shoppers in India see your UK prices? If so, Google is probably not sure which version of your page is meant for which audience. Hreflang fixes that. In this hreflang guide, I explain what the tag does, when you need it, the three ways Google lets you add it, and the errors that make Google quietly ignore it.

Here is the short version. Hreflang is a set of links that says “this page also exists in these languages or for these regions, at these URLs.” Every version lists every other version and itself. And every link must be confirmed by a link back.

What Hreflang Does and What It Does Not Do

Hreflang is a rel="alternate" link with an hreflang attribute. It tells Google that a group of URLs are local versions of the same page. Search can then show each person the version that matches their language or region.

It does not push a page higher in rankings. It works more like a swap. When one page in the group is relevant to a search, Google can show the version that suits the searcher better. A French searcher sees the French URL, not the English one.

It also does not translate anything, redirect anyone or set the language of a page. Google works out a page’s language from its visible content, not from the lang attribute or the URL. If your “Hindi” page is mostly English, the label will not change that.

I say this early because, in my experience, many people expect hreflang to bring more traffic. It won’t. It sends the traffic you already earn to the right page.

When You Need Hreflang (and When You Don’t)

Google’s help page on telling Google about local versions of your page lists three cases where it helps:

• Only the template is translated. The main content is in one language, but the menu and footer are translated. You see this on many forums and sites with user-written content.
• Same language, different regions. Small changes, such as English for the US, UK and Ireland. These pages often differ in currency, spelling, shipping or contact details.
• Fully translated sites. Every page exists in several languages, such as English, German and Spanish.

You do not need hreflang for a site in one language aimed at one market. You also gain little if your “regional” pages are exact copies with nothing local about them. In that case, I’d make each page truly useful for its market, or merge the pages.

One more point that clears up a lot of confusion. Translated pages are not duplicate content. Google only treats language versions as duplicates when the main content is in the same language. A properly translated page is its own page.

Language and Region Codes: Getting Them Right

The hreflang value is a language code. You can add a hyphen and a region code after it.

• Language: required, in ISO 639-1 format, which is two letters. Examples: en (English), hi (Hindi), de (German), ta (Tamil).
• Region: optional, in ISO 3166-1 Alpha 2 format, also two letters. Examples: IN (India), GB (United Kingdom), US, AU.

So de means German speakers anywhere. de-AT means German speakers in Austria. en-IN means English speakers in India. The values are not case sensitive, but people usually write the region in capitals.

Three rules catch people out. These are the first things I check when I look at someone’s hreflang:

1. The language always comes first. You cannot use a region on its own. Google’s own example is be. That is the language code for Belarusian, not the country code for Belgium. For Dutch speakers in Belgium, you would write nl-BE.
2. The United Kingdom is GB, not UK. UK is a reserved code, so en-uk is ignored. The same goes for other reserved codes such as EU and UN.
3. Use a hyphen. Write en-GB, not en_GB, even if your CMS stores locales with underscores.

For Chinese, the script (the writing system) is normally implied by the region. So zh-TW points to Traditional Chinese. You can also state the script with an ISO 15924 code, such as zh-Hans for Simplified or zh-Hant for Traditional.

The Three Ways to Implement Hreflang

Google treats all three methods the same. Pick the one that fits how your site is built and use only that one. Running two or three at once doubles the upkeep and gives them room to disagree. I always tell teams to choose one method and write it down, so nobody adds a second one later.

Whichever method you choose, the same rules apply:

• Each version lists every version, including itself.
• Every URL is complete, with the protocol: https://example.com/in/, not /in/ or //example.com/in/.
• The versions can sit on different domains, subdomains or subfolders.

Method 1: HTML Link Elements in the Head

This is the most common method and the easiest to check. Add one <link> element per version inside the <head> of every version. The block is the same on each page.

<head>
  <title>Running shoes</title>
  <link rel="alternate" hreflang="en-gb" href="https://example.com/uk/running-shoes/" />
  <link rel="alternate" hreflang="en-us" href="https://example.com/us/running-shoes/" />
  <link rel="alternate" hreflang="de" href="https://example.com/de/laufschuhe/" />
  <link rel="alternate" hreflang="x-default" href="https://example.com/running-shoes/" />
</head>

Make sure the tags really sit inside the head. An unclosed element, or a script that adds body content early, can make the browser end the head before your tags. Then they are not read as hreflang. Also keep hreflang off tags that carry other attributes such as media.

The downside is weight. Twenty language versions means twenty link elements on every page. And every page template has to produce them correctly.

Method 2: HTTP Link Headers

Headers are how you tag files that have no HTML head, such as PDFs. The server sends a Link header that lists every version, with each URL inside angle brackets.

HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <https://example.com/en/size-guide.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/de/groessentabelle.pdf>; rel="alternate"; hreflang="de",
      <https://example.com/hi/size-guide.pdf>; rel="alternate"; hreflang="hi"

As with HTML, the header is the same on every version and includes the file being requested. This method needs server or CDN setup, so it suits developers more than content teams. In my experience, most sites only need it for PDFs, if at all.

Method 3: XML Sitemap

For large sites, the sitemap is often the cleanest choice. The tags live in one place instead of in every page template. Declare the xhtml namespace. Then give each <url> entry a set of <xhtml:link> children that list every version, including itself.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/uk/running-shoes/</loc>
    <xhtml:link rel="alternate" hreflang="en-gb" href="https://example.com/uk/running-shoes/" />
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/laufschuhe/" />
  </url>
  <url>
    <loc>https://example.com/de/laufschuhe/</loc>
    <xhtml:link rel="alternate" hreflang="en-gb" href="https://example.com/uk/running-shoes/" />
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/laufschuhe/" />
  </url>
</urlset>

Each version gets its own <url> entry. That is how the return links are shown. The <xhtml:link> children do not count towards the sitemap’s URL limit, and their order does not matter. The usual sitemap rules still apply. So read our guide to XML sitemap best practices before you build one for thousands of URLs.

Which Method Should You Choose?

My own rule of thumb: if a CMS plugin can handle it, use the HTML head. If you have many markets and thousands of pages, I’d lean towards the sitemap.

Return Links and Self-References

This rule is behind most broken hreflang setups I see. If page A says page B is its German version, page B must say page A is its English version. Without that confirmation, Google may ignore the tag.

The reason is simple. Without return links, anyone could add hreflang on their own site and claim your page as their version. When both sides must agree, that can’t happen.

The self-reference is part of the same idea. Each page includes its own URL in the set, so the block of tags is the same on every version. That makes templates easier. It also removes a whole type of “this page forgot to mention itself” error.

Here is a test I like. Pick any page in the group and copy its hreflang block. Now imagine pasting it onto any other page in the group. If it would be wrong anywhere, your set is not consistent.

X-Default: The Fallback Page

x-default tells Google which page to show when a searcher’s language or region matches none of your versions. It has no language code of its own.

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

Google designed it for language or country picker pages. It also fits home pages that redirect visitors based on their location. Those are the cases where it works best. Many sites also point x-default at their main international version, such as a general English page. That is a sensible fallback too.

Two related points. First, x-default belongs in the set on every version, like any other tag. Second, if you have several regional versions in one language, Google recommends a language-only catch-all as well. For example, a general en page next to en-GB, en-AU and en-IN. One of the regional pages can do that job.

A Worked Example: An Indian Business in English and Hindi

Say you run a home appliance brand in India. You have an English site, a Hindi site and a UK store for customers abroad. You might set up:

• https://example.in/en/ for English speakers in India
• https://example.in/hi/ for Hindi speakers in India
• https://example.in/uk/ for English speakers in the UK, with prices in pounds

The block on every one of those pages would be:

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

A few things are going on here:

• The English India page has three labels. en-in is for English speakers in India. The language-only en is a catch-all for English speakers in countries where you have no page. And x-default is for everyone else. One URL can hold several hreflang values.
• The Hindi page is labelled hi-in. Since you only have one Hindi version, plain hi would work too. Only add the region when it adds meaning.
• The Hindi page must really be in Hindi. A page with a Hindi menu and English product descriptions is not a Hindi page. Hreflang will not make it one. I think this matters more now that AI Mode answers in Hindi and other languages too.

If you later add a Tamil version, add ta-in to the block on every page, not just the new one. Updating the set everywhere at once is what keeps the return links working.

How Hreflang Works With Canonical Tags

A canonical tag is a line of code that tells Google which version of a page is the main one. Hreflang and canonical tags do different jobs, and they clash more often than any other pair of signals. Canonical says “this is the main URL for this content.” Hreflang says “these are the language and region versions of this content.”

The safe rules:

1. Each local page should normally point its canonical to itself. Do not point the Hindi page’s canonical at the English page. That tells Google the Hindi page is a copy of the English one, which works against the hreflang.
2. Only list canonical URLs in hreflang. If a URL in your set has a canonical pointing elsewhere, redirects or returns an error, it is a weak or broken member of the group.
3. Keep the canonical in the same language. Google’s canonical guidance says that when you use hreflang, the canonical should be a page in the same language. If none exists, use the closest substitute.
4. Do not put hreflang on the canonical tag. A rel="canonical" link with an hreflang attribute is not used for canonicals. Use rel="alternate" for hreflang.

There is one grey area. Sometimes two regional pages are almost the same, such as US and UK pages that differ only in currency. Google may treat them as duplicates and pick one as canonical. Google’s advice is to use both canonical and hreflang, so it knows which regional URL to show. Making the pages truly local also helps: local prices, delivery details and contact information. Our guide to canonical tags covers how Google picks a canonical and how to check its choice.

Common Hreflang Errors and How to Fix Them

Most broken setups fall into a few patterns. When I audit hreflang, I go through them in this order.

Invalid Codes

Examples: en-uk, en_GB, eng, in for India, or a region on its own. Change the code to a valid ISO 639-1 language, with a valid ISO 3166-1 Alpha 2 region after it if needed. When you add a new market, look up its code instead of guessing.

Missing Return Links

This usually happens when someone adds a new version without updating the existing pages. Templates that differ between parts of the site cause it too. Build the hreflang block from one source of truth, such as a single table of URL mappings. Don’t hand-edit pages.

Pointing to URLs That Are Not the Final, Canonical Version

This includes URLs that redirect, return 404, are blocked in robots.txt, carry noindex, or have a canonical pointing to another page. Trailing slash and HTTP versus HTTPS differences count too. Listing an HTTP URL when the HTTPS version exists can lead Google to prefer the HTTP page. Every href should be the exact live, indexable, self-canonical URL that returns a 200 status.

Relative URLs

href="/de/" is not valid for hreflang. Always use the full URL, including https://.

Conflicting Methods

The sitemap says one thing and the page head says another. I usually see this after a site move. Choose one method and remove the other.

Hreflang Added Only by JavaScript

Google can run JavaScript. But tags added late, or only in the browser, are more fragile than tags in the HTML the server sends. If your site depends on JavaScript to build pages, our guide to JavaScript SEO explains how to check what Google actually sees.

Automatic Redirects by Location or Browser Language

Google’s crawler mostly comes from US addresses. If you force every visitor to a version based on IP address, Googlebot may never reach your other versions. Let people switch language with visible links. Use x-default on any page that does redirect.

How to Test Your Hreflang Setup

Search Console’s old International Targeting report used to flag hreflang errors. It was retired in 2022. Testing now needs a mix of checks.

1. Check the source on a sample of pages. View the page source of one URL per template and per language. Confirm the block is in the head, complete and the same across versions.
2. Check headers for files. For PDFs, request the file and read the response headers, for example with curl -I https://example.com/en/size-guide.pdf.
3. Crawl the site. Most site crawlers can report hreflang problems in bulk: missing return links, invalid codes, and versions that redirect, return errors or are not canonical.
4. Use URL Inspection. Inspect each version in Search Console. Confirm it is indexed and that the Google-selected canonical is the page itself. Also check that the rendered HTML contains your hreflang tags.
5. Watch the results by country. In the Performance report, filter by country and see which pages get impressions. Is your Hindi or UK page rarely showing in its own market while the main English page does? Then the tags or the content need another look.

Expect changes to take time. Google has to recrawl each version before it can confirm a new set. That happens at different speeds on different pages. I check the country data every few weeks rather than every day.

Conclusion

Hreflang is simpler than its reputation. The core of any hreflang guide comes down to a few rules: valid language and region codes, one method, a complete and identical set on every version including itself, full canonical URLs, and an x-default fallback. Most errors come from breaking one of those rules as the site grows.

Your next step: make a simple spreadsheet that maps each page to its language versions. Build your hreflang from it. Then confirm that every URL in it is the canonical version. If you are unsure about that last part, start with our explanation of how canonical tags work.