Hreflang SEO: errores habituales y validación internacional

Qué es hreflang y para qué sirve realmente

hreflang es un atributo HTML que indica a motores de búsqueda como Google qué versión idiomática o geográfica de una página corresponde a cada URL.

No traduce una web, no arregla una mala arquitectura internacional y tampoco va a empujarte en los rankings como por arte de magia. Su función es bastante más concreta: ayudar a Google a entender qué versión debe mostrar en las SERPs cuando un sitio trabaja varios idiomas, varios países o ambas cosas a la vez.

Aquí conviene dejar algo claro desde el principio: en una web multi idioma bien planteada, hreflang no debería faltar. No es un adorno técnico, es una parte básica del SEO internacional cuando existen URLs equivalentes entre versiones idiomáticas o geográficas.

Y aquí aparece el primer problema real: no basta con tener una web traducida. Hay que decidir cómo se va a estructurar internacionalmente.

Lo más habitual suele ser una de estas tres opciones:

• Idioma base en raíz y resto de idiomas en directorios

  https://dominio.com/
  https://dominio.com/en/
  https://dominio.com/fr/
  

• Todos los idiomas dentro de directorios

  https://dominio.com/es/
  https://dominio.com/en/
  https://dominio.com/fr/
  

• Mercados o idiomas separados en subdominios o dominios distintos

  https://es.dominio.com/
  https://en.dominio.com/
  https://dominio.mx/
  

No hay una única estructura válida para todos los proyectos, pero sí hay una condición básica: la lógica de URLs, canonicals y hreflang tiene que encajar como una sola pieza.

Si el idioma base vive en raíz y el secundario en directorio, perfecto, pero entonces los hreflang deben apuntar correctamente a esas URLs absolutas. Si todo va en directorios, igual. Lo que no funciona es montar un puzle raro con unas versiones en raíz, otras en carpetas improvisadas y luego pretender que cuatro etiquetas en el head ordenen el problema.

En muchos proyectos multi idioma el fallo no empieza en hreflang, comienza antes, en la estructura.

En SEO internacional, hreflang no va por libre. Tiene que encajar con la arquitectura, las URLs y las canonicals como una orquesta. Si una parte desafina, el resto empieza a dar problemas.

También conviene aclarar otra cosa para no mezclar conceptos: hreflang no es una redirección por IP, ni depende del idioma del navegador como lo haría una detección automática del servidor. Su función es ayudar a Google a decidir qué versión mostrar en resultados de búsqueda, no mover al usuario de una URL a otra cuando entra en la web.

Cuando está mal implementado (lo que suelo ver en auditorías de manera repetitiva):

• URLs en inglés apareciendo en mercados donde debería mostrarse la versión en español
• versiones equivalentes compitiendo entre sí
• canonicals contradiciendo la lógica internacional
• caídas o comportamientos extraños en tráfico orgánico internacional

Y cuanto más grande es el sitio, más delicado se vuelve el asunto, ya que con dos idiomas y veinte URLs puedes revisar casi todo a mano. En cambio, con cinco mercados, miles de páginas y distintas plantillas, cualquier incoherencia pequeña se va a multiplicar.

Por eso siempre prefiero ver primero una versión base acotada en cuanto idiomas y luego ampliar el multi idioma de forma ordenada, añadiendo nuevas versiones idiomáticas.

A destacar que: si desde el principio la raíz, los directorios, las equivalencias y las canonicals no encajan, hreflang empieza a sufrir enseguida.

Cómo funciona hreflang a nivel técnico

Cuando tienes varias URLs que representan la misma página en distintos idiomas o mercados, el atributo hreflang indica qué versión hay en cada una de ellas.

Ejemplo sencillo:

https://dominio.com/servicios-seo/
https://dominio.com/en/seo-services/
https://dominio.com/mx/servicios-seo/

En este caso, cada una representa una versión distinta de la misma página y lo correcto es que Google reciba esa relación de forma clara y consistente.

Dicho de forma simple: hreflang le dice a Google qué idioma o variante regional hay en cada URL equivalente. Así no dependes solo del idioma del contenido, de la estructura de la URL o de interpretaciones parciales que en proyectos internacionales muchas veces salen mal.

