How to Make WordPress Multilingual: Translate Your Site and WooCommerce (2026)

A translated homepage won’t help much if your customer reaches checkout and can’t understand the delivery instructions. That’s the real challenge with multilingual WordPress: translating the whole experience, not just the pages that look good in a demo.

For a restaurant, that means menus, modifiers, collection times, payment messages, and order confirmations. For other WooCommerce stores, the same principle applies: customers should be able to finish what they started without unexpectedly changing languages.

This guide follows one translation setup from installation through testing, while explaining the decisions that affect search visibility, maintenance, and ordering accuracy.

What You Need for a Multilingual WordPress Website

Three things often get called “website translation,” but they do different jobs.

A language switcher is navigation. It lets visitors choose a language, but the switcher itself doesn’t create translations. Browser translation changes what an individual visitor sees; it doesn’t create translated pages on your domain that you can edit, optimize, and submit to search engines.

A proper multilingual setup provides persistent translated content at distinct URLs, such as an English menu at /menu/ and its Spanish version at /es/menu/. Search engines can discover those versions independently, provided they’re crawlable and not blocked from indexing.

Start with languages your customers actually need. Check language and location reports in your analytics, queries in Google Search Console, and the questions your staff receive. Browser language is a useful clue—not proof of someone’s preferred ordering language.

Imagine a neighborhood pizzeria serving English- and Spanish-speaking customers. Its first translation project should cover the menu, delivery area, opening hours, checkout, and collection instructions. Translating five years of blog posts can wait.

Before starting, arrange a backup, a staging environment, and a fluent reviewer. Machine translation can produce a first draft, but someone must own the accuracy of ingredients, policies, and customer instructions.

Also, language and currency are separate settings. A Spanish-language menu can still charge in US dollars. Adding another currency requires its own pricing, gateway, and potentially tax considerations; translation alone doesn’t provide those decisions.

Choose a WordPress Translation Plugin That Fits Your Site

The useful comparison isn’t “which plugin has the longest feature list?” It’s how translations are edited, what WooCommerce functionality requires, and what you’ll keep paying for. TranslatePress, WPML, and Polylang approach those jobs differently.

TranslatePress: editing the visible page

TranslatePress provides a front-end translation editor: open a page, select visible text, and enter its translation. This is approachable for owners who want to translate a menu while looking at its layout.

The free version supports an original language plus one additional language. More languages require the paid Multiple Languages add-on; translating SEO metadata and URL slugs requires the paid SEO Pack. Automatic translation is available, but included allowances, supported engines, and any separate API charges depend on the setup and license.

Visible WooCommerce content can be translated through this workflow. That doesn’t establish compatibility with every checkout extension, external widget, or email template.

WPML: structured translation management

WPML offers translation-management workflows for content, strings, and assignments to translators. Its automatic translation uses credits, with costs affected by the engine and purchasing arrangement.

For a WooCommerce store, the relevant setup is a WooCommerce-capable paid package, generally Multilingual CMS or Agency, with WPML Multilingual & Multicurrency for WooCommerce and the required supporting components. Multilingual SEO also depends on configuration and integration with your SEO plugin.

Polylang: linked content in each language

Polylang organizes posts, pages, and other content as linked language versions. That suits an editorial workflow where each language has its own content editing process.

The free core plugin isn’t the complete WooCommerce solution: Polylang for WooCommerce is a separate paid component. Pro features and integrations handle additional workflow needs, including its DeepL integration for machine translation; translation-provider costs may apply separately. SEO metadata support should be checked against the SEO plugin in use.

For this walkthrough, we’ll use TranslatePress’s visual editor. Install only that translation system—not all three. Before purchasing, confirm the current feature matrix and documentation for your chosen plan, especially SEO, language limits, automatic-translation allowances, and WooCommerce requirements. Subscription cost and translation usage are two different budget lines.

Set Up Your Languages and Translate Your Main Pages

Install and establish the URL structure

Work on staging first, with public access restricted and search indexing discouraged. Take a fresh backup, then go to Plugins → Add New, search for TranslatePress, and install and activate it. Add licensed components only if your project needs their features.

Under Settings → TranslatePress, set the default language to the language your existing content actually uses. Then add your additional language and save. Don’t select Spanish as the default simply because Spanish is the translation you’re about to create.

