Adding a Missing Hreflang x-default
Hreflang tells Google which page to show a searcher whose language or country you serve. The x-default value covers everyone else: the Portuguese speaker in Switzerland when you only have English, German and French pages, or the searcher whose browser language matches nothing.
Without it, Google picks whichever version it judges best, which may not be the one you would choose. The Hreflang Checker reports x-default as missing when a cluster has no fallback. This guide helps you decide what the fallback should be, add it to every page consistently, and avoid the mistakes that make an x-default worse than none.
What x-default does, and what it does not
Hreflang values normally name a language, or a language and a country. x-default is the
one value that names neither. It marks the address to use when none of the other entries in the cluster
fits the searcher. Google introduced it for language selection pages and home pages that choose a version
for the visitor, and it is widely used for international versions of a site as well.
A few points are often misunderstood:
- It is recommended, not required. A cluster without x-default is still valid. The checker flags it because adding one gives you control over a group of searchers you would otherwise leave to Google.
- It is not a language. Writing
x-default-enoren-x-defaultis invalid. The value is exactlyx-default. - It does not redirect anyone. Like all hreflang, it only affects which address Google shows in results.
- It is per cluster. Each set of equivalent pages has its own x-default. The pricing page's fallback is the international pricing page, not the home page.
- It must be in every member. Like every other entry, the x-default line appears on all pages in the cluster, not just the home page or the fallback page itself.
Choosing the fallback: three patterns
The right fallback depends on who reaches you from outside your target markets and what they can do when they arrive.
| Pattern | x-default points to | Suits | Watch out for |
|---|---|---|---|
| Language or country picker | A page that lists every version and lets the visitor choose | Sites with several languages of similar weight, or country stores with different ranges and prices | The picker must have real, indexable content and plain links, not only a script-driven menu |
| International version | A general version in the most widely read language, often English without a region | Sites with regional English pages plus a sensible version for the rest of the world | Prices and delivery on that page should make sense for international visitors |
| Main market doubles as fallback | The same address as one of the language entries | Sites with one dominant market and a few translations | That page appears twice in the block, once with its code and once as x-default, which is correct |
For most small and medium sites, the third pattern is the simplest: the English page is already the one you would want an unmatched visitor to see. A picker only earns its place when no single version is a good default, for example a shop whose products, prices and shipping differ completely by country.
What not to use as a fallback
- The home page for every page in the site, regardless of topic. The fallback should be the equivalent page.
- A page with
noindex, a login, or a 404. Google cannot use it. - A different page in each member of the cluster. Every page must name the same fallback address.
- A page whose canonical points somewhere else.
What a correct x-default looks like
Here is a delivery information page with a British page, an Irish page, a German page and an international English page as the fallback. The same five lines go in the head of all four pages:
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/delivery/">
<link rel="alternate" hreflang="en-IE" href="https://example.com/ie/delivery/">
<link rel="alternate" hreflang="de" href="https://example.com/de/lieferung/">
<link rel="alternate" hreflang="en" href="https://example.com/delivery/">
<link rel="alternate" hreflang="x-default" href="https://example.com/delivery/">Notice that the international page is listed twice: once as en, catching English speakers
outside the UK and Ireland, and once as x-default, catching everyone who matches nothing,
such as a Spanish speaker in Mexico. Those are different groups, so both lines are useful.
In an XML sitemap the same fallback appears as one more alternate under each address:
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/delivery/"/>And for files without an HTML head, such as a PDF brochure, it goes in the HTTP Link header alongside the others:
Link: <https://example.com/files/brochure.pdf>; rel="alternate"; hreflang="x-default",
<https://example.com/de/files/broschuere.pdf>; rel="alternate"; hreflang="de"Errors that come with adding x-default
Adding x-default in a hurry introduces its own problems. The checker reports several of these alongside or instead of "missing x-default":
| Error | Why it happens | Correction |
|---|---|---|
| x-default only on the home page | Added by hand to one template | Add it in the shared head code so every clustered page gets its own |
| Two x-default lines with different addresses | A plugin adds one and the theme adds another | Keep one source of hreflang output |
| x-default names the home page from a product page | A single site-wide setting | Point to the fallback version of the same product |
| x-default page redirects | The address is a location-based redirect | Point to a page that returns 200, or make the chooser a real page |
| x-default page is noindexed | Pickers are sometimes treated as utility pages | Allow indexing, and give the picker useful text |
| Invalid value | Typed as x_default, xdefault or default | Use
exactly x-default |
https://example.com/, redirects visitors
to a country version based on their location, be careful using it as x-default. Google mostly crawls
from the United States, so it may only ever see one destination. A static chooser page, or an international
version that does not redirect, is far easier for Google to understand and for the checker to verify.Adding x-default on common platforms
WordPress
Multilingual plugins such as WPML and Polylang can output x-default automatically, usually pointing to the default language. Check the plugin's settings for the x-default option and which language it uses, and make sure no SEO plugin or theme adds a second one. The WordPress hreflang guide covers plugin combinations.
Shopify
Shopify generates hreflang for markets and languages itself. Check the rendered source of a few pages to see whether an x-default line is present and which address it uses, and look at apps or theme code if there is more than one. The Shopify hreflang guide has the details.
Next.js and Nuxt
In the Next.js App Router, add an x-default key to the alternates.languages
object alongside the locale keys. In Nuxt, the i18n module's head helper can output a fallback line based
on the default locale; check the generated head to confirm. See hreflang
in Next.js and Nuxt.
Static sites and custom templates
Wherever the template loops over locales to print hreflang lines, add one more line after the loop, built from the same page's default-locale address:
{% for alt in page.all_versions %}
<link rel="alternate" hreflang="{{ alt.code }}" href="{{ alt.url }}">
{% endfor %}
<link rel="alternate" hreflang="x-default" href="{{ page.version('en').url }}">If a page has no version in the default locale, choose deliberately: either leave x-default out for that cluster, or point it at the version you would most want unmatched visitors to read. Do not fall back to the home page.
The fix, step by step
Step 1
Decide what unmatched visitors should see
Look at who reaches you from outside your target languages and countries, using your analytics country and language reports. Then choose a pattern: a language or country picker, an international version, or letting your main market page double as the fallback. For most sites with one dominant language the last is simplest. Choose a picker only when no single version would serve an outsider reasonably, for example when products or shipping differ completely by country.
Step 2
Choose the fallback address for each cluster
Apply the pattern page by page, so each cluster falls back to its own equivalent: the international pricing page for the pricing cluster, the international version of a product for that product. Only the home page cluster should fall back to the home page or the site-wide picker. Where a page exists in some locales but not the default one, decide whether it needs an x-default at all rather than pointing it somewhere unrelated.
Step 3
Add the x-default line to every member
Add the line in the code or plugin setting that already prints the hreflang block, so it
appears on every page in each cluster with exactly the same address. Use the value x-default
with no variations. If you declare hreflang in a sitemap, add an xhtml:link for the fallback
under every entry instead. Make sure only one tool outputs hreflang, so the page does not end up with
two conflicting fallbacks.
Step 4
Make sure the fallback page is usable
Open each fallback address and confirm it returns 200 without redirecting, is not noindexed or blocked, and has a canonical pointing to itself. A picker page should contain real text and ordinary links to each version, not just a script-driven menu or an automatic redirect. An international page should show prices, delivery options and contact details that make sense to visitors from anywhere.
Step 5
Recheck clusters and keep one fallback each
Run the Hreflang Checker again on a page from each locale and each page type. The missing x-default warnings should be gone, and no cluster should contain two different x-default addresses. Check that adding the fallback has not created new return tag or target errors, which happens if the fallback page does not carry the block itself. Add x-default to your checklist for new page types and new markets.
Keeping the fallback consistent
- Define the default locale once. Keep it in the same configuration as your list of locales, and build the x-default line from it.
- Review when markets change. Launching a new country can change what the best fallback
is. If you add a Spanish site, Spanish speakers outside Spain are no longer unmatched for the
esentry, but everyone else still needs a sensible default. - Keep the picker simple. A chooser page with plain links, a short description of each version and no automatic redirect is easy for people and search engines alike.
- Check after plugin updates. An update that changes the default language setting can move every x-default on the site at once.
1. Is x-default required for hreflang to work?
No. A hreflang cluster without x-default is still valid, and Google will use the language and region entries you have. What x-default adds is control over searchers who match none of your entries, such as someone searching in a language you have not translated into. Without it, Google chooses whichever version it judges best for them. Adding it is quick, which is why audit tools recommend it, but a missing x-default is less urgent than broken return tags or canonical conflicts.
2. Can the x-default be the same URL as my English page?
Yes, and for many sites it is the best choice. The English page is then listed twice in the block: once with its language code, such as en, and once as x-default. Those two lines do different jobs. The en line catches English speakers you have not given a more specific page. The x-default line catches everyone else, such as speakers of languages you do not offer. Both lines must appear on every page in the cluster.
3. Should every page's x-default point to my home page?
No. x-default works per cluster, just like the other entries, so each page's fallback should be the equivalent page in your default or international version. The fallback for a product page is the international version of that product, and the fallback for the delivery page is the international delivery page. Pointing every page at the home page sends unmatched searchers to a page that does not answer what they searched for, and makes the clusters inconsistent.
4. Can I use a page that redirects by location as the x-default?
Google's original description of x-default mentioned home pages that choose a version for the visitor, so it is not forbidden. It is risky in practice, though. Google mostly crawls from the United States and may only ever see one destination, and audit tools will report the address as a redirect rather than a page. A static chooser page with plain links to each version, or an international version that does not redirect, avoids those problems.
5. What should a language selector page contain to be a good x-default?
It should be a normal, indexable page that returns a 200 status and has a canonical pointing to itself. Give it a short introduction in a widely read language, then plain links to each language or country version, labelled in that version's own language, such as Deutsch or Français. Add any useful context, such as which countries each store ships to. Avoid making the page only a pop-up, a script-driven menu or an automatic redirect.
6. Can a cluster have more than one x-default?
No. Each cluster should have exactly one x-default address, and every page in the cluster should name the same one. Two different x-default lines usually mean two tools are writing hreflang, for example a translation plugin and custom theme code, or HTML tags and a sitemap built separately. Keep one source of hreflang output and remove the other. Different clusters can, and normally should, have different x-default addresses, each pointing at its own fallback page.
7. Does x-default affect how my pages rank?
Not directly. Like the rest of hreflang, x-default helps Google choose which of your existing pages to show a particular searcher; it does not raise the ranking of any page. Its value is in making sure searchers outside your target markets land on a page that works for them, such as an international version with sensible delivery information, rather than a page written for another country. That can improve their experience and reduce visitors leaving straight away.
The Hreflang Checker follows each cluster of locale pages and validates return tags, language codes, x-default, sitemap consistency, target reachability and canonical alignment, so missing or conflicting fallbacks are reported per cluster.
Open Hreflang Fixes →