Seu cliente envia email às 21h: "Podemos adicionar japonês no próximo trimestre?" Seu estômago cai. A rede Multisite já rasteja com 12 idiomas. A atualização do WPML quebrou seus layouts poloneses mês passado. A tabela compartilhada wp_options atingiu 840 MB e seu ambiente de staging leva onze minutos para ser clonado. Você corrigiu essa arquitetura três vezes, e cada correção torna o próximo lançamento de idioma mais difícil. Nós rodávamos essa mesma configuração — 91.000+ páginas, 30 idiomas, carga corporativa — e eliminamos completamente o Multisite e WPML. Sem renovações de plugin. Sem tabelas compartilhadas. Sem vazamento entre idiomas. O novo stack entrega mais rápido, custa 40% menos para hospedar, e escala sem a angústia. Aqui está a arquitetura que realmente implantamos, o que quebrou na migração, e as quatro decisões que a tornaram funcionar.

Então paramos de fazer dessa forma. Hoje, nosso sistema de produção serve 30 idiomas em mais de 118+ páginas por locale — isso são mais de 91.000+ páginas dinâmicas no total — sem WordPress Multisite, sem WPML, e sem a ansiedade de licenciamento anual que vem com qualquer um deles. Adicionar um novo idioma leva cerca de 45 minutos e custa aproximadamente $22 em tokens de API.

Este artigo é o breakdown completo. Arquitetura, ferramentas, custos, e o caminho de migração que refinamos em múltiplos projetos corporativos.

Índice

Por que WordPress Multisite Desmorona em Escala

WordPress Multisite foi projetado em 2010 para rodar múltiplos blogs em uma única instalação. Nunca foi arquitetado para verdadeiras implantações corporativas multilíngues. Aqui está o que acontece quando você o pressiona:

Banco de dados compartilhado, problemas compartilhados. Cada site em uma rede Multisite compartilha o mesmo banco de dados wp_ com tabelas prefixadas (wp_2_posts, wp_3_posts, etc.). O compartilhamento de conteúdo entre sites é frágil. Uma atualização de plugin em um site pode causar falhas em cascata por toda a rede. Já vi um único script de migração malformado derrubando 12 variantes de idioma simultaneamente.

Complexidade de admin se compõe. Cada sub-site tem seu próprio dashboard admin, mas não são verdadeiramente isolados. Super admins veem tudo. Admins de site veem muito pouco. Não há forma limpa de dar a um time de conteúdo alemão acesso apenas ao seu conteúdo sem gerenciamento de papéis customizado que quebra em cada atualização maior do WordPress.

Compatibilidade de plugin é um campo minado. Nem todo plugin é compatível com Multisite. Quando seu site espanhol precisa de um plugin de formulário que não funciona bem com Multisite, você fica preso escolhendo entre capacidade e estabilidade. Multiplique essa decisão por 10+ idiomas.

Sem arquitetura API-first real. Sim, WP REST API existe. Mas não foi projetada para o tipo de entrega de conteúdo ciente de locale, implantada em edge, cacheada em CDN que sites multilíngues modernos demandam. Você acaba parafusando camadas de caching e endpoints customizados que se tornam seu próprio fardo de manutenção.

O Custo Real do WPML e Plugins WordPress Multilíngues

Vamos falar de números, porque aqui é onde a história multilíngue do WordPress fica incômoda.

Licenciamento WPML: $199/ano pelo plano Multilingual Agency. Esse é o ponto de entrada para trabalho multilíngue sério. E é por site — ou por rede em Multisite, o que parece melhor até você perceber que está preso ao seu ciclo de renovação para sempre.

Impacto de desempenho: 20-40% carregamentos de página mais lentos. Benchmarquei isso em múltiplos sites de clientes. WPML adiciona queries de banco de dados em cada carregamento de página para resolver traduções, alternar idiomas, e gerenciar traduções de string. Em uma página pesada de conteúdo, isso são dezenas de queries extras. Seus scores de LCP sofrem. Seus usuários percebem.

