Qué es hreflang: definición, ejemplo de código y errores frecuentes

Una web con varias versiones de idioma se enfrenta a un problema que los motores de búsqueda no resuelven por sí solos: ¿cómo sabe Google que la versión en español, la alemana y la inglesa de una página son el mismo contenido, solo que en distinto idioma? Sin una señal explícita, un buscador trata esas tres URL como tres páginas independientes, incluso como si compitieran entre sí. Ahí entra hreflang. El atributo agrupa todas las versiones de idioma de una página y, al mismo tiempo, indica a qué idioma y, opcionalmente, a qué país corresponde cada una.

El valor del atributo hreflang sigue una sintaxis fija: primero el código de idioma en formato ISO 639-1, por ejemplo "es" para español o "de" para alemán, seguido opcionalmente de un guion y el código de país en ISO 3166-1 Alpha-2, como "es-MX" para español dirigido a México o "de-AT" para alemán en Austria. El orden es obligatorio: idioma primero, país después, nunca al revés. Un valor como "MX-es" es inválido y Google lo ignora. Existe además el valor especial "x-default", que marca la versión que se muestra cuando ninguna de las versiones definidas coincide con el idioma o la región del usuario, normalmente la página internacional o en inglés.

La forma más habitual de implementar hreflang es como un grupo de etiquetas link en el head de cada página implicada. Ese grupo debe ser idéntico en todas las versiones: cada página se enumera a sí misma y enumera todas las demás. Así se ve un bloque completo para una entrada de glosario con tres versiones de idioma más x-default, con dominio propio como ejemplo. La figura siguiente muestra el bloque completo para las tres versiones.

Este bloque, con las mismas cuatro líneas de hreflang y la misma canonical, tiene que ir en el head de las tres páginas implicadas, no solo en la española. Lo único que cambia de una página a otra es su propia URL canonical. En webs con muchas versiones de idioma, el head se vuelve difícil de mantener; ahí conviene usar en su lugar el sitemap XML, donde cada URL referencia sus alternativas mediante entradas xhtml:link. Para documentos que no son HTML, como los PDF, la vía adecuada es la cabecera HTTP Link con rel="alternate", porque un PDF no admite un head donde insertar las etiquetas.

La elección entre las tres vías depende sobre todo del número de páginas: unas pocas decenas se gestionan bien con etiquetas link en el head, mientras que varios cientos o miles de URL por idioma se manejan mejor desde el sitemap, generado desde una única fuente de datos. Sea cual sea la vía elegida, la regla es la misma: el grupo debe estar completo y ser coherente, o Google ignora toda la señal para esas URL.

Hreflang y la etiqueta canonical se confunden con frecuencia porque ambas viven en el head y ambas trabajan con URL. Pero sus funciones son distintas. La etiqueta canonical dice: de varias URL técnicamente parecidas o idénticas, esta es la versión que debe indexarse, por ejemplo cuando la misma página es accesible con y sin parámetros de tracking. Hreflang, en cambio, dice: estas páginas son versiones de idioma deliberadamente distintas del mismo contenido, todas deben indexarse, pero cada una debe mostrarse al público adecuado.

Aun así, ambas señales tienen que encajar. Cada versión de idioma necesita su propia etiqueta canonical, que apunte a sí misma. Si la versión en alemán tiene como canonical la URL de la versión en español, Google entiende que solo debe indexar la española, y todo el grupo de hreflang queda invalidado de facto, porque una de las supuestas versiones equivalentes se está marcando a sí misma como no canónica. Un error frecuente y difícil de detectar es que la URL usada en hreflang no coincida exactamente con la usada en la canonical de esa misma página, por ejemplo porque una lleva barra final y la otra no. Para Google son dos URL distintas, aunque en el navegador lleven al mismo sitio. La canonical y la autorreferencia de hreflang tienen que ser idénticas carácter por carácter.

El error más costoso en la práctica, y a la vez el más difícil de detectar, tiene que ver con las redirecciones. Un enlace hreflang siempre debe apuntar directamente a la URL final que responde con código 200, nunca a una URL que sea, a su vez, una redirección. Si una entrada hreflang señala hacia una URL intermedia que redirige con un 301 o 302 hacia otra dirección, Google no interpreta ese enlace como una señal de idioma válida.

