¿Por qué entran en conflicto las versiones de idioma durante la optimización de hreflang?

El “conflicto entre versiones de idioma” en las anotaciones hreflang normalmente no significa que el código no pueda ser leído por los motores de búsqueda, sino que un mismo conjunto de páginas transmite señales contradictorias de idioma, región, canonicalización e indexabilidad. Como resultado, los motores de búsqueda tienen dificultades para determinar qué URL debe servirse para un determinado idioma o mercado, pueden elegir una versión incorrecta para el posicionamiento o ignorar directamente parte de las relaciones hreflang.

La revisión técnica no puede limitarse a comprobar si la página contiene rel="alternate". Lo que realmente determina si la optimización de hreflang es válida es si la accesibilidad de la URL, las relaciones bidireccionales, la orientación lingüística y regional, el destino canonical y el contenido real de la página pueden formar una misma lógica.

La esencia del conflicto: varias URL compiten por la misma orientación de usuario

Un conjunto hreflang válido debe asignar una URL indexable única a cada combinación específica de idioma o idioma-región. Por ejemplo:

• en: página general en inglés para usuarios angloparlantes;
• en-US: página en inglés dirigida al mercado estadounidense;
• en-GB: página en inglés dirigida al mercado británico;
• zh-CN: página en chino simplificado dirigida a usuarios de China continental;
• x-default: versión predeterminada o página de selección de idioma para los casos sin coincidencia.

El conflicto se produce cuando dos o más URL se etiquetan para la misma audiencia sin una relación de prioridad clara. Por ejemplo, /en/ y /us/ se etiquetan ambas como en-US; o bien una misma página en inglés se declara simultáneamente como la única página alternativa para en, en-US y en-GB. Los motores de búsqueda no deducen la prioridad a partir de la nomenclatura interna de directorios de la empresa; solo evalúan si las declaraciones de la página, el contenido, el canonical y el estado de rastreo son coherentes.

Por tanto, /us/, /uk/ en la ruta de directorios o los dominios de nivel superior de país no equivalen automáticamente a una orientación regional correcta. La ruta puede expresar una estrategia de implementación, pero no sustituye un código de idioma hreflang válido.

Los conflictos más habituales proceden de cuatro tipos de incoherencia de señales

Una página apunta a varias páginas canonical diferentes

hreflang y canonical tienen funciones distintas. hreflang se utiliza para identificar versiones equivalentes dirigidas a usuarios de diferentes idiomas o regiones; canonical se utiliza para gestionar la URL preferida cuando el contenido es muy duplicado. No deben sustituirse mutuamente.

Un error típico es que la página en inglés de Estados Unidos /en-us/product-a/ se declare como en-US en hreflang, pero su canonical apunte a la página general en inglés /en/product-a/. Esto hace que el motor de búsqueda reciba dos mensajes conflictivos: uno afirma que la página es una versión independiente para Estados Unidos y el otro indica que solo es una copia duplicada de otra URL. Si la página tiene realmente un valor independiente para ese mercado, el canonical normalmente debe ser autorreferente; si de hecho no cuenta con contenido independiente ni significado de servicio propio, no debe recurrirse a hreflang para presentarla como una versión regional.

Debe prestarse especial atención a las URL con parámetros, URL con diferencias entre mayúsculas y minúsculas, versiones con barra final, versiones HTTP/HTTPS y páginas de destino publicitarias con parámetros de seguimiento. Si hreflang no apunta a la URL canonical final, la relación de idioma se establecerá sobre una dirección inestable.

Faltan enlaces de retorno y el conjunto de idiomas está incompleto

Las relaciones hreflang deben formar un circuito cerrado verificable. Si la página A declara que B es su versión en francés, la página B también debe declarar que A es la versión correspondiente en chino, inglés u otro idioma, e incluir una referencia a sí misma. Si la página en inglés enumera diez versiones de idioma, pero la página en francés solo enumera su propia versión y la página en inglés sin incluir las demás versiones, los motores de búsqueda no podrán identificar de forma estable estas páginas como un mismo conjunto completo.

Este tipo de problema suele aparecer cuando las plantillas se lanzan por lotes, la configuración multisitio del CMS no está sincronizada o las páginas traducidas se añaden posteriormente. Cuando hay muchas páginas, una simple revisión puntual del código fuente no es fiable; se debe realizar una verificación masiva por plantilla de página, directorio de idioma y reglas de asignación de URL.

Los códigos de idioma son válidos, pero la orientación comercial se solapa

