Multilingual WordPress: choose what shares fate

If the same team publishes the same page types and campaigns across languages, test one installation with a translation plugin. If local teams own distinct navigation, content, settings, domains, and release choices, test Multisite. If a market needs its own security boundary, infrastructure lifecycle, vendor, or extraction path, test separate installations.

Treat this as a starting hypothesis that still requires testing. Ecommerce inventory, memberships, search, forms, consent records, CRM routing, media, and product data can create shared-state requirements that cut across the editorial model.

The official WordPress Multisite overview describes several WordPress instances managed within one installation. It states that site content has separate database tables while the user table is shared. It gives regional business sites sharing themes or plugins as one example.

The Multisite administration documentation says network sites are separate sites and do not share content by default. Plugins can be enabled per site or network-wide, depending on their implementation. Treat content synchronisation, shared search, taxonomies, media, forms, and cross-site relationships as explicit integration work.

The current WPML setup guide documents a translation dashboard, human and automatic translation paths, content types, taxonomies, strings, menus, and URL-format choices. Its automatic-translation review guide distinguishes waiting for review from publishing and marking for later review. Map those product states to your own approval policy rather than assuming “translated” means approved.

Polylang documents language directories, subdomains, and multiple domains in its URL modification guide. It also warns that deactivation can remove language information from URLs and break external links for some configurations. Its strings documentation distinguishes core string handling from Pro features such as translated URL slugs. Confirm the edition and every extension against the real content model.

Google’s localized-versions documentation says each hreflang set should include the page itself and the other versions, and links must be bidirectional. Google supports HTML, HTTP headers, or XML sitemaps as equivalent methods and notes there is no Search benefit in maintaining all three.

Google’s multi-regional and multilingual guidance recommends different URLs for different language versions and explains the distinction between multilingual and multi-regional sites. Build a page-pair register containing URL, language, optional region, canonical, alternates, index state, source/translation relationship, redirect, last review, and owner.

Do not create hreflang for a page that does not have a useful alternate. Do not canonicalize localized pages to the source merely because they share a template. Validate the rendered output and sitemap relationships after releases and migrations.

For Leverage Edu, Some Tech Work moved a single WordPress site to a six-property network across markets and brands. The properties share a platform and update pipeline while retaining independent content and editorial structures. The migration ran without editorial downtime.

That evidence supports this specific operating model. It does not make Multisite the default for a two-language site. The architecture decision should still follow the current organisation, content relationships, integrations, recovery requirements, and exit path.

Give prospective partners the ADR, representative corpus, migration inventory, integration map, and acceptance tests. That exposes whether estimates cover content relationships, local workflows, SEO migration, recovery, and extraction rather than only plugin installation.

Some Tech Work designs and operates multilingual WordPress platforms, including migrations, editor workflows, integrations, performance, and maintenance. For an existing site, use the B2B website relaunch scope template before requesting proposals.