Choose your language URL approach before sharing translated links. TranslatePress supports language subdirectories, such as /es/, and a setting to include a language subdirectory for the default language. Keeping existing English URLs and adding /es/ is usually the least disruptive starting point for an established English-language site.

Open both language versions and check that they load over HTTPS without redirect loops. If changing a live site’s existing URL structure, plan permanent redirects rather than leaving old links broken.

Translate the pages customers need first

Open the homepage and use Translate Site from the WordPress toolbar. Select text in the visual editor, enter the translation, save, and check the result at the translated URL. Exact controls can vary by version.

Work through the ordering path rather than translating pages alphabetically:

1. Translate homepage headings, ordering buttons, and opening-hour messages.
2. Translate header navigation, footer links, and mobile-menu labels.
3. Translate contact details, delivery-area explanations, and collection instructions.
4. Translate menu categories, item descriptions, and links into the shop.
5. Translate privacy, refund, and other policy pages customers encounter before ordering.

Keep street addresses accurate and recognizable. Translate the instruction “Collect from the side entrance,” not the business’s official street name into an invented equivalent.

Automatic translation can speed up this stage. However, don’t assume generated text enters a private approval queue: it may become visible depending on configuration. Generate and review it on staging before exposing the translated site publicly.

[IMAGE: WordPress restaurant homepage in a visual translation editor, with an English ordering button selected and its Spanish translation displayed beside the page preview]

Make the switcher easy to find and operate

Use the plugin’s supported menu integration, block, shortcode, or floating switcher as appropriate for your theme. Label choices with recognizable language names, such as “English” and “Español,” rather than flags alone. Countries and languages don’t have a one-to-one relationship.

Place the switcher where desktop and mobile visitors can find it. Check keyboard focus, Enter or Space activation where applicable, screen-reader labels, and touch-target spacing.

Finally, switch languages while viewing an individual menu item. The visitor should reach that item’s translated equivalent, not get dumped back on the homepage. Use language-aware switcher links rather than manually linking every choice to a language homepage.

Translate WooCommerce Products and the Ordering Journey

WooCommerce translation gets interesting after someone clicks “Add to cart.” Product pages are only one part of a journey that includes notices, validation errors, account screens, and sometimes third-party payment interfaces.

WooCommerce provides community-maintained language packs for many standard interface strings. Those don’t automatically translate your product copy, custom fields, or every extension’s messages, and coverage varies by locale.

Work through a real order

Create a representative test order rather than checking an empty cart. For our pizzeria, use a large mushroom pizza with extra cheese, a gluten-free base option, and pickup at a selected time.

Translate the product name, short and full descriptions, category labels, attribute names, and visible variation choices. Then select each option and inspect the resulting price display, availability message, and cart line item. The goal is to translate what customers see—not manually rename internal IDs or integration values.

Review each stage in the chosen language:

• Product options, required-selection warnings, and add-to-cart notices.
• Cart items, coupon messages, removal notices, and empty-cart text.
• Checkout labels, required-field errors, delivery or pickup choices, and order notes.
• Payment instructions, terms acceptance, and the order-received page.
• Account login, password reset, order history, and order details.

Trigger errors deliberately. Leave a required field blank, enter an invalid postcode, and try an unavailable delivery address. A perfect-looking checkout can still hide untranslated messages until something goes wrong.

Check restaurant extensions separately

For restaurant-specific ordering, FoodMaster’s WooCommerce restaurant ordering system provides delivery, pickup, dine-in ordering, QR table ordering, POS, kitchen display, and automatic printing capabilities. It’s a relevant foundation when your restaurant needs more than a standard product catalog.

Translation compatibility is a separate acceptance test, though. Check the particular FoodMaster screens and features you enable with your chosen translation setup; don’t assume every selector, kitchen label, or printing output follows the storefront language.

The same applies to a checkout extension such as Tipping’s tip option for WooCommerce checkout. Review the tip label, preset choices, custom-amount prompt, and order summary in each language if you add it.

Dynamic text deserves special attention. Open modifier dialogs, change fulfillment methods, and wait for delivery slots to refresh. Some strings arrive through JavaScript, AJAX, or external services and may need another translation mechanism—or developer work—rather than selection in the visual editor.

Review food terminology and emails by hand

Have a fluent reviewer check our sample pizza order against the kitchen’s actual ingredient and preparation information. “Gluten-free base available” must not become “allergen-free pizza.” “No added nuts” is not the same claim as “nut-free.”