Que el código de idioma sea correcto no significa que la orientación sea razonable. en es inglés general y en-US es inglés de Estados Unidos; pt es portugués general y pt-BR es portugués de Brasil. Las páginas de idioma general pueden coexistir con las páginas regionales, siempre que la función de cada página esté claramente definida.

Por ejemplo, un sitio conserva simultáneamente en, en-US y en-GB, pero los precios, unidades, datos de contacto, zonas de entrega, ortografía y contenido de las tres páginas son completamente idénticos. Aunque técnicamente pueden etiquetarse, carecen de una base de diferenciación comercial. En este caso, el problema no se limita a hreflang, sino que el sitio ha creado artificialmente varias URL que compiten por demandas de búsqueda similares.

A la inversa, si una página regional utiliza un código incorrecto, también dejará de ser válida. La parte de idioma de hreflang debe utilizar códigos de idioma ISO 639-1, y la parte regional debe adoptar códigos de país o región ISO 3166-1 Alpha-2, con el idioma primero y la región después, como de-DE y ja-JP. Los códigos inexistentes, el uso de nombres de idioma en lugar de códigos o colocar el código de país delante causarán problemas de análisis.

La propia página no es indexable, pero se incluye como versión de idioma

La URL de destino a la que apunta hreflang debe devolver una página válida que pueda rastrearse normalmente. Si la página de destino presenta una redirección, 404, soft 404, error 5xx, noindex, bloqueo de rastreo mediante robots.txt o requiere inicio de sesión, la relación de idioma difícilmente surtirá efecto aunque esté escrita en el código fuente.

Un caso más oculto es la redirección geográfica: cuando un usuario o rastreador visita la página general en inglés, el servidor lo redirige automáticamente a la página de Estados Unidos según la IP; y la página de Estados Unidos vuelve a apuntar a la página general en inglés mediante hreflang. Las redirecciones automáticas pueden interferir en el rastreo y en la elección autónoma del usuario, y fácilmente hacen que la orientación de la página no coincida con la declaración de la anotación. Las recomendaciones regionales pueden implementarse mediante una barra de aviso, un selector o enlaces claros; no conviene anular forzosamente la URL de acceso del visitante y del motor de búsqueda.

HTML, HTTP Header y Sitemap no deben generar tablas de versiones contradictorias

hreflang puede proporcionarse mediante HTML<head>, encabezados de respuesta HTTP o XML Sitemap. Para páginas web convencionales, las anotaciones HTML son más fáciles de verificar; para archivos no HTML puede considerarse HTTP Header; cuando hay un gran número de URL, Sitemap facilita la gestión centralizada. Independientemente del método utilizado, la clave no es “colocarlo en más sitios”, sino usar la misma asignación de URL en cada uno.

Si en HTML se etiqueta /fr/ como fr-FR, pero en Sitemap la misma URL se etiqueta como fr-CA, no aumentará la cobertura, sino que generará un conflicto de orientación inexplicable. A nivel de ingeniería, las relaciones entre versiones de idioma deben tratarse como datos estructurados y generarse a partir de una tabla de asignación unificada, en lugar de que distintos equipos las mantengan por separado en plantillas, plugins y Sitemap.

Durante la revisión, primero debe confirmarse la “identidad” de la página y después comprobar las etiquetas

El orden de comprobación efectivo debe comenzar por la identidad de la URL y no por fragmentos de código. Primero se determina si cada página tiene un público de servicio independiente por idioma o región; después se confirma que cada público solo tenga una URL canonical indexable; a continuación se verifican el canonical autorreferente de esa URL, el estado HTTP, las directivas robots y el contenido de la página; por último, se comprueba si todas las versiones alternativas se referencian mutuamente dentro del mismo conjunto.

En los sitios web B2B multilingües, las páginas de producto, páginas de categoría, páginas de soluciones y páginas de destino de consultas suelen tener distintos alcances de cobertura de versiones. Las páginas que no tienen contenido en francés no necesitan inventar hreflang en francés por una apariencia de integridad; si algunas regiones solo comparten contenido en inglés, tampoco es necesario copiar una URL en inglés para cada país. El valor de hreflang radica en eliminar ambigüedades reales entre versiones existentes, no en etiquetar todos los directorios de mercado.

Cuando las versiones de idioma entran en conflicto, se debe dar prioridad a eliminar la orientación duplicada, corregir el canonical y la URL final, completar las referencias bidireccionales y, después, unificar la fuente de asignación en HTML o Sitemap. Solo cuando el contenido de la página, la ruta de acceso y las señales de búsqueda apuntan a una misma definición de versión, hreflang puede desempeñar su función de coincidencia regional sin convertirse en una nueva fuente de indexación incorrecta y dispersión del tráfico.