Got a call from a client last week. They run a WooCommerce shop selling high-end audio gear and wanted to expand into the German market. They had tried to “just translate” their key pages, and it turned into a mess: product sync problems, SEO that went nowhere, and a language switcher that was really just a few links dumped in the footer. Good intentions, poor execution on their multilingual WordPress site.
I have seen this a dozen times. Someone reads a guide, maybe even the decent overview on the WordPress.com blog, and assumes it is straightforward. Running two languages, especially on an e-commerce site, is harder than that. It covers translated strings, but also inventory, user accounts, URL structures, and SEO. Get it wrong and you are in for a long cleanup.
The right and wrong way to handle a multilingual WordPress site
Years ago my first instinct might have been to duplicate the pages and move on. That is quick and it works well enough for a five-page brochure site. On a WooCommerce store it falls apart fast, because you end up with a tangle of content that nobody can manage. The fix is to plan the structure properly from day one.
There are really only two professional ways to tackle this: a Multisite setup or a dedicated multilingual plugin. Everything else is asking for trouble.
Option 1: the Multisite network
This is the heavy-duty option. You run a network of sites, one per language, where each language lives on its own domain (e.g., myshop.com for English and myshop.de for German). It suits large operations whose regional sites carry different content, marketing, or even separate product lines. The downside is the administrative overhead. You are maintaining separate sites, with separate user tables and separate content, so it is powerful but overkill for most businesses.
Option 2: a dedicated plugin
This is the right choice for almost everyone. Plugins like WPML or Polylang do more than add a language dropdown. They give you a framework for managing translations on a single WordPress install, and they handle the parts that cause the most trouble:
- SEO-friendly URLs: they create subdirectory structures automatically (like
/de/for German) and, just as important, manage thehreflangtags that tell Google which version of a page to serve in each region. Doing that by hand is painful. - Connected content: the plugin knows that a product in German is the same product as its English version, not a separate item. That matters for syncing inventory and reviews in WooCommerce.
- Translation management: you get a single interface that shows what is translated, what is pending, and what needs updating.
When a developer needs to build custom functionality, these plugins offer a stable API. For example, if you need to fetch the German version of a specific post ID inside a template, you don’t have to hack together some fragile query. You just use their hooks.
// Simple WPML example: Get German ID from an English Post ID
$english_post_id = 123;
$german_post_id = apply_filters( 'wpml_object_id', $english_post_id, 'post', false, 'de' );
if ( $german_post_id && $german_post_id !== $english_post_id ) {
// We have a valid translation, so we can get its URL
$german_url = get_permalink( $german_post_id );
// Now do something with it...
}So what’s the lesson here?
Do not try to outsmart the problem. Building a multilingual WordPress site without a dedicated plugin is like building a house with a hammer and no nails: a lot of noise, and a structure that falls apart. A premium plugin like WPML costs almost nothing next to the developer hours you will burn fixing a hacked-together manual setup. Pay for the tool. It was built by people who already solved the problems you have not run into yet.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
