Hreflang x-default: What It Means and How to Use It Correctly
The x-default value in hreflang is the most misunderstood part of international SEO. It is not your homepage. It is not a synonym for English. It is not optional in the way most teams assume. This guide covers exactly what x-default means, where it belongs, the patterns that quietly break it, and how to verify it before you push to production.
What hreflang x-default Actually Means
The hreflang="x-default" attribute is a fallback signal. It tells search engines which URL to serve to users whose browser language and inferred region do not match any of the language/region pairs you have declared in your other hreflang annotations. It is the "none of the above" option.
Google introduced x-default in 2013 specifically to handle automatic redirect landing pages — the kind of generic entry point a global brand uses to detect a visitor's location and bounce them to the right localized version. Over the years its usage broadened, and today most international sites use x-default as a generic catch-all even when no IP-based redirect is involved.
The critical thing to internalize is the directionality of the signal. x-default does not say "this is the default page of my site." It says "for users not covered by any of my other hreflang alternates, send them here." The targeting is defined by exclusion, not inclusion.
Where to Put x-default: Three Valid Locations
Google accepts hreflang annotations — including x-default — in three places. Pick one and stick to it across the entire site. Mixing methods within the same cluster causes silent indexing inconsistency.
1. HTML head <link> tags. The most common implementation. Each page in the cluster outputs the full set of alternates, including a self-reference and exactly one x-default:
<!-- Goes inside <head> on every page in the cluster --> <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="de-de" href="https://example.com/de/" /> <link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/" /> <link rel="alternate" hreflang="es-es" href="https://example.com/es/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" />
2. XML sitemap xhtml:link annotations. Best for sites with hundreds or thousands of localized URLs where putting hreflang in the head bloats every page. Note the xhtml namespace declaration on the <urlset> root and the explicit x-default entry per <url> block:
<?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://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="de-de" href="https://example.com/de/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/" />
</url>
<url>
<loc>https://example.com/uk/</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="de-de" href="https://example.com/de/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/" />
</url>
</urlset>3. HTTP Link response header. Used for non-HTML files like PDFs where you cannot put a <link> tag in a head. Send the full set of alternates as a single Link header (or comma-joined headers):
HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <https://example.com/whitepaper-en.pdf>; rel="alternate"; hreflang="en-us",
<https://example.com/whitepaper-de.pdf>; rel="alternate"; hreflang="de-de",
<https://example.com/whitepaper-fr.pdf>; rel="alternate"; hreflang="fr-fr",
<https://example.com/whitepaper-en.pdf>; rel="alternate"; hreflang="x-default"Whichever method you choose, do not duplicate hreflang signals across two methods for the same URL. If your sitemap declares hreflang and your pages also declare hreflang in the head, Google has to reconcile them — and when they disagree, the entire cluster gets flagged as inconsistent. See our hreflang sitemap guide for the full sitemap-only workflow.
x-default for IP-Based Redirect Landing Pages
The original use case for x-default — and still its strongest application — is the redirect landing page. If your root domain https://example.com/ performs IP-based or Accept-Language-based detection and redirects users to /us/, /de/, or /fr/, that root URL is a perfect x-default target.
The reason it works is that Googlebot, which crawls primarily from US IPs but does not honor the redirect for indexing purposes, sees the root URL as a meta-page that exists to disambiguate users. Declaring it as x-default tells Google: "index this URL as the catch-all entry point; the redirect logic will handle the user."
If your root URL is a real localized homepage (say it is the US version and there is no /us/ subdirectory), you can still declare it as x-default — but you also need to declare it with hreflang="en-us". The same URL can serve two roles, and that is allowed.
<!-- Root URL serves both en-us users AND unmatched fallback --> <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="de-de" href="https://example.com/de/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" />
x-default and Canonical Tag Interaction
This is where most teams get into trouble. Hreflang and canonical operate in different dimensions and should not contradict each other. The rule is straightforward: each localized page should self-canonical, and the hreflang annotations point to the alternates. The x-default URL has its own self-canonical too.
What breaks: declaring hreflang="x-default" pointing to https://example.com/ on every localized page, while simultaneously canonicalizing every localized page to https://example.com/. The canonical says "these are duplicates of the root," which means Google drops them from the index entirely — at which point the hreflang cluster collapses because the alternates no longer exist as indexed URLs.
Correct setup for a German page in a multi-locale cluster:
<!-- On https://example.com/de/ --> <link rel="canonical" href="https://example.com/de/" /> <link rel="alternate" hreflang="en-us" href="https://example.com/us/" /> <link rel="alternate" hreflang="de-de" href="https://example.com/de/" /> <link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" />
For the deeper rules on how these two systems interact, see our hreflang and canonical relationship guide.
Common Wrong Patterns
The vast majority of broken x-default implementations come from the same handful of mistakes. Audit your site against this list:
Wrong pattern 1: multiple x-default declarations in the same cluster. If page A declares x-default pointing to example.com/ and page B (in the same cluster) declares x-default pointing to example.com/uk/, the cluster is malformed. Each cluster needs exactly one x-default URL, and every page in the cluster must declare the same x-default URL.
<!-- WRONG: two different x-default URLs in one head --> <link rel="alternate" hreflang="x-default" href="https://example.com/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/us/" /> <!-- ALSO WRONG: same cluster, different page declares different x-default --> <!-- example.com/de/ says x-default = example.com/ --> <!-- example.com/fr/ says x-default = example.com/uk/ -->
Wrong pattern 2: x-default pointing to a localized page with conflicting hreflang. Pointing x-default to /de/ while also declaring hreflang="de-de" for the same URL is allowed only when that German page is genuinely intended as the global fallback. If you do this for a non-English locale, an unmatched user from, say, Brazil will land on a German page — which is rarely what teams actually want.
Wrong pattern 3: omitting x-default from some pages in the cluster. Hreflang requires the full set of alternates on every page in the cluster. If 9 of your 10 locale pages declare x-default and one does not, the orphan page breaks the bidirectional linkage Google requires. Either every page in the cluster has x-default or none of them do (and none is fine — x-default is optional).
Wrong pattern 4: x-default pointing to a noindex, redirect, or 404 URL. The x-default target must be a 200 OK, indexable page. If your "default" URL is a redirect that bounces to a localized page, Google sees the redirect chain and drops the x-default signal. If it noindexes, Google treats the cluster as missing a fallback. Always verify the x-default target with URL Inspection.
Wrong pattern 5: confusing x-default with a language code. hreflang="x-default" is the literal string. It is not hreflang="default", not hreflang="xdefault", not hreflang="en-default". Any other variant is silently ignored.
How Google Actually Handles x-default
A few non-obvious rules from Google's public statements and observed behavior:
x-default is not the homepage by default. If you do not declare x-default at all, Google does not silently treat your homepage as the fallback. It uses other signals — ccTLD, server location, Search Console country targeting, and the user's language settings — to pick which page to show, and the choice is unpredictable per query. Declaring x-default explicitly is the only way to control the fallback.
x-default is optional, but recommended for any multi-locale site. If you genuinely have full coverage (your site has versions for every language Google might encounter), you can skip it. In practice no site has that, so always declare it.
x-default does not influence ranking. It only influences which URL Google serves to a specific user when none of the language alternates match. The ranking signals consolidate at the cluster level the same way regardless of which page in the cluster gets shown.
x-default can point to the same URL as one of the language alternates. This is the standard pattern when you have a global English page that doubles as the catch-all. Both hreflang="en" (or en-us) and hreflang="x-default" can point to the same URL on the same line of declarations.
x-default and Bing. Bing also supports hreflang and respects x-default in the same way. Yandex similarly. So while x-default is most associated with Google, the implementation is search engine agnostic.
Pre-Launch Testing Tools
Test x-default before you push to production. Three tools cover the bases:
Google's Rich Results Test and URL Inspection. URL Inspection (inside Search Console) is the authoritative source — it shows exactly which hreflang alternates Google has indexed for the URL, including x-default. Rich Results Test renders the page with Googlebot and shows the rendered head, useful for catching JavaScript-injected hreflang that Google does not pick up.
Merkle hreflang tester. Free at technicalseo.com/tools/hreflang/. Paste a URL, the tool fetches it, parses the hreflang annotations, and verifies bidirectional linkage across the cluster. It will flag duplicate x-default, missing return links, and language code typos.
Screaming Frog with hreflang configuration. Crawl your site and enable Configuration → Spider → Crawl Behaviour → Crawl Hreflang. The Hreflang tab then surfaces all clusters and flags issues including missing x-default, missing return links, inconsistent x-default across the cluster, and non-canonical URLs in hreflang annotations.
For a manual command-line check on a single URL:
# Extract every hreflang declaration from a page
curl -s https://example.com/de/ | \
grep -oE 'hreflang="[^"]+"[^>]+href="[^"]+"'
# Check that exactly one x-default exists
curl -s https://example.com/de/ | grep -c 'hreflang="x-default"'
# Expected output: 1
# Confirm the x-default target returns 200
TARGET=$(curl -s https://example.com/de/ | \
grep -oE 'hreflang="x-default"[^>]+href="[^"]+"' | \
grep -oE 'https?://[^"]+')
curl -o /dev/null -s -w "%{http_code}\n" "$TARGET"
# Expected output: 200Debugging x-default in GSC International Targeting
Google Search Console used to have a dedicated International Targeting report under Legacy Tools that surfaced hreflang errors at the cluster level, including x-default issues. That report has been deprecated in the modern GSC interface, and hreflang debugging now happens primarily through URL Inspection.
To debug an x-default issue in current GSC:
Step 1: URL Inspection on a representative cluster URL. Enter one of your localized pages. Expand the "Page indexing" section. The "Referring page" and the response headers do not surface hreflang directly, but the "View crawled page" → "HTML" tab shows exactly the markup Googlebot received. Search for x-default in that HTML and confirm the URL is correct and present.
Step 2: Live test. Click "Test Live URL" in URL Inspection. This renders the page right now and shows the current hreflang state, which is critical when you have just deployed a fix and want to confirm it without waiting for a recrawl.
Step 3: Cross-check the alternates. Run URL Inspection on each alternate URL in the cluster. Every page should declare the same x-default. Inconsistent x-default declarations across the cluster are the single most common cause of "Google ignored my hreflang" complaints.
Step 4: Look for "Duplicate, Google chose different canonical" on the x-default URL. If the URL you have declared as x-default is itself being canonicalized to a different URL by Google, the x-default signal effectively redirects to that canonical — which often is not what you want. Fix the canonical first, then the x-default behavior follows.
For broader hreflang error diagnosis, see our hreflang errors guide, and for the rules on self-references that complement x-default, see self-referencing hreflang.
x-default Implementation Checklist
Before you ship a hreflang implementation that includes x-default:
1. Pick exactly one x-default URL per cluster. Document which URL it is. The most common choice is the language-neutral root or the global English version.
2. Declare x-default on every page in the cluster, identically. Same URL, same casing, same trailing slash treatment, same protocol.
3. Confirm the x-default URL returns 200 OK and is self-canonical. Not a redirect, not noindex, not blocked by robots.txt.
4. Pick one declaration method (head, sitemap, or HTTP header). Do not mix.
5. Validate with Merkle hreflang tester or Screaming Frog before deployment. A single tool run catches 90% of issues.
6. Spot-check with URL Inspection after deployment. Pick five representative URLs across the cluster and verify Google sees what you intended.
SitemapFixer can crawl your sitemap and surface every hreflang inconsistency including missing or duplicate x-default annotations across the entire cluster — useful for sites with hundreds of locale URLs where manual auditing breaks down.