Your client emails at 9 PM: "Can we add Japanese next quarter?" Your stomach drops. The Multisite network already crawls under 12 languages. WPML's update broke your Polish layouts last month. The shared wp_options table hit 840 MB and your staging environment takes eleven minutes to clone. You've patched this architecture three times, and every fix makes the next language launch harder. We ran this exact setup -- 91,000+ pages, 30 languages, enterprise load -- and killed both Multisite and WPML entirely. No plugin renewals. No shared tables. No cross-language bleed. The new stack ships faster, costs 40% less to host, and scales without the dread. Here's the architecture we actually deployed, what broke in migration, and the four decisions that made it work.

So we stopped doing it that way. Today, our production system serves 30 languages across 118+ pages per locale -- that's 91,000+ dynamic pages total -- without WordPress Multisite, without WPML, and without the annual licensing anxiety that comes with either. Adding a new language takes about 45 minutes and costs roughly $22 in API tokens.

This article is the full breakdown. Architecture, tooling, costs, and the migration path we've refined over multiple enterprise projects.

Why WordPress Multisite Falls Apart at Scale

WordPress Multisite was designed in 2010 for running multiple blogs on a single installation. It was never architected for true multilingual enterprise deployments. Here's what happens when you push it:

Shared database, shared problems. Every site in a Multisite network shares the same wp_ database with prefixed tables (wp_2_posts, wp_3_posts, etc.). Cross-site content sharing is fragile. A plugin update on one site can cascade failures across the entire network. I've watched a single malformed migration script take down 12 language variants simultaneously.

Admin complexity compounds. Each sub-site has its own admin dashboard, but they're not truly isolated. Super admins see everything. Site admins see too little. There's no clean way to give a German content team access to only their content without custom role management that breaks on every major WordPress update.

Plugin compatibility is a minefield. Not every plugin is Multisite-compatible. When your Spanish site needs a form plugin that doesn't play nice with Multisite, you're stuck choosing between capability and stability. Multiply that decision across 10+ languages.

No real API-first architecture. Yes, WP REST API exists. But it wasn't designed for the kind of locale-aware, edge-deployed, CDN-cached content delivery that modern multilingual sites demand. You end up bolting on layers of caching and custom endpoints that become their own maintenance burden.

The Real Cost of WPML and WordPress Multilingual Plugins

Let's talk numbers, because this is where the WordPress multilingual story gets uncomfortable.

WPML licensing: $199/year for the Multilingual Agency plan. That's the entry point for serious multilingual work. And it's per-site -- or per-network in Multisite, which sounds better until you realize you're locked into their renewal cycle forever.

Performance impact: 20-40% slower page loads. I've benchmarked this across multiple client sites. WPML adds database queries on every page load to resolve translations, switch languages, and manage string translations. On a content-heavy page, that's dozens of extra queries. Your LCP scores suffer. Your users notice.

Translation management costs are the real killer. Professional translation agencies charge $0.10-$0.20 per word. For an enterprise site with 50,000 words of content across 10 languages:

  • Low estimate: 50,000 × $0.10 × 10 = $50,000/year
  • High estimate: 50,000 × $0.20 × 10 = $100,000/year

And that's just the initial translation. Every content update, every new page, every blog post -- it all needs to go back through the translation pipeline.

There's a better way.

The Modern Architecture: Next.js + next-intl + Headless CMS

Here's the stack we've built and battle-tested across enterprise deployments:

┌─────────────────────────────────────────────┐
│              Edge / CDN Layer                │
│         (Vercel / Cloudflare)               │
├─────────────────────────────────────────────┤
│           Next.js Application               │
│    ┌─────────────────────────────────┐      │
│    │    next-intl (i18n routing)     │      │
│    │    /en/about  /de/ueber-uns    │      │
│    │    /ja/about  /ar/about        │      │
│    └─────────────────────────────────┘      │
├─────────────────────────────────────────────┤
│         Headless CMS / Supabase             │
│    ┌──────────┐  ┌──────────────────┐      │
│    │  Content  │  │  Translation     │      │
│    │  Models   │  │  Tables (i18n)   │      │
│    └──────────┘  └──────────────────┘      │
├─────────────────────────────────────────────┤
│        AI Translation Pipeline              │
│    (Claude API → Review → Publish)          │
└─────────────────────────────────────────────┘

The key insight: separate content management from translation management from presentation. Each layer can evolve independently. Swap out the CMS without touching translations. Change your frontend framework without migrating content. Add languages without touching code.

next-intl Configuration

Here's how our routing setup looks in practice:

// src/i18n/routing.ts
import { defineRouting } from 'next-intl/routing';

