Choosing a CMS for a Multilingual Site in 2026: Honest Guide

Building for global audiences is easy to promise and hard to deliver — especially when your CMS wasn't designed for it. Most teams discover the gap mid-project: the CMS works great in English, then someone asks "can we do French and Arabic?" and suddenly you're reading GitHub issues about locale routing at midnight.

This guide covers what multilingual CMS support actually means, how the five main platforms handle it honestly, and — critically — when each one is the right call. Including an honest take on where UnfoldCMS sits in this picture (hint: it's not top of the list for heavy i18n work, and we're upfront about that).

TL;DR: Contentful and Strapi have proper built-in i18n. WordPress + WPML is the most widely deployed option. Directus handles it via a language field pattern. UnfoldCMS works for 1–2 languages using separate content per language — no translation UI, no locale routing, no RTL mode. If you need 5+ languages with editor translation workflows, Contentful or Strapi are the honest answer.

What "Multilingual CMS Support" Actually Means

The phrase covers four separate problems. Don't let a vendor slide over this — ask which ones they actually solve.

1. Translation management This is a UI where editors can write content in one language and translate it to another in the same interface, side by side. Fields stay in sync. A "needs translation" badge tells editors what's out of date. Without this, you're managing separate documents with no structural connection — which is fine for 2 languages, painful for 5.

2. Locale routing The CMS (or your frontend) serves /en/blog/post and /fr/blog/post as distinct URLs. The CMS knows which content belongs to which locale, so a fetch for locale=fr returns the French post — not the English fallback.

3. hreflang tags Each language version of a page carries <link rel="alternate" hreflang="fr" href="/fr/post/"> tags pointing to its equivalents. Without these, Google ranks one random language version and ignores the others. More on this below.

4. RTL layout support Arabic, Hebrew, Persian, and Urdu read right-to-left. A CMS without RTL consideration breaks your layout: text alignment, button placement, menu direction. This is a frontend concern too, but a CMS that outputs content with hardcoded dir="ltr" makes it harder.

When a CMS says "multilingual support," verify which of these four they handle. Often it's just #1 (translation management) and the rest is left to you.

The 5 Approaches to Multilingual CMS

There's no single right architecture. Here's what teams actually do:

Approach 1: Locale fields on the same content type The CMS has a locale field. One "Post" record has title_en, title_fr, body_en, body_fr. Simple schema, bad for scalability past 3 languages — you get very wide tables.

Approach 2: Content linked by translation group Each language is a separate record, but they're linked: post_en points to post_fr via a translation_group relationship. Cleaner schema, slightly more complex queries. This is what Strapi's i18n plugin does.

Approach 3: Headless + frontend routing All content is in English in the CMS. A translation layer (DeepL, Crowdin, a custom spreadsheet) generates translated copies that the frontend serves per locale. The CMS itself is "language-unaware" — the frontend handles routing and hreflang.

Approach 4: Separate installs per language One CMS instance for English, another for French. No syncing at all. Editors manage completely separate sites. Sounds wrong, but for teams with separate editorial teams per market, it's often the cleanest solution.

Approach 5: Separate content strategy, single CMS Same CMS, different posts per language with no structural link between them. The URL slug signals the language (/fr-best-cms or a language prefix). Works fine for 1–2 extra languages. Falls apart past that because there's no way to know what's been translated and what hasn't.

How 5 CMS Platforms Actually Handle It

This table is based on what each platform ships — not their marketing pages.

Let's go deeper on each.

Contentful

Contentful has the most polished i18n experience in this list. You define locales in the Space settings, then each content field gets a locale selector. Editors see all languages in one record. The Content Delivery API accepts ?locale=fr-FR and returns the right content.

The cost is real: Contentful's pricing is based on users and bandwidth, and starts at $300/month for team plans with more than 1 space. For international sites with multiple editors across markets, you're looking at $500–$1,500/month quickly. That's the honest trade-off. If your budget allows it, the i18n DX is excellent.

For a deep comparison, see UnfoldCMS vs Contentful.

