How to manage multilingual content efficiently with Payload CMS and Next.js

Managing multilingual content with Payload CMS and Next.js is not about flipping a plugin on. It is a product model: which fields are localized, how URLs behave, and how your team publishes without breaking SEO. Here is a practical method used in production on beease.fr (FR / EN) and on client projects shipped with this stack.

If you are building a brochure site or a headless redesign, the business goal is simple: a marketing team that publishes in French, a coherent English version, and Google that clearly knows which language to serve. Our Payload CMS + Next.js offer is built exactly for that.

The real problem: one bilingual site, two conflicting truths

Many “multilingual” projects end up as fragile duplicates: two trees copied by hand, translation plugins fighting the theme, unstable URLs, meta forgotten in one locale. Marketing loses time, SEO dilutes, and every page change becomes a ticket.

With a headless CMS like Payload, you separate clearly:

• editorial content (pages, posts, meta) localized in the CMS;
• UI chrome (buttons, nav labels, empty states) handled in the front end;
• routing (locale prefix, slugs, hreflang) wired once.

That is the same logic that makes Payload healthier than a WordPress plugin factory: fewer patches, more structure. We covered it in Payload CMS vs WordPress and in our comparison of headless alternatives to WordPress.

What Payload localizes (and what it does not)

On beease.fr, the Payload config stays intentionally simple: two locales (fr, en), default locale fr, and fallback: true. In practice, if an EN field is still empty, Payload returns the FR value when reading. You avoid blank pages while translation is in progress.

Typical localized fields on a Beease site:

• title, slug, rich text (content / layout / hero);
• SEO meta (title, description, image) via @payloadcms/plugin-seo;
• some global labels (header, footer).

What stays non-localized on purpose: categories, publish dates, structural relations, and often media (except alt). One Payload document has a single ID and several locale field sets. You do not duplicate the page: you complete the locale.

Practical rule: publish the source locale first (FR), then translate the same record. Never maintain two “twin” documents by hand.

Official Payload docs on localization cover the options; the differentiator is wiring them to a real Next.js front end and a clear editorial process.

Next.js: predictable next-intl routing

On the front end, beease.fr uses next-intl with localePrefix: "as-needed" and localeDetection: false. In plain terms:

• French has no prefix (/blog/...);
• English lives under /en/...;
• no auto-switch from Accept-Language: the user (or the link) chooses the language.

Why turn off auto-detection? It surprises visitors, breaks shared URLs, and often mixes SEO with UX. A stable URL per locale, an explicit switcher, and alternates / hreflang built from each locale’s slugs: more predictable for Google and for your teams.

The Next.js + Payload pairing also keeps editorial HTML on the server: essential for a truly SEO-ready CMS.

Two layers: CMS content vs UI chrome

A common mistake: putting everything in Payload, including “Read more” or “Home”. On beease.fr, we split:

• Payload: titles, body, editorial CTAs, meta, slugs;
• next-intl messages (messages/fr.json, messages/en.json): UI labels, breadcrumbs, empty states.

Result: writers focus on content that converts. Developers version UI chrome like code. Less friction, fewer regressions each release. For project vocabulary, the web development glossary can help non-technical teammates.

Different slugs per language

The slug is localized. The EN version can target an English SEO intent without mirroring French. The front resolves the path with the active locale, and the sitemap / hreflang point to each variant, with x-default toward FR.

An effective editorial workflow

The stack is not enough: you need a process. Here is a workflow that works well in production:

1. Write and validate in FR (Payload draft, fr locale only).
2. Translate on the same document to en (same ID), as a draft, without overwriting the source.
3. Adapt, do not calque: titles, meta, link anchors, EN SEO slugs.
4. Publish when both locales are ready (or ship FR then EN if the business requires it, thanks to fallback).

Media (thumbnail, block images) stay shared: translate alt when needed, do not duplicate the file. Internal links stay Payload relations (pages / posts / case studies), not hardcoded URLs: the front picks the right slug per locale.

If you migrate from multilingual WordPress, budget URL cleanup and slug mapping before cutover. Then industrialize production with a clear stack (VPS, Docker, HTTPS).

For self-hosted deployment, see our guide to deploying Payload CMS with Next.js.

What marketing gains (not only developers)

Effective multilingual is judged on the business side. Your marketing lead should be able to:

• open the FR record, switch to EN in the Payload admin, and complete it without touching code;
• adjust SEO title / description in each locale without a developer ticket;
• preview the locale URL (/en prefix or not) before publish;
• keep design and blocks (CTA, comparison, code) aligned across languages.

That is the autonomy Payload is meant for: a safe frame, clear fields, no jungle of translation plugins. Developers model once; marketing iterates after.

When to start multilingual (and when to wait)

Not every site needs two languages on day one. If 95% of traffic and leads are FR, prioritize an excellent monolingual foundation (performance, technical SEO, pillar content). Add EN when there is a clear business intent: export, partners, international hiring, or product pages already requested in English.

If you already know from the brief that the site will be bilingual, model localization from day one. Retrofitting localized fields later is possible, but more expensive (migrations, review, redirects). On beease.fr, FR + EN is part of the product: Payload config and Next.js routing were designed together.

Multilingual checklist before go-live

• Locales declared in Payload + fallback aligned with the pivot language.
• Editorial and SEO meta fields marked localized: true; shared structure outside locale.
• next-intl (or equivalent): prefix, no auto-detection if you want predictable URLs.
• Distinct FR / EN slugs when SEO intent differs.
• hreflang + x-default generated from per-locale paths.
• Dynamic sitemap including language variants.
• Language switcher pointing to the equivalent document, not always home.
• Human review of the target locale (tone, CTAs, meta lengths).

This checklist complements the basics of an SEO-optimized CMS: multilingual is one more layer on a crawlable foundation.

Take action on your multilingual site

A brochure website or SME redesign rarely benefits from improvising languages. What works: one Payload document per piece of content, explicit locales, a Next.js front that routes cleanly, and an FR → EN workflow owned by marketing inside a safe frame.

Beease designs that foundation (content model, SEO, editorial autonomy). Explore our Payload CMS integration, or contact us to discuss your project.

Martin Lotz

CEO

Sales Engineer

Martin Lotz is CEO and Sales Engineer at Beease Digital. As a key member of the team, he bridges clients’ business needs with the agency’s technical solutions.

Schedule a demo with Martin