Hreflang Tags: Why They Matter and How to Get Them Right

Hreflang Tags: A Practical Implementation and Troubleshooting Guide

hreflang connects equivalent pages that use different languages or target different regions. It helps Google understand that the URLs belong to the same localised set and gives Google a clearer signal about which version may suit a searcher.

It does not translate a page, force a visitor onto a regional site, guarantee that a particular URL will be shown, or replace canonical tags and normal indexability checks. This guide explains when hreflang is useful, how to implement it with one maintainable method, how to validate an entire language cluster, and what to investigate when the wrong page still appears.

1. Hreflang in 60 Seconds

• Use hreflang when equivalent content has separate URLs for different languages or regions.
• Every participating page should identify itself and the relevant alternate versions with complete URLs, including the protocol and hostname.
• Return links matter: if page A identifies page B as an alternate, page B should identify page A.
• Google supports three equivalent implementation methods: HTML <link> elements, HTTP Link headers, or XML sitemap annotations. Using all three gives no Search advantage and can create conflicting data.
• The language comes first, with an optional script and region: en, en-gb and zh-Hant can be valid; uk on its own is not a valid way to target the United Kingdom.
• x-default is an optional fallback for unmatched users, often a country or language selector.

Google’s documentation for localised page versions is the primary reference for syntax, supported codes and return-link requirements.

2. Decide Whether You Actually Need Hreflang

Hreflang is useful when two or more URLs satisfy the same underlying task for different audiences. Common examples include:

• a product page translated into English, French and German;
• UK, US and Australian versions of the same service page with different prices, spelling, availability or legal wording;
• pages whose main content is shared but whose navigation or surrounding interface is translated;
• equivalent pages hosted on different subdirectories, subdomains or domains.

Do not use hreflang as a general language label

Hreflang is not needed when there is only one URL. It also should not connect pages that merely look similar but answer different questions, sell different products or lead to different actions. Build each cluster around genuinely equivalent pages.

The HTML lang attribute serves a different purpose. Keep it accurate because browsers and assistive technologies use it to process and pronounce content correctly, but do not treat it as a replacement for hreflang. Google says it determines page language from visible content rather than from hreflang or the HTML lang attribute. The W3C explanation of page language covers the accessibility reason for declaring it.

Use separate, crawlable URLs and keep a visible language switcher

Google recommends separate URLs for different language versions rather than changing the content of one URL only through cookies or browser settings. It also advises against automatically redirecting every visitor based on an assumed language or IP location, because users and crawlers may be prevented from reaching other versions. Give people a clear way to choose another language or region instead. See Google’s guidance for multilingual and multi-regional sites.

Hreflang is not a duplicate-content cure

Translated pages are not automatically a duplicate-content problem merely because they share a template. Google notes that localised versions are considered duplicates only when the main content remains untranslated. For highly similar same-language regional pages, hreflang and canonicalisation may both be relevant, but they solve different parts of the problem.

3. Make Hreflang, Canonicals, Redirects and x-default Agree

Canonical tags identify the preferred URL; hreflang maps localised alternatives

Each language or regional page that you intend Google to index separately will usually need a canonical that supports that intention. In many straightforward international setups, that means a self-referencing canonical on each localised URL. Do not automatically canonicalise every alternate page to one global version, because that tells Google you prefer the global URL instead of the regional page.

Same-language regional pages can require more judgement when their main content is almost identical. Google recommends using canonicalisation and hreflang together for similar or duplicate regional URLs. Check that the canonical target is indexable, belongs in the intended localised set and does not contradict the URL you expect to appear. The Google canonicalisation guide explains the available signals; ScanMySEO’s canonical issues guide provides a broader troubleshooting workflow.

Hreflang does not redirect visitors

An hreflang annotation helps Google choose a search-result URL. It does not change what happens after someone lands on your website. If the business also uses location prompts or redirects, let users override the choice and avoid trapping them in a version they cannot leave.

Use x-default only when there is a genuine fallback

x-default identifies the URL for users whose language or region is not otherwise represented. It can point to a country selector, a language-neutral landing page, or a sensible default version. It is recommended for a real fallback, but it is not mandatory on every cluster.

If you have several regional variants in the same language, also consider a language-only catch-all. For example, a site with en-ie, en-ca and en-au may include a generic en page for English-speaking users outside those regions. That language catch-all and x-default perform different jobs.

4. Implement Hreflang With a Repeatable Workflow

1. Build a page-variant map.

   Create one row per content set and one column per language or region. Record the final, indexable URL for each equivalent page. Leave a cell empty when no true equivalent exists rather than pointing that language to an unrelated homepage.

2. Choose one source of truth.

   Generate annotations from the same data that powers your language switcher, routing or catalogue. Manual tag lists become unreliable as URLs are added, removed or redirected.

3. Select one implementation method.
   • HTML head: practical when page templates can output the full cluster reliably.
   • XML sitemap: practical when a central system already maintains every localised URL and can generate consistent sitemap entries.
   • HTTP Link header: especially useful for non-HTML files such as PDFs.

   Google treats the methods as equivalent. Choose the method your team can keep correct instead of duplicating annotations across all three.

4. Use supported codes and complete URLs.

   Start with an ISO 639-1 language code, optionally followed by an ISO 15924 script and/or ISO 3166-1 Alpha-2 region. Separate subtags with hyphens. Examples include fr, en-gb, zh-Hant and zh-Hans-US. A region cannot appear by itself, and Google ignores unsupported or reserved region values such as UK, EU and UN.

