Hreflang and x-default for International SEO: When You Actually Need Them

Pedro Dias Last updated:  ~9 min read

Most sites don't need hreflang. When regional targeting matters, what x-default actually signals, and how to avoid common implementation mistakes.

What hreflang does and doesn't do

Hreflang tells search engines which version of a page to serve based on a user's language or region. It connects alternate versions of content—linking your English page to your German equivalent, or your Brazilian Portuguese page to your European Portuguese variant.

What hreflang does not do is teach search engines to identify languages. Google, Bing, and AI systems already detect languages with high accuracy. They analyse page content, HTML lang attributes, and contextual signals. A French page doesn't need hreflang to appear in French search results—search engines will recognise it as French.

This distinction matters because it clarifies when hreflang adds value versus when it's unnecessary overhead.

When you actually need hreflang

Hreflang solves a specific problem: distinguishing between pages that share the same language but target different regions.

Consider a site with these pages:

  • /en-us/: English for US audiences
  • /en-gb/: English for UK audiences
  • /en-au/: English for Australian audiences

Without hreflang, search engines see three English pages. They'll index all of them, but they may not serve the UK version to UK searchers or the Australian version to Australian searchers. Hreflang signals which regional variant belongs where.

The same applies to:

  • pt-BR vs pt-PT (Brazilian vs European Portuguese)
  • es-MX vs es-ES (Mexican vs European Spanish)
  • zh-Hans vs zh-Hant (Simplified vs Traditional Chinese)

The Chinese script distinction

Chinese presents a unique case: the primary distinction is script (Simplified vs Traditional), not country. While zh-CN and zh-TW technically work, they conflate script with geography in ways that can cause problems.

Script-based codes (recommended):

  • zh-Hans: Simplified Chinese (used in mainland China, Singapore, Malaysia)
  • zh-Hant: Traditional Chinese (used in Taiwan, Hong Kong, Macau)

Country-based codes (less precise):

  • zh-CN: Chinese for China (implies Simplified)
  • zh-TW: Chinese for Taiwan (implies Traditional)
  • zh-HK: Chinese for Hong Kong (implies Traditional)

The issue with country codes: a user in Singapore reads Simplified Chinese, but zh-SG isn't commonly implemented. A user in the US might read Traditional Chinese if they're from a Taiwanese background. Script-based codes (zh-Hans, zh-Hant) target the actual differentiator—how the text is written—rather than assuming script from location.

Use zh-Hans and zh-Hant unless you have genuinely different content for specific countries (different pricing for China vs Taiwan, for example). If you do need country-level targeting, combine script and region: zh-Hans-CN, zh-Hant-TW.

Note: If your site only has one version per language—French, German, Spanish—you probably don't need hreflang. Search engines already know what language your content is in. Hreflang becomes valuable when you need to differentiate regional variants of the same language.

The single-language scenario

If you have:

  • /fr/: French content
  • /de/: German content
  • /es/: Spanish content

You don't need hreflang. Google will detect the French page as French and serve it to French-language searchers. The German page will appear in German results. This happens automatically through content analysis.

Hreflang in this scenario adds implementation complexity without corresponding benefit. You're solving a problem that doesn't exist.

When hreflang becomes essential

Hreflang is essential when:

  1. Same language, different regions: You have en-US and en-GB pages, or pt-BR and pt-PT, where the content differs by locale
  2. Pricing and currency differences: Regional pages show different currencies, pricing, or availability
  3. Legal or regulatory variations: Content changes due to regional compliance requirements
  4. Significantly different content: Regional pages aren't translations—they're distinct content created for each market

Without hreflang in these cases, search engines may show users the wrong regional variant, leading to confusion over pricing, shipping, or relevance.

The x-default confusion

x-default is the most misunderstood element of hreflang implementation. Many sites implement it incorrectly or unnecessarily.

What x-default actually signals

x-default tells search engines: "If the user's language or region doesn't match any of my specified hreflang variants, show them this page."

It's a fallback—not a default homepage, not a "main" language, not a language selector.

When you need x-default

You need x-default if you have a language-agnostic landing page that lets users select their region.

Consider this structure:

  • example.com/: Language selector page (no specific language)
  • example.com/en-gb/: UK English
  • example.com/en-us/: US English
  • example.com/de/: German
  • example.com/fr/: French

The root domain (example.com/) isn't content in any specific language—it's a gateway that asks users to choose. This page should be marked as x-default:

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

When a user searches from a location or language you don't serve (say, Japanese), Google shows them the x-default page—your language selector—rather than arbitrarily picking one of your language variants.

When you don't need x-default

If you don't have a language-agnostic selector page, you probably don't need x-default.

Many sites designate their English version as x-default because "English is our fallback." This misunderstands the purpose. If your English page is actual English content—not a language selector—it shouldn't be x-default. It should be hreflang="en" (or en-US, en-GB, etc.).

Warning: Using x-default on a page that contains language-specific content sends a confusing signal. The page says "I'm the fallback for all languages" while actually being in English. This can cause ranking issues in multilingual scenarios.

x-default as a genuine fallback language

There's one other valid use for x-default: when you want to signal which language version should serve users whose language you don't support.

If your site has:

  • English (en)
  • German (de)
  • French (fr)

