How We Took an Online Casino From 18% to 72% Indexation

An online casino built as a React single-page app had 6,000 URLs and only 1,080 of them in Google’s index. Moving the key templates to server-side rendering brought that to 4,320 pages and more than doubled organic clicks.

At a glance

Industry	Online casino (B2C)
Markets	Europe and CIS
Languages	English, Russian
Size	About 6,000 URLs
Stack	Custom platform, React SPA
Duration	3 months
Main problem	Important content and links created by JavaScript, poor indexation

Results

Metric	Before	After	Change
Indexed pages	1,080 (18%)	4,320 (72%)	+300%
Organic clicks / month	8,500	21,000	+147%
Impressions / month	180,000	490,000	+172%
Keywords in top 10	120	380	+217%
Keywords in top 3	25	65	+160%
Average position	24.6	16.8	Better

Average CTR fell a little, from 4.72% to 4.29%. That is expected: the site started showing up for many more queries, including at lower positions.

The problem

The platform had plenty of pages: game pages, provider pages, categories and promo landing pages. Most of them were not in the index. Search Console kept showing the same statuses:

• Crawled - currently not indexed
• Discovered - currently not indexed
• Duplicate without user-selected canonical
• Alternate page with proper canonical tag

Some of those are normal. Our first job was to separate normal exclusions from real problems, and to find out whether the cause was content, crawling, rendering or configuration.

What we found

The site rendered almost everything in the browser. When a server received a request for a game page, it sent back a thin HTML shell. Game descriptions, headings and navigation only appeared after JavaScript ran.

That caused four concrete problems:

1. The first HTML response had almost no content. Google could render the page, but only as a second, slower step.
2. Some internal links were click handlers, not <a href> links. Google had no dependable path to many game pages.
3. Titles, descriptions and H1s were set by JavaScript. In some cases the raw HTML had the wrong metadata or none, while the rendered page had the right one.
4. Some game pages loaded their main content late, which made rendering less reliable.

How we checked

• Search Console, URL Inspection on representative game pages: the crawled HTML, Google’s rendered screenshot, indexing status.
• Screaming Frog, crawled twice (Text Only and JavaScript rendering), then compared titles, H1s, internal links, metadata and body content.
• Chrome DevTools with JavaScript disabled. On several templates we got an almost empty layout, which showed how much depended on the client.
• Ahrefs for keyword distribution and ranking changes over time.

What we changed

We wrote a technical spec and worked with the client’s developers.

Server-side rendering for the pages that matter. We prioritized game pages, provider pages, categories and key promo landing pages. Title, meta description, H1, canonical and main text now come in the first HTML response.

Real links. JavaScript-only navigation was replaced with standard anchor links wherever it affected discovery.

Rendering clean-up. We cut unnecessary JavaScript on key pages, fixed inconsistencies and made sure the server HTML and the client app produced the same content, to avoid hydration problems.

Technical housekeeping. Canonicals, XML sitemap structure, robots.txt rules, status codes, redirects and duplicate URLs.

Validation. After release we repeated the crawls, compared raw and rendered HTML again and watched how Google crawled and indexed the pages.

What was hard

• Architecture. The developers did not want to change a SPA that already ran the whole platform, and SSR needed extra development and testing time. We rolled it out template by template, starting with the most valuable ones, to limit risk.
• Hydration. The server HTML and the client app had to match.
• Caching. Some pages kept serving old HTML after release, so cache invalidation had to be reviewed.
• Interactivity. Game components had to stay interactive while the main content was in the server response.

Timeline

Weeks	Work
1	Technical audit, rendering investigation
2	Spec and planning
3-5	Development: SSR and front-end changes
6	Testing: rendering and metadata
7	Release
8-10	Monitoring crawling and indexation
11-12	Evaluating visibility and traffic

The technical changes showed up quickly after release. The indexation and traffic gains took several more weeks.

What we took from it

JavaScript is not the enemy, and Google can render it. But when thousands of pages depend on rendering, each one is a small gamble. For a large casino, putting the content and the links that matter into the first HTML response makes crawling and indexing far more predictable.

It also reminded us not to treat SSR as a ritual. “It uses React” is not a diagnosis. We got here by proving the problem first: what Google received, what the page looked like without JavaScript, and where the two differed.

Want to test your own site?

We wrote up the checks we use in Can Googlebot See Your Casino Site? You can run them yourself in about 30 minutes.

Have a similar site?

If you have a casino, sportsbook or platform with thousands of JavaScript-heavy pages and a low indexation rate, a technical audit is the fastest way to find out why. See our technical SEO for iGaming service or get in touch.