Plugins multiidioma WordPress: cuál elegir y el factor IA

Por qué escribo sobre esto

Llevo años montando y manteniendo webs en varios idiomas para clientes de sectores muy distintos: clínicas, despachos, hostelería, comercio. Y cada vez que llega un proyecto nuevo con requisito multiidioma, vuelve la misma pregunta: ¿qué plugin pongo? La respuesta no es única, y casi nadie lo cuenta así. La mayoría de comparativas que circulan están escritas por quien vende uno de los plugins, o por afiliados que cobran comisión. Yo no vendo ninguno. Trabajo con ellos.

Este artículo es el resultado de ordenar lo que he aprendido en producción y contrastarlo con una investigación documental a fondo sobre el estado del mercado en 2026. Mi objetivo es que, al terminar de leerlo, sepas tres cosas: cómo funciona por dentro cada familia de plugins, qué papel está jugando la inteligencia artificial en la traducción de sitios, y qué herramienta encaja con qué tipo de proyecto. Sin adjetivos de folleto.

Adelanto mi posición, porque me parece honesto hacerlo antes que esconderla en las conclusiones: para el grueso de los proyectos que gestiono —webs informativas, corporativas, blogs con tráfico razonable— mi gold estándar es Polylang. Luego explico por qué, y también en qué casos dejo de recomendarlo.

Las tres familias: dónde vive tu traducción

Antes de hablar de plugins concretos hay que entender una sola cosa, porque de ella se deriva casi todo lo demás: dónde se guarda el texto traducido. Hay tres respuestas posibles, y cada una tiene consecuencias muy distintas para tu SEO, tu factura y tu libertad para cambiar de herramienta.

1. Traducción en tu propia base de datos (modelo nativo)

El plugin guarda las traducciones dentro de la base de datos de tu WordPress, como filas nuevas en las tablas del propio sistema. Es el modelo de WPML, Polylang y TranslatePress.

La consecuencia importante es esta: el contenido traducido es tuyo y vive en tu servidor. Google lo recibe ya renderizado en la primera petición, sin depender de que se ejecute ningún JavaScript, lo que garantiza que tus páginas en otros idiomas se indexen. Y si un día cancelas la licencia del plugin, pierdes el panel de gestión pero el texto sigue ahí. La dependencia del proveedor es prácticamente nula.

El precio que se paga es de rendimiento: meter todas las traducciones en la base de datos la engorda, y eso puede penalizar el tiempo de respuesta del servidor si no tienes una buena caché. Es un problema real en webs muy grandes, pero gestionable con la infraestructura adecuada.

2. Traducción en la nube del proveedor (modelo SaaS)

Aquí el plugin intercepta el HTML que genera tu WordPress justo antes de enviarlo al navegador y lo sustituye por el contenido traducido que vive en los servidores del proveedor. Es el modelo de Weglot, Linguise y los planes de pago de GTranslate.

La ventaja técnica es que tu base de datos no se toca y que estos sistemas traducen sin despeinarse las maquetaciones más enrevesadas de constructores como Elementor o Divi, porque trabajan sobre el HTML ya generado. Para un despliegue rápido es cómodo.

El inconveniente es de fondo y conviene entenderlo bien: el contenido traducido no es tuyo, lo alquilas. Mientras pagas, funciona. El día que dejas de pagar, las URLs en otros idiomas devuelven error porque el proxy deja de servir esas páginas. Es lo que en el sector se llama dependencia del proveedor o vendor lock-in, y en este modelo es severa. Hay que tenerlo claro desde el principio, no descubrirlo dos años después.

3. Traducción en el navegador (modelo JavaScript)

El servidor entrega la página en su idioma original y un script la traduce sobre la marcha en el navegador del visitante. Es lo que hace la versión gratuita de GTranslate.

Sobre esto seré breve y rotundo, porque es donde más gente se equivoca: para SEO internacional no sirve. Google rastrea el código fuente original sin ejecutar esa traducción, de modo que el contenido en otros idiomas sencillamente no existe para el buscador. Es útil como ayuda de accesibilidad para quien ya está en tu web, nada más. Si tu objetivo es posicionar en otros idiomas, este modelo es indexabilidad cero.

