How to Build a Multilingual WordPress Website: WPML, Polylang or Custom?

A multilingual WordPress website is one of those projects that looks simple in the sales call and turns complicated in week two: the plugin is installed, the pages are duplicated, and then someone notices the menus are still English, the form confirmations are half German, the shop emails go out in the wrong language and Google is indexing three copies of the same page. Done properly, a multilingual site is a genuine growth asset – most of my client base is in Germany, Austria and Switzerland, where German plus English is simply the cost of doing business, and the sites that handle it well win measurably more enquiries.

This guide is the version I wish every client read before choosing a plugin: when you actually need multiple languages and when you do not, an honest comparison of WPML, Polylang, WordPress multisite and SaaS translators like Weglot, what a “translated site” really includes beyond posts and pages, URL structures and hreflang done right, a realistic machine-plus-human translation workflow, WooCommerce specifics, and what all of it costs for two, three or five languages. It draws on 12+ years and 500+ WordPress projects, a good share of them bilingual or worse.

Table of contents

• When you actually need a multilingual website
• The four approaches: WPML, Polylang, multisite or SaaS
• What “fully translated” really includes
• URL structure: subdirectory, subdomain or ccTLD
• Multilingual SEO done right
• Machine translation plus human review: the realistic workflow
• RTL languages and typography
• Performance: the real cost and how to keep it fast
• WooCommerce multilingual: products, currencies, taxes, emails
• Cost and timeline for 2, 3 and 5 languages
• Starting monolingual? Plan for languages now
• Frequently asked questions

When you actually need a multilingual website

Add a language when there is a market behind it, not because a second flag in the header looks international. The honest test: do you sell to, hire from or get enquiries from people who prefer another language? A Munich B2B firm selling across the DACH region and to international buyers needs German and English – that is two real markets. A local plumber in Leeds does not need a French version because a template offered one.

Signals that a language will pay for itself:

• Analytics evidence: a meaningful share of sessions from countries or browser languages you do not serve – and a visibly worse bounce rate for them.
• Sales evidence: enquiries arriving in another language, or a sales team already answering them manually.
• Regulatory or trust reasons: in Germany, Austria and Switzerland many buyers simply will not send a contact form on an English-only site, and legal pages (Impressum, Datenschutz) are expected in German regardless.
• Paid traffic plans: running Google Ads in a market without landing pages in its language burns budget.

And the counter-case: if 95% of your revenue is one market, a single-language site with excellent content beats a bilingual site where the second language is thin, stale machine output. Half-translated sites are worse than monolingual ones – visitors hit English fragments mid-checkout and trust drops exactly where it matters. If you cannot commit to maintaining a language, do not launch it.

The four approaches: WPML, Polylang, multisite or SaaS

Every multilingual WordPress build I have done falls into one of four architectures. There is no universally right answer – there is a right answer per project, and the table below is how I shortcut the conversation.

WPML: the feature-complete standard

WPML is the oldest and most complete option: post, page, taxonomy, menu, widget and string translation, a built-in Translation Management workflow with translator roles, Advanced Custom Fields support via its ACFML add-on, WooCommerce support via WooCommerce Multilingual, and automatic translation credits (DeepL, Google, Microsoft) billed per word. Cost is around EUR 99 per year for the Multilingual CMS plan (EUR 199 for Agency), renewing annually for updates and support.

Its reputation for slowing sites down is partly earned history and partly misconfiguration. WPML added a lot of autoloaded options and string queries in older versions; current versions are much better, but you still have to configure it deliberately: translate only the post types and taxonomies you actually use, disable the Translation Feedback and usage-tracking extras, keep String Translation lean by not scanning every plugin “just in case”, use the “Translate what you choose” mode rather than translating everything automatically, and put a proper page cache in front so language detection does not run PHP on every hit. Configured that way, I have WPML sites scoring 90+ on mobile PageSpeed without heroics.

Polylang: the lean choice

Polylang’s free core covers posts, pages, categories, menus and basic strings, and it stores language data using WordPress taxonomies – architecturally lighter than WPML’s extra tables. Polylang Pro (around EUR 99 per year) adds slug translation, duplication tools, synchronised post types and better theme-builder support; Polylang for WooCommerce is a separate add-on. There is no built-in translation management to speak of – fine for a two-language site maintained by one editor, limiting for a team of translators. For the typical DACH business site – German plus English, one content owner, ACF-built templates – Polylang Pro is my default recommendation: less surface area, fewer options screens, fast.

