WordPress multilingüe en 2026: WPML, Polylang, MultilingualPress y headless

#WordPress multilingüe en 2026: WPML, Polylang, MultilingualPress y headless

WordPress multilingüe es una de esas preguntas en las que la respuesta “depende” es honesta y útil. En 2026 conviven cuatro estrategias probadas, cada una con un equilibrio distinto entre experiencia editorial, SEO, rendimiento y coste operativo. Esta guía elige la estrategia adecuada para los perfiles de cliente más habituales y señala qué falla cuando se elige mal.

Este artículo enlaza con el pilar de servicios de WordPress headless para los casos en que el SEO y las Core Web Vitals deciden la elección.

#WordPress multilingüe en 2026 en resumen

• Polylang Pro: opción segura por defecto para WordPress editorial en un único sitio, con equipos pequeños o medianos.
• WPML: estándar para tiendas WooCommerce con flujos de traducción complejos.
• MultilingualPress: encaja en redes Multisite donde cada idioma es un sitio independiente.
• Headless con Astro 5+ o Next.js 15: lo mejor cuando el control del SEO y el rendimiento importan más que la comodidad editorial.
• Las cuatro requieren hreflang correcto, sitemaps por idioma y una estructura de URL limpia.

#Qué hace WordPress con varios idiomas sin plugins

El núcleo de WordPress traduce la interfaz, no el contenido. Una instalación nueva funciona en un único idioma del sitio, elegido en los ajustes generales, y el núcleo descarga los paquetes de idioma correspondientes desde translate.wordpress.org para sí mismo y para los plugins y temas del directorio de WordPress.org.

Desde WordPress 4.7 cada usuario puede elegir en su perfil el idioma del escritorio. El núcleo lo guarda como metadato de usuario con la clave locale y recurre al idioma del sitio cuando el campo está vacío (make.wordpress.org/core, 2016). La misma versión añadió switch_to_locale() y restore_previous_locale(), que los plugins usan para enviar un correo en el idioma del destinatario en lugar del idioma de la petición que lo disparó.

WordPress 6.5 sustituyó el cargador de traducciones. Los paquetes de idioma de WordPress.org incluyen ahora archivos .l10n.php junto a los .mo y .po, y cuando existen ambos el núcleo carga el archivo PHP, que OPcache puede mantener en memoria. Los sitios que solo tienen archivos .mo siguen funcionando, y el filtro translation_file_format devolviendo 'mo' desactiva los archivos PHP (make.wordpress.org/core, 2024). Los plugins comerciales distribuidos fuera de WordPress.org tienen que generar los archivos PHP por su cuenta, por ejemplo con wp i18n make-php de WP-CLI 2.10.

Lo que el núcleo no tiene es un vínculo entre dos entradas que dicen lo mismo en dos idiomas. La hoja de ruta de WordPress sitúa los sitios multilingües en la fase 4 del proyecto Gutenberg, después de la edición, la personalización y la colaboración, sin fecha de lanzamiento (hoja de ruta de WordPress). Hasta que esa fase llegue al núcleo, cada estrategia de las siguientes añade la traducción de contenido mediante un plugin, una red Multisite o un front end separado.

#Cuáles son las cuatro estrategias de WordPress multilingüe

#1. Polylang (Pro) en un único sitio WordPress

Cómo funciona: cada entrada, página, taxonomía y elemento de menú existe una vez por idioma dentro de una sola instalación de WordPress. El plugin vincula entre sí las entradas relacionadas. El editor de bloques muestra un selector de idioma y los editores traducen desde el mismo escritorio.

Cuándo elegirlo:

• El equipo es pequeño o mediano y los flujos editoriales son sencillos.
• El sitio tiene hasta una docena de idiomas con una estructura compartida.
• El presupuesto de alojamiento es modesto; mantener una sola instalación de WordPress es bastante más barato que Multisite.
• WooCommerce no está presente o tiene un papel limitado.

Concesiones: WPML tiene una experiencia algo más pulida para los editores que cambian de idioma con frecuencia. Polylang Pro da menos problemas de compatibilidad con temas y plugins fuera del ecosistema WooCommerce.

Qué cubre la versión gratuita y qué añade Pro, según la ficha de Polylang en WordPress.org: la versión gratuita traduce entradas, páginas, medios, categorías, etiquetas, tipos de contenido personalizados y taxonomías, y lee el idioma de un código en la URL, de un subdominio o de un dominio propio. Pro añade duplicación y sincronización de contenido entre traducciones, slugs de URL traducidos, traducción automática con DeepL y exportación e importación en XLIFF para traductores externos. WooCommerce necesita el complemento independiente Polylang for WooCommerce, que traduce la tienda, el carrito, el pago y la cuenta del cliente y envía los correos de WooCommerce en el idioma del cliente.

#2. WPML en un único sitio WordPress

Cómo funciona: un modelo de arquitectura similar al de Polylang (un sitio, muchas entradas por idioma), pero con una capa de gestión de traducciones más elaborada que incluye memoria de traducción, integración con traductores profesionales y una integración más completa con WooCommerce.