Os custos de gerenciamento de tradução são o verdadeiro assassino. Agências de tradução profissional cobram $0,10-$0,20 por palavra. Para um site corporativo com 50.000 palavras de conteúdo em 10 idiomas:

  • Estimativa baixa: 50.000 × $0,10 × 10 = $50.000/ano
  • Estimativa alta: 50.000 × $0,20 × 10 = $100.000/ano

E isso é apenas a tradução inicial. Cada atualização de conteúdo, cada página nova, cada post de blog — tudo precisa voltar pelo pipeline de tradução.

Há um caminho melhor.

A Arquitetura Moderna: Next.js + next-intl + Headless CMS

Aqui está o stack que construímos e testamos em batalha em implantações corporativas:

┌─────────────────────────────────────────────┐
│              Camada Edge / CDN                │
│         (Vercel / Cloudflare)               │
├─────────────────────────────────────────────┤
│           Aplicação Next.js                 │
│    ┌─────────────────────────────────┐      │
│    │    next-intl (roteamento i18n)  │      │
│    │    /en/about  /de/ueber-uns    │      │
│    │    /ja/about  /ar/about        │      │
│    └─────────────────────────────────┘      │
├─────────────────────────────────────────────┤
│         Headless CMS / Supabase             │
│    ┌──────────┐  ┌──────────────────┐      │
│    │  Conteúdo │  │  Tabelas de      │      │
│    │  Modelos  │  │  Tradução (i18n) │      │
│    └──────────┘  └──────────────────┘      │
├─────────────────────────────────────────────┤
│        Pipeline de Tradução por IA          │
│    (Claude API → Revisão → Publicação)      │
└─────────────────────────────────────────────┘

A percepção chave: separar gerenciamento de conteúdo do gerenciamento de tradução da apresentação. Cada camada pode evoluir independentemente. Troque o CMS sem tocar em traduções. Mude seu framework frontend sem migrar conteúdo. Adicione idiomas sem tocar em código.

Configuração next-intl

Aqui está como nossa configuração de roteamento se parece na prática:

// 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*']
};

Isso lhe oferece estruturas de URL limpas: /en/services, /de/dienstleistungen, /ja/サービス. Cada locale obtém suas próprias páginas geradas estaticamente, servidas do edge. Sem queries de banco de dados em tempo de execução para resolução de idioma.

Tabelas de Tradução Supabase

Armazenamos traduções em Supabase com um schema simples mas efetivo:

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);

Este schema lida com 30 idiomas × milhares de chaves de tradução sem nem piscar. Queries são simples, cacheáveis, e rápidas.

Configurando o Pipeline de Tradução

O pipeline de tradução é onde essa arquitetura realmente brilha. Aqui está nosso workflow:

  1. Conteúdo é criado em inglês no headless CMS
  2. Um script de build extrai todas as strings traduzíveis em arquivos JSON
  3. Claude API traduz cada arquivo JSON por locale de destino
  4. Uma etapa de revisão (opcional, para conteúdo crítico) permite que editores humanos aprovem traduções
  5. Traduções são commitadas ao repositório ou empurradas para Supabase
  6. Next.js reconstrói as páginas afetadas via ISR ou rebuild completo
// 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)
  );
}

Isso é simplificado, mas captura a ideia central. Em produção, fazemos batching de requisições, lidamos com limites de taxa, validamos estrutura de saída, e executamos verificações de qualidade automatizadas.

Tradução por IA: A Economia que Mudou Tudo

Aqui é onde a matemática fica divertida.

Tradução tradicional para nosso site (118+ páginas, aproximadamente 50.000 palavras por idioma):

  • Por idioma: $5.000-$10.000 (taxas de agência)
  • 30 idiomas: $150.000-$300.000
  • Atualizações anuais: $50.000-$100.000

Tradução por IA com Claude:

  • Por idioma: ~$22 em tokens de API
  • Tempo por idioma: ~45 minutos
  • 30 idiomas: ~$660 total, ~22,5 horas
  • Adicionar um novo idioma: 45 minutos, $22

Isso não é digitação errada. Vinte e dois dólares por idioma.