Multisite: one install per language

WordPress multisite (or even fully separate installs) gives each language its own site: own theme settings, own plugins if needed, own editorial team, own domain. Plugins like MultilingualPress link translations across sites for hreflang. It wins when the languages are really separate businesses: a German entity and a UK entity with different teams, different content calendars, different legal pages and possibly different ccTLD domains. The price is duplication – every plugin update, every template change, every new feature happens per site – and content parity drifts unless someone owns it. I recommend it for organisations, not for a five-person company that wants a French version.

SaaS translators: Weglot and TranslatePress

Weglot proxies your site, machine-translates everything it renders – menus, strings, checkout, the lot – and serves language subdirectories or subdomains with hreflang handled. Setup is genuinely a day. The catch is the meter: pricing scales with word count and languages, from roughly EUR 15 per month for one language and 10,000 words to EUR 300+ per month for larger sites – forever. A content-heavy site pays more every year than a WPML licence costs in a decade, and your translations live in their platform, not your database. TranslatePress sits in between: a WordPress plugin (from roughly EUR 89-109 per year) with a visual front-end editor that translates everything it renders, storing translations locally; less enterprise workflow than WPML, far easier for non-technical editors. SaaS-style tools are right for “we need Spanish live this month and content rarely changes”; wrong when you want to own the translations long term or the word count is large.

Side-by-side comparison

My rules of thumb: Polylang Pro for a straightforward bilingual business site; WPML for content teams, many languages or WooCommerce with per-language pricing; multisite when organisational structure demands it; Weglot/TranslatePress when speed to launch beats long-term ownership.

What “fully translated” really includes

Translating posts and pages is maybe 60% of the job. The remaining 40% is where multilingual sites quietly fail their QA, so here is the checklist I run on every build:

• Menus: one menu per language, assigned per language – not one menu with mixed labels. Both WPML and Polylang handle this, but someone has to build and maintain each menu.
• Widgets and footer content: address blocks, opening hours, footer link lists – all need per-language versions or string translation.
• Theme and plugin strings: “Read more”, “Search results for”, breadcrumbs, 404 text. Properly internationalised themes ship translatable strings; a custom build should use text domains and translation functions from day one, which is exactly the kind of groundwork I put into custom theme development so the multilingual layer has something clean to hook into.
• ACF and custom fields: every flexible-content block, repeater and options page needs a translation strategy – translate the field content per post (ACFML or Polylang Pro) and decide which fields copy across (image fields, numbers) versus which get translated.
• WooCommerce: products, variations, attributes, category and checkout pages, and – the one everybody forgets – order and account emails per language.
• Slugs: /en/services/ should be /de/leistungen/, not /de/services/. WPML and Polylang Pro both translate slugs; free Polylang does not.
• Media alt text and captions: translated alt text matters for accessibility and image SEO; WPML has media translation, elsewhere it is manual.
• Forms: field labels, validation messages, confirmation texts and the notification emails – per language, including where the enquiry gets routed (German enquiries to the German-speaking inbox).
• Legal pages: privacy policy, terms, cookie banner texts, and for DACH the Impressum. These are legal documents – never machine-translate them unreviewed.
• SEO metadata: titles, meta descriptions, OpenGraph text and schema fields, per language.

When I quote a multilingual project, this list is the scope document. It is also why “just install WPML” estimates from a sales call are usually half the real number.

URL structure: subdirectory, subdomain or ccTLD

You have three options for where each language lives, and the choice is hard to change later, so make it deliberately.

Subdirectories: example.com/de/

One domain, languages in folders. All authority accumulates on one domain, one hosting setup, one SSL certificate, plugins handle it natively, and hreflang ties the versions together. Google treats subdirectories as part of the same site, so a strong English site gives the new German section a running start. This is my recommendation for 90% of projects.

Subdomains: de.example.com

Slightly cleaner separation, and multisite maps to it naturally. But search engines treat subdomains as more separate than folders, so authority is diluted, and you manage extra DNS and certificates. I rarely see a reason to prefer it unless multisite infrastructure forces it.

ccTLDs: example.de, example.co.uk

The strongest geotargeting signal and the strongest local trust – German buyers do click .de results more. The cost: each domain builds authority from zero, each needs its own SEO investment, and you are usually running multisite or separate installs. Right for established companies with real per-country operations and marketing budgets; wrong for a company adding its second language.