Cuándo elegirlo:

• El sitio es una tienda WooCommerce con productos, categorías, atributos y textos del checkout traducidos.
• El equipo trabaja con servicios de traducción externos a través de un sistema de gestión de traducciones (TMS).
• Los plugins de los que depende el sitio indican WPML como socio con soporte oficial.

Concesiones: la licencia de WPML es de pago, con niveles según el número de sitios. Algunas versiones de WordPress y WooCommerce han causado fricciones en el pasado; el retraso de compatibilidad de WPML es real, pero suele ser breve.

#3. MultilingualPress en WordPress Multisite

Cómo funciona: cada idioma es un sitio independiente dentro de una red Multisite. MultilingualPress vincula las entradas entre sitios y ofrece al editor un selector. La arquitectura es “una red, muchos sitios” y no “un sitio, muchos idiomas”.

Cuándo elegirlo:

• Los idiomas funcionan de forma operativamente separada: equipos editoriales distintos, calendarios de publicación distintos, conjuntos de plugins distintos.
• Razones de marca o legales exigen una separación visible entre los sitios de cada idioma (dominios distintos, imagen de marca distinta).
• El rendimiento por idioma importa y aislar los plugins de un idioma de los demás ayuda.

Concesiones: Multisite es un modelo operativo más pesado. La compatibilidad de plugins se reduce. La búsqueda y los informes entre sitios requieren trabajo adicional.

#4. WordPress headless con Astro 5+ o Next.js 15

Cómo funciona: WordPress (con Polylang o WPML para crear el contenido) se convierte en el back end. El sitio público lo renderiza Astro o Next.js, que obtiene el contenido de cada idioma a través de la WordPress REST API o de WPGraphQL. El hreflang, el sitemap, los datos estructurados y la caché en el edge pasan a ser responsabilidad del front end.

Cuándo elegirlo:

• El SEO y las Core Web Vitals influyen directamente en los ingresos (comercio electrónico, generación de leads, sectores regulados).
• El contenido sale más allá de la web (aplicación móvil, superficies para agentes de IA, sindicación).
• El cliente quiere control explícito sobre la estructura de URL por idioma, la caché en el edge y la precisión del hreflang.
• La jurisdicción de la UE no es negociable; Cloudflare Workers + un origen WordPress alojado en la UE es el patrón habitual.

Concesiones: el equipo editorial trabaja con una ligera capa intermedia (las vistas previas pasan por un dominio separado). Hay dos stacks que mantener. Las ventajas de arquitectura se acumulan durante los próximos cinco años; el coste se nota en los primeros seis meses.

Este es el camino que el pilar de servicios de WordPress headless describe en detalle.

#Cómo elegir una estrategia de WordPress multilingüe

#Cómo guardan Polylang y WPML las traducciones en la base de datos

El modelo de almacenamiento decide lo difícil que será una migración posterior, una consulta propia o una exportación a headless.

Polylang usa taxonomías del núcleo de WordPress. El código del plugin registra cuatro: language y term_language guardan el idioma de una entrada o de un término, mientras que post_translations y term_translations agrupan los elementos que son traducciones entre sí. Una entrada en alemán es una entrada normal con un término language asignado, así que WP_Query, las exportaciones y las copias de seguridad ven datos estándar de WordPress.

WPML usa tablas propias. Los idiomas y los vínculos de traducción están en icl_translations: element_id es el ID de la entrada o el term_taxonomy_id, element_type indica el tipo de objeto, trid agrupa los elementos que son traducciones entre sí, language_code es el idioma del elemento y source_language_code queda vacío en el original (tablas de la base de datos de WPML). Los textos que no pertenecen a entradas, como el lema del sitio, van a icl_strings e icl_string_translations, y los trabajos de traducción a icl_translate_job y tablas relacionadas. Una consulta propia o un script de migración tiene que unir esas tablas, porque la tabla de entradas por sí sola no dice en qué idioma está cada entrada.

#Cómo migrar de WPML a Polylang

En esta dirección existe una herramienta específica. WPML to Polylang, mantenida por los desarrolladores de Polylang, importa idiomas, idiomas y traducciones de entradas y términos (incluidos tipos de contenido y taxonomías personalizados), menús multilingües, traducciones de cadenas y los ajustes de traducción de los campos de ACF. No borra los datos de WPML. El orden documentado: copia de seguridad de la base de datos, desactivar WPML, activar Polylang y el importador sin crear ningún idioma en Polylang, lanzar la importación desde la pantalla del importador en el menú de herramientas y, por último, añadir un selector de idioma. El importador no tiene gestión de errores propia, y sus autores informan de una prueba correcta en un sitio con unas 9.000 entradas y archivos de medios. Los enlaces, las redirecciones y las integraciones de plugins requieren igualmente una revisión manual después, por eso el cambio debe hacerse antes del lanzamiento y no después.

#Cómo configurar WordPress Multisite para una red de sitios por idioma

