El atributo hreflang indica a Google qué versión lingüística o regional de una página mostrar a un usuario concreto. Mal implementado, casi nunca provoca un error visible: las páginas se siguen indexando, el sitio sigue funcionando, y precisamente eso es lo que hace tan difícil detectar el problema. Los síntomas reales, pérdida de tráfico en una versión lingüística, página equivocada mostrada en los resultados, suelen aparecer varias semanas después de publicar un sitio multilingüe.
Qué hace realmente hreflang, y qué no hace
hreflang no traduce nada ni redirige a nadie automáticamente. Se limita a declarar relaciones entre URL: «esta página en español tiene un equivalente en inglés en tal dirección, un equivalente en francés en tal otra». Google usa después esa información para decidir qué URL mostrar según el idioma y la ubicación de búsqueda del usuario. Sin hreflang, un sitio multilingüe sigue siendo indexable, pero Google tiene que adivinar la versión correcta, y se equivoca más a menudo de lo que se piensa en páginas de alto tráfico internacional.
Los errores más frecuentes
La mayoría de los problemas de hreflang detectados en sitios en producción se reducen a un puñado de causas recurrentes.
| Error | Síntoma observado | Causa típica | Corrección |
|---|---|---|---|
| Etiquetas no recíprocas | Search Console señala un «error de etiqueta de retorno» | La página B apunta a A, pero A no apunta de vuelta a B | Generar las etiquetas por pares, nunca a mano página por página |
| Código de idioma inválido | Google ignora la etiqueta sin error explícito | Uso de un código de país solo («es-ES» mal formado) o un código inventado | Respetar ISO 639-1 para el idioma, ISO 3166-1 para la región, en ese orden |
| Ausencia de x-default | Versión incorrecta mostrada a usuarios fuera de los idiomas cubiertos | Ninguna página de respaldo declarada | Añadir una etiqueta hreflang="x-default" hacia la versión genérica o el selector de idioma |
| URL no canónicas en hreflang | Conflicto entre la etiqueta canonical y la de hreflang | Las URL de hreflang apuntan a versiones con parámetros o no canónicas | Usar solo las URL canónicas exactas, tal como están indexadas |
| Incoherencia entre sitemap y etiquetas HTML | Unas páginas se tratan bien, otras no, sin lógica aparente | Los dos mecanismos declaran relaciones distintas | Elegir un único método de implementación por sitio, nunca los dos a la vez |
Google ignora en silencio las etiquetas hreflang mal emparejadas, sin generar un error visible en Search Console hasta varias semanas después.
Auditar un sitio existente
El informe de «Segmentación internacional» de Search Console sigue siendo el punto de partida más fiable: enumera los errores de retorno detectados en una muestra de páginas. Sin embargo, no cubre la totalidad del sitio, y su retraso de actualización puede superar la semana. Para una auditoría completa, sigue siendo necesario un rastreo técnico (Screaming Frog, Sitebulb o un script propio): permite comprobar, URL por URL, que cada relación hreflang es realmente recíproca y que los códigos de idioma son válidos.
Esta lentitud en la detección se conecta con un problema más amplio de seguimiento: sin un panel regular que cruce indexación y rendimiento por idioma, un error de hreflang puede pasar inadvertido durante meses. Implementar un panel de GA4 y Search Console segmentado por idioma permite detectar rápidamente una caída de tráfico localizada en una sola versión del sitio, señal frecuente de un problema de hreflang más que de una bajada general de visibilidad.
Implementar hreflang correctamente
Coexisten dos métodos: las etiquetas <link> en el <head> de cada página, o una declaración en el sitemap XML. La segunda es preferible en sitios voluminosos, ya que evita sobrecargar cada página y centraliza las relaciones en un único archivo que mantener.
<!-- En el head de la página en español -->
<link rel="alternate" hreflang="es" href="https://ejemplo.com/es/guia-hreflang/" />
<link rel="alternate" hreflang="en" href="https://ejemplo.com/en/hreflang-guide/" />
<link rel="alternate" hreflang="fr" href="https://ejemplo.com/fr/guide-hreflang/" />
<link rel="alternate" hreflang="de" href="https://ejemplo.com/de/hreflang-leitfaden/" />
<link rel="alternate" hreflang="x-default" href="https://ejemplo.com/" />
<!-- Declaración equivalente en el sitemap XML -->
<url>
<loc>https://ejemplo.com/es/guia-hreflang/</loc>
<xhtml:link rel="alternate" hreflang="en"
href="https://ejemplo.com/en/hreflang-guide/" />
<xhtml:link rel="alternate" hreflang="fr"
href="https://ejemplo.com/fr/guide-hreflang/" />
<xhtml:link rel="alternate" hreflang="x-default"
href="https://ejemplo.com/" />
</url>
Más allá de Search Console: otras herramientas de control
Search Console por sí sola no basta para un control regular, dado su alcance muestral y su retraso de procesamiento. Tres tipos de herramientas cubren lo esencial de lo que necesita un equipo técnico. Un rastreador SEO clásico (Screaming Frog, Sitebulb) incorpora una pestaña dedicada que lista automáticamente las etiquetas hreflang no recíprocas, los códigos de idioma inválidos y las páginas sin autorreferencia, sobre la totalidad del sitio y no solo una muestra. Para sitios que publican varias veces al día, un script de control ejecutado en integración continua detecta las regresiones antes de publicar, en lugar de varias semanas después vía Search Console. Por último, la herramienta de prueba de hreflang de Merkle (technicalseo.com) sigue siendo una referencia para verificar manualmente un pequeño número de URL sin depender de un rastreo completo.
Un escenario frecuente: añadir un idioma después del lanzamiento
La mayoría de los errores de hreflang detectados en auditoría no aparecen en el lanzamiento de un sitio multilingüe, sino al añadir un idioma adicional a un sitio que ya contaba con dos o tres. El patrón se repite: un equipo añade el alemán a un sitio francés-inglés-español, pero el script o la configuración que genera las etiquetas hreflang solo se pensó para tres idiomas. Las nuevas páginas en alemán existen y se indexan, pero no aparecen en ninguna etiqueta hreflang de las páginas existentes, y sus propias etiquetas apuntan a URL que, a su vez, no las referencian de vuelta. El resultado es un error de retorno en la totalidad de las páginas nuevas, invisible hasta que alguien relanza una auditoría completa.
La solución es menos una cuestión de herramientas que de proceso: tratar cualquier incorporación de idioma como un cambio de esquema de datos en lugar de como un contenido aislado, y relanzar sistemáticamente un rastreo completo del sitio después, no solo sobre las páginas nuevas.
El caso de los CMS multilingües
En WordPress, las extensiones de gestión multilingüe (Polylang, WPML) generan por lo general las etiquetas hreflang automáticamente a partir de las traducciones vinculadas en base de datos, lo que evita la mayoría de los errores manuales. El riesgo se desplaza entonces hacia la configuración: una sección o categoría sin traducir puede romper la cadena de enlace, y volver a publicar un artículo en el idioma por defecto sin pasar por el mecanismo de traducción del tema suele producir una página huérfana, sin ninguna etiqueta hreflang que apunte a ella. La elección del CMS y de su arquitectura multilingüe merece decidirse al inicio del proyecto; la guía de elección de un CMS detalla los criterios a considerar antes de añadir una capa de traducción a un sitio existente.
Lo esencial
hreflang no perdona la aproximación: una etiqueta huérfana o un código de idioma mal formado no impide que nada funcione, pero priva en silencio a parte de la audiencia internacional de la versión correcta del sitio. Una auditoría regular, una única implementación por sitio (HTML o sitemap, no ambos) y una autorreferencia sistemática cubren la mayoría de los casos vistos en producción.
En casi todas las auditorías multilingües que llegan a mi mesa, el problema nunca viene de falta de voluntad, sino de un olvido al añadir un quinto idioma a un sitio que empezó con dos. El script de generación de etiquetas no se actualizó, y nadie se da cuenta hasta que baja el tráfico en la versión nueva. Mi reflejo: tratar hreflang como código, con una prueba automatizada que verifique la reciprocidad de las etiquetas en cada despliegue, en lugar de como una casilla que marcar en un plugin. — Simon Janvier
Para saber más: la documentación oficial de Google sobre versiones localizadas y hreflang.
