Errores comunes de hreflang en WordPress multilingüe

Por qué hreflang se rompe tan a menudo en WordPress

Hreflang depende de un conjunto completo de URL de idiomas recíprocas. En WordPress, ese conjunto suele ensamblarse a partir de relaciones de contenido, estructuras de enlaces permanentes y el sistema que almacena la asignación de idioma. Si cualquier parte de esa cadena cambia sin actualizar las demás, las alternativas dejan de describir el mismo conjunto de contenido.

Por eso muchos fallos no se ven como páginas rotas. La página sigue cargando, pero los motores de búsqueda reciben señales contradictorias: una URL dice que es la versión en inglés, otra apunta a un slug distinto y una tercera versión puede ya no ser indexable o puede canonicalizar hacia otro lugar. El resultado es un problema de relaciones, no solo de marcado.

Enlaces de retorno que faltan

Un conjunto de hreflang debe ser recíproco. Si la página en francés apunta a la página en inglés, la página en inglés debe apuntar de vuelta a la página en francés y a todas las demás alternativas válidas del conjunto.

En WordPress, los enlaces de retorno suelen fallar cuando una traducción se publica más tarde, cuando una plantilla solo muestra alternativas en algunos tipos de entrada o cuando existe una relación de idioma en una dirección pero no en la otra. Esto crea un grafo incompleto: los motores de búsqueda pueden ver que una página declara alternativas, pero no pueden verificar el conjunto completo desde cada miembro.

La consecuencia operativa es que un solo enlace recíproco que falte puede debilitar todo el clúster. El problema es especialmente fácil de pasar por alto cuando los editores de contenido actualizan solo una versión de idioma y asumen que la relación sigue intacta.

Asignaciones incorrectas de idioma o configuración regional

Un fallo común es confundir códigos de idioma, variantes regionales o etiquetas del sitio. El valor de hreflang debe describir el idioma real o el destino de idioma-región, no la etiqueta del menú ni la convención interna de nombres del sitio.

En WordPress, esto suele aparecer cuando un sitio tiene varias variantes de inglés, o cuando una traducción se asigna a la relación de configuración regional equivocada después de una migración de contenido. La página puede estar completamente traducida, pero si la asignación indica el idioma o la región incorrectos, la señal se vuelve engañosa.

Esto importa porque hreflang se usa para distinguir versiones estrechamente relacionadas. Si la asignación es incorrecta, los motores de búsqueda pueden tratar la página equivocada como la mejor coincidencia para el idioma o la región de un usuario, aunque el contenido en sí sea correcto.

Conjuntos de URL incoherentes entre versiones de idioma

Cada página de un clúster hreflang debería referenciar el mismo conjunto de alternativas. Si la página en inglés enumera inglés, francés y alemán, pero la página en alemán enumera solo alemán e inglés, el conjunto es incoherente.

Esto suele ocurrir cuando las relaciones de idioma se mantienen manualmente, cuando una plantilla se reutiliza en tipos de entrada con distinta cobertura de traducción o cuando algunas páginas se excluyen de la salida de alternativas porque no tienen una traducción coincidente. El problema no es simplemente que falte una URL; es que el clúster ya no describe un conjunto estable y compartido.

Para quienes implementan WordPress, la pregunta práctica es si la lista de alternativas se deriva de la relación de contenido actual o si está codificada de forma fija por plantilla. Las listas codificadas se desvían en cuanto se añade, elimina o despublica una traducción.

Destinos no indexables

Hreflang debe apuntar a URL que los motores de búsqueda puedan indexar. Si un destino está bloqueado, marcado como noindex, no disponible o de otro modo no es apto para indexación, no puede servir como alternativa fiable.

En WordPress, esto puede ocurrir cuando una página traducida sigue en borrador, está protegida, excluida por la configuración del sitio o se renderiza mediante una ruta que no está pensada para indexarse. También puede ocurrir cuando existe una traducción en el sistema de contenido, pero la URL pública no es realmente accesible.

El modo de fallo es sutil: la relación parece completa en el CMS, pero el destino no puede participar en la indexación de búsqueda. Eso significa que la señal de hreflang apunta a una página que no puede cumplir su función en el clúster.

Redirecciones dentro del conjunto hreflang

Hreflang debería referenciar la URL de destino final y canónica en lugar de una URL que redirige de inmediato. Las redirecciones añaden otra capa de interpretación y pueden ocultar qué URL pretende representar la versión de idioma.

En WordPress, las redirecciones suelen aparecer después de cambios en enlaces permanentes, actualizaciones de slugs o ajustes de enrutamiento específicos por idioma. Si la salida de hreflang sigue usando la URL antigua, la relación apunta a un objetivo en movimiento. Si la cadena de redirección cambia más adelante, el conjunto hreflang puede degradarse silenciosamente.

La compensación de ingeniería es clara: las redirecciones son útiles para conservar enlaces antiguos, pero hreflang debe mantenerse en las URL de destino estables. De lo contrario, el grafo de idiomas y la capa de enrutamiento se separan.

Conflictos de canónicas

Una URL de hreflang y su señal canónica deben coincidir en qué página representa el contenido. Si una página traducida canonicaliza hacia una versión en otro idioma, las señales entran en conflicto.

Esto puede ocurrir cuando la lógica canónica se hereda de una plantilla, cuando una capa de datos propiedad de un plugin genera alternativas pero el tema o la capa SEO genera una canónica distinta, o cuando una relación de contenido se copia de un idioma a otro sin ajustar el destino canónico. El resultado es que un sistema dice: “esta es la página en francés”, mientras otro dice: “la página en inglés es la versión preferida”.

Ese conflicto puede hacer que hreflang sea menos fiable porque los motores de búsqueda reciben dos instrucciones en competencia sobre la misma URL. El patrón más seguro es la coherencia: cada página de idioma indexable debería canonicalizarse a sí misma salvo que exista una razón deliberada y documentada para no hacerlo.

Relaciones obsoletas tras cambios de contenido

Los cambios de contenido en WordPress no siempre conservan automáticamente las relaciones de idioma. Un cambio de slug, la eliminación de una traducción, la duplicación de una entrada o una fusión de contenido pueden dejar referencias obsoletas en metadatos de entrada, campos personalizados o datos de relación propiedad del plugin.

Este es uno de los fallos a largo plazo más comunes porque el sitio pudo haber sido correcto en el lanzamiento. Con el tiempo, los editores actualizan un idioma, mueven una página o retiran una traducción, pero el conjunto de alternativas no se reconstruye. Entonces la salida de hreflang anuncia URL que ya no pertenecen juntas.

El riesgo operativo es acumulativo. Cuanto más a menudo cambia el contenido, más probable es que el grafo de idiomas quede parcialmente desactualizado, a menos que el sistema regenere las relaciones a partir de la fuente de verdad actual.

Cómo suelen aparecer estos fallos en WordPress

La mayoría de los problemas de hreflang en WordPress provienen de un desajuste entre el estado del contenido y el estado de salida. El CMS puede saber qué entradas son traducciones, pero la página renderizada, la etiqueta canónica, la capa de redirección o la estructura de enlaces permanentes pueden ya no reflejar esa relación.

Por eso quienes implementan deben pensar en términos de dependencias: la relación de traducción, la URL pública, la indexabilidad del destino y el destino canónico deben coincidir. Si una capa cambia sin las demás, el clúster hreflang se vuelve incoherente aunque el marcado en sí sea sintácticamente válido.