MultilingualPress funciona sobre una red Multisite, así que primero van las decisiones de la red. Multisite se activa con define( 'WP_ALLOW_MULTISITE', true ); en wp-config.php, lo que desbloquea la pantalla de configuración de la red. Esa pantalla pide elegir entre subdominios y subdirectorios. La documentación de WordPress dice que la red puede cambiarse a la otra opción después de la instalación, pero que puede no ser fácil (crear una red). Elija la estructura que encaje con el plan de URL de los idiomas antes de que exista el primer subsitio.

Los dominios propios por idioma no necesitan plugin. El mapeo de dominios es nativo desde WordPress 4.5: el administrador de la red edita el subsitio e introduce el dominio completo, con el esquema, como dirección del sitio. Cada dominio adicional tiene que apuntar a la red en el DNS, cada dominio necesita un certificado SSL (SNI sirve varios dominios desde un mismo servidor), y un inicio de sesión que falla en silencio en un subsitio mapeado suele resolverse con define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); en wp-config.php (mapeo de dominios en Multisite).

#Cómo consultar contenido traducido en WordPress headless

Un front end headless tiene que pedir a WordPress el contenido en un idioma y los ID de sus traducciones, porque construye él mismo el conjunto de hreflang y el selector de idioma.

Con Polylang esto funciona mediante la REST API, pero solo en Polylang Pro. GET /wp/v2/posts?lang=fr lista las entradas en francés, y entradas y términos reciben dos campos adicionales: lang con el código de idioma y translations, un objeto que asigna a cada código de idioma el ID del elemento traducido (REST API de Polylang).

Con WPML la vía documentada es GraphQL. El complemento WPML GraphQL requiere WPGraphQL, WPML y WPML String Translation. Añade el argumento language a las consultas de listas (where: { language: "de" }, o "all" para todos los idiomas) y el campo translations a entradas y términos, de modo que una sola petición devuelve una página junto con sus versiones de idioma (WPML GraphQL). Los menús y las páginas de opciones de ACF aceptan el mismo argumento.

En ambos casos el front end asume lo que antes imprimía el plugin: el hreflang construido a partir del campo translations, una entrada del sitemap por idioma y los metadatos traducidos. Las estructuras de URL, las reglas de hreflang de Google y los sistemas de gestión de traducciones se tratan en la guía de estrategia global de contenidos, así que este artículo no los repite.

#Hreflang, sitemaps, URL y metadatos en WordPress multilingüe

Cinco elementos que toda estrategia de WordPress multilingüe debe entregar correctamente:

Etiquetas hreflang. Cada página debe declarar sus alternativas por idioma, más una entrada autorreferencial, más un x-default. Prueba con herramientas reales (Sitebulb, Screaming Frog o un crawler propio).

Sitemap por idioma. Yoast, Rank Math y los front ends headless permiten generar sitemaps por idioma. Valida el resultado manualmente antes de enviarlo a Google Search Console.

Estructura de URL limpia. Usa subdirectorios (/en/, /de/) o subdominios (en.example.com) de forma coherente. Los parámetros de consulta (?lang=en) son un antipatrón en 2026 y provocan problemas de indexación.

Datos estructurados traducidos. Los bloques JSON-LD de Schema.org necesitan name, description e inLanguage traducidos en cada página. La traducción automática de los datos estructurados es un fallo silencioso habitual.

Metadatos traducidos. El título SEO, la meta description, los títulos de Open Graph y las Twitter cards se traducen de forma independiente del cuerpo del texto. Polylang y WPML lo cubren; los front ends headless requieren plantillas explícitas por idioma.

#Errores comunes en WordPress multilingüe

Tres patrones que rompen WordPress multilingüe en producción:

Cambiar de estrategia a mitad de camino. Empezar con Polylang y pasar a WPML, o al revés, suele implicar reescribir enlaces, redirecciones e integraciones de plugins. Elige una vez, a fondo, antes de escalar.

La traducción automática como único flujo de traducción. El texto editorial generado por máquina se lee como texto de máquina. Usa la traducción automática solo para los primeros borradores; la versión pública la revisa un hablante nativo.

Ignorar el índice del buscador. Los sitios multilingües tienen N veces más URL. Los problemas de indexación se acumulan. Revisa Search Console cada semana durante los tres primeros meses tras el lanzamiento y de nuevo cada vez que llegue una actualización importante de un plugin o tema.

#Mejor configuración de WordPress multilingüe según el tipo de sitio

Para un WordPress editorial en un único sitio en 2026: Polylang Pro es el punto de partida adecuado, salvo que WooCommerce o requisitos de cumplimiento te lleven a otra opción.

Para una tienda WooCommerce: WPML es el punto de partida adecuado.

Para una red multimarca o multirregión: MultilingualPress sobre Multisite.

Para un sitio crítico en rendimiento o regulado: headless con Astro o Next.js, con WordPress como back end editorial. El pilar de servicios de WordPress headless y la guía de Cloudflare Workers y WordPress en el edge cubren los detalles de arquitectura.

#Guías relacionadas sobre WordPress multilingüe

• Pilar de servicios de WordPress headless
• Cloudflare Workers y WordPress en el edge
• Tech Radar Q4 2026: veredictos sobre el stack