A 13,000-page static games site with no framework, and the robots.txt rule that hid our CSS from Google

This post was drafted by AI. The code, numbers and site are real.

Easy Free Games is a browser games site with 3,800 HTML5 games in 9 languages. It has no framework, no database and no server code. One Python script writes plain HTML files, and Cloudflare Pages serves them.

Here's what that setup looks like, and the parts that were harder than expected.

The numbers

• About 13,000 HTML pages from one build
• 9 languages: English at the root, the others in subfolders like /fr/ and /ar/
• About 2,800 lines of Python in build.py
• One CSS file and one JS file for the whole site

Why static

A games portal is almost all read-only pages. Nothing changes between requests, so there's no reason to render anything at request time. Static files are cheap to host, fast from a CDN, and easy for search engines to crawl.

The build reads the game feeds, picks and sorts the games, then writes every page. Translations live in one JSON file per language, and a small check script flags missing or suspicious strings before anything ships.

Not every page should be indexed

Generating 13,000 pages is the easy part. Asking Google to index all of them on a new domain is a bad idea, because thin pages can drag down the good ones.

So the build has a gate:

• English indexes the top games, plus any game with hand-written content.
• Other languages index a game only when it has text written in that language. A translated page shell around an English description stays noindex.
• Page 2+ of list pages get noindex,follow and stay out of the sitemaps.

Every language uses the same set of games, which keeps the hreflang links consistent. One bug worth mentioning: a hub page recommended games that had no page in that language. Nothing looked broken, because the links quietly fell back to English. A small script that compares the recommended games with the generated files caught it.

A robots.txt rule that blocked our own CSS

The site has no URLs with query strings, so robots.txt had Disallow: /*? to keep crawlers away from junk URLs. Sensible, except the stylesheet and script are loaded as /assets/site.css?v=<build> for cache busting. That one rule told Googlebot not to fetch the CSS or JS, so it was rendering every page unstyled.

The fix is one line, because the longest matching rule wins:

Disallow: /*?
Allow: /assets/

If you version assets with a query string, check your own robots.txt for this.

Games in a locked iframe

The site embeds games from other providers, so each game runs in a sandboxed iframe:

<iframe sandbox="allow-scripts allow-same-origin allow-pointer-lock
  allow-orientation-lock allow-forms allow-modals allow-presentation
  allow-popups allow-popups-to-escape-sandbox"></iframe>

Leaving out allow-top-navigation means a game can't redirect the whole page. allow-popups is there so a click on an ad can still open a new tab.

We also learned to test ads in a clean browser. They looked broken for a while, and the sandbox was the first suspect. The real cause was that the test browser was blocking the ad servers on every site.

The widget

Site owners can show games on their own pages with two lines:

<div class="efg-widget" data-type="top" data-n="6" data-theme="dark">
  <a href="https://easyfreegames.com/">Free online games</a>
</div>
<script async src="https://easyfreegames.com/widget.js"></script>

The script is 3.7 KB, or about 1.8 KB gzipped. A few decisions kept it simple:

• Shadow DOM: the host page's CSS can't break the widget, and the widget's CSS can't leak out.
• No iframe, no cookies, no tracking: it renders thumbnails that link to game pages.
• Static JSON data: the build writes the data files, so the widget needs no API.
• A real fallback: the link inside the div stays there if the script never runs.

You can try the options on the widget page.

A small free tool

The site also has a free gamepad tester built on the browser Gamepad API. It shows every button and axis, measures stick drift and suggests a deadzone. It has no dependencies and makes no network requests.

What I'd do again

For a site that's mostly read-only, a single build script has been easy to change and easy to check. The hard problems were not technical. They were deciding which pages deserve to exist, and proving that things work instead of assuming they do.