Skip to content
igaminger
Let's talk

Technical SEO

Can Googlebot See Your Casino Site? A Hands-On Test

By the iGaminger team · · 10 min read

Most casino SEO checklists tell you to “make sure search engines can access your site.” None of them tell you how to check.

This one does. You need a terminal, Search Console access and about 30 minutes. At the end you will know whether Google sees your real pages, or a 403, a redirect, an age modal or an empty shell.

Why this matters more for iGaming than for most niches: you are often legally required to block some countries, show an age gate before anything else, and put a firewall in front of everything. Each of those can turn your site into a closed door for Google, and nothing in your analytics will warn you.

From our own work. An online casino built as a React single-page app, about 6,000 URLs, targeting Europe and the CIS. Only around 1,080 pages (18%) were indexed, and Search Console kept showing “Crawled - currently not indexed” and “Discovered - currently not indexed”. The content was fine. The problem was the HTML the server sent: titles, H1s, game descriptions and some internal links were all created by JavaScript in the browser, so the first thing Google received was nearly empty. The full story, with numbers, is in our case study.

What you are testing

Googlebot crawls mostly from US IP addresses. It does not click buttons, does not keep cookies between requests, and runs JavaScript in a separate step that can fail or be delayed. So your site has to pass four checks:

  1. Does the server answer Googlebot with a 200 and the real page?
  2. Is the content in the HTML, or does it only appear after JavaScript runs?
  3. Does an age gate or consent banner sit on top of the content, or replace it?
  4. Does a firewall treat Googlebot differently from a normal visitor?

Test 1: What status code does the page return?

Fetch your key pages with a Googlebot user agent and look only at the status and redirects:

curl -s -o /dev/null -L \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -w "%{http_code} %{url_effective} redirects:%{num_redirects}\n" \
  https://example.com/slots/

Run it for the homepage, a category page (slots, live casino, sportsbook), a game or event page, and a bonus page.

What you want: 200, the same URL you asked for, redirects:0.

Red flags:

  • 403 or 429: a firewall is blocking the request.
  • 302 to /blocked/, /not-available/ or a country page: geo logic is running before the page loads.
  • 200 on a URL that is clearly an error page (a “soft 404”).

Do this from a server in the US, not your laptop. Googlebot’s location is the point. A cheap cloud VM or a VPN exit in the US works.

A caveat on this test: curl with a Googlebot user agent only shows what your site serves to anyone claiming to be Googlebot. Well-configured firewalls verify the real thing by IP, so they may treat your test differently from real Googlebot. Test 4 closes that gap.

Test 2: Is the content in the raw HTML?

Googlebot reads the HTML first. If your lobby, bonus list or odds are built by JavaScript, the first pass sees almost nothing.

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/slots/ -o raw.html

grep -o "<title>[^<]*" raw.html
grep -o "<h1[^>]*>[^<]*" raw.html
grep -o "<a [^>]*href" raw.html | wc -l

You are looking for three things:

  • A real <title> and <h1>.
  • Real text about the page, not only a loading spinner or an app container (<div id="root"></div>).
  • Links to your game pages in the HTML. Count them. A lobby with 400 games and 12 links in the raw HTML is a problem.

Then compare with what Google actually rendered. In Search Console, open URL Inspection, enter the URL, click Test live URL, then View tested page. Check the HTML tab and the screenshot. If the screenshot shows a modal or a blank page, that is what Google sees.

Two iGaming-specific traps:

  • Game iframes. If the only substance of a slot page sits inside a click-to-play iframe, Google has almost nothing to index. The text around the game (provider, RTP, features, how to play) has to be in the page itself.
  • Infinite scroll in lobbies. Googlebot does not scroll. Every game beyond the first screen needs to be reachable through paginated URLs (/slots/?page=2) with normal links.

CSR vs SSR: why the raw HTML test matters

There are two ways a page gets its content.

  • Server-side rendering (SSR), or static generation: the server sends finished HTML. Googlebot reads the text and links straight away.
  • Client-side rendering (CSR): the server sends an almost empty page and a JavaScript bundle. The browser builds the content afterwards. Google does render JavaScript, but as a second, slower step with its own failure modes (blocked scripts, timeouts, content that needs a click).

Casino and sportsbook front ends are often single-page apps, because lobbies, odds and bet slips are interactive. That is fine for players. For SEO, the rule is simple: anything you want indexed (page text, internal links, title, canonical, structured data) should be in the HTML the server sends, with JavaScript adding the interactive layer on top.

What it looked like on that casino. Opening game pages with JavaScript switched off in Chrome DevTools gave an almost empty layout. Some navigation items were click handlers instead of real <a href> links, so Google had no reliable path to many game pages. Titles and H1s were set by JavaScript, so the raw HTML and the rendered page disagreed.

What we changed. We moved the main templates to server-side rendering: game pages, provider pages, categories and key promo landing pages. Title, meta description, H1, canonical and the main text now arrive in the first HTML response, and menus use standard anchor links. We did it template by template instead of rebuilding the whole platform, because the developers (reasonably) did not want to touch an app that was already live everywhere.

It was not painless. We had to keep the server HTML and the client app consistent to avoid hydration mismatches, deal with a cache that kept serving old HTML after deployment, and keep the game components interactive.

What happened. Over about three months:

Metric Before After
Indexed pages 1,080 (18%) 4,320 (72%)
Organic clicks per month 8,500 21,000
Impressions per month 180,000 490,000
Keywords in the top 10 120 380

