x-default for an Export Site Language Selector: Routing the Unmatched-Language Visitor

This guide answers one routing decision for export sites that already publish more than one language version on a single domain: what should happen to a visitor whose language is not among the explicitly declared hreflang values. It separates the x-default fallback role from assigning English to everyone, from locale catchall URLs, and from automatic redirects, then shows what the surrounding bidirectional hreflang set must satisfy for the annotation to be processed. All technical statements come from Google Search Central’s localized-versions documentation; no ranking, indexing, or routing outcome is promised.

The visitor your hreflang set does not cover

Your hreflang set is a list of promises. Each entry names a language or region code and the URL that serves it. A visitor whose browser language appears nowhere in that list is not covered by any of those promises, and on a site with a language selector or an auto-redirecting home page, that visitor is the one who has to guess.

The x-default value exists precisely for that gap. In the HTML link element syntax, the language code can be a supported language or region code targeted by that version of the page, or x-default to match any language not explicitly listed by an hreflang tag on the page. The HTTP header method defines the same value the same way: x-default matches any language not explicitly listed by an hreflang tag on the page.

Two things follow from that definition. First, x-default is a catch-all for languages you did not enumerate, not a synonym for your English version. Second, the visitor it serves is defined by absence: they are unmatched because your set does not name their language, not because their browser is unusual or their region is unsupported.

It is worth knowing that leaving the gap undeclared does not necessarily mean Google never finds your other language versions. Google notes that even without taking action, it might still find alternate language versions of your page, but that it is usually best for you to explicitly indicate your language- or region-specific pages. The practical reading is that an undeclared fallback is not a hard failure you can detect from a crawl report; it is an unstated preference that you have left for someone else to resolve.

Source reference

Selector page or existing language version: the actual decision

Once you accept that unmatched visitors need a declared destination, you have to choose what that destination is. Google’s guidance points at one candidate in particular: consider adding a fallback page for unmatched languages, especially on language/country selectors or auto-redirecting home pages, using the x-default value.

The worked example in the same documentation shows what that looks like in practice. The default page at the bare domain does not target any language or locale, and it has selectors to let users pick their language and region. In that example, the head section directs US, UK, generic English speakers, and German speakers to localized pages, and all others to a generic home page.

So the two candidate targets behave differently for the unmatched visitor. Pointing x-default at the selector page hands the decision to the visitor: they arrive somewhere that exists to let them choose, and the page itself does not presume a language. Pointing x-default at an existing language version commits every unmatched visitor to that language before they have read anything, and the selector page — if you keep one — becomes a page that unmatched visitors never reach through this signal.

That second option is the one to be careful about, because it is easy to reach by accident. If your English page is the only version that targets a broad, unspecified audience, it can look like the natural fallback. But x-default matches any language not explicitly listed, and the documented example routes those visitors to a generic home page rather than to a specific language version. Choosing the English page as the x-default target is therefore a deliberate decision to serve all unmatched languages in English, not a neutral default.

This scenario is hypothetical and is used only to illustrate the two candidate targets; it describes no real site, test, or measured outcome. A labelled hypothetical makes the trade-off concrete. Suppose an export site publishes English and German versions and a selector page at the root. If the operator points x-default at the German page, a buyer whose browser language is neither English nor German lands on German content with no obvious route back to the selector. If the operator points x-default at the selector page, that same buyer lands on a page whose only job is to let them pick. The second arrangement matches the documented example; the first is a choice the operator can still make, but should make knowingly.

What the x-default annotation must sit inside to be processed

An x-default link is not a standalone instruction. It is one member of a set, and the set has conditions. The most common reason a fallback appears to do nothing is that the surrounding annotations were never valid as a group.

The first condition is completeness. Each language version must list itself as well as all other language versions. The second is reciprocity: if two pages do not both point to each other, the tags will be ignored.

Reciprocity is the condition that catches people out, because a one-way annotation looks correct on the page you are editing. If your English page lists the German page and the selector, but the German page’s head does not list the English page back, the pair does not hold. The documentation’s stated reason is defensive: without the mutual requirement, someone on another site could create a tag naming itself as an alternative version of one of your pages.

The third condition concerns how each URL is written. Alternate URLs must be fully qualified, including the transport method, so a value must read as a complete https:// address rather than a protocol-relative or root-relative path. The fourth is a permission rather than a restriction: alternate URLs do not need to be in the same domain. That matters for export sites that keep a regional presence on a separate host, because the set can span hosts as long as each URL is fully qualified and each page points back.

