Cómo implementar etiquetas hreflang para WordPress multilingüe
Has traducido todo tu sitio de WordPress a seis idiomas. Los archivos .po están limpios, los archivos .mo están compilados, cada cadena se muestra perfectamente en francés, alemán y japonés. Sin embargo, semanas después del lanzamiento, revisas Google Search Console y encuentras algo desconcertante: tu página en francés está posicionando para consultas en alemán, tu página en español de México se está sirviendo a usuarios en España, y dos de tus versiones de idioma se están canibalizando silenciosamente en los rankings. El contenido está bien. El problema es que Google no tiene idea de qué versión pertenece a qué audiencia.
Esto es exactamente lo que las etiquetas hreflang WordPress están diseñadas para solucionar. Hreflang es la señal que les dice a los motores de búsqueda qué idioma y versión regional de una página deben servir a cada usuario. Si lo haces mal, sufres dilución por contenido duplicado, resultados en idioma incorrecto y un presupuesto de rastreo desperdiciado. Si lo haces bien, cada página traducida llega a la audiencia para la que fue escrita. Esta guía cubre la sintaxis, la diferencia entre códigos de idioma y de idioma-región, el x-default obligatorio, la reciprocidad de las etiquetas de retorno y tres formas prácticas de implementarlo en WordPress.
Qué hace realmente hreflang
Hreflang no traduce nada. Es un mapa de relaciones. Cuando tienes la misma página en varios idiomas, las anotaciones hreflang le dicen a Google "esta URL es la versión en inglés, esta es la versión en alemán, esta es para hablantes de español en México". Google utiliza ese mapa para servir la versión correcta en los resultados de búsqueda basándose en la configuración de idioma y la ubicación del usuario.
La anotación reside en la <head> de tu HTML como un conjunto de elementos <link>. Cada elemento nombra una página de destino y el idioma (y opcionalmente la región) que atiende. Aquí hay un conjunto correcto de etiquetas hreflang para una página disponible en inglés de EE. UU., inglés del Reino Unido y español de México, con una alternativa predeterminada:
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />
Cada página del conjunto debe generar este mismo bloque, listando cada alternativa, incluyéndose a sí misma. Este último punto confunde a la mayoría de las personas, y volveremos a él.
Por qué esto es importante para el SEO
Sin hreflang, Google trata tus páginas traducidas como casi duplicados que compiten por las mismas palabras clave. El resultado es la dilución: las señales de clasificación se dividen entre las versiones en lugar de consolidarse. Con un hreflang correcto, cada versión hereda la autoridad del conjunto en su totalidad y aparece ante los buscadores adecuados. Esta es una de las acciones de SEO de mayor impacto que un sitio multilingüe puede realizar, y complementa en lugar de reemplazar la traducción real del contenido en tus archivos .po. Cubrimos el aspecto del contenido en profundidad en nuestra guía sobre cómo la traducción de archivos PO afecta las clasificaciones de Google.
Códigos de idioma vs. códigos de idioma-región
¿Cuál deberías usar, en o en-GB? Usa el código más sencillo y que sea verdadero. Si tu contenido en inglés es genérico y no mantienes versiones separadas para el Reino Unido y América, usa solo en. Solo añade una subetiqueta de región cuando realmente ofrezcas contenido diferente a países diferentes.
Los valores de Hreflang siguen el formato idioma o idioma-región. La parte del idioma es un código ISO 639-1 (en, es, de, pt). La región opcional es un código de país ISO 3166-1 Alfa 2 (US, GB, MX, BR). Así que:
enapunta a todos los hablantes de inglés, independientemente del país.en-GBapunta a los hablantes de inglés en el Reino Unido.esapunta a todos los hablantes de español.es-MXapunta específicamente a los hablantes de español en México.
Un detalle crítico: la subetiqueta de región es un país, no una variante de idioma. es-MX no significa "dialecto español mexicano", significa "español, mostrado a usuarios en México". Google lo sigue sirviendo basándose en la ubicación del usuario. Si mantienes dialectos regionales en tus traducciones, el código de región es cómo los diriges. Profundizamos en el aspecto lingüístico de esto en nuestra guía sobre variantes regionales de español y portugués.
Un ejemplo incorrecto común
Aquí hay un bloque hreflang incorrecto que vemos constantemente:
<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />
Tres errores. en-uk no es válido porque el código de país para el Reino Unido es GB, no UK. sp no es un código de idioma; el español es es. Y pt-PT_BR mezcla dos regiones con un guion bajo que no tiene significado en hreflang. Los motores de búsqueda ignoran silenciosamente los valores malformados, por lo que no obtienes ningún error ni beneficio, solo horas de depuración preguntándote por qué nada cambió.
Ten en cuenta que hreflang usa un guion (en-GB), mientras que los archivos de localización de WordPress usan un guion bajo (en_GB). No copies los códigos de nombre de archivo de tus .po directamente en las etiquetas hreflang.
El x-default y la reciprocidad de las etiquetas de retorno
Dos reglas causan más fallos silenciosos de hreflang que cualquier otra cosa: el x-default ausente y la reciprocidad rota.
El valor x-default le dice a Google qué página servir cuando ningún otro idioma coincide con el usuario. Es tu alternativa, típicamente tu selector de idioma o tu página de inicio para el mercado principal. No es estrictamente obligatorio según la especificación, pero en la práctica siempre debes incluirlo. Sin él, un visitante de habla portuguesa para quien no tienes una versión en portugués obtiene un resultado aleatorio en lugar de un valor predeterminado intencional.
La reciprocidad de las etiquetas de retorno no es negociable. Cada página en un conjunto hreflang debe apuntar de vuelta a todas las demás páginas, incluyéndose a sí misma. Si tu página en inglés lista el alemán como alternativa, tu página en alemán debe listar el inglés como alternativa. Si la página en alemán omite la referencia de retorno, Google desconfía de toda la relación e ignora las anotaciones.
<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
La autorreferencia (de apuntando a la página en alemán mientras se visualiza la página en alemán) es obligatoria, no opcional. Un conjunto de cinco versiones de idioma significa que cada una de las cinco páginas genera las cinco etiquetas <link> más x-default.
Tres formas de implementar hreflang en WordPress
Tienes tres opciones prácticas, que van desde el control manual completo hasta la automatización total.
Método 1: Manual a través de wp_head
Para un pequeño conjunto estático de páginas, puedes inyectar etiquetas hreflang directamente a través de la acción wp_head en el archivo functions.php de tu tema:
add_action( 'wp_head', function () {
if ( ! is_page( 'pricing' ) ) {
return;
}
$alternates = array(
'en-US' => 'https://example.com/en-us/pricing/',
'es-MX' => 'https://example.com/es-mx/pricing/',
'x-default' => 'https://example.com/pricing/',
);
foreach ( $alternates as $lang => $url ) {
printf(
'<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
esc_attr( $lang ),
esc_url( $url )
);
}
} );
Esto te da un control preciso pero no es escalable. Mantener la reciprocidad manualmente en cientos de publicaciones es una trampa de mantenimiento.
Método 2: Un plugin multilingüe
Si utilizas Polylang, WPML o TranslatePress, hreflang se genera automáticamente basándose en tus relaciones de traducción. Esta es la respuesta correcta para la mayoría de los sitios porque el plugin ya sabe qué publicación es la traducción de cuál, por lo que la reciprocidad y el x-default se manejan por ti. El costo es la sobrecarga de tiempo de ejecución que estos plugins añaden, que es la compensación que examinamos en nuestra comparación de enfoques de traducción manual versus IA.
Método 3: Mapa del sitio XML con xhtml:link
En lugar de colocar hreflang en la <head> de cada página, puedes declarar las relaciones en tu mapa del sitio XML utilizando el espacio de nombres xhtml:link. Cada entrada <url> lista todas sus alternativas de idioma:
<url>
<loc>https://example.com/en/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>
Esto mantiene el HTML de tu página ligero y centraliza el mapa de idiomas en un archivo rastreable, que Google lee con gusto. La mayoría de los plugins SEO pueden generarlo automáticamente.
hreflang complementa la traducción, no la reemplaza
Aquí está el punto que todos pasan por alto: hreflang no tiene valor si las páginas subyacentes no están realmente traducidas. La etiqueta le dice a Google "esta es la versión en alemán", pero si la URL en alemán todavía muestra cadenas de plugin en inglés, etiquetas de pago sin traducir o archivos .po a medio terminar, simplemente le has dicho a Google que sirva contenido roto a los usuarios alemanes con total confianza.
El SEO multilingüe real tiene dos capas. La capa de contenido son tus archivos .po, .pot, .json y .xliff traducidos, que llevan cada cadena de tema y plugin al idioma objetivo. La capa de señal es hreflang, que dirige cada versión terminada a su audiencia. Ambas deben ser sólidas. Un conjunto hreflang impecable sobre un sitio traducido al 40 por ciento solo garantiza una peor experiencia más rápidamente.
Aquí es donde mantener limpia la capa de traducción es lo más importante. Cuando traduces tus archivos de interfaz, los marcadores de posición como %s, %1$s y {name} deben permanecer intactos, o tu página alemana "traducida" se renderizará con tokens %s literales que parecerán rotos tanto para los usuarios como para los motores de búsqueda. Un pipeline de traducción compatible con gettext con Bloqueo de Sintaxis protege esos tokens automáticamente, de modo que cada página alternativa a la que apuntas con hreflang esté realmente lista para producción. Debido a que se ejecuta en la nube con Agrupación Inteligente, puedes pasar un sitio multilocal completo a través de él sin instalar plugins de traducción que inflan el tiempo de ejecución que sirve esas mismas páginas.
Primero, asegúrate de que el contenido sea correcto, y luego deja que hreflang haga su trabajo. Ambos juntos son lo que consolida las señales de clasificación, elimina los resultados en idiomas incorrectos y coloca cada página traducida frente a las personas que pueden leerla.
¿Listo para corregir los resultados de búsqueda en idioma incorrecto desde la fuente? Prueba SimplePoTranslate gratis — no se requiere tarjeta de crédito. Traduce tus archivos
.po,.poty.jsonen el nivel gratuito, y luego apunta tus etiquetas hreflang a páginas que estén realmente listas para cada mercado.