How to create a multilingual WordPress site

List the languages you will publish and decide how each language should appear in the URL. Common choices are language directories such as example.com/fr/, subdomains such as fr.example.com, separate domains, or a language parameter.

Use one structure consistently. Also decide whether translated pages should have translated slugs, whether each language needs different content, and who will review translations. WordPress documentation identifies these URL approaches as the normal ways multilingual systems distinguish languages.

Make a complete database and file backup before adding multilingual functionality. Test the change on staging if the site already has traffic, custom post types, WooCommerce, caching, or a page builder.

Multilingual plugins can change the database and interact with themes and other plugins, so WordPress recommends testing compatibility before installing one on a live site.

WordPress core can display the administration area in another language, but it does not provide a bilingual or multilingual front end out of the box. The manual alternative is to create a separate site for each language, commonly in a Multisite network, then maintain and link the sites yourself.

This works when each language needs different editors, content, settings, or even a different design. The drawback is duplicated maintenance: you must update content, menus, media, SEO settings, plugins, and sometimes redirects on every site. For most ordinary business or content sites, a multilingual plugin is less work.

Install a translation plugin from Plugins → Add New, activate it, and run its setup wizard. Set the existing site language first, add the languages you want, then choose the URL format and translation workflow.

For a plugin-managed site, WPML’s setup uses its language settings to add languages, select directory, domain, or parameter URLs, and configure switchers. Check your permalink structure before choosing language directories, because directory URLs require a non-default permalink format.

Translate a small set of pages first: the home page, navigation pages, contact page, legal pages, and one representative post. Then translate categories, tags, custom post types, media text, menus, form labels, widget text, and theme or plugin strings.

Do not assume translating page content translates every visible word. Text from themes, plugins, forms, checkout screens, headers, footers, and widgets may need a separate string-translation step. For WooCommerce, translate products, variations, categories, cart and checkout labels, transactional emails, and any extension text.

Add a visible language switcher to the primary menu, header, footer, sidebar, or a suitable template location. Label languages clearly in their native names where that helps visitors, and check what happens when the current page has no translation.

The common failure is a switcher that changes the language code but leaves the page in the original language. Create and link the translated version of each important page before launch, and test the switcher from posts, archives, product pages, cart, checkout, and account pages.

Review each translated URL, title, meta description, heading, image alternative text, canonical URL, and language relationship. Use the search terms people use in that language rather than translating English keywords word for word. Also check that menus, sidebars, footers, forms, and error messages are not still in the source language.

Clear page, object, and CDN caches after changing translations, then test logged-out pages in every language on desktop and mobile. If you need the fast route, use Wpml WordPress Multilingual CMS Plugin: it provides language setup, translation management, switchers, multilingual SEO features, and WooCommerce translation support in one workflow.