Los plugins, uno a uno

WPML — el veterano corporativo

WPML (de OnTheGoSystems, en el mercado desde 2007) es el plugin de referencia para proyectos grandes y, muy especialmente, para tiendas WooCommerce complejas. Su gran baza es que gestiona de forma nativa cosas que otros no cubren, como la multidivisa, y que asume bien la lógica de extensiones de comercio exigentes.

Tiene dos contrapartidas. La primera es que no existe versión gratuita: hay que pasar por caja desde el primer día. La segunda es que es pesado e intrusivo. Según el análisis técnico del dossier, inyecta una cantidad notable de tablas propias y modifica el comportamiento interno de WordPress de forma que exige un alojamiento solvente, con caché de objetos, para no penalizar la velocidad. Esto último lo etiqueto como [PROBABLE]: es coherente con su arquitectura y aparece reportado en múltiples fuentes, pero el grado de impacto depende mucho de cada hosting.

Mi lectura: WPML tiene sentido cuando el proyecto es un e-commerce serio o una corporación con presupuesto y servidor a la altura. Para una web informativa es un exceso.

Polylang — mi gold estándar

Polylang (de WP Syntex, desde 2011) es el que más uso, y voy a explicar por qué con honestidad, incluyendo lo que no me gusta.

Lo que me convence: su versión gratuita es de las más completas del mercado. Incluye idiomas ilimitados, traducción manual, enrutamiento y soporte SEO con etiquetas hreflang, todo sin pagar. Y es ligero, porque se apoya en las taxonomías nativas de WordPress en lugar de inflar la base de datos con estructuras propias. Para una web informativa o un blog, esa combinación de gratis, ligero y correcto para SEO es difícil de batir.

Lo que no me gusta y debo decir: la versión gratuita no traduce los slugs de las URL (no te deja convertir /projects/ en /proyectos/), lo cual es una limitación SEO real si quieres URLs nativas en cada idioma. Para eso necesitas Polylang Pro. Y su integración con WooCommerce y con ciertos constructores como Elementor exige complementos adicionales, lo que añade fricción. No tiene IA en el núcleo gratuito; la traducción automática llega con la versión Pro (que integra DeepL) o conectando tu propia clave de API.

Mi lectura: para el tipo de proyecto que gestiono la mayor parte del tiempo, Polylang es el equilibrio correcto entre coste, rendimiento y control. Cuando el cliente necesita slugs traducidos paso a la versión Pro sin dramatismo. Donde dejo de recomendarlo es en tiendas WooCommerce con multidivisa: ahí pierde frente a WPML.

GTranslate — la tarifa plana para catálogos enormes

GTranslate (de GTranslate Inc., desde 2008) tiene una doble cara que conviene no confundir. Su versión gratuita es el modelo JavaScript del que ya he hablado: cómoda, ilimitada en idiomas y sin ningún valor SEO. Sus planes de pago, en cambio, cambian a un modelo de proxy en la nube que sí genera URLs indexables.

Su rasgo diferencial frente a otros SaaS es el precio: ofrece una tarifa plana sin límite de palabras ni de páginas vistas. Para un portal con cientos de miles de páginas, eso lo convierte en una de las pocas opciones económicamente viables, porque los modelos que facturan por volumen de palabras se vuelven prohibitivos a esa escala.

El reverso es la portabilidad: según el dossier, GTranslate no ofrece un módulo de exportación de las traducciones, de modo que recuperar tu contenido si te marchas es complicado. Sumado a la dependencia inherente al modelo SaaS, es algo a valorar antes de comprometerse.

Weglot — rápido de montar, caro de mantener

Weglot (desde 2016) es el SaaS que más se recomienda para despliegues rápidos y para webs con maquetaciones visuales muy complejas, porque al trabajar sobre el HTML final se traga sin problemas lo que otros plugins atragantan.

