How to make a WordPress site multilingual in 2026

Updated Published 13 min read

In short

WordPress has no built-in multilingual support, so you choose one of four approaches: manual per-post translation, one site per language on Multisite, automatic AI translation stored in your own database, or a cloud SaaS that hosts translations externally. The right choice depends on whether you want a faithful mirror or genuinely different content per market.

Key points

  • WordPress core cannot publish the same content in multiple languages — every approach requires a plugin or a service.
  • Installing a WordPress language pack translates the interface, not your content; the two are entirely separate problems.
  • Choose between a faithful translated mirror and genuinely independent per-market sites first — that single decision eliminates most options.
  • Language subdirectories (/de/, /fr/) are the right default for almost every site.
  • Whatever you pick must handle hreflang, per-language canonicals, translated meta and sitemaps, or the translations will not rank.

Making a WordPress site multilingual used to mean a heavy plugin and a lot of manual work. In 2026 you have real choices — and the right one depends on how much you want to automate, whether you want to own your translations, and how your site is hosted.

Does WordPress support multiple languages out of the box?

Not for your content. This is the point that trips people up, so it is worth being precise about what WordPress does and does not give you.

WordPress has excellent internationalization for interface strings. Themes and plugins wrap their text in translation functions, community translators supply locale files through translate.wordpress.org, and switching your site language pulls those files in (WordPress Developer Resources). Your admin, your theme's "Read more", and WooCommerce's checkout labels all localize.

None of that touches your content. There is no core concept of "this post, in German". No alternate URLs, no linkage between language versions, no hreflang. Publishing your content in several languages is a separate problem that core does not attempt to solve, which is why every route below involves a plugin or a service.

First, decide what "multilingual" means for you

Two questions settle most of the decision:

  • Faithful mirror or distinct markets? Do you want the same site in more languages, or genuinely different content per country — different products, pricing, legal text, campaigns?
  • Manual or automatic? Will humans translate every page, or should machine translation do the bulk with human editing where it matters?

Answer those two honestly and most of the options below eliminate themselves. Choosing a tool first and deciding what you need afterwards is how sites end up with a multisite network they did not want.

The four approaches

1. Manual, per-post translation

Plugins such as Polylang have you create a linked, translated copy of each post and page. You get complete editorial control, and content lives in your own database.

The cost is linear human effort: every page, in every language, forever — including every subsequent edit. Polylang's free core is genuinely capable and it is the most-installed option of its kind, with 800,000+ active installations on the WordPress plugin directory. Polylang Pro (from €99/yr) adds a DeepL integration that requires your own DeepL API key, though Polylang states it does not provide a one-click translate-everything feature.

Best when: a small site, a translation team, or content where every word is deliberate.

2. Multisite, one site per language

MultilingualPress makes each language a separate site inside a WordPress Multisite network, with content linked across sites.

This is the strongest option when markets should be genuinely independent — different themes, plugins, products or teams per country. It is also the heaviest: you are running and maintaining a network rather than a site, and there is no maintained free tier. Pricing is by language count, from $149/yr for two languages to $1,499/yr for unlimited.

Best when: markets are separate businesses that happen to share a brand.

3. Automatic AI translation, stored locally

The newer approach: a plugin captures your content, translates it with AI, stores the result in your own database, and serves language-prefixed versions automatically. No per-post duplication, no translated copy to create by hand.

This is the fastest path to a faithful multilingual mirror of an existing single site, and because translations are cached locally, there is no per-render dependency on a remote service. It is how Gloty works.

Best when: you have an existing single site and want it available in more languages without a content-production project.

4. Cloud SaaS

Services such as Weglot translate automatically too, but store translations on their infrastructure and serve them from there. Setup is genuinely fast and it is platform-agnostic, so the same service covers Shopify or Webflow.

The trade-offs are custody and metering: the translations live with the vendor, and pricing scales with unique word count and language count — Weglot's published tiers run from a 2,000-word free tier to $769/mo for 5,000,000 words across 20 languages. Stop paying and the translated pages stop serving.

Best when: you are not only on WordPress, or you want zero database footprint.

Get the URL structure right

Use language-prefixed subdirectories — /de/, /fr/ — for most sites. Google supports subdirectories, subdomains and ccTLDs equally for multi-regional sites, so this is an operational decision rather than a ranking one: subdirectories keep everything on one hostname, which means one certificate, one DNS setup, and link equity consolidating on a single domain.

Set the correct lang attribute on <html> for each version, add dir="rtl" for right-to-left languages, and give each page a clean transliterated slug — the slug transliterator helps. Preview the options with the URL structure previewer.

