Hreflang for multi-licence casino sites: domains, subfolders and the errors we see on audits

Multi-licence casino brands run near-identical sites for markets with different rules. Hreflang tells Google which version belongs where, if it is set up correctly.

By Daniel Weber · Technical SEO · 3 November 2026 · Updated 12 October 2026 · 7 min read

A casino brand licensed in five European markets often runs five versions of what is essentially the same site: the same games, similar promotions, the same help centre structure. Two or three of them may share a language. Without clear signals, Google treats those versions as duplicates, picks one, and shows it in markets where it is not licensed.

Hreflang is the signal that fixes this, and it is one of the most frequently broken things on the multi-market platforms we audit. Below we cover how the domain structure affects hreflang, the rules that actually matter, and the errors we find most often on casino and sportsbook sites.

Why hreflang is harder on multi-licence casino sites

Hreflang is harder on casino sites because market versions are both very similar and legally different. Two English versions for the UK and Ireland may share 90% of their text but differ on licence details, bonus terms and responsible gambling tools. Google must show each market its own version, and the platform usually generates thousands of URLs per market through game and provider pages.

Three factors make it worse than on a typical ecommerce site:

Uneven page sets. A game licensed in one market may be unavailable in another, and promotions differ by market. Hreflang clusters must reflect the pages that really exist in each version.
Geo logic. Redirects and country blocks can stop Google from fetching the alternates the annotations point to.
Separate teams and platforms. Market sites are often launched at different times on different CMS versions, so URL patterns and canonical logic drift apart.

How hreflang works: the rules that matter

Hreflang works as a set of annotations that tell Google which URLs are equivalent versions for different languages or countries. Each page lists every version in its cluster, including itself, and every listed page must link back. Codes use ISO 639-1 for language and ISO 3166-1 alpha-2 for region. Annotations only count between canonical, indexable pages that return a 200 status.

The rules in Google's documentation on Google Search Central come down to a short list:

Return links. If page A lists page B, page B must list page A. One-way annotations are ignored.
Self-reference. Each page includes itself in its own set.
Valid codes. Language alone (de) or language plus region (de-DE). Never region alone.
Canonical alignment. Every URL in the set is the canonical version of itself. A canonical tag pointing to another market cancels the hreflang.
x-default. Optional, but useful for a market selector or a default version for visitors who match none of your markets.
Signal, not directive. Google can still choose a different version if the signals conflict.

Whiteboard planning session for choosing a domain structure for a multi-market casino site — Choosing between ccTLDs, subfolders and subdomains before writing any hreflang

ccTLDs per licence: when they fit

Separate country-code domains fit when a regulator expects them, when brand trust in the market depends on a local domain, or when each licence is run by a separate entity. They give the strongest country signal and isolate compliance risk. The cost is that every domain builds authority on its own, so link building and technical maintenance are multiplied by the number of markets.

In practice, licensed operators in Spain and Italy run on national ccTLDs, and Spain's rules require licensed operators to use a .es domain. Check current licence conditions with the regulator, because technical requirements change. With ccTLDs, hreflang still matters when two domains share a language, for example an Austrian-facing and a German-facing site, or a Belgian Dutch site next to a Netherlands site.

Implementation tip: generate hreflang for all ccTLDs from one central mapping table rather than letting each market team maintain its own. Cross-domain return links are where ccTLD setups break most often. Our notes on the Spanish market cover the domain question in more detail.

Subfolders on one domain: when they fit

Subfolders on one domain fit when the regulators involved allow it and the same entity operates all markets. Every market benefits from the domain's combined authority, new markets rank faster, and hreflang is easier to keep consistent because one platform generates it. The weakness is that a compliance or penalty problem affecting the domain affects every market at once.

A typical pattern is brand.com/en-gb/, brand.com/en-ie/, brand.com/sv-se/. Keep folder names aligned with hreflang values; it makes audits and log analysis much simpler. The root should return a 200 as a market selector or default version and carry the x-default annotation, rather than redirecting visitors by IP.

Subdomains per market: when they fit

Subdomains per market fit mainly when different markets run on different platforms or providers and must be hosted separately, but a shared brand domain is still wanted. Google treats subdomains as part of the site in many respects, though in our experience they inherit authority less reliably than subfolders. For SEO alone, subdomains are rarely the first choice.

Where they are used, treat each subdomain as a separate property in Search Console, keep the hreflang mapping central, and check that cookies, consent banners and geo rules on one subdomain do not interfere with crawling of another.

Model	Country signal	Authority	Hreflang complexity	Best fit
ccTLD per licence	Strongest	Built per domain	High, cross-domain	Regulator expects local domain, separate entities
Subfolders	Via hreflang and content	Shared	Low, one platform	Same operator, regulators allow shared domain
Subdomains	Via hreflang and content	Partly shared	Medium	Separate platforms under one brand

