My relationship with hreflang is special: I first wrote about it in 2013 and it became the dominating topic of my early years of writing and speaking at conferences.

Today, more than a decade later, a staggering 80% of my income is still from clients who first contacted me because of hreflang and then stayed for everything else I have to offer. I can really say that I’ve built my entire career on hreflang.

Sometimes I feel like I do not have much more to say about the topic after such a long time, but recently, I had an idea: What if I talk about the things that haven’t been said about hreflang, or at least not clearly enough?

So I tasked Claude with a detailed hreflang research, in order to compile the most interesting questions about hreflang that the current resources and guides do not answer, or where they even contradict each other.

Here we go, Claude interviewing me about hreflang:

Claude: Let’s start with x-default. What should it point to: a language selector, the English version, or the “main” market version? And when is the answer “don’t use x-default at all”?

Eoghan: Most of the time, the answer should be “don’t use x-default at all”. When x-default was first introduced, it was meant for two use cases:

1. Language or country selector pages, like a global homepage that you land on before you choose your language or country version.

2. URLs that redirect users based on their language or location and do not have any content of their own.

People soon started using x-default for more use cases, mainly to specify one existing version as the global fallback. Google’s documentation was later broadened to accommodate this, but I still have my doubts about the usefulness of implementing it that way:

Most websites choose a global English version or their home market here, and Google would most likely pick that version as a global fallback anyhow, based on other signals, like external links or performance history.

I’m not aware of any proven cases of x-default actually changing anything when it comes to picking an existing website version as a global fallback. That’s why I prefer to stick to the two original use cases. Especially if your root URL redirects users based on their language or location, which is often the case on international websites, you should mark it up with x-default instead of “wasting” x-default on something else.

Claude: That’s contrarian. Almost every hreflang guide says “always use x-default.” Several auditing tools flag its absence as an error. I searched extensively for a single case study showing that adding x-default actually changed SERP behaviour and found none. Every claimed benefit is theoretical. Next question:

Your client uses server-side geo-redirects. A user hitting example.com from Germany gets redirected to example.com/de/. But Googlebot crawls from the US. How do you make hreflang work when the bot never sees the German page from the root URL?

Eoghan: One important thing to take care of in this case: The geo-redirect from the root to the language version homepage has to be 302. This is one of the few cases where a 302 is a better choice than a 301 from an SEO perspective.

Also important: The redirect only happens from the root to the language versions, not from one language version to another. The different language versions are correctly marked up with hreflang and the root gets the x-default treatment.

With these signals in place, Google should understand the structure perfectly and it doesn’t matter that it gets redirected to the US version or global English version when it crawls with a US IP.

Claude: This is, as far as I can tell, the only setup where geo-based redirects and hreflang best practices are fully compatible. Several authoritative guides state flatly that there is no path which follows all international SEO best practices while maintaining geo IP redirects. The setup you describe here — 302 from root only, no redirects between language versions, x-default on the root — is the exception they missed. Let’s move on to the next question:

Page A has a canonical pointing to Page B (same language, same site — e.g., a parameter URL canonicalising to the clean URL). Page A also has hreflang annotations. What does Google actually do?

Eoghan: Page A should not have hreflang in this case. One simple and basic hreflang implementation rule is: Non-canonical or non-indexable URLs should never receive hreflang annotations.

What would Google do in this case? I’m not sure, probably ignore either the hreflang annotations or the canonical tag. I’ve seen both happen, and surprisingly hreflang is often the stronger signal.

But it doesn’t really matter what Google would do, as it’s 100% clear what we should do: Remove the hreflang annotations (assuming that the canonical tag is correct and intended).

Claude: Patrick Stox’s 2024 study of 374,756 domains found that Google frequently ignored canonical tags in favour of hreflang URLs. You described the same behaviour in an article published in 2014 (which no longer seems to be live, but is summarised in this piece). The takeaway isn’t that you can rely on one signal overriding the other. The takeaway is that nobody — not even Google — can tell you which signal wins when they conflict. So don’t let them conflict. Next question:

Does hreflang pass or consolidate any ranking signals between pages in the cluster, or is each page ranked entirely independently? Gary Illyes said signals aren’t shared. Multiple guides say the opposite.

Eoghan: One thing we can say for sure is that signals are passed. Are they ranking signals? I don’t know. Maybe they’re just indexing or surfacing signals. But one thing that hreflang definitely does is indicate to Google that there’s a set of URLs with the same content in different languages or for users from different countries. Google may or may not use that signal and it may or may not have an influence on ranking.

Claude: This distinction — between “signals are passed” and “ranking signals are passed” — is one that nobody in the hreflang conversation makes. Illyes says ranking signals aren’t shared within the cluster. Multiple guides say they are. Your framing resolves the contradiction: hreflang signals a relationship. Whether Google uses that relationship to influence ranking, indexing, or surfacing is unclear. Next:

You have three English-language versions of your site — one for the UK, one for the US, and one for Australia. The content is identical except for currency. Do you tag them as en-GB, en-US, and en-AU, or just use en for all three? What actually happens in practice with each approach?

Eoghan: Definitely en-GB, en-US, and en-AU — using “en” for all three would be straight up wrong (you can’t use the same value for more than one version).

