Hreflang Tags: A Practical Guide for Multilingual Sites

Hreflang is an annotation that tells Google which language or regional versions of a page exist, so it can show a German searcher your German page and a British searcher your UK page. You add it with rel="alternate" hreflang="…" links in the HTML head, in HTTP headers, or in your XML sitemap. Every version must list itself and all the others, and the codes must follow ISO 639-1 for language and ISO 3166-1 Alpha 2 for region.

It’s a hint, not a command. Google still decides for itself which URL to index and which one to show each searcher, and when the annotations are broken or contradict each other, it simply ignores them.

Below is my route through it. When you need hreflang, which method fits, the codes that trip people up, and how to check your work now that Search Console no longer reports on it.

Is Hreflang a Directive or a Signal?

A signal. Not a rule. Google’s localized versions documentation never describes hreflang as an instruction Google must obey. It says that if return links are missing, annotations “may be ignored or not interpreted correctly.” Hint language. Plain and simple.

There’s a second point people miss. Google says it doesn’t use hreflang or the HTML lang attribute to detect a page’s language. Its own algorithms work out the language instead. Tag a French page as English and it stays French.

In my experience, this is why hreflang only works on top of a solid setup. It can tell Google how your versions relate to each other, but it can’t rescue pages that are poorly translated, blocked in robots.txt, noindexed or quietly canonicalized away to another language.

The Condition Map: What Decides Your Setup

Four questions decide how you implement hreflang. Always these four.

1. Do you have more than one language or regional version? One language for one market means you skip hreflang entirely.
2. Are the versions different languages, or the same language for different regions? English for the US and UK needs region codes. English and German don’t.
3. Where can you make changes? The HTML head, the server headers, or the sitemap. Your answer often picks the method for you.
4. What platform runs the site? Shopify and the main WordPress multilingual plugins write hreflang for you, so your job shifts from building it to checking it.

Do You Even Need Hreflang?

If your site has one language and serves one country, then you don’t need hreflang. Skip it.

If you have translated versions of the same pages, then yes. Use it.

If you have one language with regional differences, like US and UK pricing pages in English, then yes, and this is where hreflang earns its keep. Those pages look almost identical to Google, so without annotations it may fold them together and show the wrong one.

Google also notes that localized versions only count as duplicates when the main content stays untranslated. Swapping the menu and footer language while the body stays in English doesn’t make a real German page, no matter how many tags you add. I see this half-finished setup on WordPress sites more than anywhere else, usually after someone installed a translation plugin and never finished the job.

Which Language and Region Codes Are Valid?

The value is a language code, optionally followed by a region code. The language uses ISO 639-1 (two letters, like en, de, fr). The region uses ISO 3166-1 Alpha 2 (two letters, like US, GB, DE). Google’s docs say you can’t use a region code on its own.

Honestly, en-UK is the error I find most. Looks right. Isn’t valid. Google can’t match a region code that doesn’t exist in the standard, so every British visitor that tag was meant for falls through to whatever version Google picks on its own.

Method 1: HTML Link Tags in the Head

Most sites use this. Each page carries a set of <link> tags in its <head>, one for every version in the set, and that includes a tag pointing at the page itself.

<head>
  <link rel="alternate" hreflang="en-US" href="https://www.example.com/us/pricing/" />
  <link rel="alternate" hreflang="en-GB" href="https://www.example.com/uk/pricing/" />
  <link rel="alternate" hreflang="de" href="https://www.example.com/de/preise/" />
  <link rel="alternate" hreflang="x-default" href="https://www.example.com/pricing/" />
</head>

Every URL in that set carries this exact block, the x-default page included. Google requires the tags inside a well-formed <head> and wants fully qualified URLs, including https://. A relative path like /de/preise/ doesn’t count.

Watch out for anything that breaks the head early. A stray <div> or an image injected into the head by a script or plugin can make the parser close the head right there, and then every hreflang tag that comes after it lands outside the head where Google won’t read it. Sneaky one.

Method 2: HTTP Headers for Non-HTML Files

If the content isn’t an HTML page, like a PDF price list in three languages, then there’s no head to put a link tag in. Send it in the HTTP response header instead.

Link: <https://www.example.com/docs/price-list-en.pdf>; rel="alternate"; hreflang="en", <https://www.example.com/docs/price-list-de.pdf>; rel="alternate"; hreflang="de", <https://www.example.com/docs/price-list-en.pdf>; rel="alternate"; hreflang="x-default"

Each file returns the same header listing every version. You’ll need server access for this, which usually makes it a developer job, and honestly I rarely use it for anything except downloadable documents. Rare, but handy.

Method 3: XML Sitemap Annotations

If you have many versions or can’t edit the templates, then the sitemap is often the cleanest home. Each <url> entry lists every version, including itself, with xhtml:link elements. Here’s a shorter two-language version of the same pricing page set.

<?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://www.example.com/us/pricing/</loc>
    <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/us/pricing/"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/preise/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/pricing/"/>
  </url>
  <url>
    <loc>https://www.example.com/de/preise/</loc>
    <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/us/pricing/"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/preise/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/pricing/"/>
  </url>
  <url>
    <loc>https://www.example.com/pricing/</loc>
    <xhtml:link rel="alternate" hreflang="en-US" href="https://www.example.com/us/pricing/"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://www.example.com/de/preise/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/pricing/"/>
  </url>
</urlset>

Forgetting the xmlns:xhtml namespace line is the classic sitemap mistake. Check it twice. The general sitemap rules (size limits, what to include, how to submit) are in my guide to XML sitemap best practices.

