hreflang Tags: The Complete 2026 Implementation Guide from ConveyThis

Summarize this post with: 11 min read

ChatGPT Perplexity Grok Google AI

hreflang implementations tend to fail in a small number of repeatable ways: invalid codes, missing return links, redirected targets, canonical conflicts, and incomplete language clusters. This guide explains how to avoid those failures and validate the result.

If Google is showing the wrong language URL in search results, or your translated pages are difficult to discover, this guide is for you. Google documents the supported approaches in its localized versions guide.

hreflang is one of those technical SEO topics that gets explained over and over but never quite clicks, because most explanations skip the parts that actually break in production. The four-line example works fine until you have 23 languages, regional variants, alternate page formats, and a checkout flow that lives on a subdomain. Then small inconsistencies can leave parts of the language cluster unrecognized.

This guide covers the implementation that works in the real world. Not the textbook version. The version where Cloudflare caches your headers, Next.js generates pages on demand, and your CMS adds trailing slashes that don’t exist in your sitemap.

What hreflang actually does (and doesn’t do)

hreflang tells search engines which version of a page to show users in different languages or regions. It’s a relationship signal, not a ranking signal.

This distinction matters. Adding hreflang doesn’t make your French page rank higher in France. It tells Google: “this English page and this French page are equivalent translations of the same content. When someone searches in French from France, show them the French one.” Without it, Google might still rank your French page, but it might also serve your English page to French searchers — or worse, treat both as duplicate content and pick one to demote.

Three things hreflang does:

• Routes the right language version to the right user.
• Helps Google understand that similar translated pages are intended for different audiences.
• Connects equivalent language or regional variants as a cluster.

Three things hreflang does not do:

• Translate your content (obvious, but worth stating).
• Improve rankings within a single market.
• Fix poor translation quality or thin content.

The basic syntax (and why most examples are incomplete)

Here’s the version most guides show you. It’s correct, and it’s also missing the most important line:

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

This snippet declares three language versions. It will partially work. The issue: every page that uses these tags must reference itself in the list. Otherwise Google treats the references as one-directional and may discard them.

The complete version on the English page looks like this:

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

Two things changed:

• Self-referencing hreflang. The English page now declares itself as the English version. Without it, the set is incomplete and may not be interpreted as intended.
• x-default. This declares the fallback page for users whose language doesn’t match any specified version. If a Korean user lands on your site and you don’t have Korean, x-default tells Google which page to serve.

Now here’s the part that’s almost never explained correctly: the same logic applies to the French page and the German page. Each page must list every language version, including itself, and x-default. Not just the English source.

On the French page:

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

Identical to the English page. That’s the point. hreflang declarations must be reciprocal — every language version must reference every other language version. If page A points to page B, page B must point back to page A. Google calls these “return tags,” and they’re the single most-failed validation rule in international SEO.

Language codes: the cheat sheet

hreflang codes follow the format language or language-REGION. Languages use ISO 639-1 (two-letter, lowercase). Regions use ISO 3166-1 Alpha 2 (two-letter, uppercase). The most common confusions:

UK is not a country code. This is the single most-frequent error I’ve seen in 10 years of audits. The ISO 3166-1 code for the United Kingdom is GB. Use en-GB, not en-UK. Google ignores invalid codes silently — your tag exists, but it does nothing.

Three implementation methods

hreflang can be declared in three places. Each has trade-offs.

Method 1: HTML <head> tags (most common)

Tags placed in the <head> section of every page. Easy to debug, easy to inspect, supported by every CMS. The downside: every page must include every other language’s tag, which means a 50-page site in 10 languages requires 500 hreflang declarations to be generated and kept in sync.

Use this method if your site has fewer than ~10,000 pages or your CMS handles hreflang generation automatically.

Method 2: HTTP headers (for non-HTML files)

hreflang can be sent as an HTTP Link header. This is the only way to declare hreflang for non-HTML resources like PDFs:

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

Use HTTP headers when you have downloadable assets that exist in multiple languages — product manuals, regulatory documents, white papers.

Method 3: XML sitemap (for large sites)

For sites with hundreds of thousands of pages, declaring hreflang in <head> tags becomes unwieldy. Sitemap-based hreflang is more efficient and keeps your HTML lean:

<url>
  <loc>https://example.com/</loc>
  <xhtml:link rel="alternate" hreflang="en"
              href="https://example.com/" />
  <xhtml:link rel="alternate" hreflang="fr"
              href="https://example.com/fr/" />
  <xhtml:link rel="alternate" hreflang="x-default"
              href="https://example.com/" />
</url>

Same reciprocity rules apply. Each URL entry in the sitemap must list every language version, including itself.

Google treats the three implementation methods as equivalent and says there is no search benefit to using all of them. Choose the method that is easiest to generate and keep consistent; if you intentionally use more than one, make sure the declarations match.

Five common implementation mistakes

1. Missing self-referencing hreflang

The English page lists French and German versions, but doesn’t reference itself as the English version. Google ignores the entire hreflang cluster. Fix: every page must include a hreflang tag pointing to itself.

