There are four real ways to make a WordPress site multilingual, and most of the trouble agencies hit comes from picking one without knowing it was a choice.
Everybody will tell you to “just install a translation plugin,” as if they are all the same thing doing the same job. They are not. Under the hood, these approaches store your translations in different places, reach the visitor in different ways, and lock you in to different degrees. Pick without understanding that, and you can inherit a maintenance problem you never meant to sign up for.
So before you install anything, here is how the four approaches actually work, and how to choose between them.
Key Takeaways
- You do not need WordPress Multisite to run a multilingual site. A single install of the right plugin covers almost every project.
- The four approaches are a translation plugin, a cloud or proxy service, Multisite with a connector, and manual duplicate pages.
- A translation plugin does not have to slow your site down, and on most sites it is not the biggest performance factor anyway.
- Correct hreflang tags mean Google will not penalize you for translated content, so the old duplicate-content fear is misplaced.
Do you need WordPress Multisite for a multilingual site?
No, and this is the myth worth killing first, because it sends people down a far more complicated road than they need. For years the received wisdom was that “serious” multilingual meant Multisite. Ask working developers today and the common view is the opposite: for the large majority of projects, a single WordPress install plus a translation plugin is the right call, and Multisite just trades one multilingual problem for a pile of site-management ones.
There is a concrete technical reason the community keeps landing there. A multilingual plugin handles the things Google actually needs, linking translated pages together as canonical alternates and outputting hreflang tags, automatically. Multisite does not do that out of the box, so making a Multisite network behave correctly for multilingual SEO usually means more custom development. However, Multisite earns its place in one situation: when the client runs as distinct regional operations, with different content, teams, or legal entities per market, rather than one site shown in several languages. But that is a real network to administer, so reach for it only when the business actually looks like a network.
What are the ways to make WordPress multilingual?
There are four, and each is suited to a different kind of project. The trick is matching the approach to the build rather than to whatever a blog post told you to install.
The first is a self-hosted translation plugin, like WPML, Polylang, or TranslatePress, which stores translations in your own WordPress database. The second is a cloud or proxy service, like Weglot or GTranslate, which hosts the translations on the their own servers and serves them back to visitors. The third is Multisite with a connector, for the genuinely-separate-regional-sites case above. The fourth is manual duplicate pages, which is exactly what it sounds like and almost never the right answer.
The real distinction is where your translations live and how they reach the visitor, because that decides your maintenance, your portability, and to a lesser extent your performance. We compare the specific plugins in detail in the next post in this series. This post is about picking the approach.
Will a translation plugin slow down my site?
It can, a little, but performance is really a question of architecture, and each approach makes a deliberate trade-off worth understanding. How a plugin stores translations is the whole story here, and there is no single right answer, just different choices suited to different builds.
Some plugins store translations as separate entries in your database. That is what powers deep, granular translation management, the ability to translate every string, custom field, and piece of theme or plugin output with fine control, which is exactly what a complex site or a large store needs. The trade-off is more database work per page, and on big or busy sites the standard, well-understood fix is a persistent object cache like Redis or Memcached, which experienced developers run as a matter of course.
Other plugins stay deliberately lean. Polylang, by its own account, “leverages the core element of WordPress (the taxonomies)” and adds “no extra tables or bloat,” which keeps the database footprint minimal and suits performance-first, content-heavy sites. Proxy services take a third route entirely, doing the translation work on the vendor’s own servers so your site does the least work of all, in exchange for the translations living off-site.
None of those is the “slow” one. They are three sensible answers to the same problem, and the right one depends on whether you are optimizing for translation depth, a lean database, or minimal server load.
On most sites, the multilingual plugin is not your performance bottleneck at all. Full-page caching, a CDN, image weight, and your theme or page builder’s output almost always move the needle more. So weigh the architecture that fits your project, especially on a large WooCommerce build, but do not pick your whole approach around a performance worry while ignoring the things that actually slow sites down.
Why not just duplicate every page manually?
Because it breaks the moment the site grows, and it quietly sabotages your SEO while it does. Manually creating a second set of pages in another language feels simple on a five-page brochure site, so people try it. Then the client adds a blog, a menu change, a price update, and now every edit has to be made twice, by hand, forever. Miss one and the language versions drift apart.
The SEO cost is the bigger issue. Duplicated pages built by hand have no canonical link between them and no hreflang, so search engines get no signal about which version serves which audience, and the versions can compete with each other instead of ranking cleanly. This is exactly the work a real translation plugin does for you: the language relationship, the URL structure, and the hreflang tags, handled automatically. Doing it manually means rebuilding all of that yourself and maintaining it by hand, which is a standing job, not a shortcut.
Which approach is right for the site you are building?
Match the approach to the build, the client’s budget, and how much you want to maintain.
A self-hosted plugin fits most projects, and it is the right default when the client wants to own their translations and you are comfortable managing them. A proxy service fits when speed to launch matters most and the client is happy renting the translations in exchange for near-zero setup. Multisite with a connector fits the genuinely-separate-regional-business case, and little else. Manual pages fit a tiny, static, two-language site that will never grow, and even then a well-supported free plugin is usually smarter.
Whatever you land on, stick to actively maintained tools. A translation plugin sits at the center of the site, touching content, URLs, and SEO, so an abandoned one becomes a security and compatibility liability you will be untangling later. Check that anything you build on is current, well-reviewed, and still shipping updates, whether it is free or paid.
If you have not scoped the project or planned the build yet, start with scoping a multilingual WordPress build and the six things to plan before you build . Once you have chosen your approach here, the next post walks through picking the specific plugin.
Pick on purpose.
Frequently Asked Questions
Do I need Multisite to make a WordPress site multilingual?
No. A single WordPress install with a translation plugin handles multiple languages for almost every project, and it also manages canonical links and hreflang tags automatically, which Multisite does not do without custom development. Multisite with a connector like MultilingualPress only makes sense when the client genuinely runs separate regional sites with different content or teams.
Do translation plugins slow down WordPress?
They can, depending on how they store translations, and heavier ones benefit from a Redis or Memcached object cache on larger sites. Lighter options like Polylang add minimal overhead by using WordPress’s native taxonomies. On most sites, though, caching, images, and theme output affect speed more than a multilingual plugin does.
Will translated pages hurt my SEO or cause duplicate content?
No, when the site uses correct hreflang tags and gives each language its own indexable URL. Hreflang tells search engines which version serves which audience, which prevents duplicate-content problems. The duplicate-content risk mainly applies to manual duplicate pages built without those signals.
Which type of multilingual approach is best for a large WooCommerce store?
It depends on how hands-on you want to be, but performance and data ownership matter most at that scale. A self-hosted plugin keeps translations in your database and, paired with object caching, handles large catalogs well. A proxy service reduces server load but hosts translations externally. We compare the specific options in the next post in this series.
Leave a Reply