Best for: SaaS products with budgets and editors in multiple markets.

Strapi

Strapi's Internationalization (i18n) plugin ships with Strapi v4+. You enable it per content type. Each content record gets a locale, and you can switch between locales in the editor. The API supports ?locale=fr filtering.

The real cost of Strapi is the deployment: it's a Node.js application. You need Node on your server, and Strapi's build process can be slow. Cloud Strapi starts at $29/month (Starter) — affordable — but the self-hosted path requires more DevOps knowledge than Laravel-based alternatives.

For the full picture, read UnfoldCMS vs Strapi.

Best for: Teams comfortable with Node.js who want solid i18n without a Contentful bill.

Directus

Directus doesn't have a "locale" first-class concept baked into the schema. Instead, you create a languages collection and a translations junction table per content type. It's more flexible but requires more setup — you're configuring the data model yourself rather than toggling a setting.

That said, Directus handles it well once set up. The admin UI has an interface for translating fields side by side. The REST and GraphQL APIs can filter by language. Like Strapi, it's a Node.js app.

More context in UnfoldCMS vs Directus.

Best for: Teams who want total control over the schema and are happy to set up the translation data model themselves.

WordPress + WPML or Polylang

This is what most multilingual sites actually run. WPML ($99/year for single site) or Polylang (free core, $99/year for Pro) add a translation layer on top of the standard WordPress post model. Each post gets a language, and the plugins link translated versions together. WPML also generates hreflang tags automatically, which saves you a significant amount of work.

The downside everyone on r/WordPress knows: plugin complexity. WPML specifically has a reputation for slowing down admin queries and causing conflicts with page builders. Polylang is lighter but has fewer features.

From a Hacker News thread on multilingual WordPress: "WPML works, but every major WP update and plugin update is a potential conflict event. We've been running it for 3 years and it's fine — just budget for maintenance."

If your team is already on WordPress, staying there and adding WPML is often the right call. The ecosystem support is there. The cost is ongoing maintenance awareness.

Best for: Teams already on WordPress with 2–10 languages.

UnfoldCMS — The Honest Picture

UnfoldCMS does not have built-in translation management. The post model has no locale field. There's no side-by-side translation UI. There's no locale routing. There's no RTL mode.

What you can do: create separate posts for each language, use URL conventions to signal language (/fr/ prefix or a slug like guide-cms-fr), and link them manually via the features the CMS does ship — like custom fields or related posts. This works for 1–2 languages where your editorial team is small.

If you have one market in English and want to add a Spanish version for one content section, UnfoldCMS can handle that through separate content — it's tedious, not impossible.

But if you need:

• Translation workflows where editors see "not yet translated" badges
• Locale-aware API queries
• Automatic hreflang generation
• RTL text direction

...then UnfoldCMS is not the right tool today. Strapi or Contentful are.

We build in public. Multilingual support is a future priority — but we won't ship a half-built version and call it "i18n support." When it ships, we'll document it properly.

For now: we're honest. UnfoldCMS is the right CMS for English-first projects, single-language sites, and dev teams who want a clean headless CMS without Node.js complexity. It's not the right choice for 5+ languages with editor workflows.

If you're still comparing options, the headless CMS checklist has a section on multilingual requirements worth reading before committing.

When Each CMS Wins

Not every site has the same multilingual requirements. Here's a plain-language decision guide:

You have a budget and need 5+ languages with editor workflows → Contentful The DX is the best in this list. Editors love the per-locale field switching. The API is reliable. Pay for it and move on.

You want open-source, Node.js is fine, and you need 3+ locales → Strapi The i18n plugin is solid. Self-hosting saves money. Accept the Node deployment overhead as the trade-off.

You want maximum schema flexibility and Node.js is fine → Directus More setup, more control. Good for complex content models where the standard "locale per record" pattern doesn't fit.

You're already on WordPress and need to add languages → WordPress + WPML/Polylang Don't migrate the whole site. Add WPML. Budget $99/year and some maintenance time. It works.