Google documenta en su referencia oficial de Search Central sobre redirecciones cómo se gestionan estas a efectos de indexación: ante una redirección, Google mantiene internamente dos URL, origen y destino, y consolida las señales en la URL canónica, mientras que la otra pasa a ser un simple "nombre alternativo" que ya no se considera por sí solo para la indexación (fuente: developers.google.com/search/docs/crawling-indexing/301-redirects). Un hreflang que apunte al origen de la redirección en lugar de al destino deja de referenciar, por tanto, una página indexable y canónica. La propia documentación oficial de hreflang exige además, de forma explícita, que cada versión de idioma se referencie a sí misma y a todas las demás correctamente, y que vaya acompañada de una etiqueta canonical adecuada (fuente: developers.google.com/search/docs/specialty/international/localized-versions); una URL que en sí misma solo es una redirección no puede cumplir ese requisito de ser un destino estable y canónico. Combinando ambas páginas de documentación oficial, la regla queda verificada sin ambigüedad: cada hreflang debe apuntar a la página final real, la que responde con 200.

Este error casi nunca aparece al montar por primera vez un sitio multilingüe, sino más adelante, tras un cambio de estructura de URL. Si, por ejemplo, un glosario se traslada de /blog/glosario/termino a una URL más corta como /termino, y la dirección antigua se redirige con un 301 a la nueva, las entradas hreflang de las otras versiones de idioma suelen quedarse sin actualizar y siguen apuntando a la dirección antigua, ahora redirigida. La página en sí funciona con normalidad para los visitantes, porque el redirect hace su trabajo, y por eso el fallo puede pasar desapercibido durante meses. Solo se descubre revisando la Search Console o rastreando directamente las URL de destino de hreflang para comprobar su código de estado real.

Además del error de redirect, en la práctica aparecen sobre todo otros tres tipos de fallo, los tres recogidos de forma explícita en la propia lista de errores comunes de Google.

Las referencias de vuelta que faltan son el error más habitual de todos. Si la versión en español enlaza mediante hreflang a la versión en inglés, la inglesa debe enlazar de vuelta a la española, y ambas deben además referenciarse a sí mismas. Google lo formula sin ambigüedad en su documentación oficial: si dos páginas no se enlazan mutuamente, las etiquetas se ignoran. Un enlace en una sola dirección no es, para Google, una señal hreflang válida, simplemente se pasa por alto.

Los códigos de idioma incorrectos son el segundo bloque de errores. Es habitual intentar usar solo un código de país sin código de idioma, por ejemplo "MX" en lugar de "es-MX"; según Google eso es inválido, un código de país por sí solo no se acepta. Igual de habitual es invertir el orden, por ejemplo "MX-es" en vez de "es-MX". Ambos casos hacen que Google ignore la entrada afectada.

Los códigos de región no válidos son el tercer bloque: algunas webs usan códigos que suenan familiares pero que oficialmente no pertenecen a ISO 3166-1 Alpha-2, como "EU" para Europa, "UN" para Naciones Unidas o "UK" para el Reino Unido, cuando lo correcto es "GB". Esos códigos reservados o no asignados no son reconocidos por Google.

Un cuarto error, del que se habla menos, tiene que ver con páginas bloqueadas o excluidas del rastreo: si un enlace hreflang apunta a una URL bloqueada por robots.txt o con etiqueta noindex, Google no puede evaluar esa versión, aunque responda con código 200. Para el buscador, una página bloqueada no es un destino válido para una señal de idioma, igual que en el caso de una redirección falta, en la práctica, una página final accesible e indexable.

• Cada versión de idioma se referencia a sí misma y a todas las demás, incluyendo un x-default coherente para idiomas o regiones no cubiertos.
• La URL usada en hreflang coincide carácter por carácter con la usada en la canonical de la página de destino, incluida la barra final y las mayúsculas o minúsculas.
• Cada enlace hreflang apunta a una URL que responde directamente con código 200, nunca a una redirección ni a una URL con noindex.
• Tras cualquier cambio de estructura de URL, se revisa el código de estado real de todas las URL de destino de hreflang, no solo el de la nueva estructura.
• Los códigos de idioma siguen ISO 639-1 y los códigos de región opcionales siguen ISO 3166-1 Alpha-2, siempre en el orden idioma antes que país.
• Con muchas versiones de idioma conviene gestionar hreflang desde el sitemap XML en lugar de con etiquetas link sueltas en el head, así se reduce el riesgo de errores manuales.

• El enlace hreflang apunta a una URL que a su vez redirige con 301 o 302, en lugar de a la página final.
• Faltan referencias de vuelta: la página A enlaza a la página B mediante hreflang, pero B no enlaza de vuelta a A.
• Se invierte el orden de idioma y país, por ejemplo "MX-es" en lugar de "es-MX".
• Se indica un código de país sin el código de idioma correspondiente, algo que Google no acepta.
• Se usan códigos de región reservados o no válidos, como "EU", "UN" o "UK", en vez del código de país correcto.
• La URL de hreflang y la URL canonical de la misma página difieren mínimamente, por ejemplo por una barra final de más o de menos.