Tiene versión gratuita, pero es estrictamente una demo: el dossier la sitúa en un límite de 1 idioma adicional y 2.000 palabras, que se agotan con casi cualquier web real. A partir de ahí, su facturación va por volumen de palabras almacenadas, contando cada palabra por cada idioma activo. Una web modesta de 30.000 palabras en tres idiomas consume 90.000 palabras de cuota, y de ahí escala rápido.

Aquí debo marcar una distinción que el proyecto me exige: el dossier original calificaba este modelo de «trampa financiera». Esa es una interpretación, no un hecho. El hecho verificable es que el coste crece con el volumen y con el número de idiomas, y que para una web que crece eso se traduce en una factura creciente. Si es trampa o es un modelo legítimo de precio por uso, lo juzga cada uno. Yo me limito a avisar: con Weglot, haz números a tres años, no a tres meses.

Los que añade la investigación

Más allá de los cuatro que conocía, el análisis del mercado destaca otros que merece la pena tener en el radar:

• TranslatePress (Cozmoslabs, 2018): modelo nativo con edición visual sobre la propia web. Su versión gratuita conecta con Google Translate pero bloquea la traducción de slugs. Su gran atractivo está en la versión Pro con modelo Bring Your Own Key, del que hablo en la sección de IA.
• Linguise (2021): un SaaS en la línea de Weglot, según las fuentes en torno a un 30% más económico, con buena gestión de caché. Hereda el mismo modelo de suscripción por volumen y la misma dependencia del proveedor. No tiene versión gratuita perpetua, solo prueba temporal.
• Loco Translate: conviene aclarar qué es y qué no es, porque mucha gente lo instala por error. No sirve para traducir el contenido de tu web; sirve para traducir los archivos de idioma de temas y plugins (los .po y .mo). Es una herramienta de desarrollador, no de internacionalización de contenidos.
• MultilingualPress (Inpsyde/Syde): aísla cada idioma en una instalación separada sobre WordPress Multisite. Máxima independencia, pero exige conocimientos de administración de servidores que lo descartan para la mayoría.

El factor IA: qué traen gratis y qué te cobran

Esta es la parte que más ha cambiado en los últimos dos años y la que más confusión genera, porque casi todos los plugins anuncian «traducción con Inteligencia Artificial» sin aclarar en qué condiciones. Hay tres modelos de negocio detrás, y entenderlos te ahorra dinero.

La IA como alquiler (Weglot, Linguise). El plugin te da acceso a buenos motores sin que configures nada, pero pagas mensualmente por mantener el texto vivo en su nube. Cómodo y caro a largo plazo.

La IA como consumible prepago (WPML). La infraestructura es tuya, pero la empresa te revende el acceso a los modelos cobrándote créditos por palabra. Según el dossier, el modelo va desde 1 crédito por palabra con Microsoft hasta 4 créditos por palabra con su propio motor LLM. Tú controlas el dato; ellos controlan el grifo de la IA.

La IA como «trae tu propia clave» o BYOK (TranslatePress, Polylang Pro). Este es el modelo más rentable para quien tiene perfil técnico, y merece explicación. Pagas la licencia anual del plugin, pero conectas tu propia clave de API de OpenAI o DeepL. Eso significa que pagas el cómputo a precio de fábrica, sin el recargo del intermediario. El dossier cifra ese coste en torno a 1,20 dólares por traducir 200.000 palabras con modelos económicos. La diferencia con el modelo de alquiler es de uno o dos órdenes de magnitud.

Un punto importante sobre la calidad, y aquí soy estricto con las fuentes: Weglot afirma una tasa de aceptación de su IA del 90% y Linguise un 95% equiparable a traductor humano. Ninguna de esas dos cifras está verificada de forma independiente; son afirmaciones de los propios fabricantes. Las recojo como lo que son, no como datos comprobados.

Resumiendo el panorama de la versión gratuita: la traducción automática por IA no suele estar en las capas gratuitas. Polylang gratuito no la trae. WPML no tiene capa gratuita en absoluto. TranslatePress gratuito solo conecta Google Translate con tu propia clave. La IA «gratis de verdad» en estos plugins es, hoy, más promesa de marketing que realidad.

Traducción asistida por IA externa: montarte tu propio flujo

Aquí entramos en terreno que me interesa especialmente, porque conecta con cómo trabajo ahora. La pregunta es: si la IA ya traduce con calidad notable y por céntimos vía API, ¿para qué pagar la traducción del plugin? ¿No puedo montarme mi propio flujo?

La respuesta corta es que sí, y que tiene mucho sentido en ciertos casos. La idea es usar la API REST de WordPress para leer tus contenidos en el idioma original, pasarlos por una API de IA (DeepL u OpenAI) para traducirlos, y volver a escribirlos como las versiones en otros idiomas que gestiona un plugin nativo como Polylang. Un agente de IA puede orquestar todo ese proceso.

¿Cuándo compensa? Cuando tienes muchos contenidos, perfil técnico para montar el flujo y quieres pagar el cómputo a precio mayorista en lugar de alquilar créditos. Para traducir un sitio entero de una vez, la diferencia de coste frente a los créditos del plugin o frente a un SaaS es enorme.

¿Cuándo no compensa? Cuando el flujo de trabajo es continuo y lo va a operar gente no técnica. Ahí la comodidad de una interfaz integrada vale lo que cuesta. Montar tu propio agente es una inversión inicial que solo se amortiza con volumen.

El detalle técnico de cómo se implementa esto —endpoints, autenticación, la función de Polylang para enlazar traducciones y los riesgos a vigilar— lo dejo en el anexo, para no romper el hilo de quien solo quiere decidir qué plugin instalar.

Recomendación por tipo de web

Bajando todo lo anterior a tierra, así es como yo decido:

Web pequeña, blog o informativa. Polylang gratuito. Ligero, correcto para SEO y sin coste. Si necesitas slugs traducidos en cada idioma, Polylang Pro. Es mi gold estándar y el de la mayoría de proyectos que paso por mis manos.

Web corporativa media con ganas de IA. Si hay perfil técnico detrás, TranslatePress Pro con tu propia clave de API es la opción más rentable: máxima calidad de traducción pagando el cómputo a precio de fábrica y reteniendo el control del dato. Si no hay perfil técnico, Polylang Pro sigue siendo una apuesta sólida y predecible.

Web con miles o millones de páginas. Aquí el modelo nativo sufre por el peso en base de datos y los SaaS de pago por palabra se vuelven inviables económicamente. GTranslate en plan de pago, con su tarifa plana sin límite de volumen, es de las pocas opciones que aguantan esa escala. A cambio, asumes la dependencia del proveedor y la mala portabilidad.

Tienda WooCommerce. WPML. Es donde su robustez transaccional y su multidivisa nativa justifican el peso y el coste. Polylang puede hacerlo, pero te obliga a complementos de terceros para la multidivisa, y en un e-commerce esa fricción se paga cara.

Una reflexión final

Lo que más me llama la atención al ordenar todo esto no es ningún plugin concreto, sino el cambio de fondo. Durante años, la pregunta del multiidioma era «¿quién traduce y cuánto cuesta?». Hoy la traducción de calidad razonable cuesta céntimos y la hace una máquina. La pregunta se ha desplazado: ya no es quién traduce, sino dónde vive lo traducido y de quién depende que siga existiendo.

Esa es la decisión de verdad. Puedes tener una IA excelente traduciendo tu web por casi nada, y aun así estar atrapado en un modelo donde el día que dejes de pagar pierdes años de contenido indexado. O puedes pagar un poco más de fricción técnica a cambio de que lo traducido sea tuyo, esté en tu servidor y nadie pueda apagarlo. La IA ha resuelto el problema de la traducción. No ha resuelto, y diría que ha agravado, el problema de la soberanía sobre lo que es tuyo.

¿Dónde pones tú el límite entre comodidad y control? Porque esa, y no el ranking de plugins, es la pregunta que decide el proyecto.

Anexo técnico

Tabla comparativa completa

Datos según investigación documental de 2026. Los precios y límites deben reconfirmarse en la web oficial de cada plugin antes de tomar una decisión: cambian con frecuencia y varios figuran en las fuentes como pendientes de verificación.

Nota sobre IA y versión gratuita: ningún plugin de la tabla ofrece traducción automática por IA en su capa gratuita de forma realmente operativa. El modelo BYOK (TranslatePress Pro, Polylang Pro) es el más económico para perfil técnico: licencia anual del plugin + tu propia clave de API, pagando el cómputo a precio de fábrica (en torno a 1,20 USD por 200.000 palabras con modelos económicos, según fuentes).

Flujo de traducción asistida por IA vía API REST de WordPress

Este es el esquema para montar tu propio flujo de traducción con un agente de IA, sin depender de los créditos del plugin. El principio: leer el contenido original vía API REST, traducirlo con una API de IA externa y reescribirlo como traducción enlazada en Polylang.

1. Endpoints relevantes de la API REST

• GET /wp-json/wp/v2/posts — leer entradas en el idioma original.
• GET /wp-json/wp/v2/pages — leer páginas.
• GET /wp-json/wp/v2/{custom_post_type} — leer CPT registrados con show_in_rest.
• POST /wp-json/wp/v2/posts — crear la entrada traducida como nuevo post.
• POST /wp-json/wp/v2/posts/{id} — actualizar contenido o metadatos.

2. Autenticación

Para un flujo automatizado, lo razonable es usar Application Passwords (nativo en WordPress desde la versión 5.6), que genera una credencial específica por aplicación sin exponer la contraseña principal. La alternativa es JWT mediante plugin, útil si necesitas tokens de expiración corta. Application Passwords es suficiente para la mayoría de casos y no añade dependencias.

3. El paso crítico: enlazar la traducción en Polylang

Crear el post traducido vía API REST no basta: hay que asignarle el idioma correcto y enlazarlo con el original, o Polylang lo tratará como contenido suelto sin relación de traducción, y el hreflang no se generará.

Polylang expone funciones de su API para esto. El flujo es: asignar idioma al nuevo post y luego registrar el grupo de traducciones que vincula original y traducción.

// ⚠️ VERIFICAR firma exacta en la documentación oficial de Polylang antes de usar
// Asignar idioma al post traducido
pll_set_post_language( $id_post_traducido, 'en' );

// Enlazar original y traducción como grupo
pll_save_post_translations( array(
    'es' => $id_post_original,
    'en' => $id_post_traducido,
) );

⚠️ Aviso: los nombres pll_set_post_language() y pll_save_post_translations() proceden de la API documentada de Polylang, pero el dossier no aportó la firma exacta verificada. Confirmar en la documentación oficial de desarrolladores de Polylang antes de llevar esto a producción. Estas funciones son PHP, no REST: el agente necesita ejecutarlas en el contexto de WordPress (vía un endpoint propio o WP-CLI), no puede llamarlas directamente desde fuera.

4. WP-CLI como alternativa

Para traducciones masivas en lote, WP-CLI suele ser más robusto que la API REST: ejecutas un comando propio que recorre los posts, llama a la IA y crea las traducciones enlazadas en una sola pasada, sin la sobrecarga HTTP de miles de peticiones REST. Es la vía recomendable cuando hablamos de cientos o miles de entradas.

5. Riesgos a vigilar

• Shortcodes y bloques Gutenberg: el contenido no es texto plano. Si mandas a traducir el HTML/JSON de los bloques sin protección, la IA puede romper la estructura. Hay que aislar el texto traducible y preservar las etiquetas, atributos y delimitadores de bloque.
• HTML que no debe traducirse: nombres propios, fragmentos de código, marcas. Conviene instruir al modelo para que los respete.
• hreflang: si el enlazado de traducciones en Polylang falla, las etiquetas hreflang no se generan y pierdes el principal beneficio SEO del multiidioma. Verificar siempre que el grupo de traducción quedó bien registrado.
• Integridad de metadatos: título SEO, meta description y slug también deben traducirse y asignarse, no solo el cuerpo del post.

El coste comparado justifica el esfuerzo cuando hay volumen: traducir un sitio completo vía API de IA externa puede costar unos pocos dólares frente a las cuotas mensuales recurrentes de un SaaS o los paquetes de créditos de un plugin. La inversión está en montar el flujo una vez; a partir de ahí, el cómputo es marginal.