One firm rule regardless of structure: never use browser-based automatic redirects to force visitors to a language. Detect and suggest (“This page is available in German”) but let people and crawlers reach every URL. Googlebot mostly crawls from US IPs with English headers – aggressive redirects can hide your other languages from the index entirely.

Multilingual SEO done right

Multilingual SEO is mostly about telling Google which page is which language’s version of what – and not flooding the index with thin duplicates.

hreflang pairs, including x-default

Every translated page needs hreflang annotations linking all its versions, each version pointing at all the others and itself, plus an x-default for the fallback. For a German/English page:

<link rel="alternate" hreflang="de" href="https://example.com/de/leistungen/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/services/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/services/" />

Use de-DE, de-AT, de-CH only if you genuinely have per-country versions; otherwise plain language codes. WPML, Polylang and Weglot all output hreflang automatically – your job is to verify the pairs are reciprocal (a one-way hreflang is ignored) and that untranslated pages do not claim translations they do not have. Search Console’s international targeting and pages report will show you broken pairs.

Per-language sitemaps and translated metadata

Your SEO plugin (Yoast, Rank Math, SEOPress – all integrate with WPML and Polylang) should emit sitemaps covering every language’s URLs, whether as one sitemap or one per language. Titles and meta descriptions must be written per language – a German page with an English meta description looks broken in German search results and tanks click-through. Keyword research is also per language: Germans search “Webseite erstellen lassen”, not a literal translation of the English head term.

Avoid auto-translated thin content

Google’s guidance is consistent: machine-translated content published without human review is scaled, low-quality content and can drag the whole domain down. If you machine-translate 400 blog posts and publish them unreviewed, you have not gained a market – you have created a duplicate-quality problem. Translate your money pages properly first; noindex or simply skip the long tail until it earns review.

Geotargeting

With subdirectories, hreflang carries most of the geographic signal. Add local signals per market where real: local business schema, local phone numbers and addresses, links from local directories and partners. If you run country-specific sections (not just languages), keep the country versions genuinely different – prices, currency, contact details – or consolidate them.

Machine translation plus human review: the realistic workflow

Nobody with a normal budget hand-translates a 60-page site from scratch any more, and nobody serious publishes raw machine output. The workflow that actually works, and the one I set up for clients:

1. Machine draft: DeepL for European languages (its German output is a class above the rest), or the AI translation built into WPML/Weglot, or a GPT-class model with a prompt carrying your glossary and tone rules. Cost is trivial – DeepL API translates a million characters for around EUR 20; a full business site drafts for under EUR 50.
2. Glossary and rules first: before drafting, fix the terms – product names that never get translated, formal versus informal address (Sie versus du is a brand decision in German, not a translator’s whim), and phrasing for legal-ish content. Ten lines of glossary prevent a hundred corrections.
3. Native human review: a native speaker – ideally in-house (the sales person who serves that market is perfect), otherwise a freelance reviewer at EUR 0.03-0.06 per word for post-editing versus EUR 0.10-0.18 for translation from scratch. Review is 3-5x faster than translating, which is where the savings genuinely are.
4. In-context QA: review on the staging site, not in a spreadsheet – German runs 20-30% longer than English and breaks buttons, headlines and menu bars that looked fine in the original.

For clients with ongoing content, I automate the drafting step – new post published in German triggers a DeepL or AI draft in English, saved as a pending translation for review. That kind of pipeline is bread-and-butter WordPress AI integration work: the API calls are cheap, the discipline is in keeping the human review step mandatory.

Governance: who updates what, when

The failure mode of every multilingual site is drift: the English page gets updated, the German one silently ages. Fix it with process, not hope. One person owns content parity; every change request carries a “languages affected” line; WPML’s “needs update” flags (or a simple checklist per release) get reviewed weekly; and untranslated new pages either wait for their translation or launch deliberately in one language with hreflang reflecting reality. Agree the rule before launch: nothing ships in language A if language B’s version would be wrong – a stale price on the German page is worse than no German page.

RTL languages and typography

