How to Make a Multilingual WordPress Site the Right Way

Why build a multilingual site

People trust a site more when it speaks their language. A visitor who lands on a page in a language they do not read tends to leave within seconds, and search engines notice that quick exit. When you offer a proper translation, the same visitor stays, reads, and is far more likely to fill in a form or place an order. That is the core business reason to build a multilingual WordPress site, and it holds true whether you serve two languages or ten.

There is a search reason too. Google indexes each language version as its own set of pages, so a French version of your service page can rank for French queries that your English page never would. You are not splitting one page into two weaker halves. You are adding new pages that target new searches. Done well, a translated site widens the range of queries you can appear for without touching your original content.

Before you start, get clear on scope. Ask which languages you actually need, whether you will translate the whole site or only key pages, and who will keep the translations current as you publish. A shop selling across Canada might need English and French for legal and market reasons. A firm expanding into the Gulf might add Arabic, which brings right-to-left layout work. Write these answers down, because they decide which plugin and which URL structure fit you best.

• Reach: new language versions can rank for searches your single-language site cannot.
• Trust: visitors read, buy, and contact you more when the page matches their language.
• Compliance: some markets expect or require content in a local language.
• Support load: clear translated pages cut down on confused questions.

One warning up front. A half-translated site can hurt more than help. If your menu is in French but your checkout is in English, people lose confidence and abandon the visit. Plan to translate the full path a visitor takes, not only the home page. Later sections show you every part that needs attention, including the strings hidden inside your theme and plugins. If you want a second opinion on scope, our services page lays out how we usually stage this work.

Two approaches: single site vs multisite

WordPress does not ship with translation built in, so you choose an approach and add the pieces. There are two broad paths. The first keeps everything on one WordPress install and adds a translation plugin. The second uses WordPress Multisite, where each language is its own site inside a shared network. Most projects should start with the single-site plugin approach. Multisite solves a narrower set of problems and adds real overhead.

The single site plus plugin approach

Here you run one WordPress install, one database, and one theme. A translation plugin stores each language version of a post and links them together. When a visitor switches language, the plugin serves the matching version. This is the path most sites take because it is simpler to run, keeps content connected, and lets plugins manage the hreflang tags and language switcher for you.

The trade-off is that all languages share the same plugins, the same theme, and the same settings. For the large majority of sites that is exactly what you want. You write a post once, translate it, and both versions live side by side with shared categories and shared media.

The multisite approach

WordPress Multisite lets you run a network of sites from one install. You can make each language a separate site, for example an English site and a French site that share a user table. Each site has its own content, and you can even run different plugins or themes per language. Some large organisations use this when their regional teams need real independence, such as different products, different legal pages, or different editors who should not see each other content.

The cost is complexity. You now maintain several sites, keep them linked for language switching, and manage hreflang across them yourself or with a plugin that supports multisite. Content is not automatically connected, so an editor can update the English page and forget the French one. For most small and mid-size sites this is more machinery than the job needs.

Our advice: unless you have a clear reason to separate teams or run different features per market, choose the single-site plugin approach. It is easier to launch, easier to keep in sync, and every major translation plugin is built around it. If you are still building the base site, our guide on how to make a WordPress website covers the foundation you will translate on top of.

Choosing a translation plugin

The plugin you pick shapes your whole workflow, so choose with care. Four names come up again and again: WPML, Polylang, TranslatePress, and Weglot. Each takes a different view of how translation should work. Below is a plain description of each, then a comparison table to help you match one to your needs.

WPML

WPML is a long-standing multilingual plugin with wide compatibility. It stores translations as separate posts, gives you a translation editor, and supports translation management for teams and professional translators. It handles menus, taxonomies, custom fields, and works with many themes and page builders. It is a strong pick when you need control, team workflows, or compatibility with a complex stack. The trade-off is that it is a large plugin with many moving parts, so it asks for careful setup.

Polylang

