A game catalog looks like a client-side application: filters, search, cards, detail pages, and playable iframes. It is still a poor reason to ship the complete content database and ask every crawler—or every phone—to reconstruct the page after JavaScript loads.
I recently localized a Nuxt catalog with 153 games into four languages. The public result is 676 indexable routes, but the architecture has three strict properties: every indexable route is prerendered as complete HTML; missing localized content fails the build instead of falling back to English; the browser does not receive Nuxt Content’s SQLite/WASM engine or the full game records.
Relying only on a crawler means an accidentally missing link can remove a page from the static build. The catalog already has a source of truth, so use it to produce the complete route list.
The base set contains: home, popular, new, search, and four site/legal pages; one page per category; one page per game.
With 153 games and eight categories, that is 169 base routes. A locale mapping applies no prefix to English and /id/, /it/, or /pt-br/ to the other languages. The same English slugs remain stable after the prefix.
Localized 404 pages are also prerendered, but they are noindex and do not enter the sitemap.
This list feeds Nitro prerendering and the sitemap generator. The sitemap is not treated as evidence that pages probably exist; a post-build check resolves every to a generated HTML file.
Game titles, iframe URLs, developers, dates, embed types, and stable slugs are product facts. Translators should not rewrite them.
Descriptions, objectives, controls, tips, category copy, and legal text are localized. A generation step combines those translations with the factual fields and writes the Markdown documents Nuxt Content will consume during the build.
For each non-English locale, the generator expects: 153 game documents; eight category documents; four site/legal documents.
That is 165 documents per locale and 495 localized Markdown files in total. Missing keys, extra slugs, duplicate entries, or fact drift are build errors.
The key rule is simple: an indexable localized route cannot silently borrow English body content. A visible fallback is useful in application chrome; it is dangerous when it creates a page advertised to search engines as a different language.
The catalog can translate its navigation, metadata, controls guide, objectives, and warnings. It does not own every embedded game’s UI.
That boundary should be explicit. The page language changes, while the game iframe may remain in English. Trying to imply otherwise creates misleading metadata and support expectations.
Do not redirect based on Accept-Language or browser settings. Automatic redirects make URLs unstable for crawlers and surprising for people who intentionally chose another language.
Every page needs a self-referencing canonical and a complete alternate set: en; id-ID; it-IT; pt-BR; x-default pointing to English.
The document lang, Open Graph locale, visible copy, and Schema inLanguage must agree. The sitemap repeats the same alternates.
This is a good place for a deterministic verifier. For all 676 HTML files, check: expected html lang; exact canonical URL; all four hreflang entries plus x-default; localized Open Graph locale; Schema language; no unresolved message keys; no known English section headings on non-English pages.