x-default is a fallback annotation for an alternate-language set. Use it when you have a sensible page for visitors whose browser language or region does not match one of the versions you explicitly provide. It is optional. It is not a tag that every international page needs by default.

That distinction matters because x-default is often treated as a universal hreflang requirement. Google instead describes it as the value for unmatched language or region settings, with particular use for language selectors and fallback pages. A site with only one language version does not create a multi-language setup by adding x-default. Google: localized versions of pages

This guide explains when the annotation is useful, how it differs from a canonical URL, and how to validate an entire alternate set before you rely on it.

// NARRATED SUMMARY

Listen to the summary

Hear the main decisions in 1 minute 25 seconds. The full article is authoritative.

Read the exact audio transcript

H ref lang x-default is a fallback for visitors whose language or region does not match the versions you explicitly provide. It is optional. A one-language site does not become international just because someone added the tag.

Start with the reader path. Decide which page should handle an unmatched visitor, such as a language selector or a neutral landing page. Keep canonical tags focused on the preferred URL for duplicate content. H ref lang serves a different job: it connects localized alternatives.

Validation should examine the declared alternate set, not one line in isolation. Use supported language and region values, include each page in its own alternate set, and make sure each declared relationship is reciprocal. Google recommends complete sets. When maintaining a full set becomes difficult, Google can process partial sets, so do not assume every possible page must link to every other page. What matters is that the pairs you declare point back correctly.

Then check the rendered HTML, HTTP headers, or sitemap where the annotations actually live. A tidy spreadsheet cannot rescue a broken implementation. The practical rule is simple: choose the fallback intentionally, declare only real alternates, and test the complete path a crawler and visitor will encounter.

This is an untimed transcript. No synchronized captions are claimed.

Start with the reader path, not the tag

Before writing any annotations, answer one practical question: where should a visitor go when none of the localized pages is a good match?

x-default makes sense when that answer is a real, reachable page, such as:

  • A country or language selector.
  • A generic English page when you publish only regional English versions.
  • A stable fallback page for an international homepage that otherwise routes people by language or region.

It is less useful when the answer is unclear. Do not point it at a page simply because it exists. First confirm that the page is an appropriate fallback for an unmatched visitor and that it is part of the same alternate set.

Google's own explanation gives the example of English and Spanish pages with an x-default that points to English for French-language users. It also notes that sites can annotate only the parts of a site that have localized versions. Google: how x-default can help you

Hreflang and canonical answer different questions

These annotations work together, but they do different jobs.

  • rel="canonical" identifies the URL you want treated as the preferred URL for substantially duplicate content.
  • rel="alternate" hreflang="..." identifies language or regional variants of the same content so a search engine can better match a variant to a searcher's language preferences.

Do not try to combine those purposes in one tag. Google says that a canonical annotation carrying hreflang is ignored for canonicalization. Use a canonical annotation for canonicalization and a separate alternate annotation for language and country variants. Google: consolidating duplicate URLs

In practice, validate canonical URLs before adding hreflang. If a supposed alternate canonicalizes elsewhere, the alternate set is not describing a clean set of equivalent, indexable pages.

An illustrative reciprocal set

The following is an invented example. The domains and paths are placeholders, not a live configuration to copy without checking your own URL structure.

<!-- Place the same complete alternate set in the <head> of every variant. -->
<link rel="alternate" hreflang="en-gb"
      href="https://example.test/uk/pricing" />
<link rel="alternate" hreflang="en-au"
      href="https://example.test/au/pricing" />
<link rel="alternate" hreflang="en"
      href="https://example.test/pricing" />
<link rel="alternate" hreflang="x-default"
      href="https://example.test/choose-region" />

Every page in this example needs the full set, including its own URL. The en page serves readers who use English but do not match the explicitly regional en-gb or en-au pages. The selector is the x-default fallback for unmatched settings. The selector is a good target only if it actually lets a visitor choose a useful destination.

Google requires fully qualified alternate URLs and says that variants should reference one another. It may ignore an annotation when pages do not point back to each other. Google: localized versions of pages

The complete four-URL set above is the clearest pattern for this example. Google also says it can process partial sets when a complete set becomes difficult to maintain. If you add localized versions over time, make each newly declared relationship reciprocal. Do not treat the maintenance exception as permission to publish one-way annotations.

Choose language and region values deliberately

An hreflang value describes the language, and optionally a region. A generic en is different from en-GB or en-AU: the former is a language-level fallback while the latter target English readers in named regions. Use Google's supported language and region values, for example en-GB, not an invented country code such as en-UK.

Use a region only when the page is meaningfully localized for that region. Avoid creating regional labels for pages with no regional difference. For scripts, such as simplified and traditional Chinese, choose the appropriate script value where that distinction is needed. Google's supported-value list controls the values it accepts for hreflang; RFC 5646 explains the underlying language-tag syntax. Google: localized versions of pages and RFC 5646: Tags for Identifying Languages

This is a content-equivalence decision before it is a markup decision. A local price, local shipping policy, translated copy, or regional legal information may justify a variant. A URL pattern alone does not.

A validation checklist

Run this list for each localized page group, not just for the homepage.

  1. List the intended variants. Record every canonical URL, the language or language-region value, and the intended fallback destination.
  2. Confirm equivalent purpose. Check that each page represents the same content or offering for its intended audience. Do not place unrelated pages in one alternate set.
  3. Confirm each page's final canonical URL. The URL used in hreflang should be the complete, final intended canonical URL. Do not cite a relative path, tracking URL, or a URL that redirects before reaching the intended page.
  4. Check self-references. Every variant should include its own language entry in the set.
  5. Check reciprocal references. If the UK page links to the Australian page, the Australian page should link back to the UK page. Apply the same check to every other pair in the group.
  6. Check the language values. Use a valid language tag, then add a script or region only where the page warrants it.
  7. Check x-default separately. If present, make sure it points to a usable selector or true fallback. If no such page exists, omit it instead of inventing a fallback role.
  8. Check the implementation surface. Google supports HTML link elements, HTTP Link headers, and sitemap annotations. Pick the approach you can maintain consistently, then inspect the rendered or returned annotations that search engines can access.

The last step protects against a common operational failure: a perfectly designed set in a spreadsheet that is absent, partial, or inconsistent on the pages themselves.

Where a focused audit helps

For a site that already has alternate pages, a focused review should examine the resources it can actually retrieve: page HTML, headers, and, where used, sitemaps. The existing Hreflang Audit for International SEO page describes checks for self-references, reciprocal links, language and region codes, and canonical alignment.

That is a narrower task than a general technical audit. If you need to assess crawlability, indexability, security headers, mobile issues, structured data, and other site-wide conditions as well, use the broader technical SEO audit with Claude Code as the appropriate starting point.

An audit can identify a markup or retrieval problem. It cannot prove that a search engine will select a particular regional result, nor does it replace a review of whether the pages genuinely serve different audiences.

The practical rule

Use x-default when you have a real fallback for a well-defined set of localized pages. Keep it optional when you do not. Build complete reciprocal alternate sets with fully qualified canonical URLs, and keep canonicalization separate from language targeting.

That produces a configuration a developer can validate, a content owner can explain, and a visitor can use when their preferred locale is unavailable.

// SOURCES

Sources