HREFLang x-default Explained: A Guide for International SEO

In this episode, Bill Scully and Bill Hunt break down the hreflang x-default tag for international SEO. They explain what it does, common mistakes, and why using it correctly matters for global websites. They talk about why you should create a country-language matrix, issues with x-default setup, and how to implement IP redirection and x-default.

They also discuss how Looker Reports can help spot hreflang problems and why a well-planned approach to x-default is key for different markets.


https://spotifycreators-web.app.link/e/lItoJprBaRb

Key Takeaways

  • x-default serves as a fallback for users without a specific region.
  • Many companies misunderstand the purpose of x-default, leading to errors.
  • Building a country-language matrix is important for effective HREFLang mapping.
  • IP redirection complicates the implementation of x-default.
  • Download their Looker report to help identify anomalies in HREFLang performance.
  • An x-default strategy should be part of a well-planned global SEO strategy.
  • Sign up for the HREFLang Error Course to prevent common x-default mistakes.

Catch the Full Episode

YouTube: https://youtu.be/wgY_KpPceE8?si=lS30KWtoMgqAHvDZ

Spotify: https://open.spotify.com/episode/6raGKhi64ll7KpvObsg6l5?si=7N999QWkRuSd9z0F-_Yyow


Show Note Links

Mastering HREFLang x-default – https://internationalwebmastery.com/blog/mastering-hreflang-x-default/

Bill Hunt’s Hreflang Advanced Masterclass – https://learn.internationalwebmastery.com/courses/implementing-hreflang

Free Looker Studio Dashboard – https://lookerstudio.google.com/u/0/reporting/8d5c7d57-6dfd-4092-939a-8a647daece66/page/p_b8g3c3ap6c


Transcript

Bill Scully (00:02)
Welcome to episode 25 of the International Web Effectiveness Podcast. I’m Bill Scully, joined by Bill Hunt, and we focus on the strategies and techniques needed to improve your web presence and manage global websites.

In our last episode, we discussed why SEO should be a team sport. Whether you’re a CEO or part of a digital team, I highly recommend checking that out.

Today, we’re diving into the complexities and common misconceptions around the hreflang x-default element.

If you manage an international website, target different regions, or simply want to strengthen your global presence, this episode is for you. We’ll break down what the x-default tag does, why it matters, and some common mistakes. Plus, I’ll share insights from an article I recently wrote on the topic.

Let’s get started. Bill, how are you?

Bill Hunt (00:53)
I’m good! How about you?

Bill Scully (00:56)
I recently got a question about x-default. I’ve been working with this for a while, so I knew the answer, but I wanted to explore it further—figure out the edge cases, how people are using it correctly or incorrectly. That led me to write an article, which should be published by the time this episode goes live.

Before we dive into the details, I’d love to hear your thoughts on common mistakes you’ve seen with x-default.

Bill Hunt (01:33)
This is a big one. It’s one of the simplest yet most misunderstood aspects of hreflang. I constantly see companies making errors because they don’t fully grasp its purpose.

You did a great job outlining its function in your article, so I’ll let you cover that. But fundamentally, many people think they know what it does, yet when they try to apply it across their often-chaotic global websites, that’s where things go wrong.

This is episode 25, and throughout the series, we’ve talked a lot about the dysfunction we see on international websites. That very dysfunction—especially in decentralized organizations—leads to many of the issues with x-default.

I get two to five questions a week—on LinkedIn or from industry colleagues—saying, “This isn’t working. What’s wrong?” And when I check, the implementation is often flawed.

As SEOs, we have this habit of inspecting the source code whenever we visit a site. I always check hreflang implementations, and it’s surprising how often people get this wrong.

That’s why, in our training—shameless plug—we have an entire course dedicated to common hreflang errors. In fact, I’m currently building out a more in-depth module focused specifically on x-default, incorporating your article and other resources we’ve created.

Bill Scully (03:55)
I didn’t realize you were working on that—sounds great!

To put it simply, x-default serves as a fallback. If you’re using hreflang to define language and region variations, and a visitor doesn’t match any of those, x-default determines which page they’ll see.

It ensures users land on the most relevant content. For example, if someone speaks English but is outside the U.S., they won’t necessarily be directed to the U.S. version of your site. Instead, you can guide them to a global or generic page.

Also, the default page doesn’t have to be a unique, standalone page—it can be an existing page already defined in your hreflang setup, such as your U.S. page or a global homepage.

