A Games Section That Runs Itself: How Jolopi Uses the PlayKovo Catalog

Most game portals begin with a long list of games and a lot of manual copying. Jolopi started from the opposite end. It keeps no catalog of its own: every game comes from the PlayKovo catalog, and the site's only job is to present those games well. It is a small, concrete example for any website owner who wants a games section without building a games pipeline first.

Jolopi is a browser-based HTML5 game site that puts the game image first. Instead of a plain box-by-box list, the home page opens with a featured-game composition, followed by a discovery grid that mixes tile sizes. There are category filters and a search box. Right now the site lists 134 games, and the interface is available in three languages: Turkish, English and German.

A few details that matter day to day:

• Favorites and recently played games are stored in the visitor's own browser.
• The layout works on phones, and the site supports keyboard navigation and basic accessibility.

The goal was to give the games in the PlayKovo library a different shop window: a visual discovery experience rather than a catalog table.

The game data comes from a JSON source published by the PlayKovo game catalog. Jolopi's server fetches it and serves it from Jolopi's own origin. Each time a fetch succeeds, the server keeps the last good response in a cache.

That cache is what makes the setup forgiving. If PlayKovo is temporarily unreachable, Jolopi keeps running on the last snapshot instead of showing an empty site. A health endpoint reports when the last successful sync happened, which makes it easy to see at a glance whether the catalog is fresh.

The ownership line is also deliberate. Jolopi only reads the catalog. It never writes anything to PlayKovo's database. If a game is added or changed on the PlayKovo side, Jolopi picks it up through the feed.

• Catalog: read-only JSON from PlayKovo, proxied under Jolopi's origin, with the last successful response cached.
• Server: a plain Node.js app (Node 20 or newer) with no dependencies. Pages are rendered on the server, so search engines receive complete HTML.
• Hosting: Vercel, running as a single serverless function. Every request goes through one handler.
• Database and auth: Supabase (PostgreSQL, Frankfurt region). It stores votes, app settings and analytics data, with row-level security policies switched on.
• Admin: a hidden /studio panel, not linked from public navigation. It is used to edit content and SEO records and to bulk-import them as JSON. Only authorized admin accounts can open it.

Keeping the catalog in one place and the storefront in another has a practical benefit. The catalog is fed from a single source, while the storefront can change its design, languages and features on its own schedule.

This part is probably the most reusable for other sites. A game page on Jolopi has its own text for each language: title, description, instructions and controls. The same game can therefore be found in Turkish, English and German, each with copy written for that language rather than a machine-swapped label.

The rest of the SEO setup follows the same idea:

• Page titles and descriptions are translated per language.
• The home page, the content pages and every category each have their own SEO record.
• Titles are short and specific to the page. Descriptions are derived programmatically from the game text, so they stay accurate without someone rewriting them for every game.
• Hosts that are not the canonical domain are kept out of search indexes, which avoids duplicate versions of the site competing with each other.
• Once the site is live, the sitemap URLs are automatically submitted to search engines through IndexNow.

None of this guarantees rankings, and we are not claiming it does. It is simply a clean foundation: complete HTML, one canonical host, unique titles, and text in the language the visitor reads.

You do not need a large team to run a games section. The pattern Jolopi follows is short enough to summarize:

1. Read the game list from a catalog feed instead of maintaining it yourself.
2. Serve that data from your own origin and cache the last good response, so a feed outage does not become your outage.
3. Render pages on the server so crawlers see real content.
4. Keep your own data (votes, settings, analytics) in a separate database and treat the catalog as read-only.
5. Write per-language text where it matters, and derive the repetitive parts like descriptions from the game copy.

If you run a site and want to see how a catalog-driven games section can be organized, the Jolopi game hub is a working reference. The website-owner guides under /developers on PlayKovo cover the publishing side in more detail.

Browse the games on Jolopi or explore the full catalog on PlayKovo.