The x-default entry: whom your hreflang set misses

What it is for

No set covers the world, and the fallback is where you admit that.

A site with versions for three languages has nothing specific to offer a visitor searching in a fourth. Something will still be shown to them, because one of your pages is the closest match by whatever measure is applied. The fallback entry replaces that measure with your decision.

That is the whole of its purpose, and it explains why it belongs on nearly every set. Exhaustive sets are rare, and a set that aims to be exhaustive today acquires a gap the moment somebody in an unplanned market finds you.

What it is not

Each of these readings looks reasonable, and each produces the wrong page.

• Not the main language version

  The fallback is not a way of saying which version came first or which market matters most. Those are business facts and the declaration has no field for them. Marking the original version as the fallback is sometimes correct, but only if it is genuinely the right thing to show somebody the set does not describe.

• Not a substitute for a missing entry

  Where a version exists for an audience, that audience gets its own entry with its own ISO 639-1 language code. The fallback is for the audiences that have no version, not a shortcut around declaring the ones that do.

• Not a ranking or priority signal

  It describes coverage, not importance. A set can name its smallest, least commercially interesting page as the fallback and be entirely correct in doing so.

Choosing which page it points at

The choice of page follows from how your versions differ.

• A selector page

  It offers the visitor the list and lets them pick. Honest, and it never shows anybody the wrong language. It also costs a step and delivers no content to somebody who arrived from a search wanting an answer, so it converts curiosity into a decision at the worst possible moment.

• A content version

  Usually the one whose language reaches the widest audience outside your set. It delivers something immediately, at the cost of being wrong for some of the people who see it.

The deciding question is what your versions differ by. Where they differ mostly by region while sharing a language, a content version is nearly always right: an unplanned visitor gets readable content and only the regional details are off. Where they differ by language with no common one among them, a selector page is the safer answer, because the failure it avoids is showing somebody a page they cannot read at all.

Where it sits in the set

An entry among the others, and it follows the same rules as the rest.

It appears once in a set, at one URL, not once per page type and not on the main version only. And it is subject to the same reciprocity as every other entry: each member of the set carries the whole set, including this one. A fallback declared on the primary page and nowhere else is a common and quiet fault, because the page that declares it looks correct in isolation.

That last point is worth connecting to the general case. The whole set inherits the weakness of whichever page is looked after least, which is the subject of hreflang errors; the fallback entry is simply one more thing every member must carry.

Three ways it goes wrong

All three survive review, because none of them looks wrong on the page where it is written.

• Declared more than once

  Two entries claiming to be the fallback is a contradiction, and it is usually the result of two people each adding one to a different template. Nothing announces the duplication; the set simply stops making a single statement.

• Pointing at something that cannot be fetched

  A fallback naming a page excluded by your own robots.txt, or one that answers with an HTTP error, nominates a page nobody can receive. This is more common with selector pages than with content pages, because selector pages are the ones people are tempted to exclude from being fetched on the grounds that they hold no content.

• Pointing at an address that redirects by location

  Before you set up automatic redirection based on where a visitor appears to be, note what it does to the rest of the set: a page that sends everybody somewhere else based on their apparent location cannot serve as the fallback, cannot be verified by you from your own country, and makes the whole set untestable, since every check you run returns the version your own location selects. If you need location-based routing, offer it rather than impose it, and keep every version reachable at its own address. Redirection itself, and how to keep it from compounding, is covered under redirects.

When a set does not need one

Neither of these cases is common.

A site with a single language and no regional versions has no set to speak of and nothing to fall back to. And a set that genuinely describes every audience the site can serve, which in practice means an audience defined by something other than language, such as a service available only in named countries, may reasonably decide that anybody outside it is not a visitor to plan for.

Everywhere else, the absence of a fallback is a decision made by not making one, and the result is that some part of your audience is shown a version selected by rules you never saw.

How to check it

The same pass that checks the rest of the set.

Fetch each member and read its declarations back. The fallback should appear exactly once per member, name the same address every time, and that address should return a page directly rather than redirecting. If different members name different fallbacks, you have two sets that overlap rather than one set with a fallback. A validator that follows and re-reads each declared address reports this without the arithmetic.

FAQ