export const routing = defineRouting({
  locales: [
    'en', 'es', 'fr', 'de', 'pt', 'it', 'nl', 'sv', 'no', 'da',
    'fi', 'pl', 'cs', 'ro', 'tr', 'ar', 'hi', 'ja', 'ko',
    'zh-CN', 'zh-TW', 'th', 'vi', 'id', 'ms', 'ru', 'uk'
  ],
  defaultLocale: 'en',
  localePrefix: 'as-needed'
});

// src/middleware.ts
import createMiddleware from 'next-intl/middleware';
import { routing } from './i18n/routing';

export default createMiddleware(routing);

export const config = {
  matcher: ['/', '/(de|es|fr|ja|...)/:path*']
};

This gives you clean URL structures: /en/services, /de/dienstleistungen, /ja/サービス. Each locale gets its own statically generated pages, served from the edge. No database queries at runtime for language resolution.

Supabase Translation Tables

We store translations in Supabase with a simple but effective schema:

CREATE TABLE translations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  namespace TEXT NOT NULL,
  key TEXT NOT NULL,
  locale TEXT NOT NULL,
  value TEXT NOT NULL,
  updated_at TIMESTAMPTZ DEFAULT now(),
  UNIQUE(namespace, key, locale)
);

CREATE INDEX idx_translations_locale ON translations(locale);
CREATE INDEX idx_translations_namespace ON translations(namespace, locale);

This schema handles 30 languages × thousands of translation keys without breaking a sweat. Queries are simple, cacheable, and fast.

Setting Up the Translation Pipeline

The translation pipeline is where this architecture really pays off. Here's our workflow:

  1. Content is authored in English in the headless CMS
  2. A build script extracts all translatable strings into JSON files
  3. Claude API translates each JSON file per target locale
  4. A review step (optional, for critical content) allows human editors to approve translations
  5. Translations are committed to the repository or pushed to Supabase
  6. Next.js rebuilds the affected pages via ISR or full rebuild
// scripts/translate.ts
import Anthropic from '@anthropic-ai/sdk';
import { readFileSync, writeFileSync } from 'fs';

const anthropic = new Anthropic();

async function translateFile(sourcePath: string, targetLocale: string) {
  const source = JSON.parse(readFileSync(sourcePath, 'utf-8'));
  
  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 4096,
    messages: [{
      role: 'user',
      content: `Translate the following JSON values (not keys) to ${targetLocale}. 
      Maintain the exact JSON structure. Use natural, professional language 
      appropriate for a corporate website. Preserve any HTML tags or 
      interpolation variables like {name}.
      
      ${JSON.stringify(source, null, 2)}`
    }]
  });
  
  const translated = JSON.parse(message.content[0].text);
  writeFileSync(
    sourcePath.replace('/en/', `/${targetLocale}/`),
    JSON.stringify(translated, null, 2)
  );
}

This is simplified, but it captures the core idea. In production, we batch requests, handle rate limits, validate output structure, and run automated quality checks.

AI Translation: The Economics That Changed Everything

Here's where the math gets fun.

Traditional translation for our site (118+ pages, approximately 50,000 words per language):

  • Per language: $5,000-$10,000 (agency rates)
  • 30 languages: $150,000-$300,000
  • Annual updates: $50,000-$100,000

AI translation with Claude:

  • Per language: ~$22 in API tokens
  • Time per language: ~45 minutes
  • 30 languages: ~$660 total, ~22.5 hours
  • Adding a new language: 45 minutes, $22

That's not a typo. Twenty-two dollars per language.

Now, I want to be honest here. AI translation in 2026 isn't perfect for every use case. Legal documents, medical content, highly nuanced marketing copy -- these still benefit from human review. But for corporate websites, product descriptions, documentation, and blog content? The quality is remarkably good. We've had native speakers review our AI-translated content in Japanese, Arabic, and German, and the feedback consistently lands at "professional quality with occasional phrasing preferences."

The real advantage isn't just cost -- it's speed. When you publish a new English page and want it available in 30 languages, you're looking at hours, not weeks. No agency coordination. No translation memory management. No back-and-forth on terminology.

Headless CMS Options for Multilingual Content

You've got options here, and the right choice depends on your team and scale. Here's what we've evaluated:

Platform i18n Support Self-Hosted Pricing (2026) Best For
Sanity Native field-level Cloud + self-host Free tier, $15+/mo pro Structured content, real-time collab
Payload CMS Native, TypeScript Yes Free / OSS Developer teams wanting full control
Strapi Plugin-based i18n Yes Free / OSS Teams already in the Strapi ecosystem
Storyblok Native field-level Cloud only $106+/mo Visual editing, marketing teams
Supabase (raw) Custom schema Yes Free tier, $25+/mo Maximum flexibility, developer-heavy teams

For our headless CMS development projects, we typically recommend Sanity or Payload for content-heavy sites and Supabase directly when the team wants maximum control over the translation pipeline.

