Tu cliente envía un correo a las 21:00: "¿Podemos agregar japonés el próximo trimestre?" Se te cae el alma. La red de Multisite ya funciona con dificultad bajo 12 idiomas. La actualización de WPML rompió tus diseños en polaco el mes pasado. La tabla compartida wp_options alcanzó 840 MB y tu entorno de staging tarda once minutos en clonarse. Has parcheado esta arquitectura tres veces, y cada corrección hace más difícil el próximo lanzamiento de idioma. Ejecutamos exactamente esta configuración — 91,000+ páginas, 30 idiomas, carga empresarial — y eliminamos completamente tanto Multisite como WPML. Sin renovaciones de plugins. Sin tablas compartidas. Sin mezcla de idiomas. El nuevo stack se envía más rápido, cuesta 40% menos de alojamiento y escala sin la angustia. Aquí está la arquitectura que realmente desplegamos, qué se rompió en la migración y las cuatro decisiones que la hicieron funcionar.

Entonces dejamos de hacerlo de esa manera. Hoy, nuestro sistema de producción sirve 30 idiomas en 118+ páginas por locale — eso es 91,000+ páginas dinámicas en total — sin WordPress Multisite, sin WPML y sin la ansiedad de licencias anuales que conlleva cualquiera de ellos. Agregar un nuevo idioma toma aproximadamente 45 minutos y cuesta aproximadamente $22 en tokens de API.

Este artículo es el desglose completo. Arquitectura, herramientas, costos y la ruta de migración que hemos refinado en múltiples proyectos empresariales.

Tabla de contenidos

Por qué WordPress Multisite falla a escala

WordPress Multisite fue diseñado en 2010 para ejecutar múltiples blogs en una sola instalación. Nunca fue arquitectado para verdaderos despliegues empresariales multilingües. Aquí es lo que sucede cuando lo presionas:

Base de datos compartida, problemas compartidos. Cada sitio en una red Multisite comparte la misma base de datos wp_ con tablas prefijadas (wp_2_posts, wp_3_posts, etc.). El intercambio de contenido entre sitios es frágil. Una actualización de plugin en un sitio puede causar fallas en cascada en toda la red. He visto un único script de migración mal formado derrumbar 12 variantes de idiomas simultáneamente.

La complejidad del admin se compone. Cada subsitio tiene su propio panel de administración, pero no están verdaderamente aislados. Los superadmins ven todo. Los administradores de sitio ven demasiado poco. No hay una forma clara de dar acceso a un equipo de contenido alemán solo a su contenido sin una gestión de roles personalizada que se rompa con cada actualización importante de WordPress.

La compatibilidad de plugins es un campo minado. No todos los plugins son compatibles con Multisite. Cuando tu sitio en español necesita un plugin de formulario que no juega bien con Multisite, estás atrapado eligiendo entre capacidad y estabilidad. Multiplica esa decisión por 10+ idiomas.

No hay arquitectura realmente orientada a API. Sí, existe WP REST API. Pero no fue diseñada para el tipo de entrega de contenido consciente de locale, desplegada en el borde, en caché de CDN que los sitios multilingües modernos exigen. Terminas añadiendo capas de almacenamiento en caché y puntos finales personalizados que se convierten en su propia carga de mantenimiento.

El costo real de WPML y plugins multilingües de WordPress

Hablemos de números, porque aquí es donde la historia de WordPress multilingüe se vuelve incómoda.

Licencia WPML: $199/año para el plan Multilingual Agency. Ese es el punto de entrada para trabajos multilingües serios. Y es por sitio — o por red en Multisite, lo que suena mejor hasta que te das cuenta de que estás bloqueado en su ciclo de renovación para siempre.

Impacto de rendimiento: 20-40% más lento en cargas de página. He evaluado esto en múltiples sitios de clientes. WPML añade consultas de base de datos en cada carga de página para resolver traducciones, cambiar idiomas y gestionar traducciones de cadenas. En una página con contenido pesado, eso son docenas de consultas adicionales. Tus puntuaciones de LCP sufren. Tus usuarios lo notan.

Los costos de gestión de traducciones son el verdadero asesino. Las agencias de traducción profesionales cobran $0.10-$0.20 por palabra. Para un sitio empresarial con 50,000 palabras de contenido en 10 idiomas:

  • Estimación baja: 50,000 × $0.10 × 10 = $50,000/año
  • Estimación alta: 50,000 × $0.20 × 10 = $100,000/año