Arabic, Hebrew, Farsi and Urdu flip the page: right-to-left reading order, mirrored layouts, icons and carousels reversed. WordPress core handles RTL well and ships rtl.css conventions, but your theme has to cooperate. If RTL is even a possibility, build with CSS logical properties (margin-inline-start instead of margin-left) so the layout mirrors automatically – retrofitting a directional theme costs days. Beyond direction: fonts (your Latin webfont likely has no Arabic glyphs – pair it deliberately, e.g. with a Noto family), line-height (Arabic scripts need more), letter-spacing (never on Arabic – it breaks connected letterforms), and mirrored imagery where direction implies meaning. Also plan for text expansion generally: German compound nouns and French sentences run long, Chinese runs short – components should be tested with the longest language, not the design language.

Performance: the real cost and how to keep it fast

Multilingual plugins add database queries (language filtering on every post query, string lookups) and more rows, and language switchers add a little markup. None of that has to be visible to users if you do the same things that make any WordPress site fast, plus a few multilingual-specific ones:

• Full-page cache per language: the cache must key on the language URL. With subdirectories this is automatic in every decent cache plugin and at the CDN. Avoid cookie- or session-based language detection on cached pages – it either breaks the cache or serves the wrong language.
• Disable what you do not use: in WPML, switch off translation for post types you never translate, prune String Translation to actively used domains, and disable the browser-language redirect. Each is a settings screen, each removes queries.
• Watch autoloaded options: multilingual and SEO plugins together can push autoloaded data past a megabyte. Check wp_options periodically; it is the most common silent slowdown I find in multilingual audits.
• Object caching: Redis or Memcached makes the repeated language/term lookups cheap.
• Test per language: measure PageSpeed on the German URLs too, not just the home page. Different fonts (extra subsets for Cyrillic or Arabic) and longer text change the numbers.

The baseline still matters most – hosting, images, fonts, plugin discipline – and everything in my WordPress speed guide applies unchanged. A well-built bilingual site should give up nothing measurable versus its monolingual twin; if adding a language cost you a second of load time, the configuration is wrong, not the concept.

WooCommerce multilingual: products, currencies, taxes, emails

Shops multiply every multilingual problem by the size of the catalogue, and add money.

Products and the catalogue

Every product needs translated titles, descriptions, attributes (“colour: red” as “Farbe: rot” – values, not just labels) and category pages, while stock, SKU and price stay synchronised across languages. WPML plus WooCommerce Multilingual handles this properly and is the main reason I put WooCommerce shops on WPML rather than Polylang – Polylang for WooCommerce works for simple catalogues but the ecosystem support (payment gateways, shipping plugins, product add-ons) is tested against WPML far more often.

Currencies and taxes

WooCommerce Multilingual includes multi-currency: prices per currency (set manually or by exchange rate), currency by language or by visitor location. Decide whether a currency is a display convenience or a commercial reality – charging in CHF for Switzerland means Swiss pricing decisions, not just conversion. Taxes are location-based in WooCommerce and mostly orthogonal to language, but your displayed prices (“inkl. MwSt.”) and invoice texts must match each market’s rules; EU shops selling cross-border deal with OSS VAT regardless of languages. If currencies, taxes and legal entities all differ per country, that is often the point where multisite – one shop per market – beats one multilingual shop, the same logic as separate teams: separate commercial realities, separate installs.

Emails and the post-purchase experience

Order confirmations, account emails, invoices and shipping notifications must arrive in the customer’s language – WooCommerce Multilingual sends them in the order’s language once the strings are translated, but every custom email template and follow-up plugin needs checking. Test the whole journey per language: add to cart, checkout field labels, payment gateway screens, thank-you page, emails, my-account. The checkout is where trust is most fragile and where stray English in a German flow costs real conversions. This end-to-end pass is a standard part of my WooCommerce development projects, and if you are still choosing a platform, the multilingual story is genuinely one of WooCommerce’s advantages over hosted carts – see WooCommerce vs Shopify.

Cost and timeline for 2, 3 and 5 languages

Realistic numbers for a typical 15-25 page business site, built by a senior freelancer at offshore rates (mine: EUR 15 per hour or a fixed quote within 24 hours). Translation costs assume machine draft plus native review at post-editing rates; your own staff reviewing brings that line towards zero.

