A Practical Guide to Getting Hreflang Tags Right

Hreflang is an HTML attribute that tells search engines which language and regional version of a page to show to which audience. If you have an English page for US visitors and another English page for UK visitors, hreflang is how you signal to Google that these aren’t duplicate content. They’re intentional regional variations. Without it, Google guesses. And Google’s guesses aren’t always right.

The concept is simple. The implementation is where things get messy. You’re dealing with language codes, region codes, return links, self-referencing tags, and three different methods of deployment. Get any of those wrong and the tags get ignored entirely. No error message. No warning in Search Console. Just silent failure.

At Gorilla Marketing, we manage hreflang across three international subdomains targeting the UK, US, and UAE. Every implementation problem covered in this guide is something we’ve encountered, diagnosed, and fixed in production. Here’s what you need to know to get it right.

What Are Hreflang Tags and What Do They Actually Do?

Hreflang is a link-level attribute (rel="alternate" hreflang="x") that creates a relationship between equivalent pages across different language or regional versions of a site. Each tag says: “This page also exists in this language/region, and here’s the URL.”

The tag uses ISO 639-1 language codes (two-letter codes like en, es, fr) and optionally ISO 3166-1 Alpha 2 region codes (US, GB, DE). The language code is required. The region code is optional but necessary when you have the same language targeting different countries.

Here’s what’s easy to misunderstand: hreflang tags are hints, not directives. Google treats them as strong signals, but they can be overridden by other factors like contradictory canonical tags, incorrect language detection, or server-side redirects. If you geo-redirect US visitors to your US site before Google can crawl the UK version, your hreflang tags on the UK page become irrelevant because Googlebot never sees them in context.

Bing, for the record, doesn’t support hreflang at all. It uses the content-language meta tag and its own webmaster tools for language and region targeting. Yandex supports hreflang. If Bing is a significant traffic source for your international sites, you’ll need a parallel implementation.

Why Do Hreflang Tags Matter for SEO?

Three concrete problems hreflang solves:

Duplicate content signals. If you run us.example.com/pricing and uk.example.com/pricing with largely similar English content, Google might see those as duplicates and pick one to index, suppressing the other. Hreflang tells Google these are intentional regional variants, not copies. That said, hreflang alone isn’t a duplicate content fix. If the pages are truly identical with no regional differences, you might be better served by a single page with proper international targeting.

Wrong country in search results. Without hreflang, a US searcher might land on your UK pricing page (with GBP prices and UK phone numbers) because Google determined it was the strongest version. That’s a conversion killer. Hreflang steers users to the version built for their market.

Cannibalized rankings. When two regional versions compete for the same query in the same SERP, neither performs at full strength. Hreflang consolidates signals so Google understands which version belongs in which market’s results.

The cost of getting this wrong isn’t dramatic. Your site won’t crash. You won’t get penalized. But you’ll leak traffic, send users to the wrong regional experience, and undermine the investment you’ve made in localized content. On high-traffic international sites, that leakage adds up fast.

When Should You Use Hreflang (and When Should You Skip It)?

Hreflang makes sense when you have:

Same language, different regions. English for the US and English for the UK. Spanish for Spain and Spanish for Mexico. The content is in the same language but tailored to different markets with different spelling, pricing, regulations, or cultural references.

Different languages for the same content. Your product page exists in English, French, and German. Each version covers the same product but in the user’s language.

A combination of both. French for France, French for Canada, English for the US, English for the UK. This is where hreflang earns its complexity.

Skip hreflang when:

You only have one language and one region. A US-only site in English doesn’t need hreflang. There’s nothing to differentiate.

Your “international” pages are just translations with no real targeting. If you auto-translated your site into 40 languages with no localization, hreflang won’t save those pages from performing poorly. The tag signals intent. It doesn’t fix thin content.

You’re using a single URL with dynamic content. If the same URL serves different language content based on IP detection or browser settings, hreflang can’t help. Each language version needs its own URL.

One common mistake: implementing hreflang for pages where the regional differences are trivial. If your US and UK pages are identical except for a single currency symbol, consider whether separate pages are worth maintaining at all. Every hreflang implementation adds ongoing maintenance overhead.

How Do Language and Region Codes Work?

The hreflang attribute value follows a specific format: a required language code, optionally followed by a region code.

Language codes use the ISO 639-1 standard. Two lowercase letters:

Region codes use ISO 3166-1 Alpha 2. Two uppercase letters, hyphenated after the language:

You can use a language code alone (en, es) when you’re targeting all speakers of that language regardless of region. Add the region code when you need to distinguish between regional variants of the same language.