And a user searches in Dutch (which you don't support), you might want them to see your English content rather than having Google make an arbitrary choice. In this case, you can use x-default on your English pages:

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

Note that hreflang="en" and hreflang="x-default" point to the same URL. This tells Google: "For English users, serve the English page. For users whose language I don't support, also serve the English page as the fallback."

This is valid, but only necessary if you have a strong reason to influence fallback behaviour. In most cases, letting Google choose a fallback works fine.

Implementation patterns

Pattern 1: Regional variants of the same language

You have en-US, en-GB, and en-AU content:

<link rel="alternate" hreflang="en-us" href="https://example.com/en-us/page/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/page/" />
<link rel="alternate" hreflang="en-au" href="https://example.com/en-au/page/" />

x-default is optional here. Add it only if you have a language selector or want to specify a fallback for non-English users.

Pattern 2: Multiple languages, no regional variants

You have English, German, and French content:

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

This is often unnecessary. Search engines will identify and serve each language version correctly based on content analysis. Hreflang here is harmless but adds maintenance burden.

Pattern 3: Language selector with hreflang

You have a root language selector and regional content:

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

The x-default points to your region selector, ensuring users from unsupported regions see a choice rather than arbitrary content.

HTML vs XML sitemap implementation

Hreflang can be implemented in three ways: HTML <link> elements in the <head>, XML sitemaps, or HTTP headers. Each page in a language cluster must declare all its alternates—including itself.

When HTML becomes unwieldy

For a page with 5 language variants, you need 5 <link> elements per page. Manageable. But consider a site with 25 language/region combinations: every page now carries 25 hreflang declarations in the HTML head.

<!-- 25 variants means 25 link elements on every page -->
<link rel="alternate" hreflang="en-us" href="..." />
<link rel="alternate" hreflang="en-gb" href="..." />
<link rel="alternate" hreflang="en-au" href="..." />
<!-- ... 22 more ... -->

This adds significant weight to every page load. For sites with many variants, XML sitemap implementation is cleaner:

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

Benefits of XML sitemap implementation

  • Reduced page weight: No additional markup in the HTML head
  • Centralised management: All hreflang declarations in one place, easier to audit and update
  • Separation of concerns: Content templates don't need internationalisation logic
  • Easier automation: Sitemaps can be generated programmatically from a URL mapping database

When to use each method

Scenario Recommended method
Fewer than 10 variants HTML or XML (either works)
10+ variants XML sitemap
Dynamic/JS-rendered pages XML sitemap (more reliable for crawlers)
HTTP headers available HTTP headers for non-HTML resources (PDFs)
Warning: Choose one implementation method and stick to it. Mixing methods—declaring some hreflang in HTML and others in XML sitemaps—creates confusion. Search engines may process them inconsistently, and debugging becomes difficult when signals come from multiple sources. If you find hreflang declarations in both places, consolidate to one method.

Common mistakes

Treating x-default as "primary language"

x-default doesn't mean "main version." It means "fallback when no language matches." If your English page is content, not a selector, use hreflang="en", not hreflang="x-default".

Implementing hreflang for single-language content

If you only have one French page, one German page, one Spanish page—no regional variants—hreflang is unnecessary overhead. Search engines detect languages automatically.

Forgetting bidirectional linking

Hreflang must be reciprocal. If page A declares page B as an alternate, page B must declare page A. Missing return links break the signal.

Mixing language-only and language-region codes

Be consistent. If you use en-US and en-GB, don't also use plain en for a third English version. Decide whether you're targeting languages or regions and implement accordingly.

Using multiple implementation methods

Implementing hreflang in both HTML and XML sitemaps for the same pages creates redundancy and potential conflicts. If the declarations don't match exactly, search engines receive mixed signals. Pick one method—typically XML for large sites, HTML for smaller ones—and use it consistently across all pages.

Tip: Validate your hreflang implementation with third-party tools like Ahrefs, Screaming Frog, or Sitebulb. Google deprecated Search Console's International Targeting report, so external crawlers are now the primary way to catch missing return links, incorrect codes, or conflicting signals.

FAQs

Do I need hreflang if I only translate into different languages?

Not necessarily. If you have one page per language (French, German, Spanish) without regional variants, search engines will identify each language automatically. Hreflang is most valuable when distinguishing regional variants of the same language.

Should I set x-default to my English pages?

Only if you genuinely want English to be the fallback for users whose language you don't support. If your English pages are language-specific content rather than a language-neutral selector, using x-default on them can be misleading.

Can I use x-default without other hreflang tags?

Technically yes, but it makes little sense. x-default is a fallback—it only matters when other hreflang variants exist. Without other variants, there's nothing to fall back from.

Does hreflang help with AI systems and LLMs?

AI systems detect language from content, not hreflang tags. Hreflang is a search engine signal for serving regional variants. It has no known effect on how AI systems process or retrieve content.

Key takeaways

  1. Hreflang solves regional targeting, not language detection: Search engines already identify languages. Hreflang is valuable when you have regional variants of the same language (en-US vs en-GB, pt-BR vs pt-PT).

  2. x-default is a fallback, not a primary designation: Use it for language-agnostic selector pages or to specify which version users see when their language isn't supported. Don't use it on language-specific content.

  3. Simpler is often better: Single-language content per market doesn't need hreflang. Adding it increases maintenance burden without corresponding benefit.

  4. Validate implementation: Hreflang errors are silent failures. Use third-party crawlers (Ahrefs, Screaming Frog, Sitebulb) to catch missing return links, incorrect codes, or conflicting signals.

Further reading

✎ Original content researched and drafted by the author. AI tools may have been used to assist with editing and refinement.

Share this article

Your Brand, VISIVELY!