A client once asked me why their Dutch visitors were landing on the German site. The hreflang setup looked complete: en-US, en-GB, de-DE, fr-FR, es-ES, all reciprocal, all validating clean. There was no Dutch version, so there was nothing to point at, and I had assumed Google would fall back to English. It did not. It fell back to German, presumably because Dutch and German share enough signals to look like the closest match, and a Dutch speaker who reads English fine got a page they could not read at all.
The fix was one line. One x-default entry pointing at the English homepage, and the Dutch traffic started landing somewhere sensible within a fortnight.
x-default is the least glamorous part of hreflang and the part I now add first. This guide covers what it does, where to point it, the mistakes that make it useless, and how it behaves alongside the rest of your annotations. It sits under the complete hreflang guide, next to the errors that break implementations.
TL;DR:
x-defaultis the hreflang value that names the page to serve when none of your other language or region entries match the user. It is not a language code and does not replace one: your English page still needs its ownenentry, withx-defaultalongside as the catch-all. Point it at a language selector or your primary international page, never at a redirect chain or a page that isnoindex. Google treats it as optional; leaving it out means the algorithm picks for you. When you generate hreflang tags here, a set with no x-default raises a warning.
What is x-default in hreflang?
x-default is a reserved hreflang value that identifies the fallback page for users whose language and region do not match any other entry in the set. It looks exactly like any other annotation:
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
Google introduced it in 2013 specifically for homepages that auto-redirect users based on their location, and the definition has since widened to cover any fallback. The value is not a BCP 47 language tag and never was; it is a keyword Google's parser recognizes and everything else ignores.
That distinction matters when you read validators. A strict language-tag validator will tell you x-default is invalid, because as a language tag it is. As an hreflang value it is correct and documented. Any tool that rejects it is validating the wrong specification.
Is x-default required?
No. Hreflang works without it, and Google's documentation lists it as recommended rather than mandatory.
In practice I treat it as required, for the reason at the top of this article. Without it, Google decides what to do with unmatched users, and the decision it makes is opaque and occasionally strange. With it, you have made the decision yourself and you can reason about the outcome. The cost is one extra annotation in a block you are already generating.
The one case where you can genuinely skip it: a site whose language set covers its entire realistic audience, with no ambition to acquire visitors outside it. A regional government site serving two official languages to one country, for instance. Even there, adding it costs nothing.
Where should x-default point?
There are three defensible targets and one common mistake.
| Target | When it fits | Watch out for |
|---|---|---|
| Language selector page | Many locales, no obvious default | The page must be indexable and useful, not a bare redirect stub |
| Primary international version, usually English | One language dominates your traffic | Do not point it at a country-specific URL like /en-us/ if you also serve /en-gb/ |
| Generic root that geo-detects | You already have IP-based routing | The URL must return 200 for a crawler, not a 302 to a locale |
| A country-specific page | Never | Tells Google your fallback for the whole unmatched world is one market's page |
My default choice is the neutral English version at the site root, because it is the version most likely to be readable by someone whose language you do not serve. A language selector is the more principled answer when you have a dozen locales and no natural default, but it is a worse landing page: it asks the visitor to do work before they see anything of value.
Whichever you pick, the target must be a real, indexable, 200-status URL. An x-default pointing at a page that redirects on arrival still works, but every hop is a chance to lose the signal, and a redirect that varies by IP means Googlebot, crawling from one location, may never see what your users see.
Does x-default replace the language entries?
No, and this is the misunderstanding I correct most often.
x-default is a routing instruction, not a language declaration. It says "when nothing matches, go here." It does not say "this page is English." So the page you point it at still needs its own language entry in the same set. A complete block for a site with English, German, and a fallback looks like this:
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
Note that https://example.com/ appears twice, once as en and once as x-default. That is correct and expected. The same URL is both "the English version" and "where unmatched users go", and Google needs both facts stated.
A set that has x-default pointing at the root but no en entry for it is broken in a subtle way: English speakers have no explicit match, so they are routed through the fallback path rather than the language path. It usually still works. It is still wrong.
How does x-default interact with reciprocity?
The same way every other entry does. The full set, x-default included, goes on every page in the group.
So the German page carries the identical block shown above, including the x-default line pointing at the English root. It feels odd the first time you write it, because you are declaring a fallback on a page that is itself one of the alternates. That is the design: every page in a set carries the whole map, so that any page Google crawls first gives it the complete picture.
Where this breaks in practice is templating. Teams render the language entries from a loop over the locale map and then append x-default as a special case, and the special case gets forgotten on one template. One page missing one entry is enough to make that page's set inconsistent with its siblings. Generate all of it from one source, x-default included, and the class of bug disappears. The Next.js guide and the WordPress guide both show the loop with the fallback folded in rather than bolted on.
Can I use x-default on pages other than the homepage?
Yes, and you should. The 2013 announcement framed it around homepages, which is why a lot of older advice says it is homepage-only, but the mechanism applies to any set of alternates.
For a deep page, the fallback should be the equivalent deep page rather than the homepage. If your pricing page exists in English, German, and French, the x-default for that set is your English pricing page, not your English homepage. Sending an unmatched user from a pricing query to a homepage is a worse experience and a worse conversion path, and it makes the annotation less accurate than it could be.
The exception is a page that genuinely exists in only one market. If a compliance page applies to Germany alone, it has no alternates, needs no hreflang set, and therefore needs no x-default.
What about multiple x-default entries?
One per set. A set with two x-default entries pointing at different URLs is a contradiction, and Google's handling of contradictions is to discard rather than to guess.
This happens more often than you would expect on sites where hreflang is assembled from two sources: a plugin emits one block and a hand-written template emits another, and the page ends up with both. It also happens when a sitemap carries hreflang for the same URLs that already have HTML tags. The hreflang generator catches duplicate codes within a set, including a repeated x-default, but it cannot see a second block emitted by something else on the page. View source and count.
How do you verify x-default is working?
There is no direct report for it, which is part of why it gets neglected. Three checks that do work:
Look at the rendered HTML, not the template. curl the page and grep for x-default. If your framework strips or reorders head tags, or a plugin injects a competing block, this is where you find out.
Check the target resolves. Fetch the x-default URL with a crawler user agent and no cookies, from outside your own country if you can. What you are checking for is a 200 rather than a redirect, and the same content Googlebot would see.
Watch the queries, not the rank. In Search Console, filter Performance by countries you do not target explicitly and see which page they land on. If unmatched countries are arriving at the page you nominated, the annotation is doing its job. If they are arriving at a random locale, either the tag is missing or something else on the page contradicts it.
Search Console's International Targeting report will surface return-tag errors that involve the x-default entry along with everything else, since it is part of the reciprocal set like any other line.
Common x-default mistakes
The list, in the order I encounter them:
- Not having one. The default failure. Unmatched users get whatever Google guesses.
- Pointing it at a country-specific URL.
/en-us/as the global fallback tells Google your worldwide default is the US store, prices and all. - Pointing it at a redirect. Especially an IP-based one, which means Googlebot and your users see different pages.
- Using it instead of a language entry. The fallback URL still needs its own
enordeline. - Two of them. Usually a plugin and a template both emitting hreflang.
- Only on the homepage. Deep pages have alternates too, and they deserve a fallback that matches their depth.
- Pointing at a
noindexpage. You have advertised a destination you told Google to ignore.
Every one of these is silent. Nothing errors, nothing warns, and traffic from the markets you do not serve goes quietly to the wrong place. That is the argument for generating the block rather than hand-maintaining it, and for reading the rendered output rather than trusting the template. The hreflang errors guide covers the rest of the family, and the hreflang tool guide walks through building a validated set from scratch.
Frequently asked questions
What does x-default mean in hreflang?
x-default names the page a search engine should serve when none of the other language or region entries in the hreflang set match the user. It is a fallback routing instruction rather than a language code.
Is x-default mandatory?
No. Google recommends it but hreflang works without it. Without an x-default, Google chooses which version to show unmatched users, and that choice is not something you control or can easily observe.
Where should x-default point?
To a language selector page or your primary international version, usually the English one at the site root. Avoid pointing it at a country-specific URL, a redirect, or a page marked noindex.
Does the x-default page still need its own language tag?
Yes. If your English homepage is the x-default target, the set still needs an en entry pointing at the same URL. The same URL legitimately appears twice, once as a language and once as the fallback.
Can I have more than one x-default?
No. One per hreflang set. Two entries pointing at different URLs is a contradiction, and it usually means two systems on the page are both emitting hreflang blocks.
Can x-default be used on pages other than the homepage?
Yes. Any set of alternates can have a fallback, and for deep pages the fallback should be the equivalent deep page rather than the homepage.
Does x-default need to appear on every page in the set?
Yes. It is part of the reciprocal block, so the identical set including the x-default line goes on every page in the group.
How do I check that x-default is working?
Fetch the rendered HTML and confirm exactly one x-default entry is present, verify its target returns 200 without redirecting, then use Search Console's Performance report to see which page visitors from untargeted countries are landing on.