Agora, quero ser honesto aqui. Tradução por IA em 2026 não é perfeita para todo caso de uso. Documentos legais, conteúdo médico, copy de marketing altamente nuançado — esses ainda se beneficiam de revisão humana. Mas para sites corporativos, descrições de produtos, documentação, e conteúdo de blog? A qualidade é notavelmente boa. Temos tido falantes nativos revisando nosso conteúdo traduzido por IA em japonês, árabe e alemão, e o feedback consistentemente se situa em "qualidade profissional com preferências ocasionais de fraseado."

A vantagem real não é apenas custo — é velocidade. Quando você publica uma nova página em inglês e quer que esteja disponível em 30 idiomas, você está olhando para horas, não semanas. Sem coordenação de agência. Sem gerenciamento de memória de tradução. Sem vai e volta sobre terminologia.

Opções de Headless CMS para Conteúdo Multilíngue

Você tem opções aqui, e a escolha certa depende de seu time e escala. Aqui está o que avaliamos:

Plataforma Suporte i18n Auto-Hospedado Precificação (2026) Melhor para
Sanity Nativo em nível de campo Cloud + auto-hospedado Tier gratuito, $15+/mês pro Conteúdo estruturado, colaboração em tempo real
Payload CMS Nativo, TypeScript Sim Gratuito / OSS Times de desenvolvedores querendo controle total
Strapi i18n baseado em plugin Sim Gratuito / OSS Times já no ecossistema Strapi
Storyblok Nativo em nível de campo Apenas Cloud $106+/mês Edição visual, times de marketing
Supabase (bruto) Schema customizado Sim Tier gratuito, $25+/mês Máxima flexibilidade, times de desenvolvedores

Para nossos projetos de desenvolvimento de headless CMS, típicamente recomendamos Sanity ou Payload para sites com muito conteúdo e Supabase direto quando o time quer controle máximo sobre o pipeline de tradução.

A distinção importante: com uma abordagem headless, o CMS lida com armazenamento de conteúdo e workflow editorial. O gerenciamento de tradução vive na camada de sua aplicação. Essa separação significa que você nunca está preso à ideia do fornecedor de CMS sobre como conteúdo multilíngue deve funcionar.

Passo a Passo: Construindo um Site de 30 Idiomas

Aqui está o processo real que seguimos para desenvolvimento de website multilíngue:

Passo 1: Defina Sua Estratégia de Locale

Antes de escrever código, decida:

  • Quais idiomas você realmente precisa? (Verifique sua analytics)
  • Você usará URLs localizadas (/de/kontakt) ou subdomínios (de.example.com)?
  • Você precisará de variantes de região (en-US vs en-GB) ou apenas códigos de idioma?
  • Qual conteúdo é traduzido vs. qual é locale-específico?

Nosso padrão é roteamento baseado em caminho (/de/, /ja/) porque é mais simples para SEO, mais fácil de implantar em um único domínio, e funciona naturalmente com middleware Next.js.

Passo 2: Configure Next.js com next-intl

Instale e configure:

npm install next-intl

Estruture seu diretório de mensagens:

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

Cada arquivo contém traduções com namespace:

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

Passo 3: Construa o Pipeline de Tradução

Crie um script que:

  1. Leia seus arquivos de origem em inglês
  2. Envie para Claude API para tradução
  3. Valide a estrutura JSON de saída
  4. Escreva arquivos de locale
  5. Execute verificações de qualidade automatizadas (chaves faltantes, variáveis de interpolação quebradas)

Passo 4: Implemente hreflang e SEO

Aqui é onde muitas implementações multilíngues falham. Cada página precisa de tags hreflang apropriadas:

// 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}`}
      />
    </>
  );
}

Passo 5: Lide com Idiomas RTL

Se você está suportando árabe, hebraico, ou outros idiomas RTL (suportamos árabe), você precisa de CSS direcional:

// 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 suporta variantes rtl: nativamente, o que torna estilo direcional gerenciável.

Passo 6: Implante e Monitore

Com Next.js no Vercel, as páginas de cada locale são geradas estaticamente e servidas de nós edge mais próximos dos usuários. Um usuário alemão acessando /de/dienstleistungen obtém uma resposta de um nó edge em Frankfurt em menos de 100ms. Sem query de banco de dados. Sem busca de WPML. Apenas HTML estático.