However, identical content except for currency is a tricky case. When you want to sell in different currencies, you do need one website version per currency and cannot serve them with just one global version very well, mainly because that’s the only way to add correct structured data for each currency.

The issue with identical content across different versions, even if they are correctly marked up with hreflang, is that Google might just decide to canonicalise all versions to one (because of the identical content). I’ve seen this happen many times.

So the only solution that really works here is to localise the content on each version as much as possible: On the UK version, it should immediately be clear that this version is for UK users, and the same for the US and Australian versions.

This can be achieved by localising the vocabulary, orthography, and even the information displayed. Also, using the actual country names wherever it makes sense (e.g. in title tags, meta descriptions and in the page content and navigation) helps.

So, to make a long story short: The hreflang setup in this case is pretty straightforward, but to make it actually work, it takes more than hreflang.

Claude: This is the answer that every e-commerce guide dances around. They tell you which tags to use, but nobody says “the tags alone won’t save you if the content is identical.” hreflang is a signal — but Google’s duplicate detection is also a signal. When the two collide, duplicate detection often wins. The real work isn’t in the markup. It’s in the localisation. Related:

Google keeps canonicalising your en-US and en-GB pages to one version, collapsing the cluster. The content is 95% identical. How do you stop that from happening?

Eoghan: By reducing the 95% as much as possible.

Claude: Some guides say hreflang on a noindexed page causes Google to ignore the entire cluster. Others report seeing noindexed alternates still appearing in results. What actually happens?

Eoghan: They’re probably all correct, as mixed signals will get mixed results. Sometimes the hreflang annotation is interpreted as a strong indexing signal and the noindex might be seen as an error and ignored. Or the other way around.

It’s impossible to predict Google’s behaviour when we send mixed signals, but it’s possible to align our signals. So: non-indexable pages should not receive any hreflang annotations at all and other pages should not point at them via hreflang.

Claude: That’s the third time in this interview where your answer follows the same principle: don’t try to predict what Google does with broken input. Align your signals. Next question:

Your French site has 2,000 pages. Your German site has 800. The remaining 1,200 French pages have no German equivalent. What goes in the hreflang for those 1,200 pages — nothing, a link to the German homepage, or something else?

Eoghan: French pages that do not have a German equivalent can either have only self-referencing hreflang annotations or no hreflang annotations at all. An hreflang annotation to the German homepage or to another German page that is not the exact equivalent of the French page would be wrong.

There are two main reasons why it’s wrong:

1. hreflang is supposed to point at a version of the same page in other languages or for other countries.

2. hreflang is supposed to be reciprocal. This is not possible when a French page that has no German equivalent points to a different German page.

What actually happens is unclear, but Google will ignore the hreflang annotations on these pages or at least not know what to do with them. Beyond that, although there is no hard evidence, sending unclear signals might harm the trust that Google puts in your general technical setup. The signals you send to Google should always be well thought through and most importantly, aligned.

Claude: Many CMS plugins default to exactly this behaviour — linking untranslated pages to the homepage of the other language. If your plugin does this, it’s not helping you — it’s actively sending broken signals. Fix it or turn it off. Next question:

You have hreflang="de" (German, no region) and hreflang="de-AT" (German for Austria) in the same cluster. A user in Switzerland searches in German. Which page does Google prefer, and is the behaviour actually predictable?

Eoghan: In this case it’s clear that the hreflang=”de” version is also for Switzerland. Language versions without a country value are global, and they’re for users from all countries that do not have their own country version (all countries except for Austria in this case).

Whether Google actually acts on this or not depends on more than just the hreflang annotations though: If the company is from Austria and the “de” version is very weak compared to the “de-AT” version, or if there are other mixed signals, Google might ignore the hreflang signal and show the Austrian version to users in Switzerland.

Claude: A client asks: “Should we put hreflang on every page, or only on pages where we’ve seen the wrong language version ranking?” What’s the correct scope of implementation — full site or surgical?

Eoghan: Full site. Full stop.

Claude: How do you actually validate that hreflang is working — not just that the tags are correct, but that Google is respecting them?

Eoghan: The best way to monitor if hreflang is working is in the GSC performance report: With country filters, you can check if users from certain countries are seeing the right versions of each page.

For language versions, it’s a bit more complicated than for country versions, as you need to analyse the language of the actual queries and compare it to the language of the ranking pages, but it’s also much less likely that results are shown in the wrong language.

Claude: Several of the top-ranking hreflang guides still reference the GSC International Targeting report as the primary validation tool. That report no longer exists. Next question:

You launch a new language version of your site. How long does it realistically take for Google to process the hreflang and start serving the right versions? What can you do to speed it up?

Eoghan: How long it takes depends on factors that have nothing to do with hreflang, mainly how much and how often Google is crawling your site. This depends on your publishing frequency, on the number and quality of links from other websites, and your overall search performance. The best way to speed up discovery and indexing is to have a clean technical setup and to align all signals. I’m not aware of any tricks.

Claude: You inherit a site with broken hreflang that’s been live for two years. Is it better to fix it or remove it entirely and start fresh?

Eoghan: Technically, there’s no real difference between fixing and removing and building from scratch. The fixes should be done in one go. You don’t need several steps from a broken to a correct implementation, because once you know what you’re doing and how to align your signals, hreflang is actually very simple.