Building a Multilingual WordPress Website

A multilingual WordPress website shows the same site in two or more languages, with each language version on its own URL so search engines can index it and visitors can switch between them. WordPress does not do this on its own. You add it with a translation plugin or by running WordPress multisite, and you need a plan for who writes and maintains each language. The technical setup takes days. The translation process lasts the life of the site.

Language or country?

Decide first what you are actually targeting. A site for French speakers anywhere is a language decision. A site for customers in France, with French prices, delivery and legal terms, is a country decision. The answer shapes the URL structure and how much of the site differs between versions.

URL structure options

For most UK businesses adding one or two languages, subdirectories are the right choice. All the plugins below support them.

Multilingual WordPress plugins compared

Pricing, WooCommerce support and machine translation options differ by plan and change often, so check each vendor's current details: WPML, Polylang, TranslatePress. Hosted translation services such as Weglot work differently again: translation happens through an external service on a subscription, which is quick to set up but adds a recurring cost and a dependency outside your site.

My default for a business site with a custom content model is Polylang or WPML, because both handle custom post types, taxonomies and custom fields properly. TranslatePress suits sites where editors want to translate what they see on screen. Multisite suits organisations where each language version is managed by a different team with genuinely different content.

Hreflang

Hreflang tags tell Google that pages are language versions of each other, so it can show the French version to French searchers. The main plugins generate them automatically. What matters is that they are correct:

• every version must link to every other version, including itself
• tags must be reciprocal; Google's guidance on localised versions says one-way annotations may be ignored
• an x-default tag should point to the fallback version, often the English site or a language selector
• only link pages that are actually translated, not pages that fall back to English

Check them with a crawler after launch. Broken hreflang is common and silent.

Content that gets missed

Translation plugins translate posts and pages easily. These are the items that get forgotten:

• menus, widgets and footer text
• form labels, error messages and confirmation emails
• custom fields, which need configuring as translatable
• SEO titles, meta descriptions and image alt text
• WooCommerce emails, shipping descriptions and checkout text
• legal pages, which may need local versions rather than translations
• theme strings hard-coded in templates, which must be properly internationalised in code

That last point is why the theme matters. A custom theme should wrap every text string in WordPress translation functions so plugins can find it. Custom post types and custom fields explains the field side.

SEO for each language

Each language version needs its own keyword research, because people in another language search for different phrases, not translated ones. Titles and descriptions should be written for that language, not translated word for word. The URL slugs should be translated too. The general principles of an SEO-friendly website structure apply to each version.

A worked example

Hypothetical, to show the decisions in order. Say a Kent engineering supplier sells to UK customers and wants to reach buyers in France and Germany. It has 30 pages, 12 product categories and a contact form, but no online checkout.

1. Targeting: French and German speakers, not specific countries, because prices are quoted on request. Language targeting is enough.
2. URLs: subdirectories, so /fr/ and /de/, keeping all links pointing at one domain.
3. Plugin: Polylang, because the content model uses custom post types and the editors are comfortable in the WordPress admin.
4. Scope: translate the homepage, the 12 category pages, the contact page and the legal pages first. Leave the English blog untranslated and out of the language switcher on those pages.
5. Translation: machine translation as a draft, then reviewed by a fluent speaker with technical knowledge, because a mistranslated specification is worse than none.
6. Enquiries: form labels and confirmation emails translated, and enquiries routed to whoever handles that language.

That site launches with 17 translated pages per language, not 30, and every one of them is good. It is better than a full machine-translated copy nobody has read.

Keeping it maintained

The common failure is a second language that is launched and then neglected. New pages appear in English only, prices drift, and the French site quietly falls out of date. Before launching, decide who translates new content, how quickly, and whether incomplete translations are hidden or fall back to English.

Next step

If you are adding a language to an existing site or building a multilingual one, I set up the structure, plugin and hreflang as part of the WordPress development service. The WordPress website development guide covers the content model decisions underneath it.