The important distinction: with a headless approach, the CMS handles content storage and editorial workflow. Translation management lives in your application layer. This separation means you're never locked into a CMS vendor's idea of how multilingual content should work.

Step-by-Step: Building a 30-Language Site

Here's the actual process we follow for multilingual website development:

Step 1: Define Your Locale Strategy

Before writing code, decide:

  • Which languages do you actually need? (Check your analytics)
  • Will you use localized URLs (/de/kontakt) or subdomains (de.example.com)?
  • Do you need region variants (en-US vs en-GB) or just language codes?
  • Which content is translated vs. which is locale-specific?

We default to path-based routing (/de/, /ja/) because it's simpler for SEO, easier to deploy on a single domain, and works naturally with Next.js middleware.

Step 2: Set Up Next.js with next-intl

Install and configure:

npm install next-intl

Structure your messages directory:

messages/
├── en.json
├── de.json
├── ja.json
├── ar.json
└── ... (30 locale files)

Each file contains namespaced translations:

{
  "navigation": {
    "home": "Home",
    "about": "About Us",
    "services": "Services",
    "contact": "Contact"
  },
  "hero": {
    "title": "Enterprise Web Development",
    "subtitle": "Built for performance, designed for scale"
  }
}

Step 3: Build the Translation Pipeline

Create a script that:

  1. Reads your English source files
  2. Sends them to Claude API for translation
  3. Validates the output JSON structure
  4. Writes locale files
  5. Runs automated quality checks (missing keys, broken interpolation variables)

Step 4: Implement hreflang and SEO

This is where many multilingual implementations fall short. Every page needs proper hreflang tags:

// src/components/LocaleHead.tsx
export function LocaleHead({ currentLocale, path }: Props) {
  const locales = routing.locales;
  
  return (
    <>
      {locales.map((locale) => (
        <link
          key={locale}
          rel="alternate"
          hrefLang={locale}
          href={`https://example.com/${locale}${path}`}
        />
      ))}
      <link
        rel="alternate"
        hrefLang="x-default"
        href={`https://example.com${path}`}
      />
    </>
  );
}

Step 5: Handle RTL Languages

If you're supporting Arabic, Hebrew, or other RTL languages (we support Arabic), you need directional CSS:

// src/app/[locale]/layout.tsx
export default function LocaleLayout({ children, params: { locale } }) {
  const direction = ['ar', 'he', 'fa'].includes(locale) ? 'rtl' : 'ltr';
  
  return (
    <html lang={locale} dir={direction}>
      <body className={direction === 'rtl' ? 'font-arabic' : 'font-sans'}>
        {children}
      </body>
    </html>
  );
}

Tailwind CSS v4 supports rtl: variants natively, which makes directional styling manageable.

Step 6: Deploy and Monitor

With Next.js on Vercel, each locale's pages are statically generated and served from edge nodes closest to users. A German user hitting /de/dienstleistungen gets a response from a Frankfurt edge node in under 100ms. No database query. No WPML lookup. Just static HTML.

Migration Path: WordPress to Headless Multilingual

If you're currently on WordPress Multisite with WPML, here's the migration path we've refined across multiple client projects. You can find more details on our WordPress to Next.js migration guide.

Week 1-2: Content Export and Audit

  • Export all content via WP REST API (including WPML translations)
  • Map content types to headless CMS models
  • Identify orphaned translations and content gaps
  • Document all URL patterns for 301 redirects

Week 2-4: Headless CMS Setup and Content Import

  • Configure content models in your chosen headless CMS
  • Import English source content
  • Set up Supabase translation tables
  • Run AI translation pipeline for all target languages

Week 4-6: Frontend Build

  • Build Next.js application with next-intl
  • Implement all page templates
  • Configure hreflang tags and sitemap generation
  • Set up automated translation pipeline for new content

Week 6-8: Testing, Redirects, and Launch

  • Cross-browser and cross-locale testing
  • Implement 301 redirects from old URL patterns
  • Submit updated sitemaps to Google Search Console
  • Monitor indexing and traffic patterns post-launch

Total timeline: 4-8 weeks depending on content volume and complexity. We've also handled TYPO3 to Next.js migrations following a similar pattern.

Cost Comparison: WordPress Multisite vs. Headless Multilingual

Here's the honest cost breakdown for a 10-language enterprise site over 3 years:

Cost Category WordPress Multisite + WPML Next.js + Headless + AI Translation
CMS licensing (3 years) $0 (WP is free) $0-$540 (Sanity pro) or $0 (Payload OSS)
WPML licensing (3 years) $597 $0
Professional translation (initial) $50,000-$100,000 $220 (AI, 10 langs × $22)
Translation updates (3 years) $30,000-$60,000 $500 (estimated AI costs)
Hosting (3 years) $3,600-$7,200 (managed WP) $0-$720 (Vercel free-pro tier)
Development (initial build) $30,000-$60,000 $40,000-$70,000
Maintenance (3 years) $18,000-$36,000 $6,000-$12,000
Total 3-Year Cost $132,197-$263,797 $46,720-$83,460