Y eso es solo la traducción inicial. Cada actualización de contenido, cada página nueva, cada publicación de blog — todo necesita pasar de nuevo por el pipeline de traducción.

Hay una forma mejor.

La arquitectura moderna: Next.js + next-intl + CMS sin interfaz

Aquí está el stack que hemos construido y probado en combate en despliegues empresariales:

┌─────────────────────────────────────────────┐
│         Capa de Edge / CDN                  │
│         (Vercel / Cloudflare)               │
├─────────────────────────────────────────────┤
│           Aplicación Next.js                │
│    ┌─────────────────────────────────┐      │
│    │    next-intl (enrutamiento i18n)│      │
│    │    /en/about  /de/ueber-uns    │      │
│    │    /ja/about  /ar/about        │      │
│    └─────────────────────────────────┘      │
├─────────────────────────────────────────────┤
│      CMS sin interfaz / Supabase            │
│    ┌──────────┐  ┌──────────────────┐      │
│    │ Contenido │  │    Tablas de     │      │
│    │  Modelos  │  │  Traducción (i18n)     │
│    └──────────┘  └──────────────────┘      │
├─────────────────────────────────────────────┤
│      Pipeline de traducción por IA          │
│    (Claude API → Revisión → Publicación)    │
└─────────────────────────────────────────────┘

La idea clave: separar la gestión de contenido de la gestión de traducciones de la presentación. Cada capa puede evolucionar independientemente. Cambia el CMS sin tocar las traducciones. Cambia tu framework de frontend sin migrar contenido. Agrega idiomas sin tocar código.

Configuración de next-intl

Aquí es cómo se ve nuestra configuración de enrutamiento en la práctica:

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

Esto te da estructuras de URL limpias: /en/services, /de/dienstleistungen, /ja/サービス. Cada locale obtiene sus propias páginas generadas estáticamente, servidas desde el edge. Sin consultas de base de datos en tiempo de ejecución para la resolución de idioma.

Tablas de traducción de Supabase

Almacenamos traducciones en Supabase con un esquema simple pero efectivo:

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 esquema maneja 30 idiomas × miles de claves de traducción sin romper un sudor. Las consultas son simples, almacenables en caché y rápidas.

Configuración del pipeline de traducción

El pipeline de traducción es donde esta arquitectura realmente brilla. Aquí está nuestro flujo de trabajo:

  1. El contenido se escribe en inglés en el CMS sin interfaz
  2. Un script de compilación extrae todas las cadenas traducibles en archivos JSON
  3. Claude API traduce cada archivo JSON por locale de destino
  4. Un paso de revisión (opcional, para contenido crítico) permite a editores humanos aprobar traducciones
  5. Las traducciones se comprometem al repositorio o se envían a Supabase
  6. Next.js reconstruye las páginas afectadas vía ISR o reconstrucción completa