2. Non-reciprocal return tags

English page points to French page. French page doesn’t point back. Google sees this as broken and may discard the relationship. Fix: every reference must be mutual. The French page must list the English page as its English alternative.

3. Pointing hreflang to redirected URLs

Your English page declares the French version at https://example.com/fr/ but that URL 301-redirects to https://example.com/fr/home/. Google follows the redirect, but the hreflang signal is weakened — and in some cases ignored entirely.

Fix: hreflang must point to the final canonical URL, not to a redirect chain. Audit with a crawler that flags non-200 hreflang targets.

4. hreflang and canonical conflicts

Your French page has a canonical pointing to the English page (because someone copy-pasted the canonical tag). Google reads this as “the French page is just a duplicate of the English page” and the hreflang relationship gets ignored. Fix: every translated page must self-canonicalize. The French page’s canonical points to itself, not to the English original.

5. Mixing language and region codes inconsistently

Some pages declare hreflang="en", others declare hreflang="en-US". Google treats these as separate language clusters. Pick one strategy per language and stick with it across the entire site.

Production edge cases to plan for

Edge case 1: Region-only targeting (en-CA without en)

You have an English-Canadian variant of your page but no global English version. Don’t use hreflang="en" alone — Google may serve your Canadian page to UK users, which probably isn’t what you want. Instead, declare hreflang="en-CA" specifically and let x-default handle non-Canadian English speakers.

Edge case 2: Same content, different regions

US, UK, and Australian English versions of the same product page with identical text. This is fine — declare each region explicitly:

<link rel="alternate" hreflang="en-US" href="https://example.com/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="en-AU" href="https://example.com/au/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Even when content is identical, regional hreflang variants are valuable for products with region-specific pricing, currency, or shipping.

Edge case 3: Mobile and desktop variants

If you have separate m. subdomain mobile pages, each mobile page needs its own hreflang declarations pointing to other mobile language variants. Don’t point a mobile French page to a desktop English page — Google considers this a broken cluster.

Edge case 4: Subdomains vs. subdirectories

Both work for hreflang. fr.example.com and example.com/fr/ are equally valid. The choice is operational (DNS, hosting, analytics) — not an SEO factor by itself. What matters is consistency: pick one structure and apply it across all languages.

Edge case 5: Pagination

Page 2 of your French blog index should declare hreflang to page 2 of your English blog index, not to page 1. Map equivalent pages to equivalent pages, including pagination, query parameters, and filters.

Edge case 6: 404 and 410 pages

If a translated version of a page doesn’t exist (yet), don’t declare hreflang for that language. Pointing hreflang to a 404 is worse than not declaring it at all — Google sees it as a broken relationship and may demote the entire cluster.

How to validate before going live

Use complementary checks because no single report proves that every URL pair is correct:

• Google Search Console. Submit the language sitemaps, inspect representative URLs with URL Inspection, and compare Page indexing and Performance data by language directory. The former International Targeting report is no longer available in the current Search Console interface.
• Screaming Frog. Crawls your entire site and reports non-reciprocal hreflang, missing return tags, broken hreflang URLs, and inconsistencies. The single best tool for pre-launch QA.
• Merkle’s hreflang tag testing tool. Free, browser-based, good for spot-checks during development.

Run crawler validation and representative URL checks before a major launch, then monitor Search Console after Google recrawls the pages.

How automated tools handle hreflang

If you’re using a website translation platform like ConveyThis, Weglot, or similar, hreflang generation should be automatic. The platform crawls your content, detects new pages, and inserts the correct hreflang tags on every translated version — including self-referencing tags, return tags, and x-default.

This is the strongest argument for using a translation platform over a manual translation pipeline. Manually maintaining hreflang across a 200-page site in 12 languages means tracking 31,200 tag relationships. Every new page adds 12 new relationships that must be added in 12 places. Manual maintenance breaks at scale.

If you’re using a platform and still seeing hreflang errors in Search Console, the cause is usually one of three things: a CDN caching layer that’s stripping headers, a CMS plugin that’s overwriting tags, or a redirect rule that’s interfering with the canonical structure. All three are fixable, but they require coordination between your translation platform, your hosting setup, and your CDN.

The bottom line

hreflang isn’t complicated. It’s verbose. The complexity comes from the volume of declarations and the fragility of any single missing tag. Get the foundations right — self-referencing, reciprocal, canonical-aligned, x-default present — and the rest is just maintenance.

Correct hreflang removes ambiguity about which equivalent URL is intended for a given language or region. Fix the basics first, then monitor impressions, clicks, and selected canonical URLs as Google recrawls the cluster.

About the author

Alex Buran, Founder of ConveyThis

Alex has spent the last decade building infrastructure for multilingual websites. He writes about localization, AI search, and the technical side of going global.

LinkedIn: https://www.linkedin.com/in/alexburan/

Tired of debugging hreflang manually? ConveyThis generates valid, reciprocal, self-referencing hreflang tags on every translated page automatically — including x-default and edge cases. See the API documentation