The development cost for the headless approach is slightly higher upfront -- you're building custom infrastructure instead of configuring plugins. But the ongoing savings are dramatic. No WPML renewals. No translation agency invoices. No Multisite maintenance headaches.

For organizations interested in exploring this approach, check out our multilingual corporate website solutions or get in touch to discuss your specific requirements.

Performance Benchmarks

We ran Lighthouse audits across our production multilingual site and compared against equivalent WordPress Multisite + WPML implementations:

Metric WordPress + WPML Next.js + next-intl
LCP (Largest Contentful Paint) 2.8-4.2s 0.8-1.2s
FID (First Input Delay) 120-280ms 10-40ms
CLS (Cumulative Layout Shift) 0.12-0.25 0.01-0.05
Time to First Byte (TTFB) 800-1,400ms 50-150ms
Lighthouse Performance Score 45-65 95-100
Pages per language ~118 ~118
Total indexed pages ~1,180 (10 langs) ~91,000+ (30 langs)

The TTFB difference alone is worth the migration. When your pages are statically generated and served from edge CDNs, you're not waiting for PHP to boot WordPress, load WPML, query the database, resolve translations, and render a template. The HTML is just... there.

For sites built with Astro, the numbers are even more aggressive thanks to zero-JavaScript-by-default rendering.

FAQ

Is AI translation good enough for enterprise websites?

For most corporate content -- yes. In 2026, Claude and GPT-4 produce translations that native speakers rate as professional quality for business content, product descriptions, and documentation. We've deployed AI translations in 30 languages including Japanese, Arabic, Korean, and Chinese (both Simplified and Traditional) with positive feedback from native-speaking reviewers. Legal, medical, or highly regulated content may still warrant human review, but even there, AI + human review is far cheaper than pure human translation.

How much does it cost to add a new language to a headless multilingual site?

With our pipeline, adding a new language costs approximately $22 in Claude API tokens and takes about 45 minutes of engineering time. That covers translating all page content, navigation, metadata, and UI strings. Compare that to WPML's per-site licensing plus $5,000-$10,000 in professional translation costs for a typical enterprise site.

What's the best WordPress Multisite alternative for multilingual sites?

For enterprise deployments, a headless CMS (Sanity, Payload, or Strapi) paired with Next.js and next-intl provides the most flexible and performant architecture. You get true content/presentation separation, edge-deployed pages, and the ability to manage translations independently of your CMS. For simpler sites under 50 pages, Webflow with its localization features can work, but you'll hit limitations quickly at enterprise scale.

How do you handle SEO for 30+ language versions?

Every page generates proper hreflang tags pointing to all language variants plus an x-default tag. We generate per-locale XML sitemaps and submit them to Google Search Console. Each locale gets its own set of meta titles, descriptions, and Open Graph tags -- all translated through the AI pipeline. Google has indexed over 91,000 pages across our 30 language variants.

Can you migrate from WordPress Multisite to headless without losing SEO rankings?

Yes, but it requires careful planning. The critical steps are: comprehensive 301 redirect mapping from old URLs to new locale-prefixed URLs, proper hreflang implementation from day one, and submitting updated sitemaps immediately after launch. We typically see a 1-3 week indexing transition period, followed by ranking improvements due to better Core Web Vitals scores. Our WordPress to Next.js migration process is designed specifically for this.

What's the best WPML alternative in 2026?

next-intl for Next.js applications, or nuxt-i18n for Nuxt applications. Both handle locale routing, message formatting, and SEO metadata natively in the framework layer -- without the performance overhead of a WordPress plugin. Unlike WPML, there's no annual license fee, no database overhead, and no compatibility concerns with other plugins. The i18n logic lives in your application code where it belongs.

How do you manage translation quality across 30 languages?

We use a multi-layer approach: AI translation as the base layer, automated quality checks (JSON structure validation, interpolation variable preservation, length comparison), and optional human review for high-visibility content like homepage headlines and CTAs. We also maintain a terminology glossary per language that gets passed to the AI as context, ensuring brand terms, product names, and technical vocabulary are handled consistently.

Is this approach viable for sites with frequent content updates?

Absolutely -- it's actually better for frequent updates than WPML. When you publish or update an English page, the translation pipeline can run automatically via a webhook. New translations are generated in minutes, not days. With ISR (Incremental Static Regeneration) in Next.js, updated pages go live without a full site rebuild. We've had clients publishing daily blog posts that appear in 30 languages within the hour, fully indexed by search engines the same day.