AXOX Hub Hub
Seo Sep 14, 2026 5 min read

Hreflang Tags: Why Your International SEO Still Isn't Working

Hreflang tags for international SEO fail silently more often than they work. Learn the exact mistakes, syntax rules, and fixes that actually matter.

Most sites that "support multiple languages" have hreflang tags somewhere in their code. Most of those implementations are broken in at least one way — and Google usually won't tell you. It just quietly ignores the tag and serves whatever page it thinks is best, which is often not the one you intended for that user's language or region.

If you've published translated or regional pages and you're still seeing the wrong version rank in the wrong country, this is almost always a hreflang problem, not a content problem.

What Hreflang Actually Does (and Doesn't Do)

Hreflang is an annotation, not a redirect. It tells search engines: "this page has an equivalent version in this other language/region — here's the URL." It does not:

  • Force a redirect for users
  • Translate content for you
  • Boost rankings on its own
  • Fix duplicate content issues by itself

It's purely a signal that helps Google pick the right URL to show in search results for a given language/region combination. If the signal is malformed, Google discards it and falls back to its own judgment.

The Three Places You Can Implement Hreflang

  1. HTML head tags — <link rel="alternate" hreflang="x" href="y"> inside <head>
  2. HTTP headers — useful for non-HTML files like PDFs
  3. XML sitemap — annotations inside <url> entries, good for large sites

Pick one method per site and stick to it. Mixing HTML tags on some pages and sitemap annotations on others is a common source of conflicting signals.

Correct HTML Syntax

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

Every one of these tags must appear on every page in the set — including a self-referencing tag on the page it's placed on. This is the rule people forget most often.

The Mistakes That Break Hreflang Silently

1. Missing Return Tags

If your /us/ page points to /uk/, the /uk/ page must point back to /us/. If the return link is missing, Google treats the whole annotation as unreliable and may ignore it entirely. This is the single most common hreflang failure across enterprise sites.

2. Using the Wrong Language/Region Codes

  • Language codes must follow ISO 639-1 (e.g. en, fr, de)
  • Region codes must follow ISO 3166-1 Alpha 2 (e.g. US, GB, CA) — not ISO 3166-1 Alpha 3, and not made-up codes like uk for the United Kingdom (the correct code is gb)
  • Region is optional, language is not — hreflang="us" alone is invalid

3. Pointing to Non-Canonical or Redirecting URLs

Hreflang URLs should be the final canonical URL, not a URL that 301s somewhere else, not a URL with tracking parameters, and not a URL blocked by robots.txt. If the target URL redirects, Google has to follow the chain to resolve the signal — and often just drops it instead.

4. Hreflang Conflicting with Canonical Tags

Each page in a hreflang set should self-canonicalize. If your /fr/ page has a canonical tag pointing back to /us/, you're telling Google "this page doesn't really exist independently" while your hreflang tag says "this is the correct page for French users." Those two signals contradict each other and canonical usually wins, which quietly kills your international targeting.

5. Forgetting x-default

x-default tells Google which page to show users whose language/region doesn't match any of your defined variants. Without it, you're leaving that fallback decision entirely to Google's algorithm.

A Quick Workflow to Audit Your Hreflang Setup

  1. Pull the full list of URLs in your language/region set
  2. Check every page for a self-referencing hreflang tag
  3. Verify return tags exist in both directions for every pair
  4. Confirm all URLs are canonical, not redirecting, and not noindexed
  5. Check language/region codes against ISO standards
  6. Make sure there's exactly one x-default per set

You can speed up steps 2–5 considerably by running each URL through AXOX Hub's Meta Tag Analyzer, which pulls the raw head tags — including hreflang annotations and canonical tags — so you can visually spot mismatches between pages without digging through page source manually for every locale.

Hreflang in Sitemaps: When It's the Better Choice

If you're managing dozens of locale variants per page, sitemap-based hreflang is usually cleaner than stuffing dozens of link tags into every page head. The structure looks like this:

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

The same return-tag rule applies — every URL entry needs to reference every other URL in the set, including itself.

Subdomains, Subdirectories, or ccTLDs?

Hreflang works identically regardless of URL structure, but the structure still affects how much authority consolidates:

  • ccTLDs (example.fr) — strongest geo-targeting signal, but you split domain authority across separate domains
  • Subdirectories (example.com/fr/) — easiest to maintain, authority stays consolidated
  • Subdomains (fr.example.com) — a middle ground, but treated closer to separate sites by some crawlers

If you're choosing a structure from scratch for a new international rollout, subdirectories combined with correctly implemented hreflang is usually the lowest-maintenance option for small and mid-sized teams.

Validate Before You Deploy at Scale

Before rolling hreflang out across hundreds of URLs, test the pattern on a handful of representative pages first. Check the rendered HTML (not just the template source — some CMSs strip or duplicate tags at render time), confirm return tags resolve correctly, and re-check after any CDN or caching layer changes, since stale cached HTML is a frequent cause of hreflang tags silently reverting to an old version.

Run your key locale pages through the free Meta Tag Analyzer at AXOX Hub to confirm exactly what search engines are seeing in your head tags — it's the fastest way to catch a broken hreflang pair before it costs you rankings in another country.

Try the free tool

Open Tool
← Back to Blog