Multi-Language Content Without a Second Website

The proposal always arrives fully formed. A second WordPress install on its own French subdomain, with its own theme, its own plugins and its own editors, so the French team can get on with it without waiting for anybody. It is quicker to start. Nobody argues with that. Six months later there are two websites that disagree with each other: one carries the new pricing page, the other is still running a campaign that ended in March.

That is the failure mode worth designing against. Multilingual content management is not a translation problem wearing a technical hat. It is a structure problem. Teams that treat it as translation end up maintaining two of everything: two content models, two sets of redirects, two analytics properties, and two people who know how the header works and disagree about it.

The position here is straightforward. One site, many locales, with the locale expressed in the URL and in the content model rather than in a separate installation. It costs more in week one and considerably less in year two. There is a genuine exception, named below, but it is narrower than most teams assume and it is almost always commercial rather than technical. It is also a decision about how the site is built, not a plugin you add later.

What a second website actually costs

Duplication looks cheap because the first copy is cheap. Cloning a template and translating forty pages takes a fortnight and feels like progress. But the cost was never in the copy. It is in every change after it.

Each subsequent change has to be made twice, and the second time is always done later, by someone with less context, under less pressure to be exact. That gap is where translation debt begins. Nobody decides to let the French site fall behind. It falls behind because falling behind is the default state, and staying level requires a mechanism that nobody built.

• Navigation, footer and consent text. Every menu change, cookie banner revision and legal link becomes two tickets, and the second one is the one that gets forgotten.
• Redirects and canonicals. Two redirect maps drift apart, and the drift only surfaces when a page starts appearing in the wrong language for the wrong market.
• Forms and their validation. A field added on one site is missing on the other, and the enquiry data stops being comparable a month before anyone notices.
• Design system updates. A component changed centrally has to be reapplied by hand, which is how two sites end up with different button styles and the same brand.
• Security patching. Two installations, two plugin sets, two update windows, and two chances to be the one nobody checked this quarter.
• Measurement. Two properties means somebody has to add them up before answering a question that should have taken one query.

None of this is dramatic. It is a slow tax, and it lands on the same small group of people every month. We have written separately about what it actually costs to maintain the thing you just built. A second installation roughly doubles every line in that reckoning, and adds one that did not exist before: the cost of noticing that the two copies have diverged.

Where the locale lives in the URL

Before anything is translated, decide how a locale is addressed. This is the one decision that is genuinely expensive to reverse, because it is the one that search engines and other people’s links depend on.

Subdirectories, and why they usually win

A subdirectory puts the locale in the path: /fr/, /de/, /es/. One domain, one certificate, one set of DNS records, one accumulation of history. Adding a fifth language becomes a routing change rather than a procurement exercise, which is the difference between a day and a project.

The operational argument is stronger than the search argument, although both point the same way. One deployment pipeline. One place to patch. One place to change the footer. And a locale that turns out not to be worth keeping can be removed by deleting a route and publishing the redirects, which is a much easier conversation than winding down a domain somebody signed a three-year contract for.

Subdomains and country domains

Subdomains and country-code domains both split the site at the DNS level, and both have honest uses. A country domain signals a market clearly and can be a commercial requirement in places where buyers expect to see it. It also means separate certificates, separate configuration, separate crawling and a separate thing to forget about. Choose it because a market demands it, not because it looked tidier on the diagram.

One more thing about codes: do not add a region until you have a regional difference. A plain /fr/ serves everyone reading French. The day Canadian French needs different pricing, different legal wording or a different address format, you add /fr-ca/ and set the fallback. Adding it early gives you two pages to keep level and no reason to.

hreflang is a claim, not a hint

hreflang tells search engines that two URLs are the same page prepared for different audiences. It is a claim about equivalence, and claims can be wrong. When it is wrong the usual symptom is not a penalty. It is the English page appearing in France, or the wrong version being swapped in for half a market while the other half sees the right one.

1. Every set is reciprocal. If the English page points at the French one, the French page has to point back, at exactly the same URL. A one-directional annotation is ignored, and being ignored quietly is worse than being wrong loudly.
2. Every annotated URL is a canonical URL. Never point hreflang at a page that canonicalises somewhere else, and never omit the self-referencing entry. Those two mistakes together account for most of the broken sets we find.
3. The codes have to be real. Language uses ISO 639-1, region uses ISO 3166-1 Alpha 2, and the region part is optional. “en-UK” is not a code; the code is “en-GB”. Invalid values are dropped, so a typo removes a page from the set silently.
4. x-default is the page for everyone else. It should point at the version a visitor gets when no locale matches, usually the source language or a market selector. It is not a synonym for the English page, even where the two happen to share a URL.

Where to put the annotations

Three places are valid: the HTML head, the HTTP response header, and the XML sitemap. For anything past a handful of locales, put them in the sitemap. Six locales means thirty-six annotations on every page in the head, and thirty-six opportunities for a template to emit one of them from stale data. Generated into a sitemap from the same content records that produced the pages, they cannot disagree with the site unless the site itself is wrong. That is a technical SEO decision worth making before the first locale ships, rather than after the third.

Separately, and often skipped: set the lang attribute on the html element of every page. Search engines are not the main beneficiary here. Screen readers use it to pick pronunciation rules, and a page declared as English but written in German is read aloud as nonsense.

Fallback rules decide what a visitor actually sees