The hreflang errors we see on casino audits

The hreflang errors we see most often on casino audits are missing return links, invalid codes such as en-UK, annotations pointing to redirected or non-canonical URLs, canonical tags that send every market to the .com, and clusters that pair pages which are not equivalent. Any one of them can cause Google to show the wrong market version for brand and money queries.

Invalid language and region codes

Country codes and language codes are not the same list, and confusing them is the most common code error we find. Swedish is sv, not se, which is the code for Northern Sami. Danish is da, not dk. Czech is cs, not cz. Greek is el, not gr. The United Kingdom is GB, so en-UK is invalid. Google ignores invalid values silently, so a market can run for months with no working hreflang and no error message beyond a crawler report.

Annotations pointing at URLs Google cannot fetch

Hreflang to a URL that redirects by IP, returns a 403 to US visitors or sits behind a compliance wall is effectively broken, because Googlebot crawls mainly from the US. On audits this is often the single largest source of hreflang errors on licensed platforms.

Canonicals that override hreflang

We regularly find market pages with a canonical pointing to the international or UK version, usually because a template default was never changed. Google follows the canonical and drops the market version, whatever the hreflang says.

Same-language versions that are too similar

Pairs such as nl-NL and nl-BE, or de-DE and de-AT, are valid, but if the pages are near-identical Google may fold them together. Make the real differences visible: licence holder and number, responsible gambling tools, payment methods, promotion terms and support details. This is part of proper iGaming content localisation, not cosmetic editing.

Clusters that pair non-equivalent pages

A promotion that exists only in one market should not list the homepage of another market as its alternate. Leave it out of the cluster. The same applies to games unavailable in a market: no page, no annotation.

Annotating markets you are not licensed for

Adding de-CH or en without a region to widen reach can surface a page in countries where you hold no licence. Annotate only the markets you are authorised to serve.

How to implement and monitor hreflang at scale

Implement hreflang at scale from a single source of truth: a mapping table or service that knows which URL exists in which market and generates annotations for every version, preferably into XML sitemaps. Then monitor it continuously, because new games, promotions and releases break clusters every week. A quarterly manual check is not enough for a platform that ships daily.

The routine we set up on multi-market platforms:

Generate hreflang sitemaps per market from the mapping table, and include only canonical, indexable 200 URLs.
Crawl each market weekly with a crawler configured to validate return links, codes and canonical conflicts.
Fetch a sample of alternates from US IP addresses to confirm Googlebot can actually reach them.
In Search Console, compare performance by country for each market property, and investigate any market where another version takes a meaningful share of impressions.
Set the html lang attribute and a content-language meta tag consistently with hreflang, which also helps Bing.

Hreflang is rarely the most exciting part of a technical SEO programme, but on multi-licence casino brands it decides whether each licence gets the traffic it was bought for. When a new licence is added, treat hreflang as part of the launch checklist: the new market enters the mapping table before go-live, every existing market gains the new alternate on the same day, and the first crawl after launch confirms that return links resolve in both directions. Launching a market and adding hreflang a month later means Google spends that month deciding on its own which version to show. Fix the domain model first, generate the annotations centrally, and test them from the crawler's point of view rather than from your own browser.

Frequently asked questions

Is en-UK a valid hreflang value?

No. Hreflang region codes use ISO 3166-1 alpha-2, where the United Kingdom is GB, so the correct value is en-GB. Google ignores annotations with invalid codes rather than correcting them. The same applies to region-only values such as GB on its own, and to codes like es-419, which Google does not support.

Can hreflang target a single province or state, such as Ontario?

No. Hreflang works at language and country level only. A page annotated en-CA is a candidate for all of Canada. For province-level licences such as Ontario, combine country-level hreflang with on-page licensing information, clear regional content and, where needed, geolocation controls on registration and gameplay rather than on the content itself.

Should hreflang be in the HTML head or in an XML sitemap?

Either works for Google, and so do HTTP headers for non-HTML files. On large casino sites we usually prefer XML sitemaps because the annotations are generated in one place, are easy to validate and do not add weight to every page. What matters most is using one method consistently rather than mixing sources that disagree.

Does Bing use hreflang?

Bing has historically relied more on the content-language meta tag and the html lang attribute, alongside other signals such as the domain and server location. Keeping hreflang, the lang attribute and a content-language meta tag consistent covers both engines at little cost, and is worth doing on any multi-market casino site.

Ready to grow organic revenue in regulated markets?

Tell us your GEOs, your platform and where traffic stalls. We come back with a scoped plan, not a sales deck.

Request a free audit See results

Prefer chat? Message us on Telegram