Un cambiador de idioma WordPress multisitio tiene una sola tarea. El visitante hace clic en EN y llega a la misma página que estaba leyendo, pero en inglés. Nada más. Y aun así, de cada diez redes bilingües que abro para auditar, siete fallan justo ahí.
No fallan por falta de plugins. Fallan por exceso. Hay dos o tres de traducción instalados, dos de ellos peleándose por el mismo hook (los puntos donde el core deja enganchar código), y el enlace del menú que apunta a /en/about/ se escribió a mano en 2022, cuando el sitio inglés vivía en una carpeta y no en la raíz. Hoy ese enlace devuelve un 404 y el cliente jura que antes funcionaba.
De esto va el artículo: de Huginn, el conmutador que construí para resolver ese clic dentro del core de WordPress y no encima de él. Y de cómo distinguir un plugin que resuelve el problema de uno que solo lo maquilla con un README bien escrito.
En una frase: si tu web está en dos idiomas y el botón de idioma te manda al inicio en vez de a la misma página que estabas leyendo, esto explica por qué pasa y cómo se arregla.
Cómo leerlo: a partir de la mitad hay código, y no hace falta entenderlo para seguir el argumento. Si vienes a decidir y no a programar, lee «Qué resuelve un cambiador de idioma WordPress multisitio (y qué no)», sigue con «Dónde está funcionando hoy» y salta al cierre. Con eso tienes lo que necesitas.
Hay un momento en el que el problema deja de ser molesto y se vuelve caro. Es el día que heredas la red. El sitio en español y el sitio en inglés comparten tema, Elementor y estructura de páginas, y no comparten ninguna relación entre contenidos. La entrada 412 en español y la 413 en inglés son la misma nota, pero WordPress no lo sabe. Lo sabía la persona que las creó, y esa persona ya no trabaja contigo.
Desde ahí, todo lo que se hace a mano se convierte en deuda: el menú con URLs fijas, el botón del header que siempre manda al home del otro sitio, el artículo que sale en español y tres semanas después nadie recuerda que tocaba traducirlo. Nada de eso es un fallo de WordPress. Es lo que pasa cuando la única fuente de verdad sobre la relación entre dos contenidos es la memoria de alguien.
Qué resuelve un cambiador de idioma WordPress multisitio (y qué no)
Conviene separar dos problemas que el mercado mezcla a propósito. Traducir contenido y navegar entre contenidos traducidos son cosas distintas. Un plugin de traducción toma el texto de una entrada y produce otra versión. Un conmutador toma la entrada que el visitante está leyendo y le dice a WordPress cuál es su pareja en el otro sitio.
Cuando la red ya tiene dos sitios reales, cada uno con su tema, sus plantillas de Elementor Pro, su SEO y sus medios, la traducción automática no es lo urgente. Lo urgente es que el botón de idioma no aterrice en el lugar equivocado. Esa parte es la que resuelve Huginn, y la otra la deja en paz a propósito.
Los tres síntomas que delatan una red sin conmutador:
- El botón de idioma lleva siempre al home del otro sitio, sin importar dónde esté el visitante.
- La traducción existe, pero el clic devuelve un 404 porque nadie las vinculó en la base de datos.
- El menú del sitio en inglés tiene URLs del sitio en español escritas a mano, y cada migración las rompe otra vez.
La conversación suele empezar con un mensaje que llega un domingo: «oye, el botón de inglés me lleva al inicio aunque esté leyendo una entrada, ¿eso es normal?». No. Nunca lo fue. Es lo que pasa cuando el enlace del menú se escribe a mano para que dos sitios parezcan uno.
El tercer síntoma es el que más veces he visto pasar por alto. Un menú con URLs fijas funciona el día de la entrega y falla el día que alguien cambia una carpeta, un dominio, o el orden de los sitios en la red. Y como el menú lo revisa poca gente, el fallo aparece cuando el cliente lo reporta por WhatsApp.
Dónde está funcionando hoy
Un cambiador de idioma WordPress multisitio no se prueba con una demo. Se prueba el día que alguien publica una entrada nueva en un sitio y espera que el botón lleve a la pareja correcta del otro. Este ya pasó esa prueba.
It´s P Foundation, fundación sin ánimo de lucro 501(c)(3) con operación en Estados Unidos y Colombia, tiene su sitio bilingüe montado sobre este conmutador. El sitio oficial vive en la raíz, en español, y la versión inglesa en /en/. Cada uno con su propio contenido y sus propias entradas, y a ritmos distintos: lo último publicado en inglés no coincide con lo último publicado en español. No son dos versiones del mismo texto: son dos sitios independientes que se reconocen entre sí.
Eso es lo que se ve en el menú de itspfoundation.org: un elemento «Cambiar idioma» que deja al visitante en la misma sección del otro sitio, no en su portada. Y es la prueba de que el modelo de dos sitios con contenido propio funciona sin añadir una sola tabla a la base de datos.
Lo que este caso no demuestra: no demuestra que el plugin sirva para cinco idiomas, ni que traduzca contenido, ni que resuelva un WooCommerce multilingüe. Demuestra lo único que promete: que el visitante cambia de idioma sin perder la página en la que estaba. Todo lo demás sigue en la lista de lo que no hace.
Cómo está hecho este cambiador de idioma WordPress multisitio
La primera decisión fue no crear ni una sola tabla. Todo el vínculo vive donde WordPress ya guarda metadatos: wp_postmeta, wp_termmeta y wp_usermeta, que son las tablas donde WordPress guarda los datos extra de cada entrada, cada categoría y cada usuario. La clave se genera sola con el ID del sitio de destino, así que una página guarda su pareja en _linked_page_2 y un término en _linked_term_2. Si mañana se elimina el plugin, esos datos quedan intactos y el sitio sigue funcionando sin pantallas blancas.
| Módulo | Clase PHP | Responsabilidad |
|---|---|---|
| Núcleo | Huginn |
Singleton (una sola instancia viva en memoria). Valida que la red sea multisitio al activar, carga las traducciones del plugin y arranca los módulos. |
| Administración | Huginn_Admin |
Detecta los tipos de contenido públicos, pinta los metaboxes (los paneles que aparecen debajo del editor) en ambos sentidos y guarda el vínculo. |
| Enrutamiento | Huginn_Switcher |
Resuelve el permalink equivalente (la dirección de la página pareja en el otro sitio), expone el shortcode [url_idioma] (un texto entre corchetes que WordPress convierte en un enlace) y cachea el resultado. |
| Conector Elementor | Huginn_Elementor |
Añade el selector a los ajustes de documento y sincroniza el vínculo al guardar desde el editor. |
| Usuarios | Huginn_User |
Biografía en dos idiomas con description_es y description_en, filtrada en tiempo de ejecución. |
| Consultas AJAX | Huginn_Ajax |
Busca la traducción en el otro sitio con un nonce (un código de un solo uso que impide que alguien de fuera dispare la consulta), permiso de usuario verificado y validación del destino. |
El ahorro real no está en la cantidad de código, está en las consultas. El resolvedor guarda el resultado en la cache de objetos de WordPress, bajo el grupo huginn, usando wp_cache_set. El segundo clic sobre el mismo botón no vuelve a consultar la base de datos. Y cada cambio de contexto entre sitios se hace con switch_to_blog (la función del core que mueve el contexto a otro sitio de la red) dentro de un bloque try...finally, no con un restore_current_blog suelto al final de la función.
Por qué el try…finally no es un detalle de estilo: switch_to_blog cambia el prefijo de tablas de forma global. Si la petición muere entre el cambio y la restauración, todo lo que se ejecute después lee y escribe en el sitio equivocado, y el fallo aparece tres semanas más tarde en un sitio que nadie tocó. El bloque garantiza la restauración incluso cuando hay una excepción en medio.
La integración con Elementor Pro: el selector donde ya estás mirando
La mayoría de los conmutadores te sacan del editor. Abres la entrada pareja en otra pestaña, copias la URL, vuelves, la pegas. Huginn mete el selector dentro de los ajustes de documento de Elementor Pro, en la pestaña de configuración, y sincroniza el vínculo en el hook elementor/editor/after_save. Traduces, guardas, y la relación queda escrita sin abrir una segunda pestaña. Los hooks del editor están documentados en Elementor Hooks.
Biografía en dos idiomas sin una consulta extra
El detalle que casi nadie resuelve es el autor. En una red bilingüe la misma persona escribe en los dos sitios, y su biografía sale en el idioma equivocado o directamente duplicada. Huginn añade dos campos al perfil, description_es y description_en, oculta el campo nativo que sobra y devuelve el valor correcto interceptando el filtro get_meta_type_metadata. La consecuencia práctica: el widget Author Box de Elementor Pro muestra la biografía que corresponde al sitio que el visitante está leyendo, sin tocar la plantilla y sin consultas adicionales.
Funciona igual con ES o con EN en la raíz
El sitio oficial de una red no siempre es el que vive en la raíz, y las instalaciones bilingües se montan en el orden que se puede. Desde la versión 1.1.0 el plugin deduce el rol de cada sitio desde su ruta real: el que está en la raíz es el oficial, el otro es el traducido. Si inviertes los IDs en los ajustes, todo se invierte con ellos, incluido el respaldo del campo nativo de biografía que leen el RSS y la REST API.
Cómo detectar si un plugin de idiomas está bien hecho
Un plugin mal hecho casi nunca se delata por un error visible. Se delata por patrones, y esos patrones se repiten tanto que acaban siendo una firma: cómo nombra sus clases, qué promete en la descripción del producto, cuántas cosas hace para las que nadie le pidió permiso, y si su documentación apunta a funciones que ya no existen.
Cuando empecé a revisar plugins escritos de un tirón por un modelo, esos patrones aparecían siempre en el mismo orden. Un plugin que presume de arquitectura no tiene una sola prueba. Uno que evita decir qué hace escribe solución integral potente y espera que nadie pregunte. Uno que hace tres cosas para una necesidad llena el menú de ajustes con tres pestañas donde había una sola necesidad. Y un plugin con enlaces rotos es un plugin cuya documentación apunta a funciones que cambiaron de nombre hace dos versiones. Es la misma deuda que describimos al hablar de vibe coding, solo que escondida en el código en vez de en la pantalla.
| Patrón que se repite | Cómo se ve en un plugin | Cómo lo evita Huginn |
|---|---|---|
| Hablar de la importancia antes que del producto | README que promete potencia y transformación antes de decir qué hace | La descripción abre con lo que es: un conmutador de idioma para multisitio |
| Nombres que no dicen nada | Nombres comerciales donde debería haber nombres técnicos | Las clases se llaman como lo que hacen: Switcher, Admin, Ajax, Elementor, User |
| Tres funciones para una necesidad | Tres funciones que hacen lo mismo y ninguna documentada | Un único resolvedor de enlaces, con cache, y los demás módulos lo consumen |
| Documentación que apunta al vacío | Documentación que apunta a funciones que ya no existen | Cada función del core que usa está enlazada a su referencia oficial |
Ese último patrón es el más incómodo y el más útil. Un plugin serio dice lo que no hace. Huginn no traduce contenido, no sincroniza menús y no intenta servir para diez idiomas. Escribirlo en el README cuesta cinco líneas y ahorra una semana de soporte. Un plugin que no sabe decir «esto no lo hago» está diciendo, en realidad, «no lo he probado».
- ¿Crea tablas propias? Si las crea, la desinstalación tiene que decirlo por escrito y cumplirlo. Compruébalo en local antes de creerle al README.
- ¿Qué pasa si lo desactivo un martes cualquiera? Desactívalo, navega diez páginas y mira la consola de errores. Ahí se ve si la promesa de estabilidad es real.
- ¿Cuántas consultas añade a una entrada? Se mide con Query Monitor. No se intuye, no se estima y no se copia de la ficha del producto.
- ¿El enlace de idioma respeta la página actual o siempre devuelve al home? Prueba desde una entrada, no desde la portada.
- ¿Dónde están sus pruebas? Si no hay carpeta de tests, la promesa de estabilidad es una opinión bien redactada.
- ¿Su documentación enlaza a funciones que existen? Un enlace roto en la documentación avisa de cómo está el resto.
Comparativa con las opciones que ya conoces
Comparo por enfoque, y no por precio, porque los precios de los otros cambian cada año y no me los voy a inventar. Lo que sí puedo decir es dónde guarda cada uno la relación entre original y traducción, porque eso decide qué tan caro sale desinstalarlo dos años después.
| Criterio | Huginn | La suite comercial | El de las taxonomías |
|---|---|---|---|
| Problema que resuelve | Navegar entre dos sitios ya construidos | Traducir contenido, menús y comercio | Traducir contenido dentro de un sitio |
| Dónde guarda la relación | En postmeta y termmeta del core |
En 23 tablas propias | En taxonomías del core |
| Añade tablas a la base de datos | No | Sí, 23 por sitio | No |
| Elementor Pro | Selector dentro de los ajustes de documento | Desde el plan de 99 euros al año | Compatibilidad por addon |
| Idiomas | Dos, por diseño | Muchos | Muchos |
El de la traducción visual va por otro camino y merece la pena nombrarlo para que nadie compare peras con manzanas: traduce sobre el editor visual y guarda cada cadena en la base de datos de tu servidor. Sirve muy bien cuando el contenido vive en un solo sitio y quieres verlo traducido sin salir de la página. No sirve para el caso de este artículo, donde hay dos instalaciones con dos temas y dos estructuras.
Cómo leer la tabla: ninguna columna gana en todo, y eso es a propósito. Una cosa es mover al visitante entre dos sitios que ya existen y otra fabricar el contenido del segundo sitio. Comparar el precio de las dos es comparar el precio de un mapa con el de un traductor.
Lo que no aparece en la ficha del producto
Todo cambiador de idioma WordPress multisitio se vende igual: capturas de banderas y la promesa de resolverlo en tres clics. Las tres opciones que cualquiera encuentra al buscar este problema son productos serios. Dos llevan más de una década manteniéndose y la tercera llegó a 400.000 instalaciones en nueve años. Nada de lo que sigue es una acusación de incompetencia: es la lista de costes que no entra en la página de venta.
Las cifras se consultaron el 8 de noviembre de 2026 en el directorio de WordPress.org, en los repositorios públicos y en las páginas de incidencias de cada proyecto. No hay estimaciones mías.
| El dato | Dónde se verifica | Qué implica |
|---|---|---|
| 23 tablas propias | Su documentación de base de datos, actualizada en agosto de 2025 | En una red con cuatro subsitios son 92 tablas nuevas, y el mapa de traducciones vive fuera del core |
| 106 incidencias conocidas sin resolver | Su listado público de incidencias, con «Performance» y «Elementor» entre los filtros | No están ocultas: están reconocidas y pendientes |
| 39 euros al año y aun así sin menús ni page builders | Su tabla de precios | Para traducir Elementor hay que subir al plan de 99. El plan barato no traduce el sitio |
| 30 hilos de soporte, 7 resueltos | Directorio de WordPress.org | Cola abierta hoy en un plugin con 900.000 instalaciones activas |
| 2,4 MB de PHP y 79 incidencias abiertas | Su repositorio público | Una de ellas, de septiembre de 2026, hace que el idioma se equivoque al navegar a una URL traducida |
En soporte la conversación es siempre la misma: «pagué el plan y los menús siguen en español». Sí. Está en su propia tabla de precios, en la fila de menús, con la fórmula not included. El plan barato traduce una parte y te muestra la puerta.
La suite comercial resuelve el multilingüismo completo y lo hace construyendo un modelo de datos paralelo al de WordPress: veintitrés tablas que no existían antes de instalarla. Su equipo publica incluso una guía para optimizar esas tablas cuando el sitio ya ha crecido, lo cual es honesto y a la vez una confesión de arquitectura.
El adverbio que hace todo el trabajo: en sus preguntas frecuentes hay una que se llama, con esas palabras, «¿va esto a ralentizar mi sitio?». La respuesta empieza por «no debería» y sigue ofreciendo la devolución del dinero si el rendimiento se degrada. Ese adverbio y esa garantía dicen más que cualquier comparativa: el coste de rendimiento es lo bastante real como para que la referencia del sector lo aborde en su propia página de ventas.
El de las taxonomías juega en otra liga y conviene decirlo antes de que parezca que lo meto en el mismo saco: no crea ni una sola tabla. Su equipo eligió el camino contrario, apoyarse en las taxonomías del core, y lo presume en la descripción del producto. Su coste es otro: 2,4 MB de PHP y 79 incidencias abiertas en su repositorio. Para una red con dos sitios ya construidos, es un motor diésel para llevar la compra a la esquina.
El de la traducción visual guarda cada cadena traducida en la base de datos de tu servidor y tiene el soporte al día: 33 de 34 hilos resueltos el día que escribo esto. Lo digo porque si te oculto el dato que me contradice, dejas de creerme en todo lo demás.
Huginn tiene 2.594 líneas de PHP contando las pruebas y el empaquetador. Y aquí va la salvedad, porque sin ella la comparación sería trampa: no hacen lo mismo. Un conmutador no traduce contenido, así que el tamaño por sí solo no significa nada. La pregunta correcta no es cuál es más grande, sino cuál resuelve tu problema. Un cambiador de idioma WordPress multisitio es una pieza pequeña, y el resto del multilingüismo es otra factura. Si tu problema es que el botón de idioma aterriza en el home, no necesitas ni 2,4 MB ni veintitrés tablas.
Cuándo esas suites son la respuesta correcta: si necesitas tres idiomas o más, si tienes que traducir el contenido y no solo enlazarlo, o si vendes con WooCommerce en dos monedas, compra una suite y no improvises con un conmutador. Este artículo va de otro problema: dos sitios ya construidos que no saben que son el mismo negocio.
Instalar el cambiador de idioma WordPress multisitio en seis pasos
Requisito previo: esto necesita una red multisitio ya creada. Si todavía no la tienes, la guía oficial es Create a Network, y no hay atajo que salte ese paso.
- Copia la carpeta. Llévala a
wp-content/pluginsy actívala en la red con Network Activate, no sitio por sitio. - Escribe los dos IDs. En Ajustes > Huginn Switcher indica el ID del sitio en español y el del inglés. El panel muestra una tarjeta con la detección automática de roles, así compruebas que acertaste antes de seguir.
- Elige los tipos de contenido. Marca dónde quieres los metaboxes: páginas, entradas, plantillas de Elementor o tus tipos personalizados.
- Vincula la primera pareja. Abre una página en español, busca el metabox Vincular traducción y elige su pareja. Los botones Ver y Editar abren el elemento del otro idioma en una pestaña nueva.
- Coloca el conmutador. Usa el shortcode
[url_idioma]en el elemento de menú, en un botón o en un widget. En Elementor, un widget de shortcode funciona igual. - Prueba desde una entrada y desde una búsqueda. Desde el home funcionan todas las soluciones. La entrada y el resultado de búsqueda son donde se rompen.
Preguntas frecuentes
¿Funciona este cambiador de idioma WordPress multisitio sin Elementor Pro?
Sí. Elementor Pro solo aporta dos cosas: el selector dentro del editor y la sincronización automática al guardar desde el editor visual. Sin él, los metaboxes clásicos de WordPress siguen vinculando páginas, entradas y términos, y el shortcode sigue resolviendo enlaces igual de bien.
¿Puedo usar este cambiador de idioma WordPress multisitio con más de dos idiomas?
No, y es una decisión, no una tarea pendiente. El modelo de datos es un par: cada sitio tiene un sitio pareja. Un tercer idioma obliga a replantear el esquema completo, y prefiero decirte que hoy no existe a prometerte una versión futura que no puedo fechar.
¿Qué pasa si desactivo o elimino el plugin?
El sitio no se cae. Al desactivarlo, WordPress retoma su comportamiento nativo en la siguiente petición. Al eliminarlo, el desinstalador limpia los ajustes de la red y vacía la cache de objetos, y deja intactos los datos de contenido y de usuario. Es la prueba que siempre hago: desactivar, navegar diez páginas y leer la consola.
¿Sincroniza los menús entre los dos sitios?
No. Los menús son nativos de cada sitio y sincronizarlos suele terminar en un menú que muestra entradas que en ese idioma no existen. Lo que sí resuelve son las URLs: el conmutador genera el enlace al elemento pareja, así que colocas el shortcode una vez en el menú y dejas de escribir rutas a mano.
El enlace que nadie quiere escribir a mano
Un idioma mal resuelto no se nota en la demo. Se nota tres meses después, cuando el cliente abre sus dos sitios en paralelo y descubre que la mitad de los enlaces cruzados llevan al home. Para entonces ya nadie recuerda qué entrada era pareja de cuál, y alguien tiene que abrir doscientas entradas para reconstruir a mano lo que un metadato de cuatro líneas habría resuelto.
Huginn es mi respuesta a eso: un cambiador de idioma WordPress multisitio que no inventa tablas, que no deja deuda al desinstalarse y que no promete traducir lo que no traduce. Forma parte de la misma familia que el conector de Google Drive que contamos en RamDrive y el asistente con Gemini que montamos para una fundación, que está en este caso. Si tu red ya existe y el botón de idioma no acierta, sabemos por dónde empezar. Si estás montando la red desde cero, también, y a veces la respuesta honesta es ordenar primero los sitios.
Y si lo que buscas no es el rescate sino la pieza ya construida: Huginn está disponible en la tienda, con licencia GPLv2, sin clave de activación y con las actualizaciones de la serie 1.x.
Recursos externos recomendados
- WordPress: switch_to_blog — la referencia oficial de la función que cambia el contexto entre sitios de la red.
- WordPress: wp_cache_set — cómo guarda WordPress datos en la cache de objetos y cuándo deja de ser gratis.
- WordPress: get_meta_type_metadata — el filtro que permite devolver un metadato sin tocar la base de datos.
- Elementor: hooks del editor y del frontend — el punto de entrada para cualquier integración seria con Elementor Pro.
- WordPress: Create a Network — la guía oficial para crear la red multisitio que todo esto necesita.
Sigue leyendo en el blog
- Archivos RGB en impresión: el mismo problema de criterio técnico, contado desde el taller de artes gráficas.
- Calculadora de corte de papel: otra herramienta propia, hecha para resolver una cuenta que se hacía a mano.
- Todas las herramientas del blog: los plugins, calculadoras y utilidades que hemos publicado.