The fifth condition is placement and markup hygiene. The link tags must be inside a well-formed head section of the HTML, and hreflang annotations should not be combined with other attributes such as media in a single link tag. The documentation suggests pasting code from your rendered page into an HTML validator if you are unsure whether the links ended up inside the head element — a check worth running on the rendered output rather than the template, since a theme or build step can move markup.

A short set of conditions to verify before you trust the fallback: every version lists itself and every other version; every pair is mutual; every URL is fully qualified with its transport method; the links sit inside a well-formed head; and no link tag mixes hreflang with unrelated attributes. If any of these fails, the fallback is not a fallback — it is an annotation that may be ignored.

Choosing the fallback URL when you serve several locales of one language

There is a second fallback decision that looks similar and is not the same. If you have several alternate URLs targeted at users with the same language but in different locales, Google advises also providing a catchall URL for geographically unspecified users of that language. The documentation’s example is a set of English pages for Ireland, Canada, and Australia, with a generic English page for searchers in the US, UK, and all other English-speaking locations — and it notes that the catchall can be one of the specific pages if you choose.

Keep the two roles apart. The catchall serves geographically unspecified users of a language you have already listed — an English speaker whose country you did not enumerate. The x-default value serves languages not explicitly listed by an hreflang tag on the page. A visitor from a country you did not list but whose language you did list is a catchall case. A visitor whose language you never listed at all is an x-default case. Conflating them is how a site ends up pointing x-default at a locale-specific page such as an en-GB URL, which then serves every unmatched language with British English.

The catchall guidance also answers a question operators often ask before adding x-default: whether the fallback has to be a brand-new URL. It does not. The catchall can be one of the specific pages, so the fallback target is a design choice constrained by the bidirectional set, not a fixed requirement to create another page.

Automatic redirects and the fallback page

The redirect question usually arrives as a shortcut: if the site already redirects visitors to a language version based on their browser, why declare a fallback at all? The documentation does not treat redirects as a replacement for the fallback annotation. It names auto-redirecting home pages as one of the places where a fallback page for unmatched languages is especially worth considering.

There is a related boundary worth stating plainly. Google does not use hreflang or the HTML lang attribute to detect the language of a page; it uses algorithms to determine the language. So the hreflang set, including its x-default member, is a statement about which URLs are localized variations of the same content and which one is the fallback — not a mechanism that tells Google what language a page is written in.

What the documentation does not do is describe automatic redirects as a substitute for the fallback annotation. It does not say that a redirect makes x-default unnecessary, and it does not describe how a redirect should interact with an unmatched-language visitor. Treat that as an open question rather than a settled one, and do not assume a redirect you have configured is doing the job the fallback annotation is meant to do.

Which method carries the annotation, and what to verify

You can express the whole set — including x-default — through HTML link elements, HTTP headers, or a sitemap. The three methods are equivalent from Google’s perspective, and while you can use all three at the same time, there is no benefit in Search and it may be much harder to manage three implementations instead of picking one. For a selector page that is ordinary HTML, the HTML method is the one that keeps the annotation next to the page it describes; the header method is the documented option for non-HTML files such as PDFs.

One maintenance point matters if your language set is still growing. If it becomes difficult to maintain a complete set of bidirectional links for every language, you can omit some languages on some pages, and Google will still process the ones that point to each other. But newly expanded language pages should be linked bidirectionally to the originating or dominant language pages. The documentation’s example is a site originally created in French, where it is more important to link newer Mexican and Spanish pages back to the strong French presence than to link the new Spanish variants to each other.

There is also a duplicate-content question that comes up whenever a fallback points at an existing version. Localized versions of a page are only considered duplicates if the main content of the page remains untranslated. That is a statement about how localized versions are treated, not a promise about how any particular fallback arrangement will perform.

Finally, be precise about what you are verifying. The documentation frames the purpose of telling Google about localized versions as helping Google Search point users to the most appropriate version of your page by language or region. It does not state a guaranteed routing outcome for any individual visitor. So the thing you can actually check is the state of your annotations: that the set is complete, mutual, fully qualified, and correctly placed, and that the x-default target is the page you intended. Whether a given unmatched visitor ends up where you hoped is not something the annotation alone guarantees.

If you are still deciding how your language versions should be structured before you add a fallback, the URL and hreflang layer is covered separately in Multilingual Website SEO: Language Signals and Acceptance. If your site already has locale routes and you need to confirm the signals survive a release, the layer-by-layer checks in WordPress Export Website SEO Maintenance Guide are the relevant companion.