Because you probably never told it which version belongs to which audience. Search engines see several similar pages and have to guess. Hreflang is the annotation that removes the guessing. It maps each version of a page to a language and, if you want, a country.
This is one of those technical details that stays invisible until it costs you money. A German customer lands on your English page, bounces, and you never find out why. Nothing looks broken in your analytics. The page just quietly underperforms.
Hreflang is not complicated to understand. It is genuinely fiddly to implement, and the failure modes are silent. Here is what it does, when you need it, and where teams get it wrong.
Hreflang is an attribute that tells search engines about the localized versions of a page. Google Search Central describes the purpose plainly: you use it to tell Google about these different variations, so Search can point users to the most appropriate version for them.
It works as a set of mutual declarations. Your English page says "there is a German version here and a French version here." The German page says the same about its siblings. Together they describe one group of pages that mean the same thing in different languages.
Important distinction: hreflang is not translation and it is not a ranking boost. It does not make your German page rank better in Germany. It helps the right version get shown to the right person, which usually improves the numbers that actually matter to you.
Only if you have more than one version of the same content aimed at different languages or regions. One site, one language, one market means you can close this article and go do something else. Nothing here applies to you.
You need it if you have translated pages, and you also need it in a case people forget: same language, different country. An English page for the United States and an English page for the United Kingdom look like duplicates to a search engine unless you say otherwise.
That second case is where most avoidable damage happens. Two near-identical English pages compete with each other, split their signals, and neither one wins. Hreflang plus a correct canonical setup is what keeps them from cannibalising each other.
If you have not translated anything yet and are weighing it up, the strategy conversation comes before the technical one. We covered that side in our piece on whether you should use AI to translate your website.
Language first, region optional, and both use fixed standards. Google Search Central requires language codes in ISO 639-1 format and region codes in ISO 3166-1 Alpha 2 format. So "de" is German, "de-AT" is German as used in Austria, and "en-GB" is English for the United Kingdom.
There is one rule that trips people up constantly. Google states that "you can't specify the country code by itself. The first code stands for the language." A value of "uk" does not mean the United Kingdom. It is the language code for Ukrainian, which is a genuinely expensive typo.
Only add a region when you actually serve that region differently. If your German page is the same for Germany, Austria, and Switzerland, use "de" and stop. Adding regions you do not maintain creates work with no benefit.
Get the values right before you worry about anything else in this article. A perfectly implemented set of tags carrying the wrong codes is worse than no tags, because it confidently sends people to the wrong place.
Three places, and you pick one. Google Search Central lists HTML link elements in the page head, Link headers in the HTTP response, and xhtml:link entries inside your XML sitemap. All three are valid and Google treats them equally.
Use HTML link elements for most sites. They are the easiest to inspect, the easiest to debug, and the easiest for a non-developer to verify by viewing source. That transparency matters more than elegance on a setup this error prone.
Use the sitemap method when the set of pages is large or generated from a database. It keeps thousands of declarations out of your page head, which helps page weight, at the cost of being harder to eyeball. If you go this route, your sitemap hygiene needs to be excellent, which we covered in our guide to getting your XML sitemap right.
Use HTTP headers when the content is not HTML at all, such as a PDF. That is really the only case where it is the obvious choice.
The x-default value marks the fallback page. Google Search Central describes it as the reserved value used when no other language or region matches the user's browser setting, and recommends it for specifying the fallback for users whose settings do not match any of your localized versions.
In practice it usually points at your main English page or a language selector page. Someone browsing in Finnish, on a site with no Finnish version, gets sent somewhere sensible rather than to whichever version the search engine guessed.
It is optional and we include it on every multilingual build. The cost is one extra line and the benefit is that the long tail of unmatched visitors gets a deliberate destination instead of an accidental one.
Almost always because the links are not mutual. Google Search Central is unusually blunt about this: "If two pages don't both point to each other, the tags will be ignored." One missing return link takes down the pairing, and nothing in your site visibly breaks.
This is why hreflang decays over time. Somebody adds an Italian page and updates the English page to reference it, but never goes back to update the German and French pages. The set stops being complete, and the annotations quietly stop counting.
Google does allow some slack here. The documentation notes that if maintaining a complete set of bidirectional links becomes difficult, you can omit some languages on some pages, and Google will still process the ones that point to each other. That is a safety net, not a plan.
The fix is to generate these tags rather than hand-write them. When the list comes from your CMS, adding a locale updates every page at once. On managed platforms like Webflow, this is generated for you, which is a strong argument for using the platform's own localization features rather than rolling your own.
They do different jobs and you need both. The canonical tag says which URL is the master version of one piece of content. Hreflang says which language or region audience each URL serves. Confusing the two is the most common way to break a multilingual site.
The rule that keeps you safe is that each localized page should be self-canonical. Your German page's canonical points at your German page, not at the English one. Pointing every language version at a single English canonical tells Google the other versions should not be indexed at all.
Google's own guidance for multi-regional sites recommends using both the canonical element and hreflang together, so the correct language or regional URL is served to searchers. If canonical tags are still fuzzy for you, we explained them in our piece on what canonical URLs do about duplicate content.
Subfolders for most businesses. Google Search Central lists three structures and their trade-offs. A country domain like example.de gives clear geotargeting and makes server location irrelevant, but it is expensive, needs more infrastructure, and targets only one country.
A subdomain such as de.example.com is easy to set up and lets you use different server locations, but Google notes that users may not recognise the geotargeting from the URL alone. A subdirectory like example.com/de/ is easy to set up with low maintenance, with the same recognition caveat.
Our default is the subdirectory. One domain accumulates authority instead of splitting it across several, and it is the cheapest structure to run. We would only argue for country domains when a business has genuinely separate operations per country, with local teams and local legal entities.
One thing to avoid outright: Google explicitly says URL parameters like a loc query string are not recommended for this. If your locale lives in a query parameter, that is worth fixing before you touch hreflang at all.
Less directly, and it still helps. Answer engines like ChatGPT, Perplexity, and Google AI Overviews work from indexed content, so anything that helps the right version of a page get indexed and understood is working in your favour.
The bigger AI-era benefit is structural clarity. A site where each language version is clearly declared, self-canonical, and consistently linked is much easier for any machine to model. Messy duplication is what makes systems pick arbitrarily.
We would not build a multilingual strategy around AI citations though. Do it because your customers read a different language, then implement it cleanly enough that every system, search or otherwise, can tell your versions apart.
Check what you already have before you add anything. View source on one translated page, look for link elements with hreflang, and confirm the codes are valid and that the pages point back at each other. That single check tells you whether your setup is real or decorative.
If you are starting fresh, decide your URL structure first, generate the tags from your CMS rather than by hand, keep every page self-canonical, and add an x-default. Do those four things and you will avoid nearly every problem described in this article.
If you want us to audit an existing multilingual setup, or scope one before you commit to translation, we are happy to walk through it with you. Let's talk. You can find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.