Decide before launch. Changing URL structure afterwards means a full redirect map and a re-indexing cycle.

Don't skip multilingual SEO

Whatever approach you pick, translated pages only earn traffic if search engines can index and attribute them correctly. That means hreflang annotations that are reciprocal and include x-default, self-referencing canonicals per language, translated titles and meta descriptions, and language-aware sitemaps.

See adding hreflang in WordPress for implementation and the multilingual SEO checklist for the full list, then verify with the hreflang checker. A good plugin generates all of this automatically; if the one you are evaluating does not, that work lands on you.

Don't forget WooCommerce

If you run a store, confirm your approach translates product titles, descriptions, attributes and variations, the cart, the checkout, and order emails.

Pay particular attention to the block-based Cart and Checkout, which render in the browser through wp.i18n rather than as server HTML. Approaches that work by rewriting page output miss these entirely, producing the classic failure where product pages are translated and the checkout is stubbornly English. This is a common gap — test it before you commit. See translating a WooCommerce store.

What does it cost?

The four approaches have genuinely different cost shapes, and the cheapest on paper is rarely cheapest in practice.

  • Manual — the plugin can be free; the translation labour is not. Cost scales with words and recurs with every edit.
  • Multisite — licence priced by language count ($149–$1,499/yr for MultilingualPress), plus the ongoing operational cost of a network.
  • Cloud SaaS — a subscription that scales with unique words and languages, from free tiers up to hundreds of dollars a month. Predictable per month, unbounded over time as you publish.
  • Local AI translation — machine-translation cost is usually a one-off per string because results are cached, so cost tracks how much content you have rather than how much traffic it gets.

Estimate your own numbers with the translation cost calculator rather than trusting a vendor's example site.

A sensible default

For most people translating an existing single site, automatic AI translation stored in your own database gives the best balance of speed, cost and control: no per-post duplication, no recurring charge for content already translated, and no dependency on a third party continuing to serve your pages.

Keep the ability to edit translations by hand for the pages that matter — your homepage, pricing, and anything legal — and make sure those human edits are protected from being overwritten by a later sync. Then work through the SEO checklist before you announce the launch.

Sources

Technical claims in this guide are drawn from the primary documentation and specifications below, each confirmed live on the date shown.

  1. Localization — Common APIs Handbook WordPress Developer Resources. Accessed .
  2. Translate WordPress (GlotPress) WordPress.org. Accessed .
  3. Managing multi-regional and multilingual sites Google Search Central. Accessed .
  4. Polylang — WordPress Plugin Directory listing WordPress.org. Accessed .
  5. Polylang Pro Polylang. Accessed .
  6. Weglot Pricing Weglot. Accessed .
  7. MultilingualPress 3 Syde. Accessed .

FAQ

Does WordPress support multiple languages by default?
Not for content. WordPress localises interface strings — admin, themes, plugins — through language packs, but core has no concept of the same post in another language, no alternate URLs, and no hreflang. Publishing content in several languages always requires a plugin or an external service.
What's the easiest way to make WordPress multilingual?
Automatic AI translation is the lowest-effort path for an existing single site: the plugin translates your pages and serves language-prefixed versions without you creating a translated copy of every post. Manual plugins and multisite give more editorial control at substantially more work.
Should I use subdirectories or subdomains for languages?
Subdirectories (/de/, /fr/) are the best default for most sites. Google supports subdirectories, subdomains and ccTLDs equally, so the decision is operational: subdirectories keep one hostname, one certificate, and link equity consolidated on a single domain. Subdomains and ccTLDs make sense mainly for genuinely separate market operations.
Do I need a paid plugin to go multilingual?
Not necessarily. Polylang's free core handles manual translation, and Gloty's plugin is free to start. Paid tiers add automation, volume or advanced features — but you can begin at no cost and upgrade when the manual effort or the volume justifies it.
Will translating my site create duplicate content problems?
Not if it is set up correctly. Content in different languages is not duplicate content. Problems arise from implementation errors — missing or non-reciprocal hreflang, or canonicals pointing every translation at the source page — which cause search engines to consolidate the versions instead of treating them as distinct alternates.
How many languages should I start with?
Start with the one or two markets where you already see demand — check your analytics for existing traffic by country and language before guessing. Every added language multiplies the surface you must keep in sync, so it is better to run two languages well than six that drift out of date.

Gloty makes WordPress multilingual automatically — AI translation, hreflang, and clean URLs, stored in your own database.

Try Gloty free
Go multilingual free
Open source · your data stays yours
Start free