Polylang is lighter and popular with people who want a clean, direct way to translate. You assign a language to each post and connect it to its translations. It gives you a language switcher and handles hreflang. Polylang keeps things close to how WordPress already works, which many developers like. For teams that want a professional translation workflow, an add-on connects it to translation services, but the core is deliberately simple.

TranslatePress

TranslatePress takes a visual approach. You translate the site from a live front-end editor, clicking any text on the page and typing the translation next to it. Because it works on the rendered page, it captures text from the theme and many plugins without you hunting for string files. It also supports automatic translation that you can then refine by hand. This visual model is friendly for people who are not comfortable in the WordPress admin, and it makes translating small interface strings quick.

Weglot

Weglot works differently again. It is a service that connects to your site, detects your content, and translates it through its own dashboard, serving the translated versions from its system. Setup is fast because it does much of the detection for you, and it handles the language switcher and hreflang. The trade-off is that your translations live partly in a third-party service rather than fully in your own database, and it runs on a subscription model. It suits teams that want speed and are comfortable with a hosted service.

How to decide? Match the model to your team. If a professional agency or in-house team will manage many languages with review steps, WPML fits. If you want something light and native to WordPress, Polylang is a good default. If your editors are not technical and you want to translate by clicking on the page, TranslatePress shines. If you want the fastest possible launch and do not mind a hosted service, Weglot is worth a look. There is no single right answer, only the right fit for how you work. If you would like us to test two of these against your actual theme before you commit, ask on our contact page.

Manual vs automatic translation

Whichever plugin you choose, you still decide how the words get translated. There are two methods, and most successful sites use a blend of both. Manual translation means a person writes each translated string. Automatic translation means a machine service produces a draft that you can accept or edit. Understanding the trade-offs keeps you from either wasting money or shipping text that reads wrong.

Manual translation

A human translator gives you the best quality, especially for marketing copy, brand voice, and anything where tone matters. A person understands context, idiom, and the difference between a formal and casual address, which many languages mark grammatically. The cost is time and budget. Translating a large site by hand is slow, and keeping it current as you publish new posts is an ongoing job.

Automatic translation

Machine translation has improved a great deal and produces readable drafts in seconds. It is ideal for getting a whole site into a second language quickly, or for content where perfect polish matters less, such as archive posts or internal help text. The risk is that machine output can miss context, mistranslate a product name, or pick the wrong tone. Never publish raw machine text on pages that carry your brand or drive sales without a human read.

The blended workflow most teams use

The practical answer is to combine them. Generate a machine draft to cover the whole site fast, then have a person review and correct the pages that matter most. This gives you speed on volume and quality where it counts. The plugins above support this pattern: TranslatePress and Weglot can auto-translate then let you edit, and WPML and Polylang connect to translation services while keeping human review in the loop.

1. Draft with a machine service so every page has a starting translation.
2. Prioritise your key pages, such as the home page, top service pages, and checkout, for human review first.
3. Edit for tone and terms, fixing product names, calls to action, and anything that reads stiff.
4. Set a rule for new content so future posts follow the same draft-then-review path.

A note on quality control. Build a short glossary of terms you never want changed, such as your brand name, product names, and key phrases. Give it to your translators and, where the tool allows, load it into the translation settings. That one step prevents a surprising amount of drift across a large site. For content-heavy sites, our post on how to create a blog in WordPress pairs well here, since a growing blog is exactly what makes translation upkeep hard.

URL structures for languages

Every language version needs its own URL so search engines can index it separately and visitors can bookmark and share it. There are three common structures, and the one you pick affects setup, maintenance, and the local signal you send to search engines. Choose before you launch, because changing URL structure later means redirects and lost time.

Subdirectory, such as example.com/fr/

This is the most common and usually the best default. Each language sits in a folder under your main domain. It is the easiest to set up, needs no extra hosting, and keeps all your languages under one domain so they share the same site authority. Every major translation plugin supports it out of the box. For most businesses, start here.

