Cómo solucionar los errores frecuentes en las etiquetas hreflang de sitios multilingües

Los errores recurrentes en las etiquetas hreflang de un sitio multilingüe a menudo no se deben simplemente a que «se escribió mal una línea de código». Afectan directamente a si los motores de búsqueda pueden mostrar la versión correcta de idioma o región al usuario adecuado: una página en inglés puede mostrarse a usuarios alemanes, un sitio de un país puede ser sustituido por el sitio principal o, aunque una página ya esté indexada, puede no obtener tráfico orgánico del mercado objetivo durante mucho tiempo.

Al abordar este tipo de problema, no se apresure a corregir uno por uno los errores de Search Console. Un enfoque más eficaz consiste en confirmar primero la arquitectura lingüística del sitio, comprobar después si las relaciones entre etiquetas forman un ciclo completo y, por último, descartar conflictos entre las URL, las redirecciones y el estado de indexación. Muchos errores aparentemente independientes se originan en realidad en un mismo problema estructural.

Primero determine: ¿sus páginas realmente necesitan hreflang?

hreflang es adecuado para páginas con contenidos altamente equivalentes, pero dirigidas a usuarios de distintos idiomas o regiones. Por ejemplo, un mismo equipo industrial tiene páginas de detalles en inglés, francés y español; o una misma página de producto ofrece diferentes monedas, instrucciones de envío o información de cumplimiento normativo para Estados Unidos, Reino Unido y Australia.

Si solo se ha añadido un complemento de traducción automática a una página en chino, el contenido no cuenta con URL independientes y estables, o las páginas en distintos idiomas redirigen en realidad a la misma dirección, añadir hreflang normalmente no resolverá el problema. Los motores de búsqueda deben poder rastrear, acceder e indexar cada versión para comprender su relación como versiones alternativas.

Especialmente en los sitios B2B de comercio exterior, un error común es dirigir todas las versiones lingüísticas a la página de inicio, o hacer que cada página de detalles de producto solo etiquete la versión lingüística de la página principal. hreflang debe basarse en una relación «página a página»: la página en inglés del producto A debe enlazarse con las páginas en alemán, francés o japonés del producto A, en lugar de vincularse de forma general a las páginas de inicio de cada idioma.

El error más común: las referencias recíprocas no forman un ciclo completo

hreflang es una relación bidireccional e incluso multidireccional. Supongamos que una página en inglés declara una página en alemán como versión alternativa; la página alemana también debe declarar recíprocamente la página inglesa. Si existen además versiones en francés e italiano, cada página participante debe declarar un conjunto completo y coherente de versiones. Añadir etiquetas solo a la página en el idioma principal sin enlaces de retorno desde las demás páginas lingüísticas es uno de los problemas más frecuentes.

Un grupo de páginas válido suele incluir tres niveles de relación:

• Cada página declara su propia versión lingüística, es decir, un hreflang autorreferencial;
• Cada página apunta a las versiones en otros idiomas o regiones del mismo contenido;
• El conjunto de URL enumerado por todas las páginas del mismo grupo se mantiene coherente.

Por ejemplo, las páginas de producto en inglés, alemán y francés pertenecen al mismo grupo. La página inglesa enumera EN, DE y FR; la página alemana también enumera EN, DE y FR; y la página francesa hace lo mismo. Los códigos de idioma pueden ser distintos, pero el conjunto de páginas al que apuntan no debe presentar omisiones propias ni mezclar otras páginas.

Algunos CMS, al añadir un nuevo idioma, actualizan solo la página actual y las páginas de los idiomas existentes no generan de forma sincronizada los nuevos enlaces. En otros sitios, tras migrar el dominio o ajustar las reglas de URL, el hreflang del mapa del sitio ya se ha actualizado, pero las etiquetas head de las páginas conservan las direcciones antiguas. Todo ello puede provocar problemas de «falta de enlace de retorno» o «imposibilidad de confirmar la página alternativa».

Que el código de idioma sea correcto no significa que el código de región también lo sea

Los valores de hreflang suelen utilizar códigos de idioma y, cuando es necesario, códigos de región, por ejemplo en, de, fr-CA y es-MX. El problema suele surgir al confundir idioma, país y mercado.

Una página en alemán dirigida a usuarios de Alemania puede utilizar de-DE, mientras que una dirigida a Austria puede utilizar de-AT. Sin embargo, si el contenido, los precios y los métodos de entrega de ambas páginas son exactamente iguales y las páginas solo se duplican para cubrir distintos países, separar forzosamente varias versiones regionales no necesariamente aporta beneficios; por el contrario, aumenta la complejidad del mantenimiento y de la evaluación de contenido duplicado.

Por el contrario, si las páginas en inglés atienden por separado a Estados Unidos y al Reino Unido, y difieren en moneda, unidades de medida, condiciones de servicio o datos de contacto, deben utilizarse claramente en-US y en-GB. Etiquetar únicamente en tampoco es un error, pero expresa una versión general «aplicable a todos los usuarios de habla inglesa» y no permite diferenciar con precisión las versiones regionales.

A nivel de código, deben evitarse formatos inventados, como usar en-UK para representar el inglés británico. Los códigos de idioma y región deben cumplir las normas y mantenerse uniformes en todo el sitio. Para una versión de respaldo cuando no se puede determinar el idioma o la región del usuario, se puede utilizar x-default, que normalmente apunta a una página de selección de idioma o a una página global predeterminada. No puede sustituir a versiones lingüísticas específicas, y mucho menos deben todas las páginas apuntar únicamente a x-default.

