What x-default Actually Promises Google
The x-default value is the single most misunderstood part of the hreflang specification. Most teams add it because a checklist told them to, copy the syntax from a blog post, and never verify what they shipped. Then a user in Warsaw searching in Polish lands on the German storefront, the conversion rate for unhandled locales quietly underperforms, and nobody connects the dots back to a malformed fallback tag. Google introduced x-default in 2013 specifically to answer one question — which URL should I send a user to when none of my explicit language or region alternates match their query? — and the value only does its job if the tag is syntactically valid, reciprocated, and pointed at the right destination.
Per Google Search Central's documentation on localized versions ("Tell Google about localized versions of your page"), x-default is described as the page for users whose language settings do not match "any other listed language." It is not a ranking signal and it is not a substitute for a proper language alternate. It is a routing fallback. This article walks through the eight mistakes that make x-default silently fail, why each one breaks, and the exact fix — validated the same way the browser-only Hreflang Checker validates it. If you want the broader system around it first, read the companion field guide to hreflang tags.
Mistake 1 — Treating x-default Like a Language Code
The most frequent error is mental, not syntactic. Engineers see en, es, fr and assume x-default is just another locale in the list. It is not. Per BCP 47 (RFC 5646, "Tags for Identifying Languages"), x-default is not a valid language tag at all — the x- prefix denotes a privateuse subtag, and a bare x-default would be rejected by a strict BCP 47 parser. Google deliberately reserves it as a sentinel value, exempt from the ISO 639-1 and ISO 3166-1 validation that every real locale must pass.
The practical consequence is that you cannot have two x-default entries in a cluster pointing at different URLs and expect Google to "pick the best one." There is exactly one fallback per cluster. The fix is conceptual discipline — think of x-default as the "everyone else" door, not as a language. A validator that understands the sentinel will accept x-default while rejecting an invented locale like en-UK; one that does not will flag x-default as an invalid locale, which is itself a sign your tooling is wrong.
Mistake 2 — Forgetting the Return Tag on x-default
Hreflang clusters are bidirectional. Every URL in a cluster must reference every other URL, and that rule applies to x-default exactly as it applies to fr-CA or pt-BR. The classic failure looks like this — the English, Spanish, and French pages each declare an x-default pointing at /en/, but the page serving as the x-default target does not declare itself as x-default. Google sees a one-way reference, treats the annotation as unconfirmed, and discards it.
If your x-default destination is the English homepage, then the English homepage's own hreflang block must include both hreflang="en" (its language self-reference) and hreflang="x-default" (the fallback self-reference) pointing to itself. Two link elements, same URL, different hreflang values. Omitting the x-default self-reference is the single most common reason an otherwise correct tag "is not working." The Hreflang Checker reports this as a missing return tag and names the exact URL that should declare x-default but does not.
Mistake 3 — Pointing x-default at a Redirecting or Noindexed URL
The x-default target must be a live, indexable, 200-status URL. Three real-world variants break this. First, pointing x-default at a URL that 301-redirects to a country-specific page defeats the purpose — Google follows the redirect and the fallback collapses into a single locale. Second, pointing it at a language-selector page that carries <meta name="robots" content="noindex"> means Google cannot serve it as a search result, so the fallback effectively vanishes. Third, pointing it at a URL blocked in robots.txt prevents crawling of the annotation entirely.
If you genuinely use a language-picker landing page as your x-default — a legitimate and Google-endorsed pattern — that page must be indexable. Do not noindex it and do not disallow it. Confirm the crawl path with the robots.txt Tester before you trust the fallback. A picker page that returns 200, is crawlable, and is indexable is the cleanest x-default destination because it makes no assumption about the user's intended language.
Mistake 4 — Multiple Conflicting x-default Declarations
This surfaces during CMS migrations when two URL conventions coexist. A page emits hreflang="x-default" href="https://example.com/" and also hreflang="x-default" href="https://example.com/en/". Google has no rule to disambiguate two fallbacks for the same cluster, so it typically ignores both. The cluster then has no working fallback at all, which is worse than having none declared, because you believed you were covered.
The fix is canonicalization — decide on one fallback URL, emit it once, and purge the second from every template and every sitemap fragment. Because this bug hides across thousands of pages, audit it at the topology level. Export your production sitemap and diff it against the previous release with the Sitemap Comparator; duplicate x-default lines stand out immediately in a structured diff.
Mistake 5 — Mismatched Absolute URLs and Protocols
Hreflang href values must be fully qualified absolute URLs. Relative paths like /en/ are not valid in an hreflang annotation and are ignored. Beyond that, the x-default href must match the canonical form of its target exactly — same protocol, same host, same trailing-slash convention. A fallback declared as http://example.com/ while the site canonicalizes to https://www.example.com/ is a mismatch, and Google may fail to associate the annotation with the indexed URL.
The subtle version is trailing slashes. If your server treats /en and /en/ as distinct URLs and your canonical uses the slash, but the x-default href omits it, you have created a near-duplicate that does not line up with the canonical. Pick one canonical form and make every hreflang href — x-default included — match it byte for byte.
Mistake 6 — Mixing Declaration Methods Inconsistently
Google accepts hreflang in three transports — HTML <link> elements in the head, HTTP Link response headers, and xhtml:link annotations inside the XML sitemap. They are equivalent, but you must not split one cluster across two methods. Declaring the language alternates in the HTML head while declaring x-default only in the sitemap produces an inconsistent cluster that Google may read as two partial, conflicting sets.
Choose one method per cluster and declare the full set — every language alternate plus x-default — in that one place. For large sites the sitemap approach wins because the whole cluster, fallback included, lives in one regenerable, diffable artifact. Whichever you pick, do not let x-default drift into a different transport than its siblings.
Mistake 7 — Assuming x-default Overrides a Bad Country Signal
x-default is a fallback for unmatched locales, not a correction layer for matched ones. If a German user is being routed to the wrong page, the problem is in your de or de-DE alternate, not in x-default — Google never consults the fallback when an explicit alternate matches. Teams sometimes "fix" a mis-routing complaint by tweaking x-default and are baffled when nothing changes.
Remember the precedence — Google first looks for an exact language-plus-region match, then a language-only match, and only when nothing matches does it fall through to x-default. Per Google's guidance, hreflang also does not establish country targeting on its own; pair it with ccTLDs or the appropriate Search Console settings. x-default cannot rescue a cluster whose explicit alternates are wrong. The diagnostic discipline here is to reproduce the failing query yourself — search in the affected language from the affected region, observe which URL ranks, and trace that URL back to the alternate that claims it. Nine times out of ten the culprit is an explicit alternate with an invalid locale code or a broken return tag, not the fallback. Reaching for x-default to patch a matched-locale problem only adds noise to a cluster that was already routing past it.
Mistake 8 — Omitting x-default on Genuinely International Sites
The opposite failure — leaving x-default out entirely — is defensible only in narrow cases. A two-language cluster where the audiences are mutually exclusive (say, an internal tool offered only in English and Japanese with no global audience) can survive without it. But any site that attracts visitors from locales it does not explicitly serve needs a fallback, or Google guesses. The guess is biased toward whichever alternate has accumulated the most link authority, which is why a global English homepage sometimes loses unmatched traffic to an older, link-rich German URL.
Declaring x-default is one extra <link rel="alternate" hreflang="x-default" href="..."/> per cluster. The cost is trivial; the cost of omission is invisible misrouting that never shows up as an error, only as softer conversion on traffic you cannot easily attribute.
A Five-Minute x-default Audit
- Confirm exactly one x-default per cluster. Zero means you are guessing; two means Google discards both.
- Verify the return tag. The x-default destination must declare itself as x-default. Missing self-reference is the number-one cause of "not working."
- Check the target status. 200, indexable, crawlable. No redirect, no noindex, no robots.txt block.
- Match the canonical form. Absolute URL, correct protocol and host, consistent trailing slash.
- Keep the cluster in one transport. Do not split x-default away from its siblings.
- Re-run the check. The same validation logic ships in the open-source
@anthropic-tools/tools-corepackage, so you can wire it into CI and fail the build on any regression.
x-default is small, but its failure modes are quiet and expensive. Paste a sitemap or a page's HTML head into the Hreflang Checker and let it tell you exactly which line breaks your fallback. If you are also restructuring URLs as part of a migration, run the sitemap migration workflow alongside it so the x-default targets survive the move intact.