A multilingual WordPress site reaches audiences that a single-language site cannot. Serving content in visitors’ native languages increases engagement, trust, and conversions — and WordPress, with the right setup, handles translation with the same flexibility it brings to every other aspect of site management. WordPress translation has multiple implementation approaches for different site types and budgets, from free community-driven translation to enterprise-grade multilingual plugin solutions. We go deeper on the whole subject in our Complete Guide to WordPress How.
WordPress Translation — The Core Platform Foundation
WordPress itself is translated into over 200 languages — the admin interface, error messages, date formats, and core strings all adapt to the configured language. This core WordPress translation infrastructure is the foundation that multilingual plugins build on. Understanding how it works prevents confusion about where site-level translation ends and plugin-level translation begins.
Set the WordPress admin language: Settings → General → Site Language → select from the dropdown → Save Changes. WordPress downloads the language pack for the selected locale and displays the admin in that language. Each user can independently set their admin language in Users → Your Profile → Language — allowing a French-speaking editor and an English-speaking developer to work in the same WordPress installation in their respective languages. This admin-level WordPress translation is separate from the front-end language — the site can display content in French while the admin interface used by the English-speaking team shows in English.
Theme and plugin WordPress translation readiness depends on whether the developer implemented internationalisation (i18n) correctly: wrapping all user-facing strings in translation functions (__(), _e(), esc_html__()) and registering a text domain. Themes and plugins that are correctly internationalised can be translated by anyone — the WordPress.org translation platform (translate.wordpress.org) hosts community translations for all plugins and themes in the directory. When a plugin with community translations is installed and WordPress’s site language is set, WordPress automatically downloads the translation files from the translation platform. Plugins and themes that are not internationalised — where strings are hard-coded in English without translation functions — cannot be translated without modifying the source code. According to the WordPress developer documentation, all themes and plugins submitted to the WordPress.org directory must be internationalised as a submission requirement, making the directory a reliable source of translatable code.
Multilingual Plugin Approaches
A genuinely multilingual site built on WordPress translation lets visitors choose their language, content exists in multiple languages, and URLs, metadata, and navigation all adapt per language — requires a dedicated multilingual plugin. WordPress translation at this level goes beyond the single-language admin interface to a full parallel content management system for each language.
The three most widely used WordPress translation plugins:
| Plugin | Approach | Cost | Best For |
|---|---|---|---|
| WPML | Separate post translations linked to original | Premium ($39–$199/year) | Complex multilingual sites, ecommerce |
| Polylang | Similar to WPML, free core with paid add-ons | Free / Pro ($99/year) | Standard multilingual blogs and brochure sites |
| TranslatePress | Visual front-end translation editor | Free / Pro ($79–$199/year) | Sites where non-technical users translate content |
WPML’s WordPress translation approach creates separate linked posts to the original — translating a post creates a new post entry in the database for each target language, with relationships stored separately. This gives each translation a unique URL (/fr/post-slug/ for French, /de/post-slug/ for German) and allows SEO metadata to be set independently per language. Polylang uses an identical approach with a lower price point and a free core version. TranslatePress overlays a translation interface directly on the front-end of the site, allowing translators to click any visible text and translate it inline without navigating between admin pages. This visual approach makes WordPress translation significantly more accessible to non-technical translators who find the admin-based approach confusing.
URL Structure for Multilingual WordPress
URL structure for WordPress translation sites affects SEO performance and user experience — each language’s content should have its own URL that search engines can index independently and users can share and bookmark.
Three URL structures are available for WordPress translation implementations:
- Subdirectory (yoursite.com/fr/) — easiest to set up, works with a single domain and SSL certificate, consolidates domain authority, recommended for most multilingual sites
- Subdomain (fr.yoursite.com/) — treated as separate sites by search engines, requires wildcard DNS and SSL, appropriate when different languages truly represent different target markets
- Separate domains (yoursite.fr) — maximum separation between languages, strongest signal to search engines of geographic targeting, highest maintenance overhead
All three are supported by major WordPress translation plugins, configured in the plugin’s languages settings. The subdirectory approach is recommended for most sites because it consolidates domain authority (all languages share the same domain’s PageRank), requires only one SSL certificate, and is the simplest to maintain technically. Configure the URL structure during initial multilingual plugin setup before any content is created — changing the URL structure after content exists requires redirecting all existing language URLs to the new format, which is feasible but adds significant migration work. Our guide on creating a WordPress XML sitemap covers the multilingual sitemap configuration that Rank Math and Yoast provide when integrated with WPML or Polylang, providing language-specific sitemaps that search engines use to correctly attribute each language’s content to the appropriate locale and region.
Automatic and Machine Translation
Manual WordPress translation — human translators writing each language version of every post — produces the highest quality but is expensive and time-consuming. Machine translation using AI tools allows rapid translation of large content libraries at a fraction of the cost, with human review for quality control.
TranslatePress and WPML integrate DeepL and Google Translate for automatic WordPress translation: configure the API key in the plugin settings → select any post or page → click “Translate automatically” → the machine translation populates all target language fields instantly. The machine translation output requires human review for accuracy, cultural appropriateness, and terminology consistency — especially for technical content, legal text, and marketing copy where precise language matters. For content where machine translation quality is sufficient without review (product descriptions with simple specifications, metadata, navigation labels), automatic translation dramatically reduces the per-word cost of multilingual content creation.
The DeepL API consistently produces higher quality translations than Google Translate for European languages, with particular strength in German, French, Spanish, and Dutch — the most common target languages for European WordPress sites implementing multilingual WordPress translation. Both APIs charge per character translated — estimate the translation cost for the full content library before committing to automatic translation for a large site. For sites with thousands of posts, a prioritisation strategy (translate high-traffic pages first, lower-traffic content later) manages API costs while delivering the multilingual experience to the most visited content first. Reviews from DeepL’s translation quality research confirm that DeepL’s neural machine translation consistently outperforms other API-based translation services in blind evaluation tests for European language pairs, making it the preferred API integration for WordPress multilingual sites where translation quality is a priority. Our guide on managing WordPress user roles covers the Translator role configuration that WPML and TranslatePress add to WordPress’s standard role system, allowing translators to access content for translation without broader admin access.
SEO for Multilingual WordPress Sites
Correct SEO for multilingual WordPress translation ensures each language version of the content is correctly attributed to the intended language and region, preventing duplicate content issues and ensuring each language ranks appropriately in its target country’s search results.
The hreflang attribute is the critical SEO element for multilingual sites — it tells search engines which language and optional region each URL targets and links all language versions of the same content together. WPML and Polylang both generate hreflang tags automatically when integrated with Yoast SEO or Rank Math. Verify hreflang implementation: view the page source of any translated page → search for “hreflang” → confirm there is a hreflang attribute for each available language version including the original, and that each points to the correct absolute URL. Missing or incorrectly configured hreflang tags cause search engines to treat each language version as independent content — potentially triggering duplicate content signals or incorrectly ranking the wrong language version for users in a specific region.
Multilingual sitemaps for WordPress translation sites should include all language versions of each URL, with hreflang annotations in the sitemap. Rank Math’s sitemap settings with WPML integration automatically generate a language-aware sitemap that includes all language versions. Submit all language sitemaps to Google Search Console — either as individual sitemaps per language (sitemap-fr.xml, sitemap-de.xml) or as a single index sitemap that lists all language sitemaps. Google Search Console’s International Targeting report shows which languages and regions Google has attributed to each sitemap, confirming that the multilingual WordPress translation SEO configuration is being correctly interpreted. Setting the geographic targeting in Search Console for each language’s subdomain or subdirectory (if applicable) provides additional signals about the intended target market for each language version of the content.
RTL (right-to-left) languages — Arabic, Hebrew, Persian, Urdu — require additional layout considerations beyond WordPress translation of the text itself. WordPress 4.1+ has native RTL admin support, automatically flipping the admin layout when a RTL language is set. On the front-end, RTL layout requires CSS direction settings: body { direction: rtl; text-align: right; } and potentially a separate RTL stylesheet that mirrors all LTR layout rules. Most Accessibility Ready and widely used themes include RTL stylesheets (look for rtl.css in the theme folder). WPML and Polylang detect RTL languages and apply the correct direction attribute to the HTML element automatically. For custom themes without RTL support, the child theme approach provides the correct place to add RTL CSS without modifying the parent theme. Testing RTL layout should include checking that icons, bullet points, navigation arrows, and form layouts all mirror correctly — RTL is not just right-aligned text but a complete mirroring of all directional visual elements.
Content maintenance for multilingual WordPress translation sites requires a workflow for keeping translations in sync when the original content changes. WPML’s translation management system tracks whether translations are up to date — when the original English post is updated, WPML marks all translations as “needs update” and can send notification emails to assigned translators. TranslatePress highlights strings that have changed since the translation was created. Without a systematic update tracking process, translated content gradually falls out of sync with the original — showing outdated information to non-English visitors while English visitors see current content. Establishing a content update workflow that includes updating translations (or marking them for re-translation) whenever the original content changes is as important as the initial translation setup for maintaining a high-quality multilingual site long-term.
WooCommerce multilingual WordPress translation through WPML (which includes WooCommerce Multilingual as a free add-on) allows translating product names, descriptions, categories, attributes, and checkout strings. Orders are processed in the visitor’s selected language and the WooCommerce dashboard shows orders from all language versions in a unified view. Currency display per language (showing USD for English, EUR for French, GBP for UK English) requires WPML’s Multi-Currency add-on or the WooCommerce Currency Switcher plugin. For WooCommerce stores targeting multiple countries with different pricing, currency, and tax requirements per region, WPML’s WooCommerce Multilingual provides the most complete solution available — handling all aspects of the transaction flow in the appropriate language without requiring separate WooCommerce installations per market.
String WordPress translation for theme and plugin text that is not in posts or pages — navigation labels, footer copyright text, sidebar headings, and widget titles — requires a different approach than post content translation. WPML’s String Translation module captures these strings and allows translating them through the WPML String Translation admin panel. TranslatePress captures all visible strings on the front-end through its visual editor, including theme and widget strings. Polylang handles string translation through the Polylang for WooCommerce add-on and the free polylang-strings library. For sites using WPML, registering custom strings programmatically using do_action('wpml_register_single_string', 'context', 'string_name', $string); makes any custom PHP string available for translation through the WPML String Translation panel, ensuring even hard-coded strings in custom theme functions are translatable without modifying the source code.
Performance optimisation for multilingual WordPress translation sites is more complex than for single-language sites because page caching must account for language — serving the French cached version of a page to an English visitor produces the wrong content. Configure the caching plugin to cache per-language: WP Rocket detects WPML and Polylang automatically and creates separate cache entries per language. LiteSpeed Cache has WPML integration in its Compatibility settings. Without language-aware caching, the cache must be completely bypassed for multilingual sites — significantly reducing the performance benefit of caching. Verify language-aware caching is working by visiting the same URL in two browser sessions with different language cookies set, and confirming each session receives the correct language version from cache rather than both receiving the same language. If this sounds familiar, WordPress GDPR Compliance is worth a look.
