Volver a todos los artículos
tutorials 12 min read

Guía de implementación de hreflang: tres métodos, x-default y cinco errores comunes

Ali Gundogdu ·
Guía de implementación de hreflang: tres métodos, x-default y cinco errores comunes

Un sitio que se publica en más de un idioma toma una decisión silenciosa. Cuando alguien busca en Google en francés un tema que tú cubres, ¿qué versión de tu página debería ganar el resultado, el original en inglés o la traducción al francés? Cuando un lector en español llega desde México, ¿debería ver el español de España o el de Latinoamérica? Hreflang es la pequeña anotación que responde a esas preguntas para los motores de búsqueda, y hacerlo bien es lo que evita que un sitio multilingüe compita contra sí mismo.

Esta guía recorre lo que hreflang resuelve realmente, las tres formas de implementarlo, las reglas de sintaxis que aguantan a escala, el respaldo x-default que la mayoría de los sitios necesita, la relación a menudo confundida con canonical, los cinco errores que rompen la implementación en silencio y las herramientas de validación que detectan los problemas antes de que los usuarios los vean.

Qué resuelve hreflang en realidad

Hreflang es una anotación que le indica a Google y a Yandex qué versión de una página está destinada a qué idioma y región. Sin hreflang en un sitio multilingüe, se abren dos riesgos.

El primer riesgo es servir el idioma equivocado. Una persona que busca en alemán aterriza en la página en inglés porque Google no sabía que existía la versión en alemán. La conversión cae, el rebote sube y la persona recuerda la fricción.

El segundo riesgo es la competencia por contenido duplicado. Google ve páginas similares en tres URL (/en/about, /de/about, /fr/about) y las trata como variantes entre sí. Sin hreflang, el algoritmo elige una para rankear y degrada las demás, justo lo contrario de lo que un sitio multilingüe necesita.

Hreflang resuelve ambos. Le dice a los motores, “estas tres URL son el mismo contenido en tres idiomas, mostrá a cada usuario la versión que corresponde a su búsqueda”. Google no siempre lo respeta a la perfección, pero con una implementación correcta es la señal más fuerte que se puede dar.

Hreflang no mejora el ranking en sí mismo. Mejora el enrutamiento del tráfico ya existente. La página en inglés no empieza a rankear mejor en búsquedas en inglés porque se haya añadido hreflang. Lo que cambia es que el usuario alemán deja de aterrizar en la página en inglés cuando existe la página en alemán.

Tres formas de implementar hreflang

Google soporta tres ubicaciones. Son equivalentes en efecto, pero cada una tiene compromisos prácticos.

Visualización híbrida riso y mosaico antiguo de los tres pilares de la implementación de hreflang

Etiquetas en el head HTML. El método más simple y común. Cada página lista a sus hermanos hreflang en la sección <head>.

<link rel="alternate" hreflang="en" href="https://example.com/about" />
<link rel="alternate" hreflang="de" href="https://example.com/de/about" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/about" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about" />

Funciona en cualquier sitio que controle sus plantillas. La desventaja es el peso de la página en sitios con muchas versiones de idioma y el límite práctico de cuántos tags puede llevar una sección head sin volverse incómoda. Veinte idiomas significan veinte tags link en cada página.

Cabeceras de respuesta HTTP. La misma información en el header de respuesta en lugar del cuerpo HTML.

Link: <https://example.com/about>; rel="alternate"; hreflang="en",
      <https://example.com/de/about>; rel="alternate"; hreflang="de",
      <https://example.com/fr/about>; rel="alternate"; hreflang="fr"

Es la elección correcta para recursos no HTML, como documentos PDF que existen en varios idiomas. También funciona para HTML, pero la mayoría de los equipos prefieren tags HTML para contenido HTML porque son más fáciles de depurar y validar.

Sitemap XML. Anotaciones hreflang dentro de la entrada de sitemap para cada URL.

<url>
  <loc>https://example.com/about</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/about" />
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about" />
  <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/about" />
</url>

Es la mejor opción para sitios muy grandes. Un sitio con 100.000 URL en 12 idiomas llevaría 1.200.000 tags head si se implementa en HTML. La versión en sitemap es mucho más limpia y centraliza la anotación en un archivo. El costo es que el sitemap debe regenerarse correctamente cada vez que las URL cambian, y las herramientas de validación tienen que considerar los sitemaps por separado. Combinálo con un proceso de sitemap XML limpio para que escale.

Los tres métodos pueden mezclarse pero no deben combinarse para la misma página. Elegí un método por página y mantenelo consistente. Las señales contradictorias entre head HTML y sitemap son una causa frecuente de implementaciones rotas.

Estándares de código que aguantan a escala

Hreflang tiene reglas de sintaxis estrictas. Las violaciones son silenciosas, los motores ignoran la anotación en lugar de avisar. Las reglas que más importan.