// 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: `Traduce los siguientes valores JSON (no claves) a ${targetLocale}. 
      Mantén la estructura JSON exacta. Usa lenguaje natural y profesional 
      apropiado para un sitio web corporativo. Preserva cualquier etiqueta HTML o 
      variable de interpolación como {name}.
      
      ${JSON.stringify(source, null, 2)}`
    }]
  });
  
  const translated = JSON.parse(message.content[0].text);
  writeFileSync(
    sourcePath.replace('/en/', `/${targetLocale}/`),
    JSON.stringify(translated, null, 2)
  );
}

Esto es simplificado, pero captura la idea central. En producción, agrupamos solicitudes, manejamos límites de velocidad, validamos estructura de salida y ejecutamos verificaciones de calidad automatizadas.

Traducción por IA: la economía que lo cambió todo

Aquí es donde las matemáticas se ponen divertidas.

Traducción tradicional para nuestro sitio (118+ páginas, aproximadamente 50,000 palabras por idioma):

  • Por idioma: $5,000-$10,000 (tarifas de agencia)
  • 30 idiomas: $150,000-$300,000
  • Actualizaciones anuales: $50,000-$100,000

Traducción por IA con Claude:

  • Por idioma: ~$22 en tokens de API
  • Tiempo por idioma: ~45 minutos
  • 30 idiomas: ~$660 total, ~22.5 horas
  • Agregar un nuevo idioma: 45 minutos, $22

Eso no es un error tipográfico. Veintidós dólares por idioma.

Ahora, quiero ser honesto aquí. La traducción por IA en 2026 no es perfecta para cada caso de uso. Documentos legales, contenido médico, copias de marketing altamente matizadas — estos aún se benefician de la revisión humana. Pero para sitios corporativos, descripciones de productos, documentación y contenido de blog? La calidad es notablemente buena. Hemos tenido hablantes nativos revisar nuestro contenido traducido por IA en japonés, árabe y alemán, y la retroalimentación consistentemente cae en "calidad profesional con preferencias de redacción ocasionales".

La verdadera ventaja no es solo costo — es velocidad. Cuando publicas una nueva página en inglés y quieres que esté disponible en 30 idiomas, estás buscando horas, no semanas. Sin coordinación de agencia. Sin gestión de memoria de traducción. Sin ida y vuelta sobre terminología.

Opciones de CMS sin interfaz para contenido multilingüe

Tienes opciones aquí, y la opción correcta depende de tu equipo y escala. Aquí está lo que hemos evaluado:

Plataforma Soporte i18n Auto-alojable Precios (2026) Mejor para
Sanity Nativo a nivel de campo Nube + auto-alojable Nivel gratuito, $15+/mes pro Contenido estructurado, colaboración en tiempo real
Payload CMS Nativo, TypeScript Sí Gratuito / OSS Equipos desarrolladores que quieren control total
Strapi Plugin-based i18n Sí Gratuito / OSS Equipos ya en el ecosistema de Strapi
Storyblok Nativo a nivel de campo Solo nube $106+/mes Edición visual, equipos de marketing
Supabase (raw) Esquema personalizado Sí Nivel gratuito, $25+/mes Máxima flexibilidad, equipos orientados a desarrolladores

Para nuestros proyectos de desarrollo de CMS sin interfaz, típicamente recomendamos Sanity o Payload para sitios con mucho contenido y Supabase directamente cuando el equipo quiere máximo control sobre el pipeline de traducción.

La distinción importante: con un enfoque sin interfaz, el CMS maneja el almacenamiento de contenido y el flujo de trabajo editorial. La gestión de traducciones vive en la capa de tu aplicación. Esta separación significa que nunca estás bloqueado en la idea de un vendedor de CMS sobre cómo debería funcionar el contenido multilingüe.

Paso a paso: construyendo un sitio de 30 idiomas

Aquí está el proceso real que seguimos para desarrollo de sitios web multilingües:

Paso 1: Define tu estrategia de locale

Antes de escribir código, decide:

  • ¿Qué idiomas realmente necesitas? (Verifica tu análisis)
  • ¿Usarás URLs localizadas (/de/kontakt) o subdominios (de.example.com)?
  • ¿Necesitarás variantes de región (en-US vs en-GB) o solo códigos de idioma?
  • ¿Qué contenido es traducido vs. cuál es específico de locale?

Por defecto, usamos enrutamiento basado en ruta (/de/, /ja/) porque es más simple para SEO, más fácil de desplegar en un dominio único y funciona naturalmente con el middleware de Next.js.

Paso 2: Configura Next.js con next-intl

Instala y configura:

npm install next-intl

Estructura tu directorio de mensajes:

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

Cada archivo contiene traducciones con espacio de nombres:

{
  "navigation": {
    "home": "Inicio",
    "about": "Acerca de nosotros",
    "services": "Servicios",
    "contact": "Contacto"
  },
  "hero": {
    "title": "Desarrollo web empresarial",
    "subtitle": "Construido para rendimiento, diseñado para escala"
  }
}

Paso 3: Construye el pipeline de traducción

Crea un script que:

  1. Lee tus archivos de origen en inglés
  2. Los envía a Claude API para traducción
  3. Valida la estructura JSON de salida
  4. Escribe archivos de locale
  5. Ejecuta verificaciones de calidad automatizadas (claves faltantes, variables de interpolación rotas)

Paso 4: Implementa hreflang y SEO

Aquí es donde muchas implementaciones multilingües fallan. Cada página necesita etiquetas hreflang apropiadas:

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

Paso 5: Maneja idiomas RTL

Si estás soportando árabe, hebreo u otros idiomas RTL (apoyamos árabe), necesitas CSS direccional:

// 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 soporta variantes rtl: nativamente, lo que hace que el estilo direccional sea manejable.

Paso 6: Despliega y monitorea

Con Next.js en Vercel, las páginas de cada locale se generan estáticamente y se sirven desde nodos de edge más cercanos a los usuarios. Un usuario alemán accediendo a /de/dienstleistungen obtiene una respuesta desde un nodo de edge de Frankfurt en menos de 100ms. Sin consulta de base de datos. Sin búsqueda de WPML. Solo HTML estático.

Ruta de migración: WordPress a multilingüe sin interfaz

Si estás actualmente en WordPress Multisite con WPML, aquí está la ruta de migración que hemos refinado en múltiples proyectos de clientes.

Semanas 1-2: Exportación de contenido y auditoría

  • Exporta todo el contenido vía WP REST API (incluyendo traducciones de WPML)
  • Mapea tipos de contenido a modelos de CMS sin interfaz
  • Identifica traducciones huérfanas y brechas de contenido
  • Documenta todos los patrones de URL para redirecciones 301

Semanas 2-4: Configuración de CMS sin interfaz e importación de contenido

  • Configura modelos de contenido en tu CMS sin interfaz elegido
  • Importa contenido de origen en inglés
  • Configura tablas de traducción de Supabase
  • Ejecuta pipeline de traducción por IA para todos los idiomas de destino

Semanas 4-6: Construcción de frontend

  • Construye aplicación Next.js con next-intl
  • Implementa todas las plantillas de página
  • Configura etiquetas hreflang y generación de mapa del sitio
  • Configura pipeline de traducción automatizado para contenido nuevo

Semanas 6-8: Pruebas, redirecciones y lanzamiento

  • Pruebas de navegadores cruzados e idiomas cruzados
  • Implementa redirecciones 301 de patrones de URL antiguos
  • Envía mapas de sitio actualizados a Google Search Console
  • Monitorea patrones de indexación y tráfico después del lanzamiento

Línea de tiempo total: 4-8 semanas dependiendo del volumen de contenido y complejidad.

Comparación de costos: WordPress Multisite vs. Multilingüe sin interfaz

Aquí está el desglose de costos honesto para un sitio empresarial de 10 idiomas durante 3 años:

Categoría de costo WordPress Multisite + WPML Next.js + Headless + Traducción por IA
Licencia de CMS (3 años) $0 (WP es gratuito) $0-$540 (Sanity pro) o $0 (Payload OSS)
Licencia WPML (3 años) $597 $0
Traducción profesional (inicial) $50,000-$100,000 $220 (IA, 10 idiomas × $22)
Actualizaciones de traducción (3 años) $30,000-$60,000 $500 (costos de IA estimados)
Alojamiento (3 años) $3,600-$7,200 (WP gestionado) $0-$720 (Vercel nivel gratuito-pro)
Desarrollo (construcción inicial) $30,000-$60,000 $40,000-$70,000
Mantenimiento (3 años) $18,000-$36,000 $6,000-$12,000
Costo total de 3 años $132,197-$263,797 $46,720-$83,460

El costo de desarrollo para el enfoque sin interfaz es ligeramente más alto al inicio — estás construyendo infraestructura personalizada en lugar de configurar plugins. Pero los ahorros continuos son dramáticos. Sin renovaciones de WPML. Sin facturas de agencias de traducción. Sin dolores de cabeza de mantenimiento de Multisite.

Benchmarks de rendimiento

Ejecutamos auditorías de Lighthouse en nuestro sitio multilingüe de producción y comparamos contra implementaciones 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
Time to First Byte (TTFB) 800-1,400ms 50-150ms
Puntuación de rendimiento de Lighthouse 45-65 95-100
Páginas por idioma ~118 ~118
Total de páginas indexadas ~1,180 (10 idiomas) ~91,000+ (30 idiomas)

La diferencia de TTFB por sí sola justifica la migración. Cuando tus páginas se generan estáticamente y se sirven desde CDNs de edge, no estás esperando a que PHP arranque WordPress, cargue WPML, consulte la base de datos, resuelva traducciones y renderice una plantilla. El HTML simplemente... está ahí.

FAQ

¿Es la traducción por IA lo suficientemente buena para sitios web empresariales?

Para la mayoría del contenido corporativo — sí. En 2026, Claude y GPT-4 producen traducciones que hablantes nativos califican como calidad profesional para contenido comercial, descripciones de productos y documentación. Hemos desplegado traducciones por IA en 30 idiomas incluyendo japonés, árabe, coreano y chino (simplificado y tradicional) con retroalimentación positiva de revisores que hablan nativamente. Contenido legal, médico o altamente regulado aún puede justificar revisión humana, pero incluso allí, IA + revisión humana es mucho más barato que traducción puramente humana.

¿Cuánto cuesta agregar un nuevo idioma a un sitio multilingüe sin interfaz?

Con nuestro pipeline, agregar un nuevo idioma cuesta aproximadamente $22 en tokens de Claude API y toma aproximadamente 45 minutos de tiempo de ingeniería. Esto cubre la traducción de todo contenido de página, navegación, metadatos y cadenas de interfaz. Compara eso con licencias por sitio de WPML más $5,000-$10,000 en costos de traducción profesional para un sitio empresarial típico.

¿Cuál es la mejor alternativa a WordPress Multisite para sitios multilingües?

Para despliegues empresariales, un CMS sin interfaz (Sanity, Payload o Strapi) combinado con Next.js y next-intl proporciona la arquitectura más flexible y de alto rendimiento. Obtienes verdadera separación contenido/presentación, páginas desplegadas en edge y la capacidad de gestionar traducciones independientemente de tu CMS. Para sitios más simples bajo 50 páginas, Webflow con sus características de localización puede funcionar, pero golpearás limitaciones rápidamente a escala empresarial.

¿Cómo manejas SEO para 30+ versiones de idioma?

Cada página genera etiquetas hreflang apropiadas apuntando a todas las variantes de idioma más una etiqueta x-default. Generamos mapas de sitio XML por locale y los enviamos a Google Search Console. Cada locale obtiene su propio conjunto de títulos meta, descripciones y etiquetas Open Graph — todos traducidos a través del pipeline de IA. Google ha indexado más de 91,000 páginas en nuestras 30 variantes de idioma.

¿Puedes migrar de WordPress Multisite a sin interfaz sin perder rankings de SEO?

Sí, pero requiere planificación cuidadosa. Los pasos críticos son: mapeo de redirección 301 exhaustivo de URLs antiguas a nuevas URLs con prefijo de locale, implementación apropiada de hreflang desde el primer día y envío de mapas de sitio actualizados inmediatamente después del lanzamiento. Típicamente vemos un período de indexación de transición de 1-3 semanas, seguido por mejoras en rankings debido a puntuaciones Core Web Vitals mejores.

¿Cuál es la mejor alternativa a WPML en 2026?

next-intl para aplicaciones Next.js, o nuxt-i18n para aplicaciones Nuxt. Ambas manejan enrutamiento de locale, formateo de mensajes y metadatos de SEO nativamente en la capa de framework — sin la sobrecarga de rendimiento de un plugin de WordPress. A diferencia de WPML, no hay tarifa de licencia anual, sin sobrecarga de base de datos y sin preocupaciones de compatibilidad con otros plugins. La lógica i18n vive en el código de tu aplicación donde pertenece.

¿Cómo gestiones calidad de traducción en 30 idiomas?

Usamos un enfoque de múltiples capas: traducción por IA como capa base, verificaciones de calidad automatizadas (validación de estructura JSON, preservación de variables de interpolación, comparación de longitud) y revisión humana opcional para contenido de alta visibilidad como titulares de página de inicio y CTAs. También mantenemos un glosario de terminología por idioma que se pasa a la IA como contexto, asegurando que términos de marca, nombres de productos y vocabulario técnico se manejen consistentemente.

¿Es este enfoque viable para sitios con actualizaciones frecuentes de contenido?

Absolutamente — es realmente mejor para actualizaciones frecuentes que WPML. Cuando publicas o actualizas una página en inglés, el pipeline de traducción puede ejecutarse automáticamente vía webhook. Las nuevas traducciones se generan en minutos, no en días. Con ISR (Incremental Static Regeneration) en Next.js, las páginas actualizadas se publican sin una reconstrucción completa del sitio. Hemos tenido clientes publicando publicaciones de blog diarias que aparecen en 30 idiomas en el término de una hora, completamente indexadas por motores de búsqueda el mismo día.