A common error: using country codes where language codes should go. uk is not a valid language code (the language code for Ukrainian is uk, but the region code for the United Kingdom is GB). Using en-UK instead of en-GB is one of the most frequent hreflang mistakes, and Google will silently ignore the tag.

What Are the Three Implementation Methods?

There are three ways to deploy hreflang. Each achieves the same result. The right choice depends on your site architecture, CMS capabilities, and scale.

Method 1: HTML Tags in the

The most common approach. You place elements in the section of each page, pointing to every language/region variant of that page, including itself.

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

When to use it: Small to medium sites (under a few hundred pages per language version). CMS gives you access to the section. You want the implementation visible and easy to audit.

Drawbacks: Adds markup to every page load. On a site with 15 language versions, that’s 15+ extra elements per page. At scale, this bloats page size and slows initial parsing. Also, if your pages are JavaScript-rendered and Google has trouble rendering them, the hreflang tags in the might not get processed reliably.

Method 2: HTTP Headers

For non-HTML resources (PDFs, images) or when you can’t modify the , you can send hreflang via HTTP response headers.

HTTP/1.1 200 OK
Link: <https://us.example.com/pricing.pdf>; rel="alternate"; hreflang="en-US",
<https://www.example.com/pricing.pdf>; rel="alternate"; hreflang="en-GB",
<https://uae.example.com/pricing.pdf>; rel="alternate"; hreflang="en-AE",
<https://www.example.com/pricing.pdf>; rel="alternate"; hreflang="x-default"

When to use it: PDF files, documents, or other non-HTML content that needs language targeting. Also useful when your CMS locks down the and server configuration is more accessible.

Drawbacks: Harder to audit (you need to inspect HTTP headers, not just view source). Easy to break during server migrations or CDN configuration changes. Not all CDN setups make header manipulation straightforward.

Method 3: XML Sitemap

You declare hreflang relationships inside your XML sitemap using the xhtml:link element within each entry.

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

When to use it: Large sites with thousands of pages. Sites where modifying the HTML template is restricted. When you want a centralized, programmatically managed implementation.

Drawbacks: Sitemap processing isn’t instant. Google crawls and processes sitemaps on its own schedule, so changes take longer to reflect. Also, if your sitemap has errors or exceeds size limits, the hreflang declarations may not get processed.

Which Method Should You Choose?

For most sites, the HTML method is the right starting point. It’s the easiest to implement, test, and debug. Move to the sitemap method when you’re managing hundreds of pages across multiple language versions and the markup is becoming unwieldy. Use HTTP headers only for non-HTML files or when you genuinely can’t modify page markup.

You can combine methods, but don’t declare the same hreflang relationship in two places. If Google finds conflicting signals between your tags and your sitemap, it has to choose one, and you won’t control which.

What Is x-default and When Do You Need It?

The x-default tag designates a fallback page for users who don’t match any of your specified language/region combinations. If someone searches from a country or in a language you haven’t specifically targeted, x-default tells Google which version to show them.

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

Typically, x-default points to one of these:

Your primary/default language version (most common)

A language selector or gateway page

An English version, if English serves as your catch-all

You don’t technically need x-default for hreflang to function. But without it, Google has no explicit fallback for unmatched users. It’ll pick one of your existing versions based on its own signals, and that choice might not be the one you’d make.

Best practice: always include x-default. Point it at whichever page provides the best experience for someone who doesn’t fit your defined language/region matrix.

Why Do Return Links and Self-Referencing Tags Matter?

This is where most hreflang implementations break. Two rules that are non-negotiable:

Return Links (Bidirectional Confirmation)

If page A declares that page B is its French equivalent, page B must also declare that page A is its English equivalent. Every hreflang relationship must be confirmed by both sides. If page A points to page B but page B doesn’t point back, Google ignores the tag on page A.

Think of it as a handshake. Both parties have to agree.

<link rel="alternate" hreflang="en-US" href="https://us.example.com/pricing" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/pricing" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/pricing" />
<link rel="alternate" hreflang="en-US" href="https://us.example.com/pricing" />

Both pages must contain the full set of tags. Miss one direction and the whole cluster for that page pair breaks silently.

Self-Referencing Tags

Every page in an hreflang cluster must include a tag pointing to itself. The US pricing page needs a tag with hreflang="en-US" pointing to its own URL. This isn’t redundant. It confirms to Google that this page knowingly participates in the hreflang cluster and acknowledges its own role within it.

Omitting self-referencing tags is technically not a fatal error. Google’s documentation says they’re recommended, not required. But every major SEO toolset flags missing self-references as an issue, and including them eliminates ambiguity. Always add them.

How Do Hreflang and Canonical Tags Interact?