Bill Hunt (05:00)
Let me simplify it even further, because this is exactly why people struggle to understand how it works.

When I explain this to executives—who sometimes override what their SEO or development teams recommend—I ask one simple question:

Let’s say you don’t have a dedicated website for a smaller country, like Tonga or Fiji. Someone in Fiji searches for your product in English on Google. What page should they see?

Bill Scully (05:37)
Exactly.

Bill Hunt (05:51)

Let’s say you’re Nike, and you have 87 different versions of your website—or maybe even 100. But what if you don’t have a Fiji-specific website? The question is: what should users in Fiji see? More importantly, what should Google display?

I really want to make this clear: this is an instruction to Google, telling it what to present when we don’t have a language or market-specific version available. For users in Fiji, for example, what should Google show in the search results?

That’s where the x-default comes in. It gives us two options. One, we can put up a country-language selector and let users choose. That was the original purpose of x-default—to guide users through selection. Many companies, like UPS, FedEx, and even IKEA, still do this. They either redirect users to a regional site using IP detection or send them to a country selector. Once a user makes a selection, they’re cookied and redirected to the appropriate version.

That’s why, after years of requests, Google introduced the term fallback—which, by the way, you used correctly. This is the technical way of handling situations where there’s no clearly defined version for a user. For example, if someone in New Caledonia searches in French, what version should they see?

This is where people tend to pick and choose solutions, but it boils down to a simple question: if a version of your site doesn’t exist for a particular user, what should be displayed? There’s no setting on your website to manage this, other than specifying that your x-default is the fallback. You can’t rely on IP detection, and you can’t use language detection. This is simply an instruction for search engines: “Show this version when no other match exists.”

I know that was a longer explanation than I intended, but the key point is this: when you don’t have a specific version for a user, the x-default tells Google what to display. Unfortunately, many businesses misinterpret this.

For example, let’s say someone manages a team for the Asia-Pacific region from Sydney. They control 12 different Asia-Pacific sites within their development cluster. They decide to set the x-default for Australia, thinking, “I want people in the region to see the Australian site.”

But then, on the same hreflang cluster, the U.S. team says, “No, we’re the x-default.” Now you have a conflict. And let’s say you also have an English-language global site on a .com domain—what happens then?

This is where things break down. The root issue? Nobody has established a single, decisive fallback for cases where a localized version isn’t available. The fallback should be clear: “If a user doesn’t match a specific version, show them this site.”

Bill Scully (09:27)

That ties back to our planning and strategy discussions. Most companies don’t think about this from the beginning. They start with one website, then expand into different markets over time.

I can see why this issue comes up so often.

Bill Hunt (09:41)

Exactly. And decentralization plays a role, too. Some companies use regional servers. There are countless reasons why this happens. In my Fixing hreflang Errors course, I break down the common causes behind these issues.

Bill Scully (09:45)

Yeah.

Bill Hunt (10:06)

Understanding the root causes of these errors helps prevent them from happening in the first place. When we train companies on hreflang, the very first thing we tell them to do is create a country-language matrix.

It’s a simple, structured approach. Make a chart listing all the versions of your website. In the next column, identify the language each version supports. Then, list the market it serves.

For example, if you have separate English-language sites for the U.K., Australia, and the U.S., you need to explicitly map out how those versions are structured—whether they use subfolders, subdomains, ccTLDs, or another approach. This ensures each version is properly designated.

Now, let’s say you’re a Latin American company. You have a Spanish-language site and a version specifically for Argentina. What happens to users from other Spanish-speaking countries? These nuances become obvious when you build a country-language matrix.

Once you’ve mapped it out, step back and assess:
“I’ve covered 47 markets and five languages. But what about the rest of the world?”

What happens to users who speak Swahili? What about Mongolian speakers? Where do they go?

It’s important to remember that hreflang works at the page level. As Bill mentioned earlier, the x-default should be set for each individual page—not just the homepage.

One of the biggest mistakes companies make is thinking they can manually pick and choose which version to display in certain cases. But there’s no tool that lets you easily override this on a case-by-case basis. The x-default must be applied holistically across the site.

The key takeaway: Define a global fallback version. If you establish this from the start using a country-language matrix, it makes everything else much easier.

By keeping that matrix in mind, you’ll be able to confidently answer the fundamental question: What should be our fallback? Because, at the end of the day, this decision comes down to a single setting—the x-default.

