Every multilingual WordPress project eventually runs into the same fork in the road: do you duplicate the whole site per language, or do you translate strings and content within a shared structure? Both approaches can produce a clean, well ranked multilingual site. They just cost different amounts of ongoing effort and behave differently with caching and hreflang. Picking the wrong one for your team size and content volume is the most common reason multilingual sites drift out of sync or tank their Core Web Vitals.
Two fundamentally different models
Almost every multilingual plugin or setup falls into one of two camps:
- Full duplication: each language gets its own complete copy of a post, page, or product, with its own URL, its own editable content, and its own SEO fields. Some setups take this further with a full WordPress Multisite network, one site per language, sharing users and plugins but not content.
- String and meta translation: the underlying post structure stays singular. Translators fill in translated strings and, in richer implementations, translated field values, but the site treats the content as one entity with language variants attached.
Well known tools like WPML, Polylang, and TranslatePress each lean toward one side of this line, though several offer hybrid modes. The choice matters less for which specific plugin you pick and more for which underlying model you are committing to, because that model shapes your editorial workflow for years.
Full site duplication
In a duplication model, translating a page means creating a linked copy: same template, new content, its own slug. This is intuitive for editors, because a French page is just a French post that behaves like any other post. It also scales cleanly to Multisite, where each language lives on its own site within the network, sharing plugins and themes but keeping content, media, and caching fully separate.
The tradeoff is duplication of effort. A content change to the English original does not propagate anywhere. If you update pricing, a policy, or a product description, someone has to remember to update every linked translation manually. On sites with frequent content changes, this is the single biggest source of multilingual drift: the English page says one thing and the Spanish page, quietly out of date, says another.
Full duplication tends to suit sites where translations are done once by professional translators and rarely revisited, such as legal pages, brochureware, or marketing sites with infrequent updates.
String and meta translation
In a string translation model, the original content and its translations are tied together more tightly, often through post meta or a translation memory layer. Editors see the English content as the source of truth, and translation happens against that source, sometimes with visual, in-context translation interfaces that show the live rendered page next to an editable overlay.
This model is generally easier to keep synchronized because the connection between original and translation is explicit within the tool. Some implementations flag translations as outdated automatically when the source content changes, which removes the guesswork of full duplication.
The cost here is more indirection. Translators and editors are working through an abstraction layer rather than editing a normal-looking post, which can slow down teams unfamiliar with the tool, and complex custom fields or repeatable blocks sometimes need extra configuration to translate cleanly.
hreflang and the SEO layer
Regardless of which model you choose, search engines need to know that your English, French, and German pages are translations of each other rather than duplicate or unrelated content. This is done with hreflang annotations, either as tags in the page head or in an XML sitemap, pointing each language variant at its siblings and specifying an x-default fallback for unmatched locales.
Get hreflang wrong and you risk two failure modes: search engines treating translated pages as duplicate content and only indexing one, or serving the wrong language variant to users in a given region. A few practical rules hold regardless of plugin:
- Every language variant must reference itself and all its siblings in the hreflang set, not just link one direction.
- URL structure (subdirectory like
/fr/, subdomain likefr.example.com, or separate ccTLD) is a valid choice either way; consistency matters more than the specific pattern. - Canonical tags should point to the correct language version of a page, never collapse all languages onto one canonical URL.
Most mature multilingual plugins generate hreflang automatically once language pairs are configured correctly. The plugin is not the risk; unlinked or partially configured translations are, since a language variant with no declared sibling is invisible to the hreflang system even if the page itself exists.
Maintenance cost, honestly
Maintenance cost scales with three things: how often content changes, how many languages you support, and how tightly your model keeps translations linked to the source. A five language site that updates content weekly under a full duplication model is effectively maintaining five separate sites’ worth of editorial attention. The same site under a string translation model with change tracking cuts a meaningful amount of that overhead, at the price of a less flexible editing experience for translators who want full creative control per locale (marketing copy that intentionally differs by region, for instance, rather than a literal translation).
There is no universally cheaper option. Duplication is cheaper up front and more expensive to keep in sync. String translation is more expensive to set up correctly and cheaper to maintain at scale. Match the model to how often your content actually changes, not to how the demo looked.
Performance and caching implications
Multilingual sites multiply the number of unique pages your cache has to store and serve. Full-page caching through LiteSpeed Cache needs to vary correctly by URL or cookie so a French visitor never gets served a cached English page, and object caching through Redis or Memcached should key cached queries by locale where plugins support it, to avoid one language’s data leaking into another’s cache entry. This is one area where a hosting stack tuned for WordPress caching, which is the model ServerBorn runs on, removes a layer of configuration risk rather than leaving it to guesswork.
Multiplying pages also multiplies the surface area for Core Web Vitals regressions. A heavy translation plugin that adds language-switcher scripts or client side rendering to every page can quietly push INP past the 200 ms threshold or delay LCP if it blocks render. Test your actual multilingual pages, not just the English original, when checking Core Web Vitals; the numbers can differ meaningfully between locales, especially if right-to-left languages or longer translated strings affect layout and trigger CLS.
The takeaway
Choose full duplication when translations are infrequent and editors want full independent control per language. Choose string or meta translation when content changes often and staying in sync matters more than editorial flexibility. Whichever model you pick, get hreflang right from day one, verify caching is locale-aware rather than assumed, and check Core Web Vitals on every language variant, not just the source. The model you choose today is the workflow your editors will live with for years, so weigh maintenance cost as heavily as initial setup effort.