Caminho de Migração: WordPress para Headless Multilíngue

Se você está atualmente no WordPress Multisite com WPML, aqui está o caminho de migração que refinamos em múltiplos projetos de clientes. Você pode encontrar mais detalhes em nosso guia de migração WordPress para Next.js.

Semanas 1-2: Exportação de Conteúdo e Auditoria

  • Exporte todo conteúdo via WP REST API (incluindo traduções WPML)
  • Mapeie tipos de conteúdo para modelos de headless CMS
  • Identifique traduções órfãs e lacunas de conteúdo
  • Documente todos os padrões de URL para redirects 301

Semanas 2-4: Configuração de Headless CMS e Importação de Conteúdo

  • Configure modelos de conteúdo em seu headless CMS escolhido
  • Importe conteúdo de origem em inglês
  • Configure tabelas de tradução Supabase
  • Execute pipeline de tradução por IA para todos os idiomas de destino

Semanas 4-6: Construção de Frontend

  • Construa aplicação Next.js com next-intl
  • Implemente todos os templates de página
  • Configure tags hreflang e geração de sitemap
  • Configure pipeline de tradução automatizado para novo conteúdo

Semanas 6-8: Testes, Redirects, e Lançamento

  • Testes entre navegadores e entre locales
  • Implemente redirects 301 de padrões de URL antigos
  • Envie sitemaps atualizados para Google Search Console
  • Monitore padrões de indexação e tráfego pós-lançamento

Tempo total: 4-8 semanas dependendo do volume de conteúdo e complexidade. Também tratamos migrações TYPO3 para Next.js seguindo um padrão similar.

Comparação de Custos: WordPress Multisite vs. Headless Multilíngue

Aqui está o breakdown de custo honesto para um site corporativo de 10 idiomas ao longo de 3 anos:

Categoria de Custo WordPress Multisite + WPML Next.js + Headless + Tradução por IA
Licenciamento de CMS (3 anos) $0 (WP é gratuito) $0-$540 (Sanity pro) ou $0 (Payload OSS)
Licenciamento WPML (3 anos) $597 $0
Tradução profissional (inicial) $50.000-$100.000 $220 (IA, 10 langs × $22)
Atualizações de tradução (3 anos) $30.000-$60.000 $500 (custos de IA estimados)
Hospedagem (3 anos) $3.600-$7.200 (WP gerenciado) $0-$720 (Vercel tier gratuito-pro)
Desenvolvimento (build inicial) $30.000-$60.000 $40.000-$70.000
Manutenção (3 anos) $18.000-$36.000 $6.000-$12.000
Custo Total de 3 Anos $132.197-$263.797 $46.720-$83.460

O custo de desenvolvimento para a abordagem headless é ligeiramente maior antecipadamente — você está construindo infraestrutura customizada ao invés de configurar plugins. Mas as economias contínuas são dramáticas. Sem renovações de WPML. Sem faturas de agência de tradução. Sem dores de cabeça de manutenção de Multisite.

Para organizações interessadas em explorar essa abordagem, verifique nossas soluções de website corporativo multilíngue ou entre em contato para discutir seus requisitos específicos.

Benchmarks de Desempenho

Executamos auditorias Lighthouse em nosso site multilíngue de produção e comparamos contra implementações equivalentes de WordPress Multisite + WPML:

Métrica 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
Tempo até Primeiro Byte (TTFB) 800-1.400ms 50-150ms
Score Lighthouse Performance 45-65 95-100
Páginas por idioma ~118 ~118
Total de páginas indexadas ~1.180 (10 idiomas) ~91.000+ (30 idiomas)

A diferença de TTFB sozinha vale a migração. Quando suas páginas são geradas estaticamente e servidas de CDNs edge, você não está esperando por PHP iniciar WordPress, carregar WPML, consultar o banco de dados, resolver traduções, e renderizar um template. O HTML está simplesmente... lá.

Para sites construídos com Astro, os números são ainda mais agressivos graças à renderização zero-JavaScript-por-padrão.

FAQ

Tradução por IA é boa o suficiente para websites corporativos?