Average CTR dipped slightly (4.72% to 4.29%), because the site started appearing for many more queries, including at lower positions.

The lesson is not “React is bad for SEO”. Google can render JavaScript. But when thousands of pages depend on it, every page is a small bet that rendering works. SSR for the pages that matter removes the bet.

Tools that show the difference

You do not have to do this by hand with curl. These tools fetch a page both ways and show you what JavaScript added:

Tool Best for Notes
Screaming Frog SEO Spider Whole-site crawls Turn on JavaScript rendering and store both raw and rendered HTML, then use the “Show Differences” view and the JavaScript filters (for example, an H1 that exists only after rendering).
Rendering Difference Engine One page, fast Free browser extension that compares the response HTML with the rendered HTML.
Source vs Render SEO Quick head-tag check Free Chrome extension. Flags changes to title, canonical, meta robots and H1.
Keyword.com JavaScript SEO Analyzer No install Free web tool. Loads the URL as plain HTML and in headless Chrome, and shows how much of the page JavaScript injects.
Google Search Console, URL Inspection What Google really rendered The only source that shows Google’s own view.

For a full audit use a crawler (Screaming Frog, or a cloud crawler like Sitebulb, JetOctopus or Botify on large sites). For a spot check, an extension is enough. Always confirm important pages in URL Inspection, because third-party tools use their own browser and can differ from Google.

On the casino project we used Screaming Frog twice, once in Text Only mode and once with JavaScript rendering, and compared titles, H1s, internal links and body text. Chrome DevTools with JavaScript disabled and Search Console’s URL Inspection confirmed it page by page, and Ahrefs tracked the ranking changes afterwards.

Test 3: Is the age gate hiding the page?

Open your site in a private window with cookies cleared, as a first-time visitor would, then check what the raw HTML contains:

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/ | grep -ci "slots"

Replace slots with a word that should be all over your homepage. If you get 0 and the page is just an age modal and a script tag, Google cannot read your site.

Two designs exist for age gates:

Design What Googlebot gets Risk
Overlay. Full page in the HTML, gate drawn on top with CSS/JS. The full content. Low. Same HTML for everyone.
Replacement. Gate is the page. Content loads after the click or after a cookie is set. The gate only. High. Google indexes your age modal.

A tip you will see in many guides is to detect Googlebot by user agent and skip the gate for it. That can work technically, but it means you serve different things to bots and people, which is exactly what Google’s cloaking policy is about. Our default advice is the overlay design: the same HTML for everyone, no branching on user agent. Whichever way you go, get your compliance team to confirm it matches your license conditions.

Test 4: Is a firewall treating Googlebot differently?

Cloudflare, Akamai, Imperva and similar tools challenge or block traffic that looks automated. Real Googlebot should be allowed, but rules drift, and “bot fight” settings sometimes catch it.

Check it in two places:

  1. Verify what is real Googlebot. Anyone can fake the user agent, so Google tells you to verify by IP: reverse DNS on the requesting IP must resolve to googlebot.com or google.com, and the forward lookup of that name must return the same IP. Google also publishes its IP ranges as a JSON file. Your firewall should allow requests that pass this check, and your logs should show them.

  2. Look at Search Console, not just logs. Open Settings, Crawl stats. Check:

    • By response: any share of 403, 429, 5xx.
    • Host status: robots.txt fetch and server connectivity problems.
    • By Googlebot type: whether smartphone Googlebot is the one getting errors.

If you also care about AI search, check robots.txt and your CDN settings for crawlers like OAI-SearchBot, GPTBot, PerplexityBot and ClaudeBot. Some CDNs block AI crawlers by default, so a site can disappear from AI answers without anyone deciding that.

Test 5: Geo-blocking

If you block countries, decide what a blocked visitor sees:

  • A public layer that works everywhere (game info, guides, general promotion text, responsible gambling pages), with blocking only on registration, login, cashier and game launch. Google can index the public layer and users in blocked regions can still read it.
  • A hard block page for the whole site. Google indexes the block page. Your rankings in every market suffer, including the ones you serve.

Check with the curl test from Test 1, run from a US server, then from a server in each market you target. The responses should match the licensing logic you intended, and Googlebot’s US fetch should not receive a block page for content you want indexed.

How to prioritize what you find

Not every finding deserves the same urgency. We use this order:

Priority Finding Why
P0 - fix this week Googlebot gets 403/redirect/block page on money pages. Raw HTML is empty. Age gate replaces content. Nothing else matters if pages are not readable.
P1 - fix this month Lobby links missing from HTML. Game pages that are only an iframe. Intermittent 429s in Crawl stats. Pages are readable but poorly discovered or thin.
P2 - plan it Redirect chains, inconsistent canonicals, missing hreflang return tags. Efficiency and consolidation problems.
P3 - housekeeping Minor markup warnings, image sizes. Small gains.

Your 30-minute checklist

  • Status codes of 5 key URL types, from a US server.
  • Title, H1 and link count in raw HTML for the same URLs.
  • URL Inspection live test on the homepage and one game page.
  • Age gate: overlay or replacement?
  • Crawl stats: 403, 429, 5xx share.
  • Firewall rule for verified Googlebot.
  • Geo rules: what does a blocked visitor see?
  • AI crawlers: allowed or blocked on purpose?

When it is worth getting help

If tests 1 to 4 turn up problems and your dev team and compliance team disagree about the fix, that is the situation a technical audit exists for. We do these for casino, sportsbook and iGaming platform sites, and the report ends with a prioritized list like the one above, not a 90-page export. See our technical SEO for iGaming service or write to us.