Cuando los errores se repiten, priorice comprobar si la URL se puede indexar

Los motores de búsqueda no aceptan URL de hreflang «aparentemente existentes pero realmente inutilizables». Cada dirección de la etiqueta debe devolver una página oficial accesible, no una página de redirección, una página 404, una página bloqueada para el rastreo por robots o una página con noindex.

Las siguientes situaciones son especialmente frecuentes en sitios multilingües:

• hreflang aún utiliza direcciones http, pero el sitio ya se ha migrado completamente a HTTPS;
• La URL contiene parámetros de sesión, seguimiento o filtrado, mientras que canonical apunta a otra dirección;
• Después de que un usuario accede a una URL de un idioma, reglas de IP o de idioma del navegador lo redirigen forzosamente a otro idioma;
• La página se ha retirado o rediseñado, pero la etiqueta sigue apuntando al enlace antiguo del producto;
• La página de un idioma tiene canonical apuntando a la página en inglés, lo que hace que el motor de búsqueda la considere una página duplicada en vez de una versión independiente.

Entre estos casos, las redirecciones forzosas son las más fáciles de pasar por alto. Para «localizar automáticamente», algunos sitios redirigen directamente a los visitantes de Francia desde una URL en inglés a una URL en francés. Esto parece práctico para los usuarios comunes, pero al rastrear la página inglesa, los motores de búsqueda también pueden ser redirigidos, impidiéndoles verificar correctamente esa página y sus relaciones lingüísticas. Un método más seguro es conservar la URL original a la que el usuario puede acceder activamente y proporcionar una opción de cambio de idioma o un aviso de recomendación, en lugar de redirigir incondicionalmente.

canonical y hreflang también deben ser coherentes. Cada página que pueda participar en enlaces recíprocos entre idiomas normalmente debe tener canonical hacia su propia URL canónica. Si una página en francés tiene canonical hacia una página en inglés, pero se define a sí misma como versión alternativa en francés mediante hreflang, ambas señales entran en conflicto y los motores de búsqueda suelen ignorar prioritariamente parte de ellas.

Elija un método de implementación y evite que varias fuentes se sobrescriban entre sí

hreflang puede colocarse en el head de las páginas HTML, enviarse mediante un Sitemap XML o, en el caso de ciertos archivos que no son HTML, utilizar encabezados de respuesta HTTP. Para la mayoría de los sitios web corporativos y las tiendas transfronterizas, HTML head o Sitemap son suficientes; lo importante no es usar más métodos, sino contar con una fuente de datos única y actualizaciones sincronizadas.

Si el head de la página, el Sitemap y los complementos del backend generan hreflang simultáneamente, y los tres contenidos son incoherentes, la resolución de errores será muy difícil. Por ejemplo, los enlaces dentro de la página apuntan a nuevas URL, el mapa del sitio conserva URL antiguas y un complemento SEO de terceros solo reconoce algunos idiomas; el resultado final será un conjunto de relaciones que parece estar «todo etiquetado», pero que en realidad no puede verificarse.

Cuando el sitio tiene una escala pequeña y las versiones lingüísticas de las páginas son estables, generar las etiquetas en el head es más intuitivo; para tiendas o sitios de contenido con muchos SKU, muchos idiomas y actualizaciones masivas frecuentes, es más adecuado generar el Sitemap XML a partir de una fuente de datos unificada. Independientemente del método utilizado, las relaciones entre idioma, región y páginas deben mantenerse como parte de los datos del sitio, en lugar de depender de que el personal operativo copie etiquetas manualmente.

Valide mediante «un grupo de páginas», en lugar de reparar a ciegas todo el sitio

Durante la corrección, se recomienda seleccionar primero un grupo de páginas típico, como una página de detalles de producto con alto tráfico o una página de servicio principal, y colocar todas las versiones en una misma lista de comprobación. Confirme uno por uno la URL, el código de estado, canonical, el estado de indexación, el código de idioma, las referencias recíprocas y el destino de x-default. Una vez que este grupo de páginas haya superado completamente la comprobación, revise las plantillas y la lógica de generación masiva.

No considere hreflang como una herramienta de posicionamiento. Su función principal es ayudar a los motores de búsqueda a relacionar versiones entre páginas multilingües ya existentes; no puede compensar una mala calidad de traducción, contenido de página demasiado escaso, un sitio que no se puede rastrear o la falta de demanda de búsqueda en el mercado objetivo. Para las empresas que planean captar clientes internacionales a largo plazo, las reglas de URL multilingües, el proceso de producción de contenidos, las reglas canonical y la fuente de datos de hreflang deben diseñarse de manera unificada desde la fase de creación del sitio; esperar a que el número de páginas se haya ampliado para corregirlas una por una tendrá un coste mucho mayor.

Cuando los errores persistan, confirme primero si la página que genera el error sigue siendo una página oficial importante del sitio. No es necesario restaurar relaciones antiguas solo para eliminar avisos históricos de los informes en el caso de URL que ya se han retirado, redirigido o dejado de indexarse. Centre los esfuerzos de mantenimiento en los grupos de páginas principales que puedan indexarse, convertir y dirigirse al mercado objetivo; solo entonces hreflang podrá desempeñar realmente su función.