Bill Scully (12:58)
Yeah. One of the common errors I see is different CMS systems marking the x-default as their CMS system’s page. So, you’ll see a U.S. site built on a U.S. CMS, and they’ll set their pages to x-default. Then, the UK CMS system designates the UK pages, and the export follows—that breaks it.

Bill Hunt (13:30)
Because we’ve got a cluster saying A is equal to B. But when you have two different versions of the same cluster—whether you’re using XML sitemaps or hreflang tags—that cluster is supposed to be a mirror image. So, with cross-referencing, the fallback gets negated.

Bill Scully (13:33)
Yeah.

Bill Hunt (13:55)
And because the fallback is negated—since the UK cluster says it’s the UK and the U.S. cluster says it’s the U.S.—it’s effectively removed. Now, it’s up to the search engine to decide what to show in places like Ireland. Do they display the U.S. or the UK version?

Since we have different currencies and slight language nuances, it’s a coin toss. The search engine chooses because no explicit direction was given. And I know you have a lot of questions, as well as statements and recommendations, around the chaos of global websites.

There are many factors to consider. I’ll let you go through your analysis because you made an excellent table in your article. I think you outlined 12 to 15 variations, which is just the tip of the iceberg. Businesses go to market in many ways, but you highlighted the most common challenges and the ones people struggle with the most. I’ll let you take it from here.

Bill Scully (15:14)
Yeah, unfortunately, the table doesn’t translate well to audio. But what I tried to do was map out all the unique situations people encounter—things they might not face if they had a solid strategy in place.

For example, hreflang might indicate that the U.S. English page is the default, with U.S. Spanish and Canadian English as alternates. You can choose to have the fallback be the U.S. if that makes sense for your site. The table also explores different scenarios for blog content, product content, and hybrid language-region structures.

For instance, there are multiple Spanish-speaking regions, and a company based in Spain selling to other Spanish-speaking countries might set Spain as the default. Alternatively, they could have a general Spanish-language page as the default.

Some other considerations include what happens if there’s no Spanish page available—should the fallback be an English page? These are the kinds of questions businesses need to address.

Bill Hunt (16:36)
That’s a great point.

Martin brought this up in Google’s Search Off the Record podcast a few episodes ago. He asked John: “If I have an Austrian site in German and a German site, which one should I set as my x-default?”

If you only have German-language sites, you don’t necessarily need to set an x-default. It’s not mandatory. Since German is spoken primarily in specific regions, you’re not accounting for all the German-speaking expats worldwide or edge cases like someone searching in German from Fiji.

Bill Scully (17:01)
Right, you can choose whatever you want.

Bill Hunt (17:21)
Exactly. But this is where people overcomplicate things, trying to account for every possible scenario.

The recommendation was that if there’s no real economic advantage to choosing one version over another, you might not need an x-default. But if, for example, the Argentine version has more products or a better selection, you might set Argentina as the x-default for all Spanish-language markets.

Now, let’s consider a multinational setup where you have sites for Argentina, Peru, and Mexico. What do we want users to see? If there’s no English version, then we can’t set English as the x-default. Our only choice is to pick one of the Spanish-language sites—if we decide to use X-default at all.

Some businesses start with a global Spanish site, then spin off market-specific sites for Argentina, Peru, and Mexico. In that case, it might make sense to use the global Spanish site as the x-default. But if you don’t have one, don’t create one just for the sake of it. Sometimes, the best option is simply not to set an x-default.

Bill Scully (20:24)
Yeah.

Bill Hunt (20:31) I think that’s one. Then, the other issue that comes up a lot is the most common language. I have to be very careful how I phrase this—the most commonly understood language, not the most spoken or most used, tends to be English. If you had a global English site or wanted to designate one of your English sites as the fallback, that makes sense. English is a language many people can understand.

This is why Martin and his team suggested that maybe you don’t need an x-default if you only have two German-language sites or, in another scenario, three Spanish-language market sites.

Bill Scully (21:06) Right.

Bill Hunt (21:27) It may not matter which one Google shows. But if it does matter—legally, economically, or from a business opportunity perspective—pick the one that gives you and the user the best advantage and select that as the x-default.

Another thing I want you to walk us through is product-related issues. You’ve worked with many companies that have a global site with their entire product portfolio—all 150,000 products sold worldwide. But in each market, only a subset of those products is available. That creates an interesting scenario. Do you want to touch on that?

Bill Scully (22:26) Yes. Many companies can only support English, so they might have a product page for the United Kingdom, one for Australia, and a global page for everyone else. There are different reasons for this—perhaps they don’t want to display pricing that could deter customers in certain regions. In this case, they would have designated pages for Australia and the UK, while the x-default would be a global product page.

