Multilingual WordPress projects have a habit of accumulating plugins: one for translation management, another for language switching in the menu, a third because the first two do not fully cover a specific page type, and so on. Before long the site is carrying real performance weight for a feature that, done well, does not need to be heavy at all. This guide covers five setups and how to choose between them without the plugin pile-up.
What multilingual WordPress needs to get right
Whatever setup is chosen, a genuinely good multilingual site needs three things: a distinct, crawlable URL for every language so search engines can index each one separately, a way for visitors and search engines to find the right language version reliably, and a workflow the team can actually sustain for translating and keeping content updated across languages. Judging any of the five setups below against these three requirements, rather than against how many features a plugin's marketing page lists, is what actually determines whether the setup works well in practice.
Assessing your own site's scale before choosing
Before picking from the five setups below, it helps to be honest about the site's actual scale: how many languages, how much content per language, how independently each language's editorial process needs to run, and how much technical resource is available to maintain the setup afterwards. A small business site with two languages and one content team has very different needs from a larger operation running distinct campaigns and content strategies per market, and matching the setup to genuine scale, rather than to what seems impressively thorough, is what keeps multilingual WordPress manageable rather than becoming its own ongoing burden.
Setup 1: One well-chosen translation plugin
For most small to medium business sites, a single, well-supported multilingual plugin, used properly and without stacking additional plugins on top to patch its gaps, is the simplest and most maintainable route. These plugins handle URL structure, language switching and content duplication across a single WordPress installation. The key discipline is choosing one plugin and learning it properly rather than layering a second one in when the first does not immediately do everything wanted.
A note on cost and time across the setups
A single plugin approach is generally the cheapest and fastest to launch, since it works within an existing WordPress installation without additional infrastructure. Multisite and fully separate installations both increase setup time and ongoing hosting or maintenance cost roughly in proportion to how much independence they provide, which is worth weighing honestly against the actual business need for that independence rather than assuming more separation is inherently a more serious or professional approach to multilingual WordPress.
Setup 2: WordPress multisite, one language per site
Multisite lets a single WordPress installation run several distinct sites sharing core infrastructure, one per language, each with its own content and, to some extent, its own configuration. This suits businesses needing more independence between languages, different content strategies, different editorial teams, than a single-installation plugin setup comfortably allows, at the cost of more complex initial setup and ongoing administration.
Language switchers that do not frustrate visitors
Whichever underlying setup is chosen, the visible language switcher itself deserves attention: it should be easy to find, clearly labelled in each language's own script rather than only in the site's default language, and it should take a visitor to the equivalent page in the new language rather than dropping them back to that language's home page and forcing them to navigate again. This last detail is a small thing that is easy to get wrong with a poorly configured plugin, and it is one of the more common small frustrations that quietly undermines an otherwise solid multilingual WordPress setup.
Setup 3: Fully separate WordPress installations
At the far end of independence, each language can run as a genuinely separate WordPress installation, sharing nothing but a similar design. This gives maximum flexibility per language and isolates any problem in one language's site from affecting the others, but it also means maintaining, updating and securing several sites rather than one, which is a meaningfully larger ongoing commitment that only tends to suit larger, well-resourced multilingual operations.
URL structure: the decision that shapes everything else
Subfolders, the main domain followed by a language code, are the most common and generally recommended structure for most businesses, since they keep the site's overall search authority consolidated under one domain while still giving each language its own distinct, crawlable section. Subdomains or entirely separate domains per language are occasionally justified by specific business needs, such as a genuinely distinct regional entity, but add complexity that most small businesses do not need to take on.
Migrating from one setup to another later
A business that starts with a single plugin and later genuinely outgrows it is not locked in permanently; migrating content into a multisite or separate-installation setup later is a real, achievable project rather than a dead end, though it takes more planning the more content has already accumulated. This is worth knowing at the outset, since it removes some of the pressure to guess correctly forever when first choosing a setup; starting appropriately for the site's current scale, and revisiting the decision if the business genuinely grows into needing more, is a perfectly reasonable approach.
hreflang: telling search engines which version is which
The hreflang attribute tells search engines which page is the equivalent of which in another language, so that a French searcher is shown the French version and a German searcher the German one, rather than search engines guessing or defaulting to the wrong language for a given audience. Google's guidance on managing multilingual sites covers this in detail. A good multilingual plugin implements hreflang automatically; a DIY setup needs this configured deliberately, since it is easy to get wrong and the mistakes are not always obvious without technical testing.
Right-to-left languages, including Arabic
WordPress core has solid support for right-to-left languages, but individual themes and plugins vary considerably in how well they actually handle mirrored layouts, and a theme that looks polished in a left-to-right language can reveal awkward, unmirrored elements once switched to Arabic or another right-to-left language. Testing a specific theme's right-to-left rendering thoroughly, on real pages with real content rather than a generic demo, before committing to it for a right-to-left market is genuinely worth the time. WordPress's own internationalization documentation is a useful technical reference here.
Translation workflow: the part plugins do not solve alone
No plugin removes the actual work of producing good translations; it only manages where that translated content lives and how it is displayed. Deciding who translates, how translations are reviewed before publishing, and how updates to the original language get flagged for translation into the others, is a workflow question that needs answering regardless of which technical setup is chosen, and getting it wrong produces a multilingual site with stale, inconsistent content across languages even when the underlying technology works perfectly.
Performance across a multilingual setup
Every plugin added to manage multiple languages carries the same performance weight any plugin does, and multilingual sites are particularly prone to accumulating several at once, as covered at the start of this guide. Our broader guide on speeding up WordPress without a pile of plugins applies directly here: auditing which multilingual-related plugins are actually still needed, and consolidating onto one well-chosen solution rather than several overlapping ones, recovers real performance that a multilingual site otherwise quietly loses.
Choosing between the setups for your business
A single translation plugin suits the majority of small and medium business sites well, and is worth defaulting to unless there is a specific reason to need more independence between languages. Multisite becomes worth considering once different languages genuinely need different editorial teams or content strategies rather than mirrored content. Fully separate installations are rarely justified below a fairly large, well-resourced multilingual operation, and most businesses considering them are better served by one of the simpler options above.
A note on content that should not be directly translated
Not every piece of content translates cleanly word for word between languages and cultures; pricing conventions, legal disclaimers, and even the tone that reads as professional can differ meaningfully between markets. Treating translation as adaptation rather than pure conversion, particularly for key service and pricing pages, produces content that reads naturally to each audience rather than obviously translated, which matters more for trust than most businesses initially expect.
Keeping languages in sync over time
A common failure mode months after a multilingual site launches is that the original language keeps getting updated while translations quietly fall behind, since updating every language every time takes more discipline than updating one. A simple process, flagging pages for translation review whenever the source language changes, and periodically auditing for pages that have drifted out of sync, keeps a multilingual WordPress site from slowly becoming inconsistent across its languages without anyone deciding that should happen.
What automatic translation tools genuinely do well
Modern machine translation has improved considerably and can be a genuinely useful starting point for high-volume or lower-priority content, product descriptions across a large catalogue, for instance, where human translation of every single item is not realistic. The judgement call is distinguishing this kind of content from customer-facing pages that carry real weight for trust and conversion, service descriptions, pricing terms, key policy pages, where the cost of a slightly awkward or technically wrong translation is higher and human review earns its cost more clearly.
Currency and regional formatting alongside language
Multilingual WordPress projects often need to solve currency, date formatting and other regional conventions alongside the language itself, since a visitor reading their own language but seeing an unfamiliar currency or date format still experiences friction, even if the words themselves are correctly translated. Most established multilingual plugins handle at least basic regional formatting alongside translation, which is worth checking specifically when evaluating a plugin rather than assuming translation alone covers the full regional experience a visitor actually needs.
SEO considerations specific to multilingual sites
Beyond the hreflang implementation covered earlier, a multilingual site needs each language's content to be genuinely useful and well-optimised in its own right, not simply a mechanical translation of keywords that were researched only in the original language. Search behaviour and the specific phrases people actually use often differ meaningfully between languages, even for the same underlying product or service, so treating each language's content as deserving its own keyword research, rather than a direct translation of the original, produces better results in that language's search results.
Getting multilingual WordPress right from the start
Choosing the right setup for the site's actual scale, rather than defaulting to the heaviest option out of caution, avoids most of the plugin bloat that makes multilingual sites slow. Our WordPress development service builds multilingual sites with this discipline from the outset. Get in touch if you are planning a multilingual site or untangling one that has grown unwieldy.