• 2 languages (e.g. German + English): setup and configuration of Polylang Pro or WPML, menus, strings, forms, SEO metadata and QA: roughly EUR 600-1,200 of development on an existing well-built site. Translation review for ~10,000 words: EUR 300-600. Licences: EUR 99 per year. Timeline: 2-3 weeks including review.
• 3 languages: development grows modestly (the infrastructure exists after language two): EUR 900-1,600. Translation scales linearly: EUR 600-1,200. Timeline: 3-4 weeks, review being the bottleneck.
• 5 languages: EUR 1,500-2,500 development, EUR 1,200-2,400 translation review, and – the number people underestimate – ongoing content operations of a few hours per language per month forever. Timeline: 4-8 weeks. At this scale WPML’s translation management earns its keep, and a content-governance plan is mandatory, not optional.

A WooCommerce shop adds 50-100% to the development line (catalogue translation setup, currencies, email QA) plus per-product translation costs driven by catalogue size. If the multilingual build is part of a full new site, budget it as a line inside the project – the ranges in my WordPress cost guide apply, with languages added on top. The cheapest multilingual site is the one whose theme was built cleanly in the first place; retrofitting translation functions into a hard-coded theme can cost more than the plugin setup itself.

Starting monolingual? Plan for languages now

Most sites go multilingual in year two or three, not at launch, and the cost difference between a prepared site and an unprepared one is large. If languages are plausibly in your future, do this now while it is nearly free:

• Choose subdirectory-ready URLs: keep the default language at the root (example.com/services/) and plan for /de/ later, or start with /en/ from day one if you want symmetry. Decide once.
• Internationalise the theme: every string through translation functions with a text domain, no hard-coded labels in templates, logical CSS properties. Zero extra cost during a build, days of refactoring later.
• Structure content: ACF fields and reusable blocks translate cleanly; text baked into images and page-builder soup does not. Keep text as text.
• Keep slugs and IA deliberate: a clean hierarchy maps to translated equivalents; a decade of ad-hoc slugs does not.
• Plan the redirect story: if adding languages will move URLs (root English moving under /en/), that is a migration with 301s, hreflang and Search Console work – the same discipline as any migration without losing rankings. Prefer structures that avoid moving the existing language at all.

When the day comes, the sequence is: pick the architecture from the comparison above, translate the money pages first (home, services, contact, legal), launch with correct hreflang covering only what is actually translated, and grow the second language page by page. A partial but honest second language outranks and outconverts a complete but machine-thin one.

Need help building a multilingual WordPress site?

I plan and build multilingual WordPress and WooCommerce sites for clients in Germany, the UK, the US and Australia – architecture choice, WPML or Polylang setup done properly, translation workflows with AI drafting and human review, and the SEO plumbing that makes the languages actually rank. See my custom WordPress development service and portfolio, or send me a message with your languages and current site – I reply with a concrete plan and a fixed quote within 24 hours.

Frequently asked questions

How do I build a multilingual WordPress website?

Choose an architecture first – WPML or Polylang on one install for most sites, multisite for separate teams or domains, Weglot/TranslatePress for fast launches – then translate everything (pages, menus, strings, forms, metadata), set up hreflang and per-language sitemaps, and put a human review step behind any machine translation.

Which is better, WPML or Polylang?

Polylang Pro is leaner and ideal for a bilingual business site with one editor; WPML wins for content teams, many languages and WooCommerce shops thanks to its translation management and WooCommerce Multilingual add-on.

Does WPML slow down a WordPress site?

Not meaningfully if configured well – translate only what you use, prune String Translation, disable browser redirects and cache per language. Badly configured, any multilingual plugin can add noticeable overhead.

Is automatic translation good enough for my website?

As a draft, yes – DeepL and AI models produce strong first versions cheaply. Published unreviewed, no: Google treats unedited machine content as low quality, and customers notice. Always add native human review, at least on key pages.

Should I use subdirectories, subdomains or separate domains for languages?

Subdirectories (example.com/de/) for most sites – one domain accumulates all authority and plugins support it natively. ccTLDs only when you run real per-country operations with separate marketing budgets.

How much does a multilingual WordPress website cost?

Adding a second language to a well-built site typically runs EUR 900-1,800 all-in (setup, configuration, translation review), plus around EUR 99 per year in licences. Shops and larger sites cost more; five languages is a EUR 3,000-5,000 project plus ongoing content upkeep.

What is hreflang and do I need it?

hreflang tags tell search engines which URL is which language’s version of a page, so each market sees the right one. Yes, you need it on every multilingual site – WPML, Polylang and Weglot generate it, but verify the pairs are reciprocal and include x-default.