Why Go Multilingual
A WordPress multilingual site serves your content in more than one language so that each visitor reads your pages in the language they are most comfortable with. For a Canadian business that alone can be a strong reason, since serving customers in both English and French is often expected and sometimes required. For any business with an audience abroad, offering the local language is one of the most direct ways to widen your reach and earn trust. People buy, sign up, and stay longer when a site speaks to them in their own words.
This guide is the strategy layer. It is about deciding how to go multilingual, not clicking through a single plugin. We cover why the decision matters, the four broad approaches you can take, how the main plugin options compare in plain terms, how to structure URLs and use hreflang so search engines send the right page to the right person, how to actually get content translated, what changes for themes and right to left languages, where performance can suffer, and the pitfalls that catch people out. If you want the click by click build, our companion piece on how to make a multilingual WordPress site walks through the setup steps in order, and this guide is the map that sits above it.
The payoff for getting the strategy right is real. A multilingual site done well can rank in each language, feel native to each audience, and stay maintainable as you add content. Done poorly, it becomes a tangle of half translated pages, duplicate content that confuses search engines, and a maintenance burden that grows with every post. The difference is almost always in the choices made at the start, before a single word is translated. That is what this guide is here to help you get right. When you would rather have the decision made and the build handled for you, you can get a free quote.
Four Ways to Build a Multilingual Site
There is no single way to make WordPress speak more than one language, and the right choice depends on how many languages you need, how much content you have, how different the content is per language, and who will maintain it. Before comparing specific plugins, it helps to understand the four broad approaches, because they differ in more than which tool you install. They differ in how your site is structured underneath.
Single site with a multilingual plugin
This is the most common approach and the one most businesses should start with. You keep one WordPress installation and add a plugin that lets each post, page, and menu have a version in each language. Visitors switch languages with a menu or flag, and the plugin keeps the translations linked so search engines understand they are the same content in different languages. Everything lives in one place, so you manage one site, one set of plugins, and one host. For the large majority of sites, from a bilingual brochure site to a fairly large content site, this is the sensible default.
WordPress multisite
WordPress can run a network of sites from one installation, and some teams use that to give each language its own site in the network. This makes sense when the languages are run almost independently, for example by separate regional teams who each want full control of their own content, plugins, and even design, rather than translating a shared set of pages. It brings more separation and more flexibility, but also more to manage, since each site in the network is its own thing. If you are weighing this route, our guide to WordPress multisite explains how a network is structured and who it suits.
Machine translation layer
Some services translate your site automatically, either on the fly as a visitor requests a page or by generating translated copies from your original content with little manual work. The appeal is speed. You can have a site available in many languages very quickly and with little effort. The trade off is quality and control. Automatic translation has improved a great deal and can be perfectly acceptable for informational content, but it can also produce awkward or wrong phrasing in ways that matter for a brand, a legal page, or anything where precision counts. The strongest results usually come from using machine translation as a first draft that a human then reviews, rather than as the finished product.
Separate sites per language
The simplest to picture and often the hardest to maintain: run a completely separate WordPress site for each language, frequently on its own domain such as a country specific address. This gives each market total independence and can be right for large organisations where the content, offers, and even the business differ heavily by country. The cost is duplication. You maintain several sites, several sets of plugins, several hosting setups, and you get none of the automatic linking between language versions that a single site plugin provides, so you have to handle the SEO connections yourself. For most businesses this is more than they need.
Most businesses land on the first approach, a single site with a multilingual plugin, because it balances control and effort well. The rest of this guide leans toward that path while flagging where the others make sense, and the next section compares the main plugins that power it.
Comparing the Main Plugin Approaches
Within the single site route there are a few well established plugin families, and they take genuinely different philosophies to the same problem. Understanding those philosophies matters more than any feature list, because it decides how translating and maintaining your site will feel day to day. We will describe them by how they work rather than by name, since the categories outlast any one product, then compare them qualitatively.
The separate translation model
Some plugins create a distinct copy of each post or page for each language and link those copies together as translations of one another. You edit each language version as its own piece of content. The strength here is control and clarity: every language has its own fully editable page, which is ideal when translations are not word for word and you want to adjust wording, images, or even structure per language. The trade off is that you are managing more individual pieces of content, and adding a language means creating and connecting a version of everything.
The single editor, multiple languages model
Other plugins let you enter all the languages for a piece of content from one editing screen, storing the translations together rather than as separate posts. This can feel tidier for straightforward translations, since a translator works through one interface and the structure stays identical across languages by design. It can be less flexible when you want a language version to differ significantly from the original, because the model assumes the versions mirror each other.
The automatic first, refine later model
A newer style of plugin translates the whole site automatically to begin with, then lets you edit any string that the machine got wrong. This gets you to a fully translated site fast and is attractive when you have a lot of content and limited time, with the understanding that you will review the important pages by hand. The concern to weigh is ongoing dependence on the translation service and the need to proofread anything that carries weight, since an unreviewed automatic translation can be confidently wrong.
The table below compares these approaches on the factors that usually decide the choice. Treat it as a starting frame, not a verdict, because the best fit depends on your content and your team.
| Approach | Best for | Translation control | Maintenance | Learning curve |
|---|---|---|---|---|
| Separate translation copies | Sites needing per language differences | High, each version fully editable | Higher, more pieces to manage | Moderate |
| Single editor, multiple languages | Straightforward mirrored translations | Moderate, structure stays aligned | Lower, edited in one place | Low to moderate |
| Automatic first, refine later | Large sites needing speed | Lower at first, editable after | Lower to set up, review needed | Low |
| Multisite, one site per language | Independent regional teams | Total, fully separate sites | Highest, several sites | Higher |
A practical way to choose is to start from your content. If your language versions will be close translations of the same pages, a model that keeps them aligned is comfortable. If each market needs meaningfully different content, offers, or imagery, the separate copy or multisite models give you the room to differ. And if you simply need a lot of content available in many languages quickly, an automatic first approach gets you there, provided you commit to reviewing what matters. There is no universally best plugin, only the one that fits how your site actually works. If you would like a recommendation for your specific case, our team is happy to give you a free assessment.
URL Structure and hreflang for SEO
How you arrange your language versions in URLs, and how you tell search engines about them, is the part of a multilingual project that most affects search performance, and it is the part people most often get wrong. The goal is simple to state: each language version should have its own stable, crawlable address, and search engines should understand that these addresses are the same content in different languages so they can show the right one to the right person. Getting this right is central to WordPress SEO for any multilingual site.
Choosing a URL structure
There are three common structures, and the sensible default for most single site setups is the first.
- Subdirectories, where each language lives in a folder such as your domain followed by a language code. This keeps everything on one domain, so the authority your site builds is shared across all languages, and it is the easiest to set up and maintain. For most businesses this is the right choice.
- Subdomains, where each language sits on a prefix of your domain. This separates the languages a little more and can suit cases where they are run independently, but the languages share domain authority less cleanly than subdirectories do.
- Separate domains, typically a country specific address per market. This gives the strongest signal of local focus and full independence, at the cost of building authority for several domains rather than one, which is a much bigger job.
For a single site with a multilingual plugin, subdirectories are almost always the answer, and good plugins set them up for you. Separate domains belong to the separate sites strategy and to organisations large enough to justify the extra work.
Getting hreflang right
Hreflang is a small piece of code that tells search engines, for a given page, which other URLs are the same content in other languages or regions. When it is correct, a French speaker searching in France is shown your French page and an English speaker is shown your English one, rather than both being served the same version. When it is missing or wrong, search engines may show the wrong language version, treat your translations as duplicate content, or fail to connect them at all, and you lose much of the SEO value of translating in the first place.
The good news is that reputable multilingual plugins generate hreflang tags for you automatically, which is a strong reason to use one rather than assembling a multilingual site by hand. Your job is mainly to make sure every page has a proper translation relationship set, so the tags come out complete, and to avoid leaving pages half connected. Google's own documentation on localized versions of a page is the authoritative reference if you want to understand the detail behind what the plugin is doing.
One more SEO point worth stressing: translate the parts of a page that search engines read, not just the visible words. Page titles, meta descriptions, image alt text, and the URL slug itself should all be in the target language. A page whose body is French but whose title and slug are still English is only half translated in the eyes of a search engine, and it will not rank as well in French. Good plugins let you translate all of these, so use that capability.
Translating Your Content
Deciding how to structure the site is half the project. The other half is getting the words right, and translation quality is where a multilingual site earns trust or loses it. There are three broad ways to get content translated, and many sites use a mix.
Professional human translation
A person who is fluent in the target language, ideally a native speaker who understands your field, produces the most natural and trustworthy result. This is the right choice for anything that carries weight: your main pages, product descriptions, legal text, and anything that shapes how customers see you. It costs more and takes longer, but for the content that matters, it is worth it. A clumsy translation on a key page can do more harm than no translation at all, because it signals carelessness.
Machine translation with human review
Automatic translation has become genuinely useful, and for large volumes of lower stakes content, such as a big blog archive, using it as a first pass that a fluent person then reviews is a practical middle path. The machine does the heavy lifting and the human catches the errors and awkward phrasing. This gets you good enough quality at a fraction of the effort of translating everything from scratch, as long as you actually do the review step and do not ship the raw output on pages that matter.
Pure machine translation
Relying entirely on automatic translation with no review is the fastest and cheapest route, and it is sometimes acceptable for purely informational content where an occasional awkward sentence does no harm. Be honest with yourself about which content that really describes. For most business pages, unreviewed machine output undercuts the very trust you translated the site to build, so keep it to the low stakes corners if you use it at all.
Whatever mix you choose, remember that translation is not only about words. Dates, numbers, currencies, addresses, and images with text in them all may need adapting per language, and tone that works in one culture can fall flat in another. Good translation is really localisation, which means making the content feel native rather than merely converted. That is why a fluent human in the loop matters so much for the content that represents you. If you want to see how WordPress itself handles languages behind the scenes, the community Polyglots translation handbook is a useful reference.
Themes, RTL, and Design
Adding languages puts pressure on your design in ways that are easy to overlook until they show up as broken layouts. A theme that looks perfect in English can behave badly once other languages fill it, so it pays to think about design as part of the multilingual plan rather than after it.
The first issue is text length. The same sentence can be much longer or shorter in another language, and text that fit neatly in a button or a heading in English may overflow or wrap awkwardly in German or French. A well built theme handles varying text length gracefully, while a rigid one breaks. When you build a site that will be multilingual, testing your key components with longer text early saves a lot of fiddling later. If you are still choosing how to build, our guide on how to make a WordPress website covers picking a flexible foundation.
The bigger design question is right to left languages. Arabic, Hebrew, Farsi, and others read from right to left, which means the entire layout should mirror: text aligns right, menus and columns flip, and the reading order reverses. WordPress supports right to left languages well, and many quality themes include right to left styling, but not all do, and a theme that does not can look genuinely broken in those languages. If a right to left language is on your roadmap, check that your theme supports it before you commit, because retrofitting right to left support into a theme that never had it is real work.
Fonts matter too. Not every font includes the characters every language needs, so a font that renders your English beautifully may show empty boxes for accented characters or another script entirely. Choosing fonts with broad language coverage, or setting appropriate fonts per language, keeps every version looking intentional. These design details are the difference between a site that feels native in each language and one that feels like a translation bolted onto an English layout.
Performance Considerations
A multilingual site is, underneath, a site with several times as much content and some extra work happening on every page load to decide which language to serve. That has performance implications worth planning for, because speed affects both visitors and search rankings, and a slow multilingual site undoes some of the reach you translated it to gain.
The main effect is simply volume. If you have three languages, you have roughly three times the pages, which means more for search engines to crawl, more in your database, and potentially more to keep in your caches. On a small site this is nothing to worry about. On a large one it is a reason to be tidy: keep your plugin list lean, use good caching, and choose a multilingual plugin that is known for being efficient rather than one that adds heavy queries to every page. Some translation approaches add more overhead than others, and on a big site that difference shows up in load time.
Caching deserves a specific note, because a multilingual site has to cache each language version separately, and not every caching setup handles that correctly out of the box. A misconfigured cache can serve the wrong language to a visitor, which is confusing and looks broken. Reputable multilingual plugins and caching plugins are built to work together, so the fix is usually choosing tools that are known to cooperate and testing that each language is cached and served correctly. Our guide on how to speed up a WordPress website covers the caching and optimisation basics that matter even more once you add languages.
Common Pitfalls to Avoid
Multilingual projects tend to fail in a handful of predictable ways. Knowing them in advance is the cheapest way to avoid them.
Leaving content half translated
The most common problem is a site that is only partly translated, where the main pages are done but menus, footers, buttons, form labels, error messages, and the occasional page are still in the original language. This feels unprofessional and undermines trust. Plan for the whole visitor experience in each language, including the small strings that are easy to forget, not just the big pages.
Ignoring the SEO connections
Translating content without setting up proper URL structure and hreflang means search engines may never understand your language versions, so the traffic you translated for never arrives. This is the pitfall with the highest cost because it is invisible: the site looks fine, but it quietly fails to rank in the new languages. Use a plugin that handles hreflang and check that it is working.
Choosing the wrong approach for the scale
Reaching for multisite or separate sites when a single site plugin would do adds maintenance you did not need, while forcing everything into one site when regions truly need to run independently creates friction. Match the approach to how your content and teams actually work, which is exactly the decision this guide is built to help you make.
Trusting raw machine translation on pages that matter
Shipping unreviewed automatic translation on your core pages, product information, or legal text is a false economy. It looks like you saved time until a customer notices an error that makes the business look careless. Reserve unreviewed machine output for genuinely low stakes content and review the rest.
Forgetting ongoing maintenance
A multilingual site is not finished when it launches. Every new post, page, or product now needs a version in each language, and if that discipline slips, the site drifts back toward being half translated. Build the translation step into your normal publishing routine so it does not become a growing backlog. If keeping up is a concern, our WordPress maintenance can carry that load for you.
Choosing the Right Approach
Pulling it together, here is a simple way to decide. Start with the single site plus multilingual plugin route unless you have a specific reason not to, because it fits the large majority of businesses and keeps maintenance manageable. Within that route, pick the plugin model that matches your content: aligned translations point to a single editor style, per language differences point to separate copies, and a large archive that you need translated fast points to an automatic first approach with review.
Reach for multisite only when separate regional teams genuinely need to run their languages independently, and reach for fully separate sites only when the markets are so different that they are effectively different businesses. Those are real cases, but they are the minority, and they carry the highest maintenance cost, so choose them deliberately rather than by default.
Whatever you choose, get the foundations right from the start: subdirectory URLs, working hreflang, fully translated titles and slugs, a theme that flexes with text length and supports right to left if you need it, and a plan for keeping content in step across languages as you grow. Those choices are far cheaper to make at the beginning than to fix after launch. If you would like the whole thing planned and built correctly the first time, that is exactly what we do.
Getting Help
Going multilingual is one of those projects where the decisions made in the first week shape how the site behaves for years. You can absolutely do it yourself, and our companion guide on how to make a multilingual WordPress site walks through the hands on steps. But if the site is important to your business, or the choice between approaches is not obvious, or you simply want it done properly without the trial and error, bringing in a team that builds multilingual WordPress sites regularly is a sound investment.
We plan the approach around your languages, audience, and content, set up the URL structure and hreflang so the site ranks in each language, build or adapt the theme so it looks native everywhere including right to left, and set up a translation workflow that keeps quality high without slowing you down. Because we are developers, we can go beyond what a plugin does out of the box, solving the awkward edge cases that come up on real sites. You can see the range of what we do on our services page.
If you want your multilingual site done right, you can get a free quote and we will tell you honestly which approach fits and what it will take. Or book a free consultation and we will talk it through with no obligation. The reach you gain from speaking your customers' language is worth doing well, and the first step costs nothing.