Para que eso funcione bien, hay varias condiciones que deben cumplirse:

• Reciprocidad
  Si la URL A apunta a la B, la B debe devolver esa misma relación.
• Autorreferencia
  Cada URL debe incluir también su propia versión dentro del conjunto.
• Equivalencia real
  Las páginas enlazadas con hreflang tienen que ser realmente versiones equivalentes, no URLs distintas agrupadas a la fuerza.
• Canonical coherente
  Si la canonical contradice al hreflang, empiezan los conflictos.

Este último punto es especialmente importante. Uno de los problemas más serios que me encuentro es este:

• las páginas tienen hreflang
• pero la canonical apunta siempre a una única versión principal

Ahí estás mandando dos señales distintas al mismo tiempo:

• por un lado dices que las URLs son variantes entre sí
• por otro dices que una sola es la válida

Eso hay que evitarlo, ya que en unn una implementación internacional bien resuelta, hreflang y canonical deben decir lo mismo, no pelearse entre ellos. Cuando se contradicen, luego llegan esos casos en los que “en teoría está todo bien” pero en Google no termina de encajar nada.

Cuándo debes usar hreflang

Si tu web trabaja varios idiomas o varios países y existen páginas equivalentes entre versiones, lo normal es que debas usar hreflang.

Casos típicos:

• Mismo contenido en distintos idiomas
  Ejemplo: versión en español y versión en inglés de una misma URL.
• Mismo idioma orientado a distintos países
  Ejemplo: español para España y español para México.
• Contenido muy parecido entre mercados
  Ejemplo: mismas fichas o landings, pero con variaciones de moneda, stock, condiciones o enfoque local.

Donde no tiene sentido integrar el atributo hreflang es en una web con un solo idioma, o en proyectos donde no existe correspondencia real entre páginas.

Un escenario muy habitual es este:

https://dominio.com/
https://dominio.com/mx/
https://dominio.com/ar/

Si no marcas correctamente la relación entre esas versiones, Google puede mezclar resultados entre países y mostrar una URL donde no toca.

Si tienes varias versiones idiomáticas o geográficas de una misma página, lo raro no es usar hreflang. Lo raro sería no usarlo.

Sintaxis correcta de hreflang

Escribir la línea de hreflang es fácil. Lo que conviene hacer bien desde el principio es toda la lógica que hay detrás.

Ejemplo básico:

<link rel="alternate" hreflang="es" href="https://dominio.com/" />
<link rel="alternate" hreflang="en" href="https://dominio.com/en/" />

Si además orientas por país:

<link rel="alternate" hreflang="es-ES" href="https://dominio.com/" />
<link rel="alternate" hreflang="es-MX" href="https://dominio.com/mx/" />
<link rel="alternate" hreflang="en-US" href="https://dominio.com/us/" />

La lógica es esta:

• es = español
• es-ES = español orientado a España
• es-MX = español orientado a México
• en-US = inglés orientado a Estados Unidos

Y aquí sí merece la pena separar claramente una familia de errores muy común:

Errores comunes al escribir hreflang

• mx-ES → incorrecto
• sp para español → incorrecto
• uk como idioma → incorrecto
• mezclar idioma y país sin seguir el formato correcto
• apuntar bien en la home y olvidarse del resto de URLs equivalentes

También existe el valor x-default, útil en homes globales, selectores de país o versiones genéricas:

<link rel="alternate" hreflang="x-default" href="https://dominio.com/" />

No es obligatorio siempre, pero en algunos proyectos internacionales sí encaja bastante bien.

Dónde implementar hreflang

La forma más habitual y la que personalmente más me gusta para la mayoría de proyectos es dentro del head de cada página.

<link rel="alternate" hreflang="es-ES" href="https://dominio.com/" />
<link rel="alternate" hreflang="en-US" href="https://dominio.com/en/" />
<link rel="alternate" hreflang="es-MX" href="https://dominio.com/mx/" />

¿Por qué me parece la vía más natural? Porque el atributo queda ligado a la URL concreta que estás rastreando, y eso facilita bastante la revisión en auditoría.

Dicho esto, también puede implementarse en sitemap XML y en encabezados HTTP.

• HTML
  La opción más visible y más sencilla de revisar página a página.
