hreflang: cómo señalar idiomas sin romper el sitio

Respuesta breve

En webs con varios idiomas, hreflang indica a los buscadores que varias URLs son versiones equivalentes de un mismo contenido en distinto idioma o región, para que muestren la que corresponde a cada usuario. No es un factor de posicionamiento ni traduce nada: solo agrupa alternativas ya existentes. Funciona cuando cada versión se declara a sí misma, todas se declaran entre sí y los códigos son válidos. Roto o incompleto, el buscador lo ignora y elige por su cuenta.

Puntos clave

• hreflang es una señal, no una directiva: Google puede desatenderla si las anotaciones se contradicen.
• Elige una sola forma de implementarlo — HTML, cabecera HTTP o sitemap — y no mezcles.
• Cada versión debe incluirse a sí misma y enlazar a todas las demás con URLs absolutas.
• El código de idioma es obligatorio; el de región es opcional y no puede ir solo.
• El canonical de cada versión apunta a sí misma, nunca a otro idioma.
• Sin traducción real detrás, hreflang no arregla un problema de contenido duplicado.

Las condiciones de un grupo válido

1. Una sola forma de implementarloHTML, cabecera HTTP o sitemap; sin mezclar.
2. Cada versión se declara a sí mismaY enlaza a todas las demás con URLs absolutas.
3. Códigos válidosIdioma obligatorio; región opcional y nunca sola.
4. Canonical a sí mismaNunca al idioma original.
5. Traducción real detrásSin ella no arregla un duplicado.

Índice

1. Qué resuelve hreflang y qué no
2. Las tres formas de implementarlo
3. Códigos de idioma y región
4. Reciprocidad y autorreferencia
5. x-default y el selector de idioma
6. hreflang y canonical
7. Traducciones parciales y catálogos desiguales
8. Validación y mantenimiento
9. Errores frecuentes
10. Próximo paso

Qué resuelve hreflang y qué no

El problema que resuelve es concreto: tienes la misma página en español y en inglés, ambas indexadas, y quieres que un usuario de Reino Unido reciba la inglesa aunque la española sea la que mejor posiciona. hreflang comunica esa equivalencia. La documentación de Google sobre versiones localizadas lo describe como un método para señalar alternativas, no como un mecanismo de indexación.

Lo que no resuelve, y conviene tener claro antes de invertir horas:

• No mejora el posicionamiento de ninguna versión por sí mismo.
• No fuerza la indexación de una página que el buscador ha decidido no indexar.
• No sustituye a una arquitectura de URLs coherente por idioma.
• No impide que un usuario llegue a la versión «equivocada» desde un enlace directo.
• No aplica a contenidos que no son equivalentes entre sí.

Ese último punto es el que más proyectos rompe. Si la página inglesa es un resumen de tres párrafos y la española una guía completa, no son alternativas: son contenidos distintos que compiten. Antes de anotar nada, comprueba que la equivalencia existe de verdad. Si no existe, el trabajo previo es de contenido, no de etiquetas.

Las tres formas de implementarlo

Google acepta tres implementaciones equivalentes en efecto, distintas en coste operativo.

Las tres formas de implementar hreflang: dónde vive cada una, cuándo conviene y qué cuesta.

Método	Dónde vive	Cuándo conviene	Coste
Etiquetas link en el <head>	HTML de cada página	Pocos idiomas, CMS con control de plantilla	Peso en el HTML: n×n etiquetas
Cabecera HTTP Link	Respuesta del servidor	PDF y ficheros sin <head>	Requiere control de servidor o CDN
Sitemap XML	Fichero de sitemaps	Muchas URLs y muchos idiomas	Generación automatizada obligatoria

La regla práctica: con dos o tres idiomas, las etiquetas en el <head> son suficientes y fáciles de auditar. A partir de ahí el HTML crece de forma cuadrática — diez idiomas son diez etiquetas en cada una de las diez páginas — y el sitemap se vuelve la opción sensata. Lo que no debe hacerse es implementar dos métodos a la vez «por seguridad»: cuando se contradicen, se contradicen de forma invisible, y la depuración se multiplica. Si migras de un método a otro, retira el anterior en el mismo despliegue.

Códigos de idioma y región

El valor de hreflang usa un código de idioma en formato ISO 639-1 y, opcionalmente, un código de región en formato ISO 3166-1 Alpha-2 separado por guion. Tres consecuencias prácticas:

