Hreflang Errors on Multi-Market Betting Sites

Why betting brands get hreflang wrong

Licensed gambling brands often run one platform across several regulated markets, each with its own language, currency, license text and sometimes its own domain. The same welcome offer page might exist for Great Britain, Ireland, Ontario and New Jersey, all in English, with different terms. Hreflang is how you tell Google these are alternates for different audiences rather than duplicates.

It is also easy to break. Market pages launch and close with licenses, templates differ between regional builds, and geo logic redirects visitors (and crawlers) away from versions they are not meant to see.

The rules Google applies

From Google's localized versions guide:

• Three methods, pick one. HTML link tags, HTTP headers or sitemaps are "equivalent from Google's perspective".
• Complete sets. "Each language version must list itself as well as all other language versions."
• Return links. "If two pages don't both point to each other, the tags will be ignored."
• Valid codes. Language in ISO 639-1, and an optional region "in ISO 3166-1 Alpha 2 format". "You can't specify the country code by itself", and codes outside those standards, "such as es-419, aren't supported."
• x-default. Used "when no other language/region matches the user's browser setting", and Google suggests it "especially on language/country selectors or auto-redirecting home pages."
• Cross-domain is fine. "Alternate URLs do not need to be in the same domain."
• Language detection is separate. Google "doesn't use hreflang or the HTML lang attribute to detect the language of a page".

Seven common hreflang errors to check

Hreflang and canonical tags together

If you list alternates in XML sitemaps rather than page heads, see our sitemap guide; market versions on separate hosts raise the same questions as sportsbook subdomains.

Google's canonicalization guide says that with hreflang you should "specify a canonical page in the same language, or the best possible substitute language". Its troubleshooting guide lists "language variants without localized annotations" as a common cause of unexpected canonical choices. Note too that Google considers different language versions duplicates "only if the primary content is in the same language", which is exactly the case for several English-language markets. Our canonical guide covers the other causes of unexpected canonical choices. Without hreflang, Google may fold en-gb, en-ie and en-ca versions of the same offer into one cluster and show one of them everywhere.

Geo-redirects and crawler location

Many operators must block or redirect visitors from places where they are not licensed. That is a compliance requirement, and it shapes what Google can crawl. Google's locale-adaptive pages guide says "the default IP addresses of the Googlebot crawler appear to be based in the USA" and that it sends requests "without setting Accept-Language". Its multi-regional guide advises to "avoid automatically redirecting" users between language versions, because "these redirections could prevent users (and search engines) from viewing all the versions of your site."

A practical approach that respects both:

• Give each market version its own URL (ccTLD, subdomain or subdirectory) and annotate them with hreflang.
• Prefer a banner or selector suggesting the right market over a forced redirect, where your license conditions allow.
• Where you must block, block consistently for users and crawlers from the same location. Do not create a crawler-only exception that shows Googlebot content users cannot see.
• Set x-default on the selector or international homepage.

Google's multi-regional guide lists the URL structures: ccTLDs give clear geotargeting, subdomains are easy to set up, subdirectories are low maintenance because they share a host, and URL parameters are not recommended. Search Console's International Targeting report has been deprecated, and Google says country targeting "is no longer supported" while it continues to "support and use hreflang tags".

A correct set

<!-- constructed example: same set on all four pages -->
<link rel="alternate" hreflang="en-gb" href="https://casino.example/uk/welcome-offer/">
<link rel="alternate" hreflang="en-ie" href="https://casino.example/ie/welcome-offer/">
<link rel="alternate" hreflang="en-ca" href="https://casino.example/on/welcome-offer/">
<link rel="alternate" hreflang="de-de" href="https://casino.example/de/willkommensbonus/">
<link rel="alternate" hreflang="x-default" href="https://casino.example/choose-market/">

Each page carries the identical block, including a line for itself, and its own self-referencing canonical. Generating the block from one market-to-URL mapping is the most reliable way to keep sets reciprocal as markets open and close.

Audit steps

1. Export every hreflang set from a rendered crawl or from the sitemap.
2. Validate codes against ISO 639-1 and ISO 3166-1 Alpha 2.
3. Check reciprocity: for every A to B, confirm B to A.
4. Check each alternate URL returns 200, is indexable and self-canonical.
5. Check x-default exists where there is a selector or redirecting homepage.
6. Spot-check URL Inspection's Google-selected canonical on a sample from each market.

Questions technical teams ask

Why is Google showing our UK page to Irish users?

Common causes are missing return links, which make Google ignore the tags, or the Irish page canonicalizing to the UK page. Check that both pages list each other and themselves, and that each is self-canonical.

Can we use hreflang="es-419" for Latin American markets?

No. Google's guide says codes outside ISO 639-1 and ISO 3166-1 Alpha 2, such as es-419, are not supported. Use specific country codes such as es-mx, or plain es.

Do hreflang annotations have to be in the HTML head?

No. Google treats HTML link tags, HTTP headers and sitemap annotations as equivalent. Choose one method per site so the alternates never conflict.