• Sitemap XML
  Puede tener sentido en proyectos grandes donde conviene centralizar la lógica, aunque personalmente prefiero no dar por hecho que todo está bien solo porque el sitemap lo diga.
• Encabezados HTTP
  Útil sobre todo en recursos no HTML, como PDFs.

Sí, Google puede procesarlo también desde sitemap XML, pero eso no hace automáticamente que sea mejor que meterlo en el head. A mí me interesa sobre todo que la implementación sea coherente, revisable y mantenible.

Errores comunes en la implementación hreflang

Más allá de escribir bien el atributo, aquí es donde suelen aparecer los problemas de verdad.

Los más habituales que me suelo encuentrar:

• Falta de reciprocidad
  Una versión apunta a otra, pero la otra no devuelve la relación.
• Falta de autorreferencia
  La página no se incluye a sí misma en el conjunto.
• Canonical en conflicto
  Los hreflang dicen una cosa y la canonical otra.
• URLs rotas, redirigidas o no indexables dentro del clúster
• Implementación parcial
  Bien en la home y algunas plantillas, mal o inexistente en otras.
• Equivalencias mal planteadas
  Se enlazan páginas que no son realmente versiones equivalentes.

Otro patrón muy típico en webs multi idioma mal resueltas es este:

• se traduce la web
• se crea el directorio /en/ o similar
• se mete hreflang
• pero el enlazado interno sigue empujando casi todo hacia la versión base

Ahí el problema ya no es solo la etiqueta, también lo es la coherencia de todo el sistema internacional.

Cómo validar hreflang correctamente

Ver dos líneas en el head y darlo por bueno no es validar hreflang. Eso es mirar por encima y confiar demasiado rápido.

Lo que hay que revisar realmente es:

• sintaxis correcta
• URLs válidas y accesibles
• reciprocidad
• autorreferencia
• coherencia con canonical
• equivalencia real entre páginas

Herramientas útiles:

• Search Console
  Puede dar pistas, aunque muchas veces no llega a todo.
• Screaming Frog
  Para revisar hreflang a escala sigue siendo de lo más útil.
• Validadores externos
  Bien como apoyo, pero no me quedaría solo con ellos.

En auditoría SEO internacional no reviso hreflang como bloque aislado. Lo reviso junto a:

• arquitectura internacional
• canonicals
• indexabilidad
• redirecciones
• enlazado interno entre versiones

Porque muchas veces el atributo está escrito, pero el problema real viene de otra parte.

En auditorías SEO internacionales, hreflang casi nunca falla solo. Normalmente falla acompañado de problemas de arquitectura, canonical, indexación o mantenimiento entre versiones.

Buenas prácticas hreflang

Si quieres que funcione bien, esto es lo básico:

• Define primero la arquitectura internacional
  No metas hreflang antes de decidir cómo vas a estructurar idiomas, países y equivalencias.
• Relaciona solo páginas equivalentes de verdad
• Mantén reciprocidad y autorreferencia en todo el conjunto
• Haz que canonical y hreflang vayan alineados
• Revisa la implementación después de migraciones, rediseños o cambios de slugs
• Trata hreflang como mantenimiento técnico normal del sitio

Conclusión

hreflang no tiene misterio cuando lo ves como una línea de código, pero en una web internacional forma parte de un sistema bastante más amplio: arquitectura, URLs, equivalencias, canonicals, indexación y mantenimiento.

Si todo eso encaja, hreflang ayuda mucho a que Google muestre la versión correcta en cada mercado, pero si no encaja, la etiqueta por sí sola no te va a salvar.

Hreflang exige diagnóstico y validación, no solo copiar etiquetas

Un hreflang mal implementado puede crear señales contradictorias entre idiomas, países, canonicals y sitemaps. El problema no siempre está en una etiqueta aislada, sino en cómo encajan todas las versiones internacionales de la web.

Cuando hay dudas sobre versiones, indexación o señales cruzadas, conviene revisarlo dentro de una auditoría SEO técnica. Si el diagnóstico ya está claro, la corrección debe tratarse como implementación SEO con QA posterior, no como un cambio menor sin validación.

No publiques hreflang sin validar señales, canonicals y respuesta real de las URLs.