Subdomain, such as fr.example.com

Here each language lives on its own subdomain. Search engines treat subdomains as fairly close to the main domain, but you take on more configuration, including DNS records and sometimes separate certificates. Some teams choose this when different regional teams manage each subdomain, or when hosting constraints push them this way. It is a reasonable choice but rarely necessary for a single team.

Country code top-level domain, such as example.fr

A ccTLD uses a separate domain per country, like example.fr or example.de. This sends the strongest local signal and can help in markets where people trust a local domain. The cost is real: you buy and renew many domains, set up hosting or routing for each, and each domain builds its own authority from scratch. This suits large brands with serious commitment to specific countries, not a small site adding a second language.

One more detail: whichever structure you pick, keep the pattern consistent across every language and let your plugin generate the URLs. Mixing structures confuses both visitors and search engines. If you are unsure, the subdirectory pattern is the safe, common choice, and you can always grow into more separation later if a market truly demands it.

Hreflang tags and multilingual SEO

Hreflang is the single most important SEO detail on a multilingual site, and it is where many builds go wrong. An hreflang tag tells search engines that a page has other language versions and which one to show a given user. Get it right and Google serves your French page to French searchers and your English page to English searchers. Get it wrong and the wrong version shows up, or your pages compete with each other.

What hreflang does

Each page carries a set of annotations, one per language version, in the page head or in an XML sitemap. An English page about a service lists itself as English and lists the French version as French. The French version does the same in reverse. This tells search engines the pages are the same content in different languages, not duplicate content, and which to show based on the user language and region.

The rules that trip people up

• Links must be reciprocal. If the English page points to the French page, the French page must point back. A one-way link is ignored.
• Include a self reference. Each page must list itself in its own hreflang set.
• Use correct language and region codes. Use the standard codes, such as en, fr, ar, and add a region only when you truly serve different regional variants, like en-CA and en-GB.
• Add an x-default if useful. This tells search engines which page to show when no language matches the user, often your main or language-selector page.
• Point to indexable pages. Do not send hreflang to pages blocked by robots rules or set to noindex.

The good news: every major translation plugin generates hreflang tags for you when set up correctly. Your job is to verify they are present and correct, not to hand-write them on every page. That verification step matters, because a theme or another plugin can sometimes interfere.

Beyond hreflang: full multilingual SEO

Hreflang is necessary but not the whole job. Real multilingual SEO also means translating the parts search engines read: the page title, the meta description, the URL slug, image alt text, and any structured data. Do not leave French pages with English slugs and English meta descriptions. Translate the keywords too, because people search differently in each language, and a direct word-for-word match rarely captures how a native speaker actually searches.

1. Translate titles and meta descriptions for every language, not just the body text.
2. Translate URL slugs so the address matches the language of the page.
3. Research keywords per language because search terms differ across languages and regions.
4. Translate image alt text and structured data so those signals match the page language.
5. Submit a sitemap that includes all language versions so search engines find every page.

If you want a deeper foundation on the search side, our WordPress SEO guide covers the on-page basics that every language version should follow. Multilingual SEO is those same basics, repeated properly in each language, plus correct hreflang tying them together.

Translating menus, themes and plugins

New builders often translate their posts and pages, then wonder why the site still shows English buttons, English menu labels, and English form text. That is because a WordPress page is assembled from many sources, and a lot of visible text lives outside your posts. To ship a truly multilingual site, you translate all of it. This section maps every area and how to handle it.

Posts and pages

This is the obvious part. Each post and page gets a translated version, connected to the original by your plugin. Translate the title, the body, the excerpt, and the slug. Do not forget the featured image caption and the alt text on images, which are separate fields that stay in the original language unless you change them.

Menus

Navigation menus are stored separately from your content, so their labels need their own translation. Depending on the plugin, you either build one menu per language or translate the menu labels through the plugin interface. Check that menu items point to the correct language version of each linked page, so a French menu links to French pages, not English ones.