Which Method Should You Pick?

Google says the three methods are equivalent. Good news. The choice comes down to your setup and who maintains it, not to any hidden ranking difference between them.

My default is HTML tags for small sites with a handful of versions, because anyone on the team can open the page source and see them. I switch to the sitemap when the cluster grows large, since a page with dozens of alternates in every head gets heavy and painful to maintain by hand. Headers? PDFs only.

Pick one method per set of pages. Mixing isn’t forbidden. But two sources that disagree are far harder to debug than one source that’s simply wrong, and I’ve lost more hours to that than to any typo.

What Does x-default Do?

x-default is a reserved value for the fallback page. Google uses it when no other version matches the searcher’s language or region settings. It’s a good fit for a language picker page or your main international version.

It’s optional. I add it anyway. Without it, a Brazilian visitor on a site with only English and German versions gets whichever page Google decides fits best, which may not be the one you’d choose.

Why Do Return Links Break Most Setups?

Return links mean hreflang must go both ways. Google’s docs state that if page X links to page Y, page Y must link back to page X. Self-reference counts too.

This is where most hreflang setups quietly fail. A team launches a new French page and adds the tags to it, but nobody remembers to update the English and German pages that were already live, so the French page points out while nothing points back. Google may then ignore the set. All of it.

Google lists this as the first common mistake in its documentation, ahead of wrong language and region codes. It’s my first check too.

Hreflang vs Canonical: How Do They Work Together?

Canonical tags tell Google which URL to treat as the main one among duplicates. Hreflang tells Google which equivalent URL fits which audience. Different jobs. They still have to agree.

Google’s guide to consolidating duplicate URLs says that when you use hreflang, you should “specify a canonical page in the same language,” or the best substitute language if none exists. In practice, each language version should usually carry a self-referencing canonical, and every URL in your hreflang set should be the canonical URL.

The mistake I see most is canonicalizing every translation to the English page, often because an SEO plugin was set up before the translation plugin and nobody revisited the settings afterwards. That tells Google the German page is a duplicate of the English one, which contradicts the hreflang saying it’s a separate version. My guide to canonical tags covers canonicals in depth.

How Do Shopify and WordPress Handle Hreflang?

If you’re on Shopify with Markets, then hreflang is generated for you. Shopify’s international SEO help page says the tags are created automatically from your market and language setup, and that an x-default points to your primary domain. The catch: tags are only generated for markets with their own domain, subdomain or subfolder. My Shopify vs WooCommerce SEO comparison counts this as one of Shopify’s real advantages.

If you’re on WordPress, then there’s no built-in language system, so a multilingual plugin does the work. WPML, Polylang and TranslatePress all document automatic hreflang output for translated content. Settings for x-default and region codes differ by plugin and version, so check yours after setup rather than assuming.

Either way, your job changes from writing tags to auditing them. A plugin can only link the translations you’ve actually connected inside it, so an orphaned translation that nobody paired with its original gets no hreflang at all.

Common Hreflang Errors to Check

• Missing return links between versions.
• Invalid codes like en-UK, region-only values, or unsupported codes like es-419.
• Relative URLs instead of fully qualified ones.
• Hreflang pointing at redirected, noindexed or non-canonical URLs.
• Translated pages canonicalized to the original language.
• Tags placed outside the <head>, or a head broken by injected markup.
• A sitemap missing the xmlns:xhtml namespace.
• “Translations” where only the menu changed and the body stayed in the original language.

Hreflang errors also show up in my roundup of common technical SEO issues, next to the other problems that make the wrong version rank.

How Do You Check Hreflang Now?

Search Console used to have an International Targeting report for hreflang errors. Google removed it in September 2022, and the country targeting setting went with it. Hreflang itself stayed supported.

Checking now takes three steps. First, use URL Inspection in Search Console and view the crawled HTML to confirm Google sees your tags. Second, run a crawler with hreflang validation over the whole site, because that’s the only practical way to catch missing return links at scale. Third, open the Performance report, filter by country, and see which URLs actually get impressions there.

That third check tells you whether the hint worked. If German searchers still land on your English page months after launch, go back to the codes, the return links and the canonicals, in that order.

Decision Matrix

When Should You Get Help?

On a small site, most hreflang problems take an afternoon. Large stores with many markets, headless builds or custom CMS setups are different, because the bug usually sits in how templates generate URLs. That needs someone who can read the code and the crawl together.

International setups are part of our technical SEO service. If you’d like a second pair of eyes first, request a free SEO audit.

Frequently Asked Questions

Does Hreflang Improve Rankings?

Not directly. It helps Google show the right language or regional version to each searcher, so the page built for that market gets the impression and the click instead of a sibling that reads wrong to them. A translated page still has to be relevant and well written to rank in its market.

Is x-default Required?

No, but I recommend it. Google uses x-default as the fallback when no other version matches a searcher’s language or region. Without it, Google picks a version for those searchers on its own.

Should Hreflang Pages Have Self-Referencing Canonicals?

Usually, yes. Each language version should be its own canonical, and every URL in the hreflang set should be the canonical URL. Google’s docs say to point the canonical at a page in the same language.

Can I Use Hreflang for Pages in the Same Language?

Yes. That’s one of its main uses. English pages for the US, UK and Australia can use en-US, en-GB and en-AU so Google shows the right regional page, even though the language is the same.

Last updated: October 2026 by Mizanur Rahman