Confirm that modifiers preserve meaning and fulfillment instructions remain unambiguous. Don’t automatically translate customers’ free-text allergy notes without retaining the original and having staff clarify uncertainty.

Customer emails need their own check. Browser-side translation doesn’t guarantee that confirmation, refund, or password-reset emails use the customer’s language. Verify how your plugin version handles email language, how that language persists when staff update an order, and whether custom templates require separate configuration.

Make Translated Pages Discoverable in Google

Search visibility starts with accessible translated URLs, not a flag icon. Each language version needs meaningful translated content at a URL that search engines can crawl without logging in or changing a browser preference.

Translate metadata and check canonical tags

Give important translated pages their own titles and descriptions. Write them for local search intent instead of mechanically translating every word. “Pizza collection” and “pizza pickup,” for example, reflect different regional usage even within English.

In TranslatePress, translating SEO titles, descriptions, and URL slugs requires the paid SEO Pack. Confirm compatibility with your SEO plugin and other relevant metadata, including social-sharing text. Translating the visible heading alone doesn’t translate the document title.

A translated slug is useful, but it isn’t mandatory for indexing. An address such as /es/menu/ can work; consistency and correct language content matter more than making every URL word different.

Check canonical tags on representative pages. Normally, an independently indexable Spanish page should identify its preferred Spanish URL, not canonicalize to the English original. Don’t canonicalize every translation back to the default language. That sends the wrong signal about which pages you want indexed.

[IMAGE: Annotated multilingual menu example showing English and Spanish URLs, a self-referencing canonical on each version, and reciprocal hreflang links connecting the two pages]

Verify hreflang and sitemap output

Hreflang annotations identify equivalent pages for different languages or language-region combinations. An English menu should reference itself and its Spanish counterpart; the Spanish version should return those references. Each annotation should use the correct language code and a full, working URL.

Use regional targeting only when you genuinely maintain regional alternatives. Spanish content doesn’t automatically need an es-ES designation if it serves Spanish-speaking customers across multiple countries. Google’s documentation on localized page versions explains supported codes, reciprocal annotations, and the optional x-default fallback.

Inspect page source and search for “canonical” and “hreflang.” Check the homepage, a category, a product, and a policy page in each language. Look for incorrect destinations, duplicate output from different plugins, and links that redirect or return errors.

Then inspect your generated XML sitemap. TranslatePress’s multilingual sitemap integration is associated with its SEO Pack and supported SEO plugins; verify the output rather than assuming activation is enough. Confirm that translated URLs or language annotations appear as expected, and use Search Console to inspect sample URLs.

Keep language selection available to everyone. Forced IP- or location-based redirects can send travelers to the wrong version and complicate crawling. A dismissible language suggestion is generally less frustrating than taking control away from the visitor.

Test Your Multilingual Site Before Launch—and Keep It Updated

Do the final pass logged out, on a real phone, with caches enabled as they will be in production. Administrator sessions can bypass caching and hide problems ordinary customers will see.

• Open desktop and mobile navigation in every language, including the switcher.
• Use the keyboard to reach, open, and activate each language choice; verify visible focus.
• Check long translated labels for clipped buttons, overlapping prices, and horizontal scrolling.
• Complete a test order in each language using an appropriate payment test mode, then verify confirmation screens and emails.
• Check that carts persist appropriately when switching languages and that delivery selections remain understandable.
• Confirm translated pages aren’t serving another language’s cached content, and exclude personalized cart, checkout, and account content from full-page caching.

For missing translations, first identify where the text originates: page content, WooCommerce language files, an extension, JavaScript, or an external payment interface. Reproduce the exact action that reveals it, then check the appropriate translation controls. Clear relevant caches after corrections.

If checkout unexpectedly switches language, inspect the destination URL of the checkout button, theme links, redirects, and payment return URL. Check whether the problem occurs before payment, after payment, or only in emails—those are different failure points. On staging, isolate suspected conflicts one component at a time.

Make translation review part of ordinary menu maintenance. When ingredients, prices, opening hours, or policies change, assign someone to update and verify every language. WooCommerce’s underlying price may remain shared, but translated promotional copy saying “Lunch for $12” won’t necessarily update with it.

A multilingual restaurant site is ready when a customer can understand the meal, place the order, and receive accurate instructions in their chosen language. Keep testing that complete journey whenever the menu or ordering system changes. That’s where the translation earns its keep.