Usá ISO 639-1 para el idioma. Códigos de idioma de dos letras, en minúscula. en, de, fr, es, pt, ja. Los códigos de tres letras no se aceptan.

Añadí región solo cuando sea necesario. ISO 3166-1 Alpha-2, códigos de región de dos letras, en mayúscula, separados por guion del idioma. en-GB para inglés británico, en-US para inglés americano, es-MX para español de México, pt-BR para portugués de Brasil. Región sin idioma no es válida, US solo no funciona, hay que escribir en-US. La mayoría de los sitios no necesita variantes regionales, solo aquellos que de verdad tienen contenido separado para diferentes regiones deberían usarlas.

Solo URL absolutas. Cada href debe ser una URL totalmente cualificada con protocolo y dominio, https://example.com/de/about, no /de/about. Las rutas relativas no se honran.

Anotación auto-referencial. Cada página debe incluir un tag hreflang que apunte a sí misma. La página en inglés lista la URL en inglés con hreflang="en" junto con las URL en alemán y francés. Muchas implementaciones se olvidan de la auto-referencia y todo el conjunto de anotaciones se trata como inválido.

Tags de retorno bidireccionales. Cada página del conjunto debe listar a todas las demás páginas del conjunto. Si la página en inglés enlaza a la alemana con hreflang, la alemana también debe enlazar a la inglesa con hreflang. Los tags de retorno faltantes son la razón más común por la que las implementaciones de hreflang fallan en los reportes de Search Console. Una rutina de crawler SEO los detecta a escala, la revisión manual a partir de cinco idiomas no funciona.

Usá HTTPS de forma consistente. Todas las URL hreflang deberían ser HTTPS, el mismo protocolo que la URL canónica. Mezclar HTTP y HTTPS en el conjunto de anotaciones hace que Google descarte las inconsistentes.

Un código de idioma por URL. Una URL no puede tener dos valores hreflang. Si necesitás apuntar a dos idiomas desde una URL, tenés un problema de contenido, no un problema de hreflang.

El tag x-default

x-default es la anotación de respaldo. Le dice a los motores, “si no existe coincidencia de idioma, mandá al usuario aquí”.

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

El caso de uso clásico es un sitio con versiones en inglés, alemán y francés, más una página de selección de idioma. Una persona que busca en italiano no tiene versión en italiano. Sin x-default, Google adivina a qué versión enviar al usuario. Con x-default apuntando al selector de idioma (o a la versión en inglés, según la intención), el enrutamiento es explícito.

x-default no es estrictamente obligatorio, pero la mayoría de los sitios internacionales se benefician de él. Las excepciones son sitios con solo dos o tres idiomas sin una intención de respaldo realista, donde la ausencia de x-default está bien.

Hreflang frente a canonical

Esta es la fuente de más errores de implementación de hreflang que cualquier otro concepto. No son lo mismo, no se reemplazan y no están en oposición.

Canonical dice, “de estas URL similares, esta es la versión maestra”. Se usa para consolidar duplicados y variantes con parámetros de tracking bajo una URL indexable. La mecánica completa se cubre en la guía de canonical tags.

Hreflang dice, “estas URL son equivalentes en distintos idiomas, enrutá a cada usuario al correcto”.

Los dos trabajan juntos. En un sitio multilingüe, cada versión de idioma debería tener un canonical auto-referencial que apunte a sí mismo, más anotaciones hreflang que apunten a todos los hermanos de idioma.

<!-- En la página en alemán -->
<link rel="canonical" href="https://example.com/de/about" />
<link rel="alternate" hreflang="en" href="https://example.com/about" />
<link rel="alternate" hreflang="de" href="https://example.com/de/about" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/about" />

Error común, la página en alemán pone canonical hacia la página en inglés (<link rel="canonical" href="https://example.com/about" />). Esto le dice a Google que la página en alemán es duplicada de la inglesa, lo cual entra en conflicto con la señal de hreflang que dice que son hermanas. Google ignora el hreflang en este conflicto y la página en alemán no rankea para búsquedas en alemán. La solución siempre es self-canonical en las variantes de idioma, nunca canonical hacia el idioma maestro.

Cinco errores comunes

Los errores siguientes aparecen una y otra vez en las auditorías. Cada uno rompe la implementación en silencio, y Search Console rara vez los muestra con claridad.

Tags de retorno faltantes. La página en inglés lista alternativas en alemán y francés, pero la página en alemán no lista la alternativa en inglés de vuelta. Google trata la anotación como incompleta y puede ignorarla por completo. La verificación bidireccional es lo primero que hay que revisar en cualquier auditoría.

Códigos de idioma o región incorrectos. en-UK está mal, el código correcto es en-GB. pt-PT y pt-BR son válidos, pt solo también es válido para “cualquier portugués”. zh es técnicamente válido pero zh-CN (simplificado) y zh-TW (tradicional) son mucho más útiles en la práctica. Los códigos que no se parsean se descartan en silencio.

