Adding a second language sounds like a content job. In practice, it is an architecture decision. Multilingual WordPress can be handled by a plugin, by a network of sites, or by a small custom layer — and the route you choose determines your hosting bill, your SEO and how easily you can leave later. So let’s compare the three honestly, including the one we use here.
First, what multilingual WordPress must get right
Before tooling, the rules. Each language needs its own indexable URL — a folder like /el/ works well. Then each page must declare its alternates with hreflang, so Google serves the right version instead of picking one. Google’s guide to localised versions is the reference here. In addition, titles, meta descriptions, slugs and image alt text all need translating, not just body copy. Finally, keyword research must happen per language, because Greek searchers phrase things differently.
Route one: a translation plugin
WPML is the mature commercial option, with solid WooCommerce support and a translation-management workflow for agencies. Polylang is lighter and has a capable free tier, so it suits smaller sites. TranslatePress translates visually on the front end, which non-technical teams genuinely enjoy.
All three handle the SEO mechanics for you. However, they add database tables and queries, so an already heavy site gets heavier. Moreover, they own your translations. Consequently, removing the plugin later is a migration project, not a deactivation. Choose this route when you have three or more languages, a large catalogue, or several editors.
Route two: multisite
Here each language gets its own site in a WordPress network. As a result, content stays fully independent — useful when your Greek and English audiences need different products, prices or pages. Meanwhile the cost is duplication: two sets of plugins, two update cycles and no automatic link between a page and its translation. We recommend it mainly for genuinely different markets rather than for a translated brochure.
Route three: a small custom layer
This site runs the third option, so we can speak from experience. Each post and page carries extra fields for the Greek title, excerpt and body. The theme then serves them under /el/, swaps the hreflang tags and the sitemap entries, and keeps one set of templates. Therefore the site stays as fast in Greek as in English, with no extra plugin and no lock-in.
That said, be honest about the limits. A custom layer needs a developer once, it fits two languages rather than nine, and someone must maintain it. So it works beautifully for a bilingual company site and poorly for a shop with 4,000 products in five languages.
How to decide in five minutes
- Two languages, controlled content, speed matters: custom layer.
- Three or more languages, or a big WooCommerce catalogue: WPML.
- Small budget, simple site: Polylang.
- Different offers per market: multisite.
Whichever you pick, treat machine translation as a first draft and have a human edit it — the argument in our post on real-time AI translation. Also localise the details that convert: phone format, currency, VAT wording and city names, which feeds directly into local SEO. If you want a recommendation for your specific site rather than a generic answer, our team will look at your content volume and tell you which route costs least over three years.
