A Multilingual Ghost Website: Separating Design, Translations, and Operational Data
When we migrated our own corporate website from a page builder to Ghost CMS, we faced a challenge familiar to many companies serving audiences across several countries or languages: the site had to look equally polished in every language, while still being easy to update quickly and without the risk of breaking something.
At first glance this looks like a trivial task — almost any CMS supports multilingual content out of the box. In practice, though, off-the-shelf solutions almost always force you to choose between two extremes.
The problem: flexibility vs. reliability
The first extreme is handing editing entirely over to a visual block editor. That's convenient for a content manager, but risky for design: one accidental edit inside a block editor and the page structure, spacing, or mobile responsiveness can quietly break. The more custom the design, the higher the cost of that kind of mistake.
The second extreme is hardcoding everything into the code and page templates. That protects the design 100%, but any change to a piece of text, a phone number in the header, or the office hours requires a developer and a deployment. For content that changes once a quarter, that's still tolerable. For content that changes weekly, it no longer is.
Multilingual sites double the pain on both sides: in the first case you have to manually keep the structure in sync across language versions; in the second, every change costs developer time — multiplied by the number of languages.
Our approach: three layers instead of one
The solution we arrived at wasn't to pick a side between flexibility and reliability, but to split the site's content into three independent layers, each edited in its own way, by its own audience.
The design and structure layer. Layout, block composition, animations, responsiveness across devices — all of this stays in the theme code and is never edited through the admin panel. Only developers touch it, and changes go through the normal versioning, testing, and deployment process. This guarantees the design can't drift by accident, no matter who edits the content or when.
The translated content layer. Articles, service descriptions, page copy — this is standard editable content. Each language gets its own version with its own human-readable URL, built from the title in that specific language rather than transliterated from the original — this matters both for how a reader perceives the page and for how search engines see it. Language versions are linked to each other through an internal marker, so the system always "knows" which Russian page corresponds to which English one, and vice versa. Edits at this layer are made by a content manager, with no developer involved — yet each language version remains an explicitly managed, distinct unit.
The operational data layer. This sits somewhere between text and settings: phone number, address, business hours, company details — data that doesn't change often, but changes unpredictably, and can't simply be "baked into the code," because then every change would require a developer. Here we applied a solution that isn't obvious at first glance: this kind of data isn't stored as part of the page itself, but as a separate piece of content, hidden from public access, which the page pulls in when it renders. A content manager edits the values in an ordinary text editor, inside a pre-built form that's protected from "drifting" out of shape — while the design of the page where these values appear stays fully under the developer's control and can't be accidentally broken.
This hidden data unit never shows up in the site's general article listing and never lands in the sitemap for search engines — from a visitor's point of view, it doesn't exist as a separate page at all, but its content is visible exactly where it's meant to be.
What this delivers in practice
For a client, this means a clean separation of responsibilities without losing speed: a marketer or administrator can update the office hours, phone number, or a short piece of text at any time, without waiting on a developer and without risking a broken layout. A developer, in turn, can freely make structural changes to the design without worrying that the next content edit will overwrite them.
For multilingual sites this is especially valuable: adding a new language isn't an architectural overhaul — it's just adding one more set of translations and data on top of an already working scheme.
We apply this approach not only on our own website, but also offer it on client projects where a sophisticated, custom design needs to coexist with content the company itself can keep up to date — without staying permanently dependent on a developer for every small edit.