Categories, tags, and taxonomies

Category and tag names appear on archive pages and in menus, and they need translating too. Most plugins give you a place to translate taxonomy terms and their slugs. Skip this and your French blog shows English category names in the URL and on the page.

Theme and plugin strings, and gettext

This is the part that surprises people. Text like Read more, Add to cart, Search, and Your message was sent is written into your theme and plugins, not your content. WordPress handles this through a system called gettext. Developers wrap this text in translation functions, and the translations live in language files with the extensions .po and .mo. When a matching file exists for a language, WordPress swaps the original string for the translated one.

You have a few ways to handle these strings:

• Existing translations: many themes and plugins already ship translations for common languages, so you may find the text is already handled once you set the site language.
• String translation in your plugin: WPML and Polylang include tools to find and translate theme and plugin strings from the admin. TranslatePress captures much of this text directly on the front end because it reads the rendered page.
• A dedicated tool like Loco Translate: this lets you edit .po and .mo files from the WordPress admin, which is handy when a theme string has no translation yet.

A quick word on how gettext works, so the workflow makes sense. The source code contains a template file, usually with a .pot extension, that lists every translatable string. For each language you create a .po file that pairs each source string with its translation. WordPress reads a compiled .mo version of that file at runtime. Tools like Loco Translate hide this machinery behind a simple editor, but knowing the pieces helps when a string refuses to translate.

Forms, widgets, and page builder content

Contact forms, sidebar widgets, and content built in a page builder all hold text that needs translating. Forms often store labels and confirmation messages in their own settings. Widgets may need a per-language version. Page builders vary in how well they expose their text to translation plugins, which is one reason to test your chosen plugin against your actual builder before committing. If you run forms or bookings, our guide on how to add a booking system to WordPress shows the kind of plugin text you will also need to translate.

RTL languages and language switchers

Two features deserve their own section because they affect the visible design of your site: right-to-left languages and the language switcher. Handle both with care, because they are the first things a visitor notices.

Right-to-left languages

Languages like Arabic, Hebrew, Farsi, and Urdu read from right to left. This is not only about flipping text alignment. The whole layout mirrors: the menu, the sidebar, buttons, icons, and spacing all move to the opposite side. WordPress supports right-to-left layouts, and good themes ship a right-to-left stylesheet that loads automatically when the active language is right-to-left. When that stylesheet exists, much of the mirroring happens for you.

Problems appear when a theme or plugin was not built with right-to-left in mind. You might see text that stays left-aligned, icons on the wrong side, or padding that looks off. Here is how to handle it:

1. Choose a theme that states right-to-left support if you know you will serve a right-to-left language.
2. Test every template in the right-to-left language, not only the home page. Check the header, footer, forms, and any page builder sections.
3. Add right-to-left specific CSS for any element that does not mirror correctly, targeting the right-to-left state your theme sets on the page.
4. Check mixed content, such as a phone number or an English brand name inside Arabic text, which can display in an odd order without care.

Right-to-left work is where a translated site most often looks unfinished, so give it real testing time. It is also where an experienced team saves you hours, because the fixes are small but easy to miss.

Language switchers

The language switcher is how visitors move between languages. It sounds trivial, but small choices affect how usable your site feels. Every translation plugin provides a switcher you can place in the menu, a widget area, or the header.

• Show language names in their own language. Show Francais rather than French, and use the native script for others, so speakers recognise their language at a glance.
• Place it where people expect it, usually the top right of the header. Do not bury it in the footer only.
• Keep the visitor on the same page when they switch, not back to the home page. Switching from an English service page should land on the French version of that same service page.
• Be careful with auto-redirects. Automatically forcing a language based on browser settings can frustrate people and confuse search engine crawlers. If you detect language, offer a suggestion rather than a forced jump, and always let the visitor override it.
• Flags are not languages. A flag represents a country, not a language, and one language is often spoken in many countries. Prefer language names over flags, or use them together with care.

