WordPress multilingüe sin plugin: Multisite, hreflang y qué tener en cuenta

Montar un WordPress multilingüe sin plugin es posible y, en algunos proyectos, es la opción más limpia. El núcleo de WordPress no trae gestión de traducciones, pero sí Multisite, que permite tener un sitio por idioma dentro de una única instalación. Si añades un pequeño fragmento de código que conecte las traducciones e imprima las etiquetas hreflang, tendrás una web en varios idiomas sin una capa de traducción de terceros. Esta guía explica cómo funciona, muestra un fragmento probado, compara las alternativas y dice con claridad en qué casos un plugin de traducción ahorra más tiempo del que cuesta.

WordPress multilingüe sin plugin: qué hay que resolver

Antes de elegir un enfoque, enumera lo que necesita de verdad una web en varios idiomas. Los plugins de traducción reúnen estas funciones; sin plugin, cada una es tarea tuya:

• Una URL distinta por idioma, como /es/ y /en/, para que cada versión se indexe y se comparta.
• Un vínculo entre traducciones, para que el sistema sepa qué página en inglés corresponde a cada página en español.
• Un selector de idioma que lleve a la página traducida y no a la portada del otro idioma.
• Anotaciones hreflang que indiquen a los buscadores qué versión mostrar a cada usuario.
• Menús, widgets, textos del tema y slugs traducidos, no solo el contenido de las entradas.
• Un flujo editorial que diga quién traduce qué y cómo se detectan las traducciones que faltan.

Cualquier enfoque que cubra estos seis puntos sirve. La cuestión es cuánto esfuerzo cuesta montarlo y mantenerlo, y eso es lo que comparamos en las secciones siguientes.

Opción 1: WordPress Multisite con un sitio por idioma

Multisite convierte una instalación de WordPress en una red de sitios que comparten código, temas y plugins, pero tienen contenido, ajustes y medios propios. Dar a cada idioma su propio sitio es la forma más sólida de ser multilingüe sin plugin de traducción, porque menús, widgets, slugs e idioma del sitio quedan separados por diseño.

Configurar WordPress Multisite paso a paso

1. Haz una copia de seguridad del sitio y de la base de datos antes de cambiar nada.
2. Añade la línea define( 'WP_ALLOW_MULTISITE', true ); en wp-config.php, tal como explica la guía oficial Create A Network.
3. Abre Herramientas, Configuración de la red, y elige subdirectorios (example.com/es/) o subdominios (es.example.com).
4. Copia las líneas de configuración que muestra WordPress en wp-config.php y las reglas de reescritura en .htaccess, y vuelve a iniciar sesión.
5. Crea un sitio por idioma y elige su idioma en Ajustes, Generales.
6. Activa en red el tema y los plugins que necesite cada idioma.

Los subdirectorios mantienen todo en un dominio, lo que suele simplificar el SSL y ayuda a que los buscadores entiendan una única marca. Convertir una web que ya tiene contenido y tráfico exige el mismo cuidado que cualquier migración; nuestra checklist SEO de migración web cubre redirecciones y seguimiento.

Qué ganas y a qué renuncias

Ganas una separación limpia: cada idioma puede tener menús, textos legales o incluso productos distintos, y cada editor trabaja en su idioma sin tocar el otro. Renuncias a comodidad: no hay pantalla de traducción en paralelo, los medios se suben por sitio y los plugins deben ser compatibles con Multisite. Algunos planes de alojamiento limitan Multisite, así que compruébalo antes de empezar.

Vincular traducciones e imprimir hreflang sin plugin

Multisite no sabe que una entrada en español es la traducción de otra en inglés. El vínculo más sencillo y fiable es un valor compartido en un campo personalizado: todas las traducciones de un artículo reciben la misma clave de grupo, por ejemplo en un campo llamado _acme_group. El plugin de red siguiente lee esa clave, busca la entrada correspondiente en cada sitio de idioma e imprime los enlaces hreflang, incluido un x-default que apunta al sitio principal. La documentación de Google sobre versiones localizadas de tus páginas describe las reglas que siguen estas etiquetas.