This is a point of frequent confusion. Hreflang and canonical tags serve different purposes, and they need to work together, not against each other.

Canonical tags tell Google which URL is the preferred version when duplicates or near-duplicates exist. Hreflang tags tell Google which regional/language version to serve to which audience.

The rule: every page’s canonical tag should point to itself. A self-referencing canonical. If your US page has a canonical pointing to the UK page, you’re telling Google that the UK page is the “real” version and the US page is a duplicate. Google will follow the canonical and ignore the US page entirely, taking your hreflang tags with it.

<link rel="canonical" href="https://us.example.com/pricing" />
<link rel="alternate" hreflang="en-US" href="https://us.example.com/pricing" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/pricing" />
<link rel="canonical" href="https://www.example.com/pricing" />
<link rel="alternate" hreflang="en-US" href="https://us.example.com/pricing" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/pricing" />

In the wrong example, the canonical overrides everything. Google treats the US page as a duplicate of the UK page, and the hreflang tags become meaningless.

One exception: if you genuinely have duplicate URLs (e.g., example.com/pricing and example.com/pricing/), the canonical can point to the preferred version while hreflang points to that same preferred version. The key is that hreflang URLs and canonical URLs shouldn’t contradict each other.

What Are the Most Common Hreflang Mistakes?

After auditing hundreds of international implementations, the same errors show up repeatedly:

Missing return links. The single most common failure. One regional version adds the hreflang tags, but the corresponding pages on other versions don’t reciprocate. Usually happens when different teams manage different regional sites and the hreflang implementation isn’t coordinated.

Wrong language or region codes. en-UK instead of en-GB. zh-CN when you mean simplified Chinese (which should be zh-Hans for the script, though zh-CN is widely accepted). Using three-letter codes instead of two-letter codes. Google’s validator won’t catch all of these, so check codes against the ISO standards directly.

Pointing hreflang to redirected URLs. If us.example.com/old-pricing redirects to us.example.com/pricing, your hreflang tags should reference the final destination URL. Tags pointing to URLs that 301 redirect add a processing step that can cause Google to drop the signal.

Hreflang on non-indexable pages. If a page is blocked by robots.txt, returns a 404, or has a noindex tag, hreflang tags on or pointing to that page won’t work. Every URL in an hreflang cluster needs to be crawlable and indexable.

Inconsistent URLs across methods. If your tags reference https://us.example.com/pricing but your sitemap references https://us.example.com/pricing/ (with trailing slash), that mismatch can cause Google to treat them as separate pages and invalidate the relationship.

Forgetting to update after site changes. New pages get added without hreflang. Old pages get removed without cleaning up references from other regional versions. URLs change during a migration and nobody updates the hreflang tags. This is the maintenance problem, and it’s the one that kills implementations over time.

How Do You Audit an Existing Hreflang Implementation?

A structured debugging workflow saves hours of guessing:

Step 1: Crawl all regional versions. Use Screaming Frog, Sitebulb, or Ahrefs Site Audit. Configure the crawler to follow hreflang tags and flag missing return links, non-200 status codes, and mismatched URLs. Crawl each regional subdomain or subdirectory separately, then cross-reference.

Step 2: Check Google Search Console. The International Targeting report (under Legacy tools and reports) shows hreflang errors Google has detected. It won’t catch everything, but it flags obvious issues like invalid language codes and missing return tags.

Step 3: Spot-check critical pages manually. For your top 10-20 revenue-driving pages, manually inspect the hreflang tags. View source (or check HTTP headers / sitemap entries depending on your method). Confirm every tag has a valid return link on the target page. Confirm canonicals are self-referencing. Confirm all URLs resolve to 200 status codes.

Step 4: Validate language and region codes. Cross-check every hreflang value in your implementation against the ISO 639-1 and ISO 3166-1 standards. Tools like Merkle’s hreflang tag testing tool or Ahrefs’ site audit will flag invalid codes, but a manual check against the standard catches edge cases.

Step 5: Test with live search. Search for key pages from different geographic locations (use a VPN or Google’s gl= parameter). Verify that the right regional version appears in the right market’s results. If the wrong version shows up, work backward through the hreflang chain to find the break.

Schedule this audit quarterly at minimum. Monthly if you’re actively adding pages or making structural changes. Hreflang implementations degrade over time as content changes accumulate.

How Does Hreflang Work With Subdomain vs. Subdirectory Structures?

Your international SEO site structure determines how you organize hreflang, but it doesn’t change how the tags themselves work. Whether you use subdomains (us.example.com), subdirectories (example.com/us/), or separate domains (example.us), the hreflang syntax is identical. You’re always pointing from one full URL to another full URL.

