If every locale is a literal translation of one template, readers get awkward copy and search engines get a thin cluster of near-duplicates. If every language becomes a completely separate page, editorial updates drift and technical SEO becomes hard to audit.
I ran into that trade-off while building an Astro field guide for a newly released game. One guide query — the location and use of a specific key — needed an English page plus localized versions for Japanese, Spanish, French, German, and Traditional Chinese.
Here is the implementation pattern I used. Keep page structure in Astro and editorial content in data
The page component owns the stable structure: breadcrumb answer summary quick facts route steps FAQ sources related guides
Localized content lives in a typed JSON collection. Each entry carries its own locale, route, title, description, headings, steps, FAQ answers, and source note.
This gives editors one predictable content contract while allowing each locale to use natural terminology instead of inheriting English sentence structure.
It also makes omissions visible. If a localized page is missing a route step, source note, or FAQ answer, that is a data problem rather than a hidden template branch. Build one complete hreflang cluster
The English page lives at the canonical query URL. Localized versions use stable locale folders.
The shared layout turns those entries into absolute alternate links using the production site URL. It also emits an x-default URL that points to the English guide.
Every page in the cluster references the same set of alternates. This matters more than simply placing a language switcher in the visible navigation: the HTML metadata needs to describe the relationship consistently in both directions.
Each page also receives its own self-referencing canonical. Localized pages never canonicalize back to English, because they are intended to stand as distinct language results. Generate structured data from the same content
The article data already contains the information needed for several useful schema types, so I generate JSON-LD from the same source instead of maintaining a second SEO-only copy.
The page emits: Article for the guide itself BreadcrumbList for navigation context FAQPage from the visible questions and answers HowTo only when the page contains an ordered route
The conditional HowTo block is important. Adding process schema to every article would make the markup less accurate.
Because the visible guide and JSON-LD share one data source, a route correction updates both. Localize search intent, not just sentences
A guide page is not merely a translation target. Players in different languages may use different names for the same landmark, key item, platform feature, or region. A literal translation can be grammatically correct while still missing the phrase players actually search.
Each locale therefore owns: its native title and meta description its preferred landmark terminology short answer wording UI labels source and update notes
The underlying route remains evidence-aligned across languages, but the phrasing is written for the reader in that locale.