Partial translation is the normal condition of a multilingual site, not a temporary one. Something will always exist in three of your five languages. The question is what happens on the other two, and it needs an answer written down before it happens by accident.

Our rule: if a page has no translation for a locale, it does not exist in that locale. Leave it out of that locale’s navigation, out of its sitemap, and out of the hreflang set. Let a visitor reach the source-language page at the source-language URL if they follow a link to it. What you must not publish is a shell, meaning a translated header, a translated footer, and body copy still in English under a French URL.

The second rule concerns redirection. Do not send people somewhere based on their IP address or their browser language without giving them a way out. Plenty of people in Germany prefer to read English. Plenty of people are travelling. Suggest rather than enforce: a dismissible banner offering the other version, with the choice remembered. Forced redirection also damages crawling, because a crawler that is always sent to one locale never sees the rest.

The workflow that keeps locales level

Everything above is structure. Structure without a workflow simply gives translation debt a tidier place to accumulate.

One source language, and a pointer back to it

Pick one source language and mean it. Every other locale is a derivative, and every derivative carries a pointer to the exact revision of the source it was translated from. That pointer is the entire mechanism. Without it, staleness is invisible. With it, staleness is a query anyone can run. It only works if content is stored as fields rather than as one large blob, which is one of several reasons we argue you should stop storing content as a wall of HTML.

Where the derivative lives matters less than whether the link back is machine-readable. A workspace like Acrosite takes one approach to this: editors work in structured fields, and the workspace generates the files, commits them to GitHub and triggers the configured deployment, so the revision a translation was based on ends up in the commit history rather than in somebody’s memory. Any system will do, provided the answer to “which version of the English page is this French page based on” is not a person.

What should mark a translation stale

Not every source edit deserves a retranslation. Fixing a comma should not flag five locales as out of date, and if it does, people start ignoring the flags, which costs you the mechanism you just built. So classify edits at the point of editing: content change, or presentation change. Only the first propagates.

Then decide who acts on the flag. A locale with no named owner is a locale that goes stale, whatever the tooling promises. This is also where the familiar complaint surfaces, the one behind why your content team keeps asking a developer for small changes: if a translator cannot change a string without a deployment ticket, the strings do not get changed. Every hard-coded label sitting inside a component is a future translation nobody is able to make.

Our parent company has written about where drafts live and what stops them, which is the same argument one layer down. A draft that the approver cannot see is a draft that ships late or not at all. Multiply that by five locales and a time zone, and you have described most stalled localisation programmes.

A translation is not a document. It is a claim that a specific revision of another document has been carried across, and it stops being true the moment the source moves.

Where multilingual content management accumulates debt

Debt does not come from translating badly. It comes from five specific, boring, fixable things, and every one of them is easier to prevent than to unwind.

• Strings hard-coded in components. They never appear in the CMS, so they never reach a translation queue. They are also the last thing anyone notices in a locale nobody on the team reads.
• Copy written directly into a locale. A page created in French with no English source has nothing to compare against and no way to go stale, which sounds convenient until somebody asks what the English version should say.
• Media with text baked in. Screenshots, diagrams and social cards carry words. Exported once from a design file nobody can open, they are frozen in one language for good.
• Locale-specific patches. A CSS override for German compound words, a template fork for right-to-left, a plugin that only runs on one locale. Each is reasonable alone. Together they are a second site pretending to be one.
• No owner. Everything above is survivable if one named person reads that locale regularly. None of it is survivable if nobody does.

The system you pick either makes these visible or hides them, and that belongs on the list when you are choosing a CMS. Ask a vendor to show you a stale-translation report during the trial. If producing one requires an export and a spreadsheet, you already know how the second year will go.

What search actually does with all this

Consolidating two sites into one is a migration, and it deserves to be run as one. A redirect map from every old URL to its locale equivalent, one to one wherever a real equivalent exists, and a considered decision for every page where it does not. The migration checklist that protects rankings applies without modification. The only extra step is that every redirect has to land in the correct locale, and the quickest way to get that wrong is to send everything to the locale home page and call it done.

Afterwards, report per locale rather than in aggregate. A blended figure hides the case where one language is growing and another is collapsing, which is the exact thing the structure was built to let you see. Locale-level reporting also changes what you invest in, because it is far easier to argue for content and organic growth in a market when you can show that market’s own numbers instead of an average that flatters it.

One caveat we will state plainly, because it cuts against the rest of this piece: consolidation is disruptive. Moving a live locale onto a new URL structure will unsettle its performance for a period, and anyone who tells you otherwise is selling the migration. The argument for doing it is that the disruption is finite and the duplication is permanent, not that the disruption is imaginary.

Where we would start

If you have one site and one language today, the order is: content model first, URL structure second, translation third. Add a locale field to every content type before you translate a single word, even while there is only one value in it. Retrofitting locale into a model built without it is the expensive version of this project, and it is the version most teams end up doing.

If you already have two sites, do not merge them on a Friday. Take the locale with the least traffic, move it into the main site as a subdirectory, run it for a month and see what breaks. It will be something in the redirect map or something in the forms; it is nearly always one of those two. Then move the next one, carrying the list of things you learned.

And the reversal condition, because there is one: if a market needs different products, prices that must not be visible elsewhere, and its own legal entity, then it needs its own site and the duplication is the point rather than the problem. Everything else is one site with locales inside it. If you are looking at two installations and trying to work out which way to go, tell us what you are running and which pages currently disagree.