Hreflang Implementation Case Studies
Real-world hreflang implementations from Booking.com, Wikipedia, Amazon, and IKEA. How large-scale multilingual sites structure their hreflang tags and what you can learn from them.
Reading about hreflang best practices is one thing. Seeing how the largest multilingual sites on the internet actually implement it is another. The gap between theory and practice is where most hreflang implementations fall apart.
Let's look at how four major sites handle hreflang at scale, what patterns they share, and what you can take away from each approach.
Booking.com: Hreflang at Massive Scale
Booking.com operates in over 40 languages across hundreds of country-specific variants. Their hreflang implementation is one of the most complex on the public web.
How They Structure It
Booking.com uses a combination of ccTLDs, subdomains, and path-based locale targeting. A hotel listing in Paris might have URLs like:
https://www.booking.com/hotel/fr/example-hotel.en-gb.html
https://www.booking.com/hotel/fr/example-hotel.fr.html
https://www.booking.com/hotel/fr/example-hotel.de.html
https://www.booking.com/hotel/fr/example-hotel.ja.html
Notice the pattern: the language code is embedded in the URL path as a suffix before .html. The content (the hotel in France) stays the same, but the language of the page changes.
Their hreflang annotations are delivered via the HTML <head>. On a typical hotel page, you'll find 40+ <link rel="alternate" hreflang="..."> tags, one for each language variant.
<link rel="alternate" hreflang="en-gb" href="https://www.booking.com/hotel/fr/example-hotel.en-gb.html" />
<link rel="alternate" hreflang="fr" href="https://www.booking.com/hotel/fr/example-hotel.fr.html" />
<link rel="alternate" hreflang="de" href="https://www.booking.com/hotel/fr/example-hotel.de.html" />
<link rel="alternate" hreflang="x-default" href="https://www.booking.com/hotel/fr/example-hotel.html" />
Key Takeaways from Booking.com
They use language-only codes for most locales. Rather than specifying fr-FR, de-DE, and so on, Booking.com uses fr, de, ja for most languages. They only use language-region codes (like en-gb) when they have distinct content for different regions of the same language. This keeps the implementation simpler.
They set x-default to a URL without a language suffix. The x-default URL acts as a landing page that detects the user's language and redirects. This is a clean pattern for sites that want a single canonical entry point.
They serve hreflang in HTML, not sitemaps. With 40+ alternates per page, this adds significant markup to every page. But for Booking.com, the tradeoff is worth it -- HTML hreflang is processed immediately when Googlebot crawls the page, while sitemap-based hreflang depends on sitemap crawl frequency.
Scale creates maintenance challenges. When you have millions of pages each with 40+ hreflang annotations, even small bugs multiply fast. Booking.com has been observed with occasional orphaned alternates (URLs that 404) and missing return links. At their scale, this is almost inevitable, but it shows why automated validation matters.
Wikipedia: Language-Based Subdomains
Wikipedia is the textbook example of a multilingual site. Each language edition has its own subdomain: en.wikipedia.org, fr.wikipedia.org, de.wikipedia.org, and so on, covering 300+ languages.
How They Structure It
Wikipedia uses interlanguage links rather than traditional hreflang tags. Their approach predates hreflang (which Google introduced in 2011), but they have since adopted hreflang annotations as well.
Each article includes hreflang tags pointing to equivalent articles in other languages:
<link rel="alternate" hreflang="fr" href="https://fr.wikipedia.org/wiki/Example" />
<link rel="alternate" hreflang="de" href="https://de.wikipedia.org/wiki/Example" />
<link rel="alternate" hreflang="es" href="https://es.wikipedia.org/wiki/Example" />
The URL structure is clean: each language lives on its own subdomain, and the article path is in the local language. The English article at /wiki/Cat links to the French article at fr.wikipedia.org/wiki/Chat. The URLs are not translations of each other -- they're completely independent paths.
Key Takeaways from Wikipedia
Subdomain-per-language is the cleanest URL structure for hreflang. Each language variant has its own origin, which makes hreflang annotations unambiguous. There's no URL path manipulation needed.
Not every article exists in every language. Wikipedia doesn't force a 1:1 mapping. If an article only exists in English and German, only those two languages appear in the hreflang annotations. This is correct hreflang behavior -- you should never point a hreflang tag at a page that doesn't exist.
They use Wikidata as a central mapping layer. Wikipedia's equivalent of a hreflang mapping database is Wikidata. Each concept (like "Cat") has a Wikidata item that links all language versions together. This centralized approach to managing cross-language relationships is worth considering if you run a large multilingual content operation. A single source of truth for which pages are equivalents prevents drift and broken links.
Language-only codes, not regions. Wikipedia uses fr, not fr-FR. Since their content is the same French for all French speakers regardless of country, language-only codes are the correct choice.
Amazon: Country-Specific Domains
Amazon takes a different approach entirely. Each country has its own top-level domain: amazon.com, amazon.co.uk, amazon.de, amazon.co.jp, amazon.fr. These aren't just language variants -- they're entirely separate marketplaces with different inventory, pricing, and sellers.
How They Structure It
Amazon's hreflang implementation reflects their country-first model. A product page includes hreflang annotations pointing to the same product on other country stores (when it exists):
<link rel="alternate" hreflang="en-us" href="https://www.amazon.com/dp/B0EXAMPLE" />
<link rel="alternate" hreflang="en-gb" href="https://www.amazon.co.uk/dp/B0EXAMPLE" />
<link rel="alternate" hreflang="de-de" href="https://www.amazon.de/dp/B0EXAMPLE" />
<link rel="alternate" hreflang="fr-fr" href="https://www.amazon.fr/dp/B0EXAMPLE" />
Note the use of language-region codes everywhere. en-us and en-gb distinguish American English from British English content, which makes sense because the product descriptions, pricing, and availability differ between countries.
Key Takeaways from Amazon
Use language-region codes when content genuinely differs by region. Amazon's US and UK stores sell different products at different prices in different currencies. Using en-us and en-gb (rather than just en) is correct because the content is region-specific, not just language-specific.
ccTLDs provide strong geo-targeting signals on their own. Google already understands that amazon.de targets Germany. The hreflang tags reinforce this, but the domain structure does much of the heavy lifting. If you're choosing between ccTLDs and subdirectories for a new site, know that ccTLDs give you the strongest geo-targeting signal.
Product-level mapping is hard. Not every product exists in every country store. Amazon manages this with their ASIN system -- a global product identifier that works across all stores. If you sell internationally, having a universal product ID that maps across locales makes hreflang generation much more reliable than trying to match products by title or URL.
Amazon uses hreflang in HTML, not sitemaps. With billions of product pages, sitemap-based hreflang would be unwieldy. HTML-based hreflang means each page carries its own annotations, and they get processed whenever the page is crawled.
IKEA: Subdirectory-Based Country Targeting
IKEA uses a single domain (ikea.com) with subdirectories for each country and language combination. This is the most common approach for mid-to-large international sites.
How They Structure It
IKEA's URL pattern uses country code subdirectories:
https://www.ikea.com/us/en/
https://www.ikea.com/gb/en/
https://www.ikea.com/fr/fr/
https://www.ikea.com/de/de/
https://www.ikea.com/ca/en/
https://www.ikea.com/ca/fr/
The pattern is /country/language/. Canada gets two variants: /ca/en/ and /ca/fr/ for English and French. This is a textbook example of handling a bilingual country.
Their hreflang annotations look like:
<link rel="alternate" hreflang="en-us" href="https://www.ikea.com/us/en/p/example-product/" />
<link rel="alternate" hreflang="en-gb" href="https://www.ikea.com/gb/en/p/example-product/" />
<link rel="alternate" hreflang="fr-fr" href="https://www.ikea.com/fr/fr/p/example-product/" />
<link rel="alternate" hreflang="en-ca" href="https://www.ikea.com/ca/en/p/example-product/" />
<link rel="alternate" hreflang="fr-ca" href="https://www.ikea.com/ca/fr/p/example-product/" />
<link rel="alternate" hreflang="x-default" href="https://www.ikea.com/p/example-product/" />
Key Takeaways from IKEA
Subdirectory structure keeps everything on one domain. IKEA builds all their domain authority on a single ikea.com domain rather than splitting it across ccTLDs. This is a major advantage for SEO -- all backlinks point to one domain.
Bilingual countries need multiple hreflang entries. Canada with /ca/en/ and /ca/fr/ is the right approach. Each gets its own hreflang value: en-ca and fr-ca. If you serve multiple languages in a single country, you need an entry for each combination.
Consistent URL patterns enable automated hreflang generation. IKEA's predictable /country/language/path structure means hreflang tags can be generated programmatically from a simple mapping table. No manual annotation needed. If you're designing a new international site, choose a URL structure that makes hreflang generation a lookup rather than a custom process.
Sitemaps as a backup channel
For sites with many locales, consider implementing hreflang in both HTML and XML sitemaps. HTML is processed on crawl. Sitemaps provide a complete map of all alternates even for pages that get crawled infrequently. For guidance on the sitemap approach, see this hreflang sitemaps guide.
Common Patterns Across All Four Sites
Despite different URL structures and scales, these sites share several patterns:
1. Consistent URL Structures
Every site uses a predictable pattern for locale variants. Whether it's subdomains, ccTLDs, or subdirectories, the pattern is consistent. This enables automation. If generating the hreflang URL for a given page requires custom logic for each page, you have a structural problem.
2. Self-Referencing Tags
All four sites include a self-referencing hreflang tag on every page. The English page lists itself as the en alternate. This is required by the spec -- Google uses it to confirm the page acknowledges its own language targeting.
3. x-default for Fallback
Booking.com and IKEA both use x-default to designate a fallback URL for users whose language/region doesn't match any specific variant. This is important for sites with geo-detection or language-selection landing pages.
4. Bidirectional Links
Hreflang requires that if page A points to page B as an alternate, page B must also point back to page A. All four sites maintain this bidirectional relationship (with occasional bugs at scale). Missing return links are the number one hreflang error Google reports.
5. Only Link to Existing Pages
None of these sites point hreflang tags at URLs that 404. If a product or article doesn't exist in a given language, the hreflang tag for that language is simply omitted. Linking to non-existent pages wastes crawl budget and creates errors in Google Search Console.
Applying These Lessons to Your Site
You don't need Booking.com's scale to benefit from their patterns. Here's how to apply these lessons:
Pick a URL structure and stick with it. Subdirectories (/en/, /fr/) are the most common and easiest to manage on a single domain. Use them unless you have a strong reason for subdomains or ccTLDs.
Build hreflang generation into your CMS or framework. Don't add hreflang tags manually. Create a mapping of page equivalents across languages and generate the tags automatically. For implementation details, see how to implement hreflang.
Validate regularly. Every site in this study has had hreflang bugs at some point. Run automated checks to catch missing return links, broken URLs, and incorrect locale codes. The common hreflang mistakes guide covers what to watch for.
Start with HTML hreflang, add sitemaps later. HTML is the simplest delivery method and gets processed on every crawl. If you have hundreds of thousands of pages, add hreflang in XML sitemaps as a supplement.
Follow the hreflang best practices that these large sites have validated through years of operation. The fundamentals don't change with scale.
References
- Google Search Central - Tell Google about localized versions of your page
- Google Search Central - Managing multi-regional and multilingual sites
Generate hreflang tags for your site
Create correct hreflang markup based on your URL structure and target languages.
Related Articles
The best hreflang implementation is the one that generates itself. Build the structure right and the tags follow.
Generate perfect hreflang tags
Create and validate hreflang markup for your multilingual site. Free.
Try Hreflang Generator