You're building in Laravel, you need 1–2 languages, budget is tight, and i18n is not a core requirement → UnfoldCMS Use separate posts per language. Keep the URL convention clean (/fr/ prefix handled at the routing level). Know going in that you won't have a translation management UI.

You're building English-only and might add one more language later → UnfoldCMS This is actually a reasonable choice. Most sites never reach the complexity where proper i18n infrastructure pays off. Start simple, migrate if you hit the wall.

Hreflang and Multilingual SEO — Where Teams Get It Wrong

Even if your CMS handles translation perfectly, hreflang is where multilingual SEO breaks down in practice. Three mistakes that hurt rankings:

Mistake 1: Missing the x-default tag Every multilingual site needs a language-selector page or a default fallback. The hreflang="x-default" points to whichever URL should show when Google can't match the user's language. Skipping it means Google guesses.

Mistake 2: Inconsistent canonicals and hreflang If /en/post/ has a canonical pointing to /post/ (no language prefix), but hreflang points to /en/post/, you're sending conflicting signals. Google will pick one and ignore the other — sometimes the wrong one.

Mistake 3: Partial implementation Hreflang only works when every language version references every other language version. If your French page points to English but not German, Google treats the French hreflang as incomplete and may ignore all of them.

A quick audit: fetch any multilingual page, view source, and count the hreflang links. There should be one per language version, plus x-default. If any are missing, you're leaking international traffic.

The headless CMS and SEO post covers this in more depth, including how hreflang interacts with headless frontends.

FAQ

Does UnfoldCMS support multiple languages?

Not with built-in i18n features. You can create separate posts per language and manage them manually, which works for 1–2 languages. For translation workflows, locale routing, or RTL layout, UnfoldCMS doesn't currently ship those features. Contentful and Strapi are the better choices for proper multilingual support.

What's the easiest CMS for a multilingual site?

WordPress with WPML or Polylang is the easiest path if you're already in the WordPress ecosystem. WPML handles URL prefixes, editor language switching, and hreflang tags automatically. For a headless setup, Contentful's per-locale field system is the cleanest editor experience, but it comes with a higher cost.

Can I add hreflang tags manually if my CMS doesn't generate them?

Yes. You can add hreflang tags in your frontend template or site layout, independent of what the CMS outputs. For a static site or Next.js app consuming a headless CMS, you generate hreflang in <head> based on available translations you know about. The complexity is maintaining the full mesh (every language pointing to every other language) as your content grows.

Does Google penalize sites that don't use hreflang?

Not directly. Missing hreflang doesn't trigger a penalty — it just means Google may show the wrong language version to users in different countries, or may fail to rank your non-English pages at all. The impact is lost international traffic, not a ranking drop on your primary language.

The Bottom Line

If you're building for a global audience and need proper multilingual support today — translation workflows, locale-aware APIs, hreflang automation — Strapi or Contentful are the right picks. Strapi if you want open-source and self-hosted. Contentful if you have the budget and want the smoothest editor experience.

WordPress + WPML remains the most widely deployed solution for a reason. It works, the plugin ecosystem is mature, and you don't have to rethink your whole architecture.

UnfoldCMS is the honest choice for dev teams building clean, English-first sites with Laravel, who want a developer-friendly CMS without Node.js overhead — and who don't need i18n infrastructure today. If that's you, take a look at what it ships: see what's included.

If your requirements have grown past 2 languages, we'll point you to Strapi before we'll sell you something that doesn't fit.

Sources and Methodology

• Strapi i18n plugin documentation: docs.strapi.io (reviewed June 2026)
• Contentful Localization guide: contentful.com/developers/docs/concepts/locales/ (reviewed June 2026)
• Directus Translations interface: docs.directus.io (reviewed June 2026)
• WPML: wpml.org — pricing and feature set as of June 2026
• Google Search Central: hreflang documentation — canonical reference for multilingual SEO
• Community discussion: Hacker News, r/webdev threads on multilingual CMS setups (May–June 2026)
• UnfoldCMS feature status: verified against cms-features.md (June 2026) — no i18n features confirmed shipped