• es es válido; es-ES es válido; ES a secas no lo es, porque un código de región no puede aparecer sin idioma.
• El código de región es el del país, no el del idioma: el inglés de Reino Unido es en-GB, y en-UK es un error frecuente porque UK no es el código ISO del país.
• Un código inválido invalida esa anotación concreta, no necesariamente todo el conjunto, pero deja a esa versión fuera del grupo.

Decidir si necesitas región es una decisión de negocio antes que técnica. Si el contenido, el precio y las condiciones son idénticos para todos los hispanohablantes, es basta y se mantiene solo. Si tienes tienda española y mexicana con precios, impuestos y envíos distintos, es-ES y es-MX describen algo real. Fragmentar por región sin diferencia real de contenido añade mantenimiento sin ganar nada.

Reciprocidad y autorreferencia

Son las dos condiciones que más implementaciones incumplen, y las dos que hacen que el conjunto entero deje de funcionar.

Autorreferencia: cada página debe incluirse a sí misma en su propia lista de anotaciones. La versión española lista la española, la inglesa y la francesa. Omitirse a uno mismo es el error más común en implementaciones hechas a mano.

Reciprocidad: si A declara a B como alternativa, B debe declarar a A a su vez. Google trata las anotaciones sin retorno como no confirmadas y puede descartarlas. Un enlace de vuelta que falta convierte un grupo de cinco idiomas en un conjunto de fragmentos sueltos.

A esto se añade una condición menos citada: las URLs deben ser absolutas e incluir el protocolo. Una anotación relativa o apuntando a http:// cuando el sitio sirve en https:// genera un grupo que no cierra. Y deben ser URLs que respondan 200 y sean indexables: anotar una página con noindex o que redirige es declarar como alternativa algo que el buscador no puede ofrecer.

x-default y el selector de idioma

El valor x-default señala la página que debe servirse cuando ninguna otra versión encaja con el usuario. No es «la versión por defecto del sitio» ni «la más importante»: es la salida para los casos no cubiertos.

Dos usos legítimos: un selector de idioma real, sin contenido propio, que deja elegir; o la versión más general del contenido — habitualmente la internacional en inglés — cuando no existe página de selección. Es opcional. Si todas las combinaciones relevantes están cubiertas, puedes prescindir de él.

Lo que conviene evitar es la redirección automática por IP o por cabecera Accept-Language sin escapatoria. Un rastreador que llega desde una IP concreta acabará viendo siempre la misma versión, y un usuario que quiere leer en otro idioma queda atrapado. Si detectas idioma, sugiérelo con un aviso visible y deja el enlace directo a las demás versiones accesible en el HTML.

hreflang y canonical

Son señales independientes que se contradicen con facilidad. Cada versión de idioma debe llevar su canonical apuntando a sí misma. El canonical dice «esta es la URL principal de este contenido»; hreflang dice «y estas otras son sus equivalentes en otros idiomas».

El fallo clásico consiste en poner el canonical de todas las versiones apuntando a la española porque «es la original». Con eso le estás diciendo al buscador que las demás no deben indexarse, y a la vez le pides que las muestre como alternativas. Gana el canonical, desaparecen las versiones y el trabajo de traducción se pierde. Si necesitas repasar el mecanismo, la guía sobre errores con la etiqueta canonical desarrolla los casos donde el contexto cambia la decisión.

Mismo criterio con paginación, parámetros y versiones AMP si quedan: hreflang debe apuntar a la URL canónica de cada idioma, no a una variante con parámetros de sesión o de campaña.

Traducciones parciales y catálogos desiguales

Casi ningún proyecto real tiene paridad completa entre idiomas. El blog está en español, la tienda en tres idiomas y las fichas legales solo en el idioma del país. Eso es normal y no exige inventar traducciones.

El criterio: anota como alternativas únicamente las páginas que existen y son equivalentes. Una página sin traducción sencillamente no participa en el grupo. No la anotes contra la portada del otro idioma ni contra una página genérica: eso declara una equivalencia falsa y deteriora el conjunto.

Para contenido semitraducido — plantilla traducida y cuerpo en el idioma original — piensa en qué recibe el usuario. Una página con navegación en francés y texto en español no es una versión francesa. Es preferible mantener menos idiomas bien cubiertos que declarar un mapa completo sostenido por traducción automática sin revisar.

Una página con navegación en francés y texto en español no es una versión francesa.

Validación y mantenimiento

hreflang se rompe con el tiempo, no en el despliegue: URLs que cambian, páginas retiradas, idiomas que se añaden sin actualizar los grupos existentes. Necesita comprobación periódica, no una revisión única.