<?php
/**
 * Plugin Name: Acme Network Hreflang
 * Description: Prints hreflang links between translated posts on a Multisite network with one site per language.
 * Network:     true
 * License:     GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

// Translations of one article share the same value in the "_acme_group" post meta.
add_action( 'wp_head', function () {
	if ( ! is_singular() ) {
		return;
	}
	$group = get_post_meta( get_queried_object_id(), '_acme_group', true );
	if ( '' === $group ) {
		return;
	}

	$links   = array();
	$default = '';
	foreach ( get_sites( array( 'public' => 1, 'number' => 20 ) ) as $site ) {
		switch_to_blog( (int) $site->blog_id );
		$ids = get_posts( array(
			'post_type'      => 'any',
			'post_status'    => 'publish',
			'meta_key'       => '_acme_group',
			'meta_value'     => $group,
			'fields'         => 'ids',
			'posts_per_page' => 1,
			'no_found_rows'  => true,
		) );
		if ( $ids ) {
			$locale = get_option( 'WPLANG' ) ?: 'en_US'; // empty WPLANG means English
			$lang   = strtolower( strtok( $locale, '_' ) );
			$url    = get_permalink( $ids[0] );
			$links[ $lang ] = $url;
			if ( is_main_site() ) {
				$default = $url;
			}
		}
		restore_current_blog();
	}

	if ( count( $links ) < 2 ) {
		return; // one language needs no hreflang
	}
	foreach ( $links as $lang => $url ) {
		printf( '<link rel="alternate" hreflang="%s" href="%s" />' . "\n", esc_attr( $lang ), esc_url( $url ) );
	}
	if ( $default ) {
		printf( '<link rel="alternate" hreflang="x-default" href="%s" />' . "\n", esc_url( $default ) );
	}
} );

Pasamos este mismo archivo por php -l y por un banco de pruebas que simula una red en tres idiomas: imprime cada idioma más x-default, omite los idiomas sin traducción, no imprime nada en entradas de un solo idioma ni en archivos y siempre restaura el contexto del sitio original. Guárdalo en wp-content/mu-plugins o actívalo en red como plugin.

Tres notas prácticas. Primero, el código de idioma se toma del ajuste de idioma de cada sitio, así que es_ES se convierte en es; si ofreces dos variantes de un idioma, como es-ES y es-MX, amplía el código para conservar la región. Segundo, el bucle cambia de sitio en cada petición, algo asumible con pocos idiomas pero que conviene cachear en redes grandes. Tercero, un selector de idioma puede reutilizar la misma búsqueda para enlazar directamente con la página traducida.

Opciones 2 y 3: instalaciones separadas o código propio en un sitio

Instalaciones de WordPress separadas

Cada idioma también puede ser un WordPress totalmente independiente, en un subdirectorio o en su propio dominio. Es la separación más fuerte y funciona en cualquier alojamiento, pero multiplica actualizaciones, copias de seguridad y cuentas de usuario, y vincular traducciones obliga a mantener una tabla de correspondencias a mano o mediante una API. Encaja en organizaciones donde cada equipo de país gestiona su propia web.

Un solo sitio con campos por idioma

En teoría puedes guardar todos los idiomas en un sitio, por ejemplo con campos extra por idioma y un prefijo de URL gestionado con reglas de reescritura. En la práctica crece muy rápido: menús, widgets, búsqueda, slugs, sitemaps, textos del tema y datos de la tienda deben distinguir idiomas. Cuando por fin funciona bien, has escrito tu propio plugin de traducción, sin los años de pruebas de uno consolidado.

Menús, textos del tema y selector de idioma

El contenido de las entradas es solo una parte de una web traducida. En una red Multisite el resto encaja con más facilidad que en un sitio único, pero sigue necesitando un plan:

• Menús y widgets se guardan por sitio, así que cada idioma tiene su propio menú con etiquetas y enlaces traducidos.
• Los textos del tema y de los plugins, como botones, etiquetas de formulario y formatos de fecha, se traducen con archivos de idioma (.po y .mo). WordPress carga automáticamente el archivo correcto según el idioma de cada sitio, siempre que el tema incluya una traducción o se le añada.
• Los slugs se definen por entrada; URL traducidas como /es/servicios/ son lo natural y conviene usarlas en lugar de copiar el slug original.
• El selector de idioma va en la plantilla de cabecera. Puede reutilizar la misma búsqueda por clave de grupo que el código de hreflang y recurrir a la portada del otro idioma solo cuando no exista traducción.

Decide pronto cómo se comporta el selector cuando falta una traducción. Ocultar el idioma que no tiene página equivalente suele ser más claro para el visitante que enviarlo a una portada que no ha pedido. Lo mismo vale para los sitemaps: cada sitio de idioma tiene el suyo y solo debe incluir páginas que existan de verdad en ese idioma.

Flujo editorial: mantener las traducciones al día

Sin plugin no hay un panel que marque las traducciones desactualizadas, así que conviene acordar una rutina ligera:

1. Asignar la clave de grupo al publicar el artículo original, aunque la traducción aún no exista.
2. Mantener un resumen sencillo de claves de grupo e idiomas disponibles, por ejemplo una hoja de cálculo o un pequeño informe en el escritorio.
3. Cuando cambie el original, anotar la fecha en ese resumen para que los traductores sepan qué versiones revisar.
4. Pedir a un hablante nativo que revise títulos, descripciones y slugs, porque es lo primero que ve quien busca.
5. Comprobar la salida de hreflang de algunas páginas tras cada publicación, sobre todo después de actualizar el tema o los plugins.

Esta rutina lleva unos minutos por artículo y evita el problema más habitual de las webs multilingües: que un idioma se quede atrás en silencio mientras los demás se actualizan. Si el número de idiomas crece, el resumen se convierte fácilmente en un informe del escritorio, porque la clave de grupo ya está en cada entrada.

Cuándo conviene un plugin de traducción

El camino sin plugin encaja cuando el contenido cambia de un idioma a otro, cuando equipos distintos gestionan cada idioma o cuando quieres control total sobre cada URL. Un plugin suele ser mejor cuando el mismo contenido se traduce uno a uno, cuando los editores quieren traducir en paralelo o cuando una tienda WooCommerce necesita productos, precios y checkout traducidos. Nuestro propio plugin AYM Multilingual existe justo para ese segundo grupo, y montamos y mantenemos ambos tipos de configuración en nuestro servicio de WordPress multilingüe.

Elijas el camino que elijas, la parte de buscadores funciona igual: URL separadas, hreflang recíproco y metadatos traducidos por completo. Nuestra guía de SEO multilingüe y hreflang explica esas reglas y los errores que más a menudo las rompen.

Compartir:XLinkedInWhatsApp