Multilingual Website Architecture in WordPress — Done Right

A multilingual website architecture looks like a plugin question on the surface. It's actually an architectural decision that needs to happen before you publish a single post. I've built this out for Wickie across four languages (DE, EN, FR, IT) and for Lipold in two (DE, EN). Here's the thinking I bring to every multilingual build.

URL Structure: Subdirectory, Subdomain, or Separate Domain?

You have three real options:

• Subdirectory (example.com/de/, example.com/en/) — recommended for most projects
• Subdomain (de.example.com) — viable, but more SEO overhead
• Separate domain (example.de, example.com) — only makes sense for genuinely independent brands

Google treats subdomains as separate websites. That means link authority is split across multiple hosts, and you need a separate Search Console property per subdomain. Subdirectories share domain authority and are simpler to configure. For both Wickie and Lipold, subdirectory was the obvious call.

hreflang: The Overlooked Requirement

hreflang tells search engines which page targets which language and region. The error rate here is surprisingly high — even on otherwise well-built sites.

The most common mistakes:

• One-sided hreflang: If page A references page B, page B must reference page A back. If the return pointer is missing, Google ignores the tag.
• Missing x-default: Without a fallback for users from regions you haven't explicitly targeted, Google guesses. Add an x-default tag.
• Inconsistent URLs: hreflang with a trailing slash, canonical without — that creates a conflict that tools will flag but plugins won't always catch.

WPML and Polylang generate hreflang automatically. With a pure gettext approach, you're responsible for it yourself.

WPML vs. Polylang vs. Gettext — the Real Tradeoffs

There's no universal answer here, but there is a clear decision logic:

WPML is powerful and well-maintained. It handles WooCommerce, custom post types, taxonomies, and strings in themes and third-party plugins — all out of the box. The cost is real (around €99/year for Multilingual CMS), and WPML writes its own database structures that can complicate migrations later. For client sites with non-technical editors, though, WPML is often the most pragmatic choice.

Polylang is cheaper (free core plugin, PRO around €99/year for full string translation). It's leaner than WPML but has gaps with complex string translations from plugins. For projects without WooCommerce and without heavy plugin string requirements, Polylang is completely adequate.

Gettext / theme-level translations — .pot files, __( ) calls in theme code, language files — work without a plugin and without database overhead. This is the clean approach for theme strings, buttons, and UI labels. But for editorial content (posts, pages, ACF fields), it doesn't scale on its own.

My approach on Wickie and Lipold combined both: Polylang for post and page translations, gettext for theme strings. That keeps the plugin surface small while giving editors a clean translation interface.

Translation Workflow for Editors

The tech is one half, workflow the other. What I recommend:

• The source language is always the master. Translations are derivatives — never the reverse.
• ACF fields must be explicitly configured for translation (WPML: sync field groups; Polylang: enable custom fields in settings).
• Translate permalinks per language — /about-us/ in English, /ueber-uns/ in German. It's extra effort but both users and search engines notice.
• Set up a 'translations pending' status or at least a checklist, so nothing goes live in the wrong language.

SEO Pitfalls I've Seen in Practice

Duplicate content from missing canonicalization: If your plugin indexes both language versions of a page without correct rel=canonical and hreflang, they compete against each other in search results.

Sitemaps: Every language variant needs to appear in the sitemap, ideally with hreflang annotation. Yoast SEO and RankMath handle this automatically when the language plugin is properly integrated.

Robots.txt and staging environments: If you block language directories on staging with noindex, double-check that it doesn't carry over to production by accident.

Performance: Multilingual plugins — especially WPML — can multiply database queries. Caching (e.g. WP Rocket with language-specific cache directories) isn't optional on multilingual sites; it's mandatory.

The Bottom Line

Multilingual website architecture is solvable, but the early decisions — URL structure, plugin choice, hreflang implementation — determine how much pain you carry later. Get them wrong and you spend months debugging SEO problems that were avoidable from the start.

If you're planning a multilingual WordPress project and want an honest assessment of your options, get in touch. I'll help you find the right architecture for your specific setup — without unnecessary detours.