• Rastrea el sitio y extrae todas las anotaciones con su URL de origen y destino.
• Comprueba que cada grupo cierra: si A declara a B, B declara a A, y toda página se incluye a sí misma.
• Verifica el estado HTTP de cada destino: descarta redirecciones, 404 y páginas con noindex.
• Contrasta las URLs anotadas con las del sitemap; si no coinciden, tienes dos fuentes de verdad.
• Revisa los códigos contra las listas ISO, no de memoria.
• Repite la comprobación después de cada migración, cambio de slug o alta de idioma.

Cuando las anotaciones viajan en el sitemap, la validación de ese fichero deja de ser un trámite; el método aplicado en la validación del sitemap XML sirve igual aquí. Y conviene no confundir un problema de idioma con uno de indexación: si una versión no aparece en resultados, primero determina si está rastreada e indexada — la distinción entre rastreo e indexación evita atribuir a hreflang un fallo que ocurre antes.

En cuatro láminas

HTML · en cada versión, incluida ella misma: <link rel="alternate" hreflang="es" / href="https://ejemplo.es/guia/"> / <link rel="alternate" hreflang="en" / href="https://ejemplo.es/en/guide/"> / <link rel="alternate" hreflang="x-default" / href="https://ejemplo.es/"> / / <!-- canonical de cada versión: a sí misma -->

1 forma de implementarlo. HTML, cabecera HTTP o sitemap. Sin mezclar: dos fuentes con contenidos distintos se contradicen.

Solo los que existen. Columnas: Válido. es: Válido → Sí: idioma. en-GB: Válido → Sí: idioma y región. en-UK: Válido → No: la región no existe. es-LA: Válido → No: «LA» no es un país

Errores frecuentes

• Omitir la autorreferencia en cada página del grupo.
• Anotaciones sin enlace de vuelta desde la versión de destino.
• Usar en-UK, es-LA o cualquier código que no exista en las listas ISO.
• Poner el canonical de todos los idiomas apuntando a la versión original.
• Implementar a la vez etiquetas en el HTML y anotaciones en el sitemap con contenidos distintos.
• Declarar como alternativa una URL que redirige o devuelve 404.
• Usar URLs relativas o con protocolo incorrecto.
• Redirigir por IP sin dejar acceso a las demás versiones.
• Anotar traducciones automáticas sin revisar como si fueran versiones equivalentes.
• Esperar una mejora de posiciones: hreflang ordena versiones, no las promociona.

Preguntas habituales

¿hreflang mejora las posiciones?

No. Agrupa versiones equivalentes de un contenido para que se muestre la que corresponde a cada usuario; no promociona ninguna ni traduce nada. Es además una señal, no una directiva: con anotaciones que se contradicen entre sí, el buscador puede desatenderla por completo y elegir él la versión.

¿Puedo poner el canonical de todos los idiomas al original?

Es el error que más grupos rompe. El canonical de cada versión apunta a sí misma; si todas apuntan al original, se está declarando que las traducciones no son documentos propios, y entonces las anotaciones hreflang que las agrupan dejan de tener sentido. Las dos señales tienen que decir lo mismo.

¿Vale poner solo el código de región, como «es-LA»?

No: el código de idioma es obligatorio y el de región es opcional, nunca puede ir solo, y ambos tienen que existir en las listas estándar. Códigos inventados como en-UK —el correcto es en-GB— o regiones que no son países invalidan la anotación sin dar ningún aviso.

¿Qué hago si no tengo todo el sitio traducido?

Anotar solo lo que existe de verdad. Un grupo hreflang declara equivalencias, así que incluir una URL que redirige, devuelve 404 o lleva a la portada rompe el grupo entero. Con catálogos desiguales se agrupa página a página, y las que no tienen equivalente sencillamente no se anotan.

Próximo paso

Extrae de un rastreo todas las anotaciones actuales y monta una matriz de origen y destino. Marca cada celda que no cierra, cada destino que no devuelve 200 y cada canonical que apunta fuera de su propio idioma. Corrige primero los grupos que afectan a páginas con tráfico o conversión, y deja documentada la regla que genera las anotaciones para que el próximo idioma no vuelva a romperlas.

Fuentes

• Google Search Central, versiones localizadas y hreflang — documentación oficial.
• Google Search Central, sitios multirregionales y multilingües — documentación oficial.
• IETF, BCP 47: etiquetas de identificación de idiomas — documentación oficial.

Servicio relacionado

Si esto es lo que te está pasando, seo técnico es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver seo técnico