Where structure matters is in the operational complexity. With subdirectories, all hreflang tags live on the same domain, which simplifies crawling and server configuration. With subdomains or separate domains, you’re coordinating across different properties, potentially with different CMS instances, different deployment pipelines, and different teams.

The choice between subdomain and subdirectory involves trade-offs around domain authority, server configuration, and organizational structure that go beyond hreflang. We’ve covered that decision in depth in our subdomain vs. subdirectory guide.

How Do You Handle Hreflang at Scale?

Managing hreflang across 50 pages is straightforward. Managing it across 5,000 pages in 12 languages is a different problem entirely.

Automate generation. Never hand-code hreflang tags for large sites. Build a system that generates tags programmatically based on a mapping table of equivalent pages across languages. The mapping table is your single source of truth. Every deployment reads from it.

Use the sitemap method. At scale, the XML sitemap approach becomes the clear winner. It centralizes all hreflang declarations, keeps your HTML clean, and lets you update the mapping without touching individual page templates.

Build validation into your CI/CD pipeline. Before any deployment goes live, run automated checks: every URL in the hreflang map returns a 200, every relationship has a confirmed return link, all language codes are valid, no canonical conflicts exist. Catch problems before they reach production.

Monitor crawl coverage. Use Google Search Console’s index coverage reports and your crawl tool’s hreflang reports to confirm Google is processing your tags. If Google isn’t crawling certain regional sitemaps, the hreflang declarations in those sitemaps don’t exist as far as search is concerned.

Document the mapping. Maintain a clear spreadsheet or database that shows which URL maps to which equivalent across all languages. When a page is added, removed, or redirected, the mapping gets updated first. The hreflang tags follow from that source of truth.

What Do Real Implementations Look Like?

A few patterns from well-known international sites:

E-commerce (multi-region, same language). A US retailer expanding to Canada and the UK typically uses en-US, en-CA, and en-GB. Pages share much of the same content but differ in currency, shipping information, and regulatory details. Hreflang prevents Google from collapsing these into duplicates. The US version usually serves as x-default.

SaaS (multi-language). A software company with English, Spanish, French, German, and Japanese versions. Each language has its own subdirectory. Hreflang relationships connect equivalent pages across all five languages. The complexity here is maintaining parity. When a new feature page launches in English, it needs corresponding pages (even placeholder ones) in all other languages, or the hreflang cluster is incomplete.

Media/publishing (regional editions). News sites with US, UK, and Australian editions in English. Content overlap is lower because each edition produces region-specific articles. Hreflang only applies to shared content (about pages, subscription pages, evergreen reference content). Regional news articles don’t need hreflang because they don’t have equivalents.

The pattern is consistent: hreflang works best when you have genuine page-level equivalents across regions or languages. Applying it to pages that don’t have true counterparts creates maintenance burden with no benefit.

How Do You Maintain Hreflang Over Time?

Implementation is the easy part. Maintenance is where most setups fall apart.

Build hreflang into your content workflow. Every new page triggers a check: does this page have equivalents in other languages or regions? If yes, add it to the hreflang mapping. If no, skip it. This needs to be a step in your publishing process, not an afterthought.

Handle page removals cleanly. When you remove or redirect a page, update the hreflang references on every page that pointed to it. A broken link in an hreflang cluster doesn’t just affect that one tag. It can cause Google to distrust the entire cluster for that page set.

Track coverage as a metric. Monitor the percentage of your indexed pages that have valid, complete hreflang implementations. If that number drops, investigate. It usually means new pages are being published without hreflang, or site changes have broken existing tags.

Assign ownership. Hreflang breaks when nobody owns it. Assign a person or team responsible for the mapping, the validation, and the quarterly audit. Without clear ownership, the implementation degrades silently until someone notices the wrong country version ranking in their primary market.

Getting Hreflang Right Is an Investment in International Revenue

Hreflang isn’t glamorous. It’s a technical implementation detail that most of your stakeholders will never see or understand. But for any business operating across languages or regions, it’s the mechanism that ensures your localized content reaches the right audience.

Get it right, and your international pages rank in their intended markets, users land on the version built for them, and your regional SEO investments compound instead of competing with each other. Get it wrong, and you’re spending money on localization that Google can’t properly serve.

The work isn’t in writing the tags. It’s in maintaining them. Build the mapping, automate the generation, validate on every deployment, and audit regularly. That’s the difference between hreflang that works on launch day and hreflang that still works a year later.

If you’re building out international SEO and need help getting the technical foundation right, get in touch with our technical SEO team. We’ll audit what you have, fix what’s broken, and build a system that scales with your business.