5. Include self-references and return links.

   Every version should list itself and the relevant alternate URLs. The simplest implementation uses the same complete set on every page in the cluster. Where maintaining a complete set becomes difficult, Google can process reciprocal subsets, but a missing return link can cause the affected annotation to be ignored or interpreted incorrectly.

6. Point only to clean destination URLs.

   Use final, fully qualified URLs—normally HTTPS—that return a successful response, are not blocked from indexing and do not immediately redirect somewhere else. Keep protocol, hostname, trailing-slash and parameter conventions consistent.

7. Deploy and validate the whole cluster.

   Checking one page is not enough. Compare the live implementation against the expected page map and verify both directions for every relationship.

HTML head example

Place the full set inside a well-formed <head>. The same set should appear on every participating page:

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

XML sitemap example

Each <url> entry must list every alternate, including itself. Repeat the structure for every URL in the cluster:

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

HTTP Link header example

For a non-HTML resource, return all alternates in the response header:

Link: <https://example.com/file.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/de/datei.pdf>; rel="alternate"; hreflang="de"

5. Troubleshoot Hreflang in the Right Order

Start with the structural faults most likely to invalidate a cluster. A correct-looking tag on one page can still fail because the destination, canonical or reciprocal page disagrees.

1. Confirm that the pages are genuine equivalents.

   Compare the main purpose, not just the template. A German product page should normally point to the same product in other languages, not to a category page or homepage.

2. Check the destinations before the annotations.

   Verify HTTP status, indexability, canonical target and redirect destination. Fix broken, redirected or excluded URLs before debugging the language codes.

3. Validate the code format.

   Look for country-only values, underscores instead of hyphens, unsupported codes, relative URLs, duplicate values and tags placed outside the HTML head.

4. Test reciprocity across the cluster.

   For every A → B relationship, confirm B → A. Also confirm that each page references itself and that the live set matches the expected map.

5. Remove contradictions between methods.

   If HTML, headers and sitemaps are all present, compare them. Conflicting clusters are harder to maintain than one authoritative implementation.

6. Separate implementation faults from selection differences.

   A technically valid cluster does not guarantee that every manual search will show the URL you expect. Google considers several locale and relevance signals, and results can vary by location, device and search context.

Common faults to look for

• en-uk instead of en-gb;
• a region without a language, such as gb;
• one version added to the cluster without reciprocal updates elsewhere;
• an alternate URL that redirects, returns an error or contains noindex;
• a canonical that points from every regional page to one global URL;
• different URLs in the HTML and sitemap implementations;
• annotations generated only on desktop or only on mobile URLs;
• language versions whose visible main content is still in the wrong language.

6. Worked Example: UK, US and Generic English Product Pages

Imagine a retailer has three equivalent product pages and a region selector:

• https://example.com/product/ — generic English;
• https://example.com/gb/product/ — UK pricing and delivery;
• https://example.com/us/product/ — US pricing and delivery;
• https://example.com/choose-region/ — language and region selector.

Every one of those pages should output the same hreflang set:

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

The generic English URL covers English-speaking users outside the two named regions. The x-default URL covers unmatched language or region settings and gives users an explicit choice. The UK and US pages should remain independently indexable if the business expects them to appear separately, and their canonical signals should support that outcome.

A common failed version would put this block only on the UK page. The US page would then lack the return link, so the relationship would be incomplete even though the UK source code looked correct.

7. Verify the Fix After Deployment

Check the implementation itself

• Inspect the rendered HTML head, HTTP response headers or submitted sitemap, depending on the chosen method.
• Crawl all localised URLs and export a matrix of source URL, hreflang value and destination URL.
• Flag missing self-references, missing return links, invalid codes, redirects, errors, noindex pages and canonical conflicts.
• Compare a sample from every page template, not just the homepage.

Use current Search Console tools for indexability and outcomes

The old International Targeting report has been deprecated, although Google continues to support hreflang. Use the URL Inspection tool to check whether representative pages can be indexed and which canonical Google selected. It does not replace a full-site hreflang crawler, but it can reveal the indexing or canonical problem that prevents an alternate URL from participating as expected.

Then use the Search Console Performance report to compare pages and countries over time. This is an outcome check rather than proof that every tag is valid: look for unexpected countries landing on the wrong regional URL, changes after deployment and important localised pages receiving no impressions.

Keep the cluster accurate as the site changes

Add hreflang maintenance to launches, migrations and page-removal workflows. When a localised URL changes, update every page or sitemap entry that references it. When one market removes a page without an equivalent replacement, remove that URL from the cluster instead of redirecting it to an unrelated destination.

8. Hreflang Release Checklist

Before publishing

• Each cluster contains genuinely equivalent pages.
• Every URL is complete, final and indexable, using the site’s canonical protocol and hostname.
• Language, script and region codes are supported and separated with hyphens.
• Every page references itself and the relevant alternates.
• Return links are present.
• Canonical signals do not contradict the intended regional URLs.
• One implementation method acts as the source of truth.
• x-default is included only when a real fallback exists.
• Users can switch language or region without being trapped by automatic redirects.

After publishing

• Crawl the entire cluster and compare it with the expected page map.
• Inspect representative URLs from every template and locale.
• Check Google-selected canonicals for important pages.
• Monitor page and country performance for unexpected routing.
• Repeat the checks after migrations, catalogue changes and new market launches.

The most reliable hreflang setup is not the one with the most tags. It is the one generated from an accurate page map, kept consistent across every equivalent URL, and validated whenever the international site changes.