Mezclar HTTP y HTTPS. Una migración de HTTP a HTTPS deja algunas URL hreflang en el protocolo viejo. El conjunto mixto falla. Audita las URL hreflang después de cualquier migración de protocolo o dominio, este es uno de los puntos en el checklist de auditoría SEO técnica.

Enlaces a páginas noindex o redirigidas. Una URL hreflang debe resolver a una página indexable de 200 OK. Si redirige con 301 a otra URL o devuelve noindex, la anotación se descarta. La calidad del conjunto de anotaciones depende de que cada URL del conjunto esté viva e indexable.

Canonical apuntando al idioma equivocado. Como se describió antes, la variante de idioma debe ser self-canonical, no canonical al idioma maestro. Es el error de mayor impacto de la lista porque degrada directamente la versión de idioma en las búsquedas.

Pergamino híbrido riso y antiguo mostrando cinco errores comunes de hreflang como líneas de conexión rotas entre variantes de idioma

Validación

Los problemas de hreflang no son visibles en la navegación normal. Aparecen solo cuando un usuario busca en un idioma y aterriza en la versión equivocada, o cuando los datos de tráfico muestran bajo rendimiento en un mercado objetivo. La validación tiene que pasar al nivel de la implementación, no al nivel del usuario.

Reporte International Targeting de Search Console. La herramienta nativa de Google. Lista errores de hreflang a nivel de propiedad, incluyendo tags de retorno faltantes y códigos de idioma no reconocidos. La demora es real, los errores tardan días en aparecer, pero los datos son autoritativos una vez que aparecen.

Validador hreflang de Aleyda Solis. Una herramienta pública gratuita que toma una URL y devuelve el conjunto de anotaciones hreflang con validación. Útil para revisar páginas individuales durante la implementación.

Crawlers SEO. Un crawler de escritorio puede verificar el conjunto entero de anotaciones hreflang sobre miles de URL en una sola pasada. La verificación manual a cualquier escala mayor a cincuenta páginas no es realista. Los crawlers detectan tags de retorno faltantes, protocolos incorrectos, URL hreflang rotas y destinos noindex, todo en la misma auditoría.

Para sitios con despliegues multilingües activos, la validación de hreflang pertenece a la misma cadencia mensual que las revisiones de enlaces rotos y las auditorías de canonical. No llama la atención hasta que algo está mal, y para entonces el daño a los rankings internacionales ya se acumuló.

Cuándo hreflang tiene mayor impacto

Hreflang tiene el impacto más fuerte en tres escenarios.

Sitios donde cada idioma tiene importancia comercial similar. Una empresa SaaS que vende en cinco mercados europeos necesita que cada idioma rankee en su propia búsqueda. Hreflang es la capa de enrutamiento que hace eso posible.

Sitios con variantes regionales del mismo idioma. Contenido en español de México que compite con el de España en búsquedas latinoamericanas es un conflicto frecuente. Sin es-MX y es-ES hreflang, Google adivina, y la suposición se equivoca lo bastante seguido como para hacer daño.

Migraciones y lanzamientos de idiomas. Cuando un sitio agrega una nueva versión de idioma, hreflang es lo que le dice a Google que trate las páginas nuevas como hermanos correctos de idioma de las existentes, no como duplicados nuevos en competencia.

Los escenarios donde hreflang tiene menos impacto, para completar, son sitios con un idioma realmente dominante donde los demás son fracciones pequeñas del tráfico, y sitios donde los usuarios de idiomas no objetivo no estarían en el mercado objetivo de todas formas.

Conclusión

Hreflang es pequeño en código y enorme en efecto. Unos pocos tags link o una sección de sitemap, escritos correctamente y referenciados de forma bidireccional, controlan el enrutamiento internacional de un sitio multilingüe. Los cinco errores comunes son fáciles de cometer, fáciles de corregir, y las herramientas de validación existen por una razón.

Para un sitio que acaba de añadir un idioma nuevo y quiere confirmar la implementación, la secuencia de auditoría es, verificar self-canonical en cada variante de idioma, verificar tags de retorno hreflang bidireccionales, verificar que todas las URL hreflang sean HTTPS e indexables, verificar que los códigos de idioma y región se parseen correctamente, y luego seguir el reporte International Targeting de Search Console durante las dos semanas siguientes.

Para sitios con varios lanzamientos de idioma en curso, combiná el trabajo de hreflang con higiene de meta tags y una auditoría SEO técnica regular, los tres se refuerzan mutuamente en el SEO internacional.

Si necesitás una herramienta para verificar hreflang sobre un sitio entero sin revisión manual, descargá Seodisias gratis. Corre localmente en tu máquina, valida el conjunto completo de anotaciones hreflang incluyendo tags de retorno, y reporta URL rotas y mezclas de protocolo como parte de cada auditoría.