Test the switcher on mobile too, since header space is tight and a dropdown that works on desktop can be awkward on a phone. A clear switcher makes the whole multilingual effort feel intentional.

Testing before you launch

A multilingual site has more ways to break than a single-language one, so test methodically before you announce it. Work through each language as if you were a real visitor from that market. Below is a checklist that catches the common failures.

Content and links

1. Every key page has a translation and no page silently falls back to the original language.
2. Internal links stay within the language, so a French page links to French pages, not English ones.
3. Menus, categories, and tags are translated and point to the right language versions.
4. Forms submit and show confirmation text in the correct language.

SEO and technical checks

1. Hreflang tags are present, reciprocal, and use correct codes on every language version. Use a crawler or a testing tool to verify at scale rather than checking by hand.
2. Titles, meta descriptions, and slugs are translated for each language.
3. The sitemap includes all language versions and you have submitted it in Google Search Console.
4. No accidental noindex on translated pages, and no language blocked in robots rules.

Layout and display

1. Right-to-left languages mirror correctly across the header, footer, forms, and page builder sections.
2. Longer text does not break the layout. German and some other languages produce longer words and phrases that can overflow buttons and menus.
3. Special characters and accents display correctly, which comes down to correct character encoding across your site.
4. The language switcher keeps visitors on the same page and works on mobile.

Performance

Translation plugins add work on every request, and a site with several languages carries more assets. Check that your pages still load quickly in each language. If a translated page feels slow, the fixes are the same ones you would use anywhere, starting with images and caching. Our guides on how to speed up a WordPress website and how to reduce WordPress image size apply directly, since heavy images slow every language equally.

Where you can, ask a native speaker to read each language before launch. Automated tools catch technical faults, but only a person catches a translation that is technically correct yet reads oddly. A short review by a real speaker is one of the highest-value checks you can do.

Keeping translations current

Launching is not the finish line. A multilingual site needs upkeep, because every time you publish or edit content in one language, the others drift out of date. The sites that stay strong are the ones with a simple, repeatable process for keeping languages in sync. Set that process before you launch so it becomes a habit rather than a scramble.

A workflow for new content

1. Write in your primary language first, then translate, so you have one clear source of truth.
2. Translate as part of publishing, not as a separate project you postpone. A machine draft plus a quick human edit keeps the gap small.
3. Track what needs translating. Most plugins flag content that has changed in the source language but not yet in the others. Use that flag as your to-do list.
4. Review translations after theme or plugin updates, since updates can introduce new strings that arrive untranslated.

Common pitfalls to avoid

• Orphaned pages: a page updated in English but not in French leaves visitors reading old information. The change flag prevents this if you watch it.
• Untranslated new strings: after an update, check that no new theme or plugin text has appeared in the wrong language.
• Broken links after slug changes: if you change a slug in one language, check the translated versions and any internal links.
• Growing plugin conflicts: as you add plugins, test that each new one plays well with your translation setup before it reaches production.

Decide who owns this upkeep. On a small team it might be one editor. On a larger site it might be a shared checklist. Either way, name the owner, because translation drift is quiet and easy to ignore until a visitor points out that your French page still advertises last season. If you would rather not carry that load in-house, our services and pricing pages explain how we handle ongoing multilingual maintenance, and you can always get a free quote for a plan that matches how often you publish.

Bringing it together

Building a multilingual WordPress site comes down to a handful of clear decisions made in order. Choose the single-site plugin approach unless you truly need multisite. Pick the translation plugin that matches how your team works. Blend machine drafts with human review. Use the subdirectory URL structure unless a market demands more. Get hreflang right and translate the full SEO surface, not just the body text. Translate every hidden string, respect right-to-left layouts, and build a clear switcher. Then test each language like a real visitor and keep the translations current. Follow that path and you end up with a site that serves every audience properly, in the language they think in.