Para a maioria do conteúdo corporativo — sim. Em 2026, Claude e GPT-4 produzem traduções que falantes nativos avaliam como qualidade profissional para conteúdo comercial, descrições de produtos, e documentação. Implantamos traduções por IA em 30 idiomas incluindo japonês, árabe, coreano, e chinês (tanto simplificado quanto tradicional) com feedback positivo de revisores falantes nativos. Conteúdo legal, médico, ou altamente regulado ainda pode garantir revisão humana, mas mesmo aí, IA + revisão humana é muito mais barato que tradução puramente humana.

Quanto custa adicionar um novo idioma a um site multilíngue headless?

Com nosso pipeline, adicionar um novo idioma custa aproximadamente $22 em tokens de API do Claude e leva cerca de 45 minutos de tempo de engenharia. Isso cobre a tradução de todo conteúdo de página, navegação, metadados, e strings de UI. Compare com o licenciamento por site do WPML mais $5.000-$10.000 em custos de tradução profissional para um site corporativo típico.

Qual é a melhor alternativa WordPress Multisite para sites multilíngues?

Para implantações corporativas, um headless CMS (Sanity, Payload, ou Strapi) pareado com Next.js e next-intl fornece a arquitetura mais flexível e performática. Você obtém verdadeira separação de conteúdo/apresentação, páginas implantadas em edge, e a capacidade de gerenciar traduções independentemente de seu CMS. Para sites mais simples com menos de 50 páginas, Webflow com seus recursos de localização pode funcionar, mas você atingirá limitações rapidamente em escala corporativa.

Como você lida com SEO para 30+ versões de idioma?

Cada página gera tags hreflang apropriadas apontando para todas as variantes de idioma mais uma tag x-default. Geramos sitemaps XML por locale e os submetemos ao Google Search Console. Cada locale obtém seu próprio conjunto de títulos meta, descrições, e tags Open Graph — tudo traduzido através do pipeline de IA. Google indexou mais de 91.000 páginas em nossos 30 variantes de idioma.

Você pode migrar do WordPress Multisite para headless sem perder rankings de SEO?

Sim, mas requer planejamento cuidadoso. Os passos críticos são: mapeamento abrangente de redirect 301 de URLs antigas para novas URLs com prefixo de locale, implementação apropriada de hreflang desde o início, e envio de sitemaps atualizados imediatamente após o lançamento. Tipicamente vemos um período de transição de indexação de 1-3 semanas, seguido por melhorias de ranking devido a scores melhores de Core Web Vitals. Nosso processo de migração WordPress para Next.js foi projetado especificamente para isso.

Qual é a melhor alternativa WPML em 2026?

next-intl para aplicações Next.js, ou nuxt-i18n para aplicações Nuxt. Ambas lidam com roteamento de locale, formatação de mensagem, e metadados SEO nativamente na camada de framework — sem a sobrecarga de desempenho de um plugin WordPress. Diferentemente de WPML, não há taxa de licença anual, sem sobrecarga de banco de dados, e sem preocupações de compatibilidade com outros plugins. A lógica i18n vive no código de sua aplicação onde pertence.

Como você gerencia qualidade de tradução em 30 idiomas?

Usamos uma abordagem de multi-camada: tradução por IA como camada base, verificações de qualidade automatizadas (validação de estrutura JSON, preservação de variáveis de interpolação, comparação de comprimento), e revisão humana opcional para conteúdo de alta visibilidade como títulos de homepage e CTAs. Também mantemos um glossário de terminologia por idioma que é passado para a IA como contexto, garantindo que termos de marca, nomes de produto, e vocabulário técnico sejam tratados consistentemente.

Essa abordagem é viável para sites com atualizações de conteúdo frequentes?

Absolutamente — é na verdade melhor para atualizações frequentes do que WPML. Quando você publica ou atualiza uma página em inglês, o pipeline de tradução pode rodar automaticamente via webhook. Novas traduções são geradas em minutos, não dias. Com ISR (Incremental Static Regeneration) em Next.js, páginas atualizadas vão ao ar sem um rebuild completo de site. Temos clientes publicando posts de blog diários que aparecem em 30 idiomas dentro da hora, totalmente indexados pelos mecanismos de busca no mesmo dia.