Another situation is when companies don’t sell certain products in every region, but people still search for them. Some companies maintain a global site listing all products and indicate where each is available, while others create individual product pages for specific regions. In such cases, the x-default would be the global page.

One mistake many companies make is implementing a virtual root homepage with IP redirection. Have you encountered this? I’m sure you have.

Bill Hunt (23:53) Yes, it’s a huge issue. Let’s take a multinational company like IBM or Nike. They often use IP detection and folder structures for different languages or regions.

For example, a user searches for “Nike running shoes.” If Google serves up a result from the wrong market, and the user clicks it, Nike’s IP logic might detect that they’re in New Zealand and redirect them to the Australian site. This works in theory, but it creates problems.

The global homepage technically doesn’t exist because of the redirect, yet Google still knows about it due to the massive number of backlinks. For high-volume queries like “Nike,” this global page often ranks, even though users get redirected elsewhere. The issue is that companies are using a 302 redirect, which is temporary. That means search engines expect the page to return eventually, so they keep it indexed.

Bill Scully (26:06) Right. And historically, due to the number of links pointing to Nike.com, Google sees it as the homepage.

Bill Hunt (26:21) Exactly. Nike.com is the definitive version of Nike online. But because of the 302 redirect, Google holds onto that page. It still appears in search results, and traffic gets redirected across multiple market sites. This causes reporting issues for market-level SEO teams.

For example, the New Zealand team might not get credit for the thousands of clicks intended for their site because traffic is rerouted elsewhere. The only way to fix this is to properly account for the global homepage as the x-default in the hreflang setup.

Bill Scully (27:35) Right. And what you’re saying is that the link Google recognizes is actually to a virtual page. Because it redirects, you lose credit for the homepage in analytics.

Bill Hunt (27:57) Exactly. The SEO clicks don’t show up in Search Console data, which is a big deal. IT teams don’t see the problem because, in their view, users still land on the site. But from an SEO perspective, you want those clicks to be properly credited to the market-level site.

To resolve this, you need to account for the global homepage in your XML sitemap. Because the page technically doesn’t exist due to the redirect, you can’t use hreflang tags—you have to use an XML sitemap.

Bill Scully (28:49) Right. So when you say you can’t use a tag, you mean it’s impossible because there’s no actual page.

Bill Hunt (28:55) Correct. The tag will never be seen. Since the redirect happens at the CDN level, Google and other search engines never get a chance to crawl the page and see the hreflang tag. However, you can specify this in an XML sitemap.

Bill Scully (29:29) So have you created an hreflang sitemap just for homepages when the CMS already includes hreflang tags?

Bill Hunt (30:15) Yes.

Bill Scully (30:17) 

And you’ve seen it work?

Bill Hunt (30:19) Yes, in over 100 cases.

Bill Hunt (30:19)
Yes, in over 100 cases, this was the only way we could solve the problem. Now, think about this—deconstruct in your mind what you just described.

We have a cluster linking to the homepages of all existing sites. For discussion purposes, let’s say we have 100 versions. All 100 versions are publicly available, listed in our country selector and pulldowns. We have all 100 cross-tagged beautifully in hreflang tags. But we’re missing one—the root page.

What we do in this case, because we’re not the only deviation from the cluster, is add this page as the x-default. We set Nike.com or IBM.com as the x-default for the homepages and then set all other market or language pages accordingly.

Now, if you recall how hreflang works, we’re essentially saying…

Bill Scully (31:37)
Yes.

Bill Hunt (31:42)
All of these pages are interconnected. And now, we have this x-default in place.

One of the most common questions we get is: “All of our homepages already have an x-default tag pointing elsewhere—maybe to the U.S. or a global website. What do we do?” Typically, those with a global site, like Nike, will hard 301 redirect to that global version. But IBM, for example, doesn’t have a single global site. They have a U.S. site, a UK site, a Canada site—each with its own folder structure.

For companies without a proper global site, this is the best solution. Some companies use a 302 redirect from the root based on IP detection, which can cause issues. This is why I often take people to a whiteboard to explain it visually.

I also have an extensive explanation of this case in hreflang Builder, and we cover it in depth in the implementing hreflang course—with diagrams and examples. At every international SEO conference I’ve attended in the last five years, this exact question has come up. Gary and John from Google recommend this approach because, technically, it’s the only viable solution.

