The most common hreflang failure we see on casino sites has nothing to do with the tags. It is a geo-block that hands Googlebot a 403 on the .com because Googlebot crawls from the United States, and every cluster that includes that domain quietly falls apart.
Hreflang for casino sites is the standard specification plus a set of problems that only regulated, multi-licence operators have. This guide covers both, with the code, and with what to test against now that Search Console no longer reports hreflang errors at all.
What hreflang does, and what it will not do
Hreflang tells Google which of your URLs is the right version for a given language and region. It is a signal, not a directive. John Mueller confirmed in May 2025 that hreflang does not guarantee indexing, and that where two variants are the same (his example was fr-fr and fr-be) it is common for Google to pick one as canonical (Search Engine Journal).
Gary Illyes went further in August 2026: hreflang alternates are not indexed "in the proper sense". Google indexes the canonical and stores the alternates as alternate names of it, which it can then swap in when the query and location warrant (Search Engine Roundtable).
Two other facts shape everything below. Google decides a page's language from its visible content, not from lang attributes or the URL. And Google recommends separate URLs per language version over cookies, browser settings or automatic redirects (Google Search Central).
So hreflang does not make a page rank. It makes sure that when a page in the cluster ranks, the version served matches the searcher, which for a casino means the UKGC site appears in Britain and the MGA site appears in Ireland. That is a compliance outcome as much as a traffic one.
Language codes, region codes and the en-gb question
The format is an ISO 639-1 language code, optionally followed by an ISO 3166-1 alpha-2 region code. You cannot specify a region on its own. Codes reserved for other purposes, including EU, UN and UK, are ignored by Google (Google Search Central).
| Market | Correct | Seen in the wild and wrong |
|---|---|---|
| Great Britain | en-GB | en-UK, en-uk, gb |
| Ireland | en-IE | en-EU |
| Germany | de-DE | de-EU, ger |
| Austria | de-AT | de (if a separate DE site also exists) |
| Brazil | pt-BR | pt (when Portugal is a separate site) |
| Canada, French | fr-CA | fr-QC |
| Latin America, Spanish | es-MX, es-AR (per market) | es-LATAM, es-419 |
| Any English speaker not covered | en | en-WW, en-INT |
Case does not matter to Google (en-GB and en-gb are equivalent), but pick one so your crawler reports stay clean.
The en versus en-GB decision is where casino sites go wrong most. The pattern that works: the site licensed for Great Britain gets en-GB, and the global English site gets plain en. The language-only en then acts as the fallback for English speakers in Canada, Ireland, New Zealand and anywhere else you have not given a regional version. If you only have one English site and it is the UKGC one, tag it en-GB and let x-default do the fallback work, but do not pretend a UK-compliant page is your global English page.
Licence-specific domains
Anyone providing facilities for remote gambling to consumers in Great Britain needs a Gambling Commission licence, wherever the business is based (Gambling Commission). The usual response is a separate British site, typically brand.co.uk, with UKGC-specific terms, a UKGC footer, GamStop integration and British payment methods, alongside a brand.com under a Malta or other licence for the rest of the world.
Hreflang works across domains. Google's own examples use different hosts for each version. The cross-domain cluster for a slots category page looks like this:
<link rel="alternate" hreflang="en-GB" href="https://www.brand.co.uk/slots/" />
<link rel="alternate" hreflang="en" href="https://www.brand.com/slots/" />
<link rel="alternate" hreflang="de-DE" href="https://www.brand.com/de/spielautomaten/" />
<link rel="alternate" hreflang="sv-SE" href="https://www.brand.se/slots/" />
<link rel="alternate" hreflang="x-default" href="https://www.brand.com/slots/" />
That block must appear, identically, on all four URLs. The .co.uk page has to list the .com and .se, and they have to list it back. If the two domains are run by different teams on different platforms, this is where the return links go missing, and Google's documentation is explicit that annotations without return links may be ignored.
Two casino-specific consequences. First, the British and global English pages will often be near-identical apart from compliance blocks. That is fine for hreflang, but Google may still fold them into one canonical if the content is the same, so make the differences real: currency, payment methods, bonus terms, licence text, support details. Second, do not point x-default at the .co.uk. A UKGC page with British bonus terms is not the right fallback for someone in Australia.
Geo-blocked markets and Googlebot
This is the failure from the first paragraph. Google says the default IP addresses of Googlebot appear to be US-based, that it also crawls from IPs outside the US, and that it sends requests without an Accept-Language header. On blocking, its guidance is direct: treat Googlebot like any other user from that country. If you block US users, block US-based Googlebot (Google Search Central).
Read that from the casino's side. Almost no European operator holds a US licence, so almost every .com blocks the US. If the block is a 403 or a redirect to a "not available in your region" page at the domain level, the crawler that does most of Google's crawling sees exactly that, on every URL, including the ones that carry your hreflang.
The fix is architectural rather than a tag change. Keep marketing and category pages crawlable from anywhere with a compliant notice for blocked regions, and put the geo-block on registration, deposit and the game launcher. That is what you would show a US visitor who is only reading anyway, and it keeps the .com in the index. Serving Googlebot different content from what a US user sees is cloaking under Google's spam policies, so the page a US human sees and the page US Googlebot sees must be the same page.
If legal insists on a hard block, accept that the .com is largely invisible to Google and leave it out of the clusters, so the licensed sites at least form a complete cluster on their own.
Mirrored markets sharing content
Operators routinely run en-GB, en-IE, en-CA and en-NZ off one English template with a currency swap. Google's guidance for similar content in the same language across regions is to pick a preferred version and use rel canonical together with hreflang so that the correct regional URL is served (Google Search Central).
In practice that gives you two choices. Either accept that Google will canonicalise the mirrors to one URL and let hreflang swap the regional address in at serving time, with the reporting consolidated under the canonical (which is what Mueller described for fr-fr and fr-be). Or make the regional pages differ enough that they stand on their own. For a casino the differences are real if you surface them: licence and regulator, payment methods, currency, bonus terms and wagering, responsible gambling tools and helplines, phone support hours.
The mistake is the middle path: identical content, self-referencing canonicals on each mirror, and an expectation that Google will index all four. It usually indexes one.
Choosing between head tags, sitemap and HTTP headers
Google treats the three methods as equivalent. The choice is operational.
| Method | Best for | Casino-specific pitfall |
|---|---|---|
| HTML link elements in the head | Most page templates | Front ends that inject the head via JavaScript; tags that end up outside the head after a plugin adds markup |
| XML sitemap | Large game libraries (thousands of slot pages times many languages), cross-domain clusters managed centrally | A game removed in one market for regulatory reasons leaves a dead URL in every other market's cluster |
| HTTP Link header | PDFs such as terms, bonus rules and game rules | Nobody remembers the header exists when the CDN config changes |
Use one method per page. Two sources disagree eventually, which is why Screaming Frog flags multiple entries as an issue.
The HTML version, for a German-language game page with a British and global English equivalent:
<head>
<link rel="alternate" hreflang="de-DE" href="https://www.brand.com/de/spiele/book-of-ra/" />
<link rel="alternate" hreflang="en-GB" href="https://www.brand.co.uk/games/book-of-ra/" />
<link rel="alternate" hreflang="en" href="https://www.brand.com/games/book-of-ra/" />
<link rel="alternate" hreflang="x-default" href="https://www.brand.com/games/book-of-ra/" />
</head>
The sitemap version of the same cluster. Each URL gets its own entry, and each entry repeats the full set including itself:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://www.brand.com/de/spiele/book-of-ra/</loc>
<xhtml:link rel="alternate" hreflang="de-DE" href="https://www.brand.com/de/spiele/book-of-ra/" />
<xhtml:link rel="alternate" hreflang="en-GB" href="https://www.brand.co.uk/games/book-of-ra/" />
<xhtml:link rel="alternate" hreflang="en" href="https://www.brand.com/games/book-of-ra/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://www.brand.com/games/book-of-ra/" />
</url>
<url>
<loc>https://www.brand.co.uk/games/book-of-ra/</loc>
<xhtml:link rel="alternate" hreflang="de-DE" href="https://www.brand.com/de/spiele/book-of-ra/" />
<xhtml:link rel="alternate" hreflang="en-GB" href="https://www.brand.co.uk/games/book-of-ra/" />
<xhtml:link rel="alternate" hreflang="en" href="https://www.brand.com/games/book-of-ra/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://www.brand.com/games/book-of-ra/" />
</url>
<!-- and a third <url> block for https://www.brand.com/games/book-of-ra/ with the same four links -->
</urlset>
The .co.uk entry sits in the .com sitemap here for illustration. In production each host carries its own sitemap listing its own URLs with the full alternate set, referenced from that host's robots.txt.
The HTTP header version, for a bonus terms PDF that exists in British and German versions:
Link: <https://www.brand.co.uk/terms/bonus-terms.pdf>; rel="alternate"; hreflang="en-GB",
<https://www.brand.com/de/agb/bonusbedingungen.pdf>; rel="alternate"; hreflang="de-DE",
<https://www.brand.com/terms/bonus-terms.pdf>; rel="alternate"; hreflang="en"
Return tags, self-reference and the promotion problem
Every URL in a cluster must list itself and every other member, with the same set on each. If page X links to page Y and Y does not link back, Google may ignore the annotations (Google Search Central).
Casino sites break return links in three predictable ways. A promotion runs in the UK and Germany but not Sweden, and the template adds the Swedish URL anyway, where it 404s or redirects to the promotions hub. A game is pulled from one regulated market and its page removed, but the other markets keep pointing at it. And a new market launches on a platform whose template lists the other sites, without the other sites being updated to list it.
The rule that prevents all three: a URL only goes into a cluster if it exists, returns 200, is indexable and is canonical to itself. If the Swedish promotion does not exist, the cluster simply has no Swedish URL, and x-default handles Swedish visitors.
Canonical and noindex conflicts
Every hreflang URL must be the canonical. If brand.com/de/slots/ canonicalises to brand.com/slots/, the de-DE annotation points at a page Google will not index, and the cluster is inconsistent. Illyes's August 2026 explanation is the mechanism: the alternates hang off the canonical, so an alternate that is itself canonicalised elsewhere has nowhere to hang.
Where this shows up on casino sites: affiliate landing pages with tracking parameters that are canonicalised to the clean URL but still carry hreflang to the parameterised versions; legacy m. subdomains; staging or CDN hostnames that leaked into the template; and noindexed compliance pages (self-exclusion, complaints procedures) that were bulk-added to the hreflang set because the template applies it to everything. Noindex return links are their own filter in Screaming Frog because they are that common.
Testing in 2026
Search Console's International Targeting report, which used to list hreflang errors and offered site-wide country targeting, was deprecated in 2022. Google's note says it will continue to support and use hreflang, but the reporting is gone (Search Console Help). Nothing inside Search Console has replaced it, so validation now happens in a crawler.
Screaming Frog is the tool we use. Enable hreflang under Config, Spider, Crawl, and configure sitemap discovery and header reading there too if you use those methods. For cross-domain clusters, add the other domains under Config, CDNs, so the spider treats them as internal and follows the return links. The Hreflang tab then filters for non-200 URLs, unlinked URLs, missing return links, inconsistent codes, non-canonical and noindex return links, incorrect codes, multiple entries, missing self-reference, missing x-default and tags outside the head, with bulk exports under Reports, Hreflang (Screaming Frog).
The order we work through:
| Check | Where | What a pass looks like |
|---|---|---|
| Raw HTML from a US IP with a Googlebot user agent | curl or a VPN | 200 and the real page, not a block page |
| Head tags present in the raw HTML, not only after render | View source, or our Chrome SEO audit extension for a quick per-page look | Tags inside the head, one set per page |
| Return links and self-reference | Screaming Frog, Hreflang tab | Zero in Missing Return Links and Missing Self Reference |
| Canonical and indexability of every cluster member | Screaming Frog, Non-Canonical and Noindex Return Links | Zero rows |
| Which URL Google actually chose | Search Console URL Inspection, per market site | User-declared canonical matches Google-selected canonical |
| Which version surfaces per country | Search Console Performance, filter by country and page | The .co.uk gets the GB impressions, the .com does not |
Run the first check before any of the others. If Googlebot in the US cannot see the page, the rest of the report is measuring a page Google does not have.
Where this sits in the wider plan
Hreflang is the plumbing under a multi-market casino, and clean plumbing does not win markets by itself. The market pages still need authority, which is why we wrote about earning links for casino sites, and they increasingly need to be the version an AI answer cites, covered in iGaming SEO for AI search. The same cross-domain and geo-blocking logic applies to crypto exchanges, and if Britain is a core market our UK SEO page covers the regulated-brand side.
If your clusters are throwing errors you cannot trace, or you are about to split a .com into licensed domains, that is what our iGaming SEO and international SEO teams do, and a free SEO review will tell you which of the checks above you are currently failing.
Frequently asked questions
Should a casino use en or en-GB in hreflang?
Use en-GB for a site that is specifically for Great Britain, typically the UKGC-licensed .co.uk, and plain en for an English site meant for everyone else. Language-only codes act as the fallback for English speakers in regions you have not listed. Never use en-UK: UK is not a valid ISO 3166-1 region code and Google ignores it.
Does geo-blocking a country break hreflang?
It can. Googlebot crawls mainly from US IP addresses, and Google says to treat it like any other user from that country. If your .com blocks the US at the HTTP level, Googlebot sees the block page instead of your content, and every hreflang cluster that includes the .com loses its return link. Block registration, not marketing pages.
How do I check hreflang now that Search Console's International Targeting report is gone?
Crawl the site with Screaming Frog with hreflang enabled and review its hreflang filters and the Reports menu exports for missing return links, non-canonical and noindex return links. Use Search Console's URL Inspection to confirm which URL Google chose as canonical, and the Performance report filtered by country to confirm the right version is surfacing.
Can hreflang point across different domains?
Yes. Google supports hreflang between separate domains, which is how a UKGC-licensed .co.uk and an MGA-licensed .com are linked. Each page must list itself and all alternates with fully qualified URLs, and the return links must exist on the other domain. In Screaming Frog, add the other domains under Config, CDNs, so they are treated as internal.
