Do I need an x-default?

Only if you have a page that genuinely serves everyone you have not otherwise targeted: a language selector, a global landing page, or a default version. A site with en, de and fr and no generic entry point does not need one, and inventing a target to satisfy the annotation makes the set worse.

Can x-default point to a page that also has its own hreflang entry?

Yes, and that is the normal case for a global English page that is both the en version and the fallback. It gets two annotations, one naming its language and one naming it as the default, and both must be present in every page of the set.

What is the difference between x-default and en?

en targets English speakers; x-default targets everyone the set does not otherwise match, whatever they speak. They coincide on many sites, which is why they get confused, but a Japanese speaker with no ja version falls to x-default regardless of whether they read English.

x-default: the fallback for visitors you do not serve

x-default names the page to show somebody whose language you do not serve. It is one line, most sites do not need it, and the ones that add it usually point it at a page that is not a default at all.

The short answer

x-default names the page to serve when no other hreflang entry matches the visitor, which usually means a language selector or a global English version. It is not a fallback for every unmatched country if you already have a generic language entry, and most sites with a single region per language do not need it at all.

RefinementAudit check · x-default

What a default actually means here

An hreflang set says which page serves which audience. x-default is the entry for everybody the set does not cover: a visitor whose browser asks for Japanese on a site that publishes English, German and French.

Without it, a search engine picks from your set on its own, usually the closest match it can find or the version that best fits the query. That guess is often fine. x-default replaces the guess with your own instruction.

hreflang.html

<link rel="alternate" hreflang="en" href="https://example.com/en/knives" />
<link rel="alternate" hreflang="de" href="https://example.com/de/messer" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/couteaux" />
<link rel="alternate" hreflang="x-default" href="https://example.com/knives" />

Two things about that last line. It is a value of hreflang, not a separate attribute, so it lives in the same set and obeys the same rules: every page in the group has to carry the whole set, and every URL in it has to point back. An x-default inside a set that is not reciprocal does nothing, because the set itself is discarded.

And the URL it names should be a page that does not privilege one audience. In the example that is a language-neutral landing page at the root path. Pointing x-default at your English version is the most common implementation and it is a statement that English is the fallback for everybody, which may be what you mean and is worth meaning on purpose.

Who needs one, and who does not

The check is a refinement partly because the honest answer for most sites is that this does not apply. Four cases:

One language, no hreflang: not applicable. There is no set for the annotation to live in. Adding a lone x-default to a monolingual site achieves nothing at all.
Several languages, no neutral page: probably skip. If you publish English and German and nothing else, and every page belongs to one of them, there is no default page to name. Naming English as the default is defensible; inventing a page to be the default is not.
A language or country selector: this is the case. A site whose root path shows a chooser rather than content has an obvious default, and x-default is exactly what that page is for.
Country variants of one language: this is the other case. A site with en-GB, en-US and en-AU versions serves English speakers in three places and nobody else. An x-default tells a search engine which one an English speaker in Ireland should get, rather than leaving it to a guess about proximity.

The fourth case is where this annotation earns its place, and it is worth noticing that the problem it solves there is not really about language at all. It is about a set of variants that are all in the same language, where a language match cannot break the tie.

One annotation inside a set that has to be whole

An hreflang set is only valid if every member declares the whole group and every URL in it points back. So the finding here is never about one line on one page: it is whether the set including the default is reciprocal across every page in the group.

This one needs the full crawl

An x-default is one annotation inside a set, and a set is only valid if every page in it points back, so the finding needs every page in the group fetched together.

The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.

Run the full audit, free

If your set is broken in the first place, that is the thing to fix, and the hreflang guide covers why these fail all at once rather than one page at a time.

Three ways it goes wrong

More than one x-default in a set. Two pages both claiming to be the fallback is a contradiction, and the usual cause is a template emitting the annotation per language rather than once per set. The set is ignored rather than half-applied.

The default is also a language version. Pointing x-default and hreflang="en" at the same URL is legal and frequently intended: that page is both the English version and the fallback. It becomes a mistake when it happened by accident, because the page then has to serve two purposes and nobody decided it should.

The default redirects by IP.The worst of the three. If your root path detects a visitor's country and sends them somewhere, then the URL you named as the fallback never serves the fallback: a crawler arriving from one country is redirected to one language version and never sees the neutral page. Automatic geographic redirection undermines the whole set, and it is the reason a language selector should be a page rather than a redirect.

If you serve a chooser, make it a real page a crawler can read.

Links to every language version, in HTML, with the language names written in their own languages. That page is then genuinely neutral, genuinely crawlable, and a sensible thing for x-default to name. It also happens to be the only version of a language selector that works for somebody whose browser sends the wrong locale.

A chooser implemented as a script that redirects on load is invisible to anything that does not run it, which puts the whole international structure behind a rendering dependency.

Does this affect AI search?

Barely, and the reason is instructive. hreflang is a mechanism for choosing between versions of a page in a results list, and that selection step does not have an equivalent in a system that retrieves passages to answer a question. Nothing consults your default before deciding what to quote.

What does carry over is the underlying content problem. If a model is answering in French from your English page because your French page was not discovered, no annotation fixes that: the fix is that the French page is reachable, distinct and genuinely in French, which is a different check.

The one honest connection: a neutral landing page that lists your language versions in HTML is a page that describes the shape of your site to anything reading it. That is a small benefit and it comes from the page existing, not from the annotation naming it.

Why a fallback annotation sits at the bottom

Because the default behaviour is adequate. With no x-default, a search engine picks a version for an unmatched visitor, and its guess is usually the one you would have chosen. Nothing is excluded, nothing breaks, and most sites are not eligible for the finding at all, which is the clearest possible case for a Refinement.

It is also a refinement because the failure it prevents is small and specific: a visitor from an unserved country landing on the wrong one of your language versions, on a site that has several. That is a real annoyance for a minority of a minority.

Where the rating understates things is the country-variant case in the second section. On a site with three English variants, the tie-break is genuinely undecided without this, and the wrong choice means somebody sees prices in a currency they cannot pay in. The annotation is still one line; the consequence of omitting it is larger there than the chip suggests, which is what this guide is for.

Questions this check raises

Do I need an x-default?: Only if you have a page that genuinely serves everyone you have not otherwise targeted: a language selector, a global landing page, or a default version. A site with en, de and fr and no generic entry point does not need one, and inventing a target to satisfy the annotation makes the set worse.
Can x-default point to a page that also has its own hreflang entry?: Yes, and that is the normal case for a global English page that is both the en version and the fallback. It gets two annotations, one naming its language and one naming it as the default, and both must be present in every page of the set.
What is the difference between x-default and en?: en targets English speakers; x-default targets everyone the set does not otherwise match, whatever they speak. They coincide on many sites, which is why they get confused, but a Japanese speaker with no ja version falls to x-default regardless of whether they read English.