The biggest frustration for some is that their homepage already has an x-default pointing elsewhere. If that’s the case, one option is to turn off the hreflang tags on the homepages altogether since they are already covered in the XML sitemap.

From day one—well, day five, because it took Google five days to roll out XML sitemaps—I’ve leveraged sitemaps for this exact flexibility. It allows us to map things in a way that hreflang tags alone can’t.

Now, let’s talk about product pages. You brought up an example earlier, where we need specific mappings for products. Here’s the scenario:

Let’s say I sell a product in two German-speaking markets—Germany and Austria. In my hreflang setup, whether using tags or XML, both pages exist.

The question is: What should be used as the x-default? It depends on the CMS. Some CMS platforms will set Germany or Austria as the parent, making one inherit the x-default. But often, it won’t roll back to a global or English page because there isn’t one.

Bill Scully (35:04)
Right.

Bill Hunt (35:28)
In this case, my recommendation is simple—don’t over-engineer a solution. Just don’t use an x-default.

If you’re using XML sitemaps, you could, in theory, map it to a product category page or a similar product in another market. But for most companies, it’s not worth the engineering resources to force a workaround.

If you’re using hreflang and can’t set override mapping rules, hreflang Builder allows you to create complex one-to-one or one-to-multiple mappings. But in general, I’d rather just skip the x-default in these edge cases.

Bill Scully (36:48)
Yeah, you don’t want to program for every possible scenario, especially ones that barely exist. And if you do need to handle this, hreflang Builder can take care of it. I don’t know of anything else that does that.

All right, I think this is a good place to wrap up—unless you have anything else on your mind.

Bill Hunt (37:22)
No, I think we’re good. Definitely check out the article—that matrix is great. Bill goes into detail about some of the gotchas when following general hreflang standards. I’m also planning to create a module on this because some of these concepts really need to be visualized with charts, graphs, or even crayon drawings.

There are also 15 to 20 other unique hreflang use cases we’ve encountered over the years, and it’s difficult to cover them all in a single article. But check out the article, and let us know if there’s anything missing. This is a great resource to share with developers and managers to help them think about x-default more strategically.

Bill Scully (38:22)
Yeah, and to add to that, x-default isn’t a ranking factor. It simply helps users see a fallback page when there isn’t a targeted version for them. If it’s implemented incorrectly, hreflang won’t work as intended.

While we know hreflang works, there are cases where Google still chooses a different page. There’s no way around that entirely, but there are ways to identify if your hreflang setup isn’t functioning properly. We’ve developed a Looker report that helps track what pages are appearing in different regions and how trends change. This can reveal traffic shifts that align with site changes.

Bill Hunt (39:20)
Since you mentioned the Looker report, in our Building Your Business Case course, we discuss scenarios like the one Bill mentioned—where both we and the client saw a spike in traffic to the U.S. site from Canada.

The Looker report flagged this anomaly, and we investigated. It turned out that the product had originally launched in the U.S., and because of the border proximity, Canadians were seeing U.S. commercials and social media ads. So, they were searching for it and landing on the U.S. site.

When the company launched the product in Canada, the agency failed to implement hreflang. As a result, Canada was essentially operating as a “free agent,” and Google continued directing users to the U.S. page because of all the existing link authority.

Bill Scully (40:19)
Hmm.

Bill Hunt (40:31)
That’s why Canadians were landing on the U.S. page instead of the Canadian one. The Looker report flagged this, and it became the signal that something was wrong. Once they mapped the correct hreflang implementation, the U.S. site stopped cannibalizing Canadian traffic. Google started showing the Canadian page instead, and everything fell into place.

This is one of the best examples of why detecting these anomalies through the Looker report can be so valuable. That report is included in the show notes, and Bill has also written an article on how to use it. It’s a free resource, so there’s no reason not to take advantage of it.

Bill Scully (41:25)
Right. We invite you to check out the article Mastering Hreflang & x-Default. We hope you found this podcast valuable!

If you’re enjoying the show, we’d really appreciate it if you took a moment to rate and review the podcast on your favorite platform. We also want to hear from you! Send us your questions—we’re happy to answer them, and your feedback helps us plan future episodes.

Follow International Web Mastery on LinkedIn and X. You can also join our free Facebook group, and for those enrolled in our trainings, we have a private Facebook group where we actively answer questions.

That’s all I’ve got!

Bill Hunt (42:21)
Cool. See you next time.

Bill Scully (42:24)
All right, thanks. Bye.