La mayoría de los proyectos multilingües en WordPress comienzan de la misma manera: alguien elige WPML o Polylang basándose en una entrada de blog que leyó, lo configura en una tarde, lo publica, y seis meses después el sitio tiene problemas de rendimiento, el flujo de trabajo editorial es un desastre, o hay una brecha en las traducciones que nadie sabe explicar.
Este sitio funciona en cuatro idiomas (EN/PT/ES/FR) con un enfoque personalizado porque ninguno de los plugins se ajustaba limpiamente a mis requisitos. Esa decisión no fue dogmática — fue la tercera opción después de haber considerado seriamente las otras dos. Este es el marco de decisión que realmente utilizo, basado en proyectos reales.
Las tres opciones reales
Olvida las páginas de marketing de cada plugin por un momento. A nivel arquitectónico tienes tres opciones serias:
- WPML — de pago, completo en funcionalidades, pesado. Cada traducción es una entrada separada vinculada al original.
- Polylang — núcleo gratuito / Pro de pago, más ligero, mismo modelo de entradas separadas.
- Personalizado — desde un array i18n serializado en el tema hasta una estrategia de metadatos de entrada personalizada o un selector de idioma basado en variables de consulta.
El multisitio de WordPress con múltiples dominios o subdominios es técnicamente una cuarta opción, pero es un caso completamente distinto — estás ejecutando múltiples instalaciones de WordPress. No lo voy a tratar aquí; si estás a esa escala no te estás preguntando «WPML o Polylang», sino «¿debería dividir esto en sitios separados?».
WPML — cuándo justifica su peso
WPML es la respuesta predeterminada para las agencias porque cubre el conjunto más amplio de casos de forma nativa: entradas, páginas, tipos de contenido personalizados, taxonomías, campos ACF, cadenas de WooCommerce, cadenas del tema mediante el módulo String Translation, menús, widgets, biblioteca multimedia — todo es traducible.
Dónde funciona bien
- Sitios con mucho contenido editorial con un equipo de traducción que necesita un panel de traducción, integración de traducción automática y un flujo de trabajo claro sobre «qué hay de nuevo en el original y qué falta por traducir»
- Tiendas WooCommerce que venden en varios idiomas con nombres de productos, descripciones, atributos y precios localizados en distintas divisas
- Sitios construidos sobre plugins pesados (Elementor, Divi, configuraciones complejas de ACF) — WPML cuenta con integraciones para casi todo
Dónde falla
- Rendimiento. WPML añade entre ~30 y 60 consultas adicionales a la base de datos en una carga de página típica. En una página de inicio que ya ejecuta más de 150 consultas debido al exceso de plugins, WPML la empuja por encima de 200. Se puede cachear, pero en el momento en que tienes usuarios conectados o contenido basado en sesiones, se nota.
- Tamaño de la base de datos. Cada traducción es una fila en
wp_posts, cada meta traducida es una fila enwp_postmeta. Un sitio de 4 idiomas con 500 entradas se convierte en un sitio de 2.000 entradas a nivel de base de datos. - Conflictos con plugins más recientes. El enfoque de «Custom XML config» de WPML para indicarle qué cadenas traducir funciona, pero envejece: cada actualización de un plugin puede requerir ajustes en la configuración.
Coste: 99 €/año para Multilingual CMS, 199 €/año para Multilingual Agency. Vale la pena en un sitio editorial suficientemente complejo; es excesivo para un folleto de 4 páginas.
Polylang — más ligero, mismo concepto
Polylang utiliza el mismo modelo conceptual que WPML —una entrada por idioma, enlazadas entre sí—, pero la implementación es más ligera y la versión gratuita es genuinamente utilizable para sitios sin WooCommerce.
Dónde funciona bien
- Temas personalizados con tipos de entrada personalizados donde tienes control total sobre lo que se traduce y no necesitas la cobertura exhaustiva que ofrece WPML
- Sitios donde el equipo editorial es pequeño y puede prescindir de un panel de traducción dedicado
- Proyectos con presupuesto ajustado donde los 99 €/año de WPML no encajan; Polylang gratuito + Polylang Pro (99 € de pago único) es comparable
Dónde falla
- WooCommerce. Polylang para WooCommerce funciona, pero está menos pulido que WooCommerce Multilingual de WPML. Si tu tienda es el motor principal, esto importa.
- Cadenas del tema. La traducción de cadenas de Polylang Pro es más manual que la de WPML. O entregas tu tema con archivos .mo completos mediante
load_theme_textdomaino dependes de la interfaz más lenta de Polylang. - Maquetadores visuales de páginas. Existen integraciones, pero se rompen con más frecuencia que las de WPML.
Solución personalizada — cuando ninguna encaja
El camino personalizado no es un único enfoque, sino una categoría de enfoques. Los dos que veo con más frecuencia:
Enfoque A: arrays i18n en el tema
Para sitios donde el contenido está muy estructurado y es editorialmente estable —páginas de aterrizaje, sitios de marketing con un conjunto fijo de secciones—, define cada cadena traducible como una clave en un array PHP por idioma, a la que se accede mediante un helper de tipo t(). La URL utiliza un parámetro de consulta ?lang=xx (o un prefijo de ruta), y el idioma activo se determina una vez por solicitud.
Ventajas: sin sobrecarga de rendimiento, sin consultas adicionales a la base de datos, traducciones bajo control de versiones, se despliegan como código. Los editores traducen editando el array (o mediante una interfaz de administración personalizada que escribe en él).
Desventajas: no encaja en un blog con entradas que se añaden con frecuencia, ni en un catálogo WooCommerce de 500 productos. En el momento en que los editores esperan que el administrador de WP sea la fuente de verdad para las traducciones, este enfoque empieza a resultar inadecuado.
Enfoque B: estrategia de metadatos de entrada
Cada entrada tiene un conjunto de campos meta por idioma: title_pt, title_en, etc. Un pequeño filtro elige el campo correcto en el momento del renderizado según el idioma activo. Una entrada, múltiples traducciones, una sola fila en wp_posts.
Ventajas: la mitad de filas en la base de datos en comparación con WPML/Polylang. Administración más rápida (sin necesidad de alternar entre traducciones de entradas). URLs más limpias si se usan parámetros de consulta o una reescritura personalizada.
Desventajas: el SEO requiere generar hreflang manualmente (algo que de todos modos harías en un sitio serio). La interfaz editorial necesita trabajo personalizado: por defecto, el editor de WP solo muestra un conjunto de campos, no cuatro. ACF o metaboxes personalizados resuelven esto, pero añaden complejidad.
El marco de decisión
Deja a un lado las comparativas de funcionalidades y hazte cuatro preguntas:
1. ¿Quién traduce?
Agencia externa o servicio de traducción que espera un flujo de trabajo familiar → WPML. Equipo interno bilingüe → Polylang o solución personalizada. Solo tú → una solución personalizada es perfectamente válida.
2. ¿Qué tan estructurado es el contenido?
Entradas de blog y páginas que cambian con frecuencia y tienen una gran variación → WPML o Polylang. Sitio de marketing muy estructurado con secciones estables → i18n personalizado es más rápido y ligero.
3. ¿Hay WooCommerce?
Tienda multilingüe con múltiples divisas → WPML. Tienda multilingüe con una sola divisa → Polylang para WooCommerce es viable. Sin tienda → cualquiera de los dos plugins o solución personalizada.
4. ¿Cuál es el objetivo de rendimiento?
LCP por debajo de 1,5 s en el percentil 75 en móvil → la solución personalizada es el único camino que lo alcanza de forma consistente sin una caché de borde agresiva. WPML o Polylang con caché de página completa en el borde → entre 2 y 3 s en la primera solicitud, por debajo de 1 s con caché.
Consideraciones SEO para las tres opciones
El plugin no te exime de implementar correctamente hreflang. Cada página traducida necesita etiquetas hreflang recíprocas que apunten a sus páginas hermanas, más un x-default para el idioma de reserva neutro. WPML y Polylang las generan automáticamente, pero he visto que ambos producen resultados sutilmente incorrectos (un idioma que falta, código de región erróneo, parámetros de consulta duplicados).
Verifícalo en el HTML renderizado, no en la configuración del plugin. Utiliza el informe de «Segmentación internacional» de Google Search Console para detectar errores de clúster con el tiempo.
Las canónicas merecen la misma atención: cada página traducida debe ser autocanónica (es la URL canónica de esa versión en ese idioma), y no debe apuntar a la versión en el idioma original. WPML y Polylang lo hacen correctamente por defecto; los enfoques personalizados requieren trabajo explícito.
Lo que hago en la práctica
En proyectos de agencia, la opción predeterminada es WPML: las expectativas de flujo de trabajo de los clientes de agencia y los servicios de traducción se alinean con la forma en que este se presenta.
En plataformas corporativas con arquitectura personalizada, Polylang o una solución a medida, dependiendo de si el equipo editorial necesita una interfaz de traducción por entrada.
En sitios de marketing con contenido muy estructurado (como este), i18n personalizado mediante un array PHP, servido a través de ?lang=xx. Cero consultas a la base de datos para las traducciones, con control de versiones y desplegado como código. La contrapartida: editar requiere modificar un archivo, no el panel de administración de WP.
Ninguna de estas elecciones es permanente. Las rutas de migración entre ellas están bien trilladas: WPML → Polylang es sencillo, Polylang → personalizado es mecánico, y personalizado → cualquiera de los plugins es el más fácil de todos.
Lo que no quieres es tener que migrar desde una configuración que era incorrecta desde el principio porque nadie formuló las cuatro preguntas anteriores.
