Hreflang explicado con los errores más comunes

Hreflang no mejora tus posiciones: solo le dice al buscador qué versión de idioma o región mostrar a cada usuario en un resultado que ya te habías ganado. Por eso los fallos son tan difíciles de detectar — nada se cae, simplemente Google ignora la anotación y sigue mostrando la versión que él decida. Los errores que la rompen son casi siempre los mismos seis: falta de reciprocidad, códigos inválidos, ausencia de autorreferencia, x-default olvidado, canonicals que contradicen las etiquetas y URLs relativas. Puedes montar el bloque correcto en un minuto con el generador de etiquetas hreflang de Docuboxer, que funciona íntegramente en tu navegador.

Qué hace hreflang de verdad

Hreflang es una anotación entre URLs equivalentes en distinto idioma o región. Le dice al buscador: "estas páginas dicen lo mismo para públicos distintos; elige la adecuada". No es una directiva —Google la trata como señal, no como orden— y no traslada autoridad entre versiones. Tampoco resuelve la duplicación: dos páginas casi idénticas en inglés británico y estadounidense siguen siendo casi idénticas, hreflang solo evita que el buscador muestre la equivocada.

El beneficio real es de experiencia: un lector mexicano que aterriza en la versión en inglés se marcha. Ese es el problema que hreflang ataca, y por eso la métrica que debería moverse no es la posición media, sino el rebote y la conversión por país.

Error 1: falta de reciprocidad (return tags)

Es el fallo más común con diferencia. Si la página española declara a la inglesa pero la inglesa no declara a la española, Google descarta el grupo entero. La regla es simétrica y no admite excepciones: todas las páginas del grupo deben listar a todas las demás, incluida ella misma. Si tienes tres idiomas, cada una de las tres páginas lleva tres etiquetas.

Los sitios que traducen por oleadas caen aquí sin darse cuenta: publican la versión en francés apuntando a la española, pero la española nunca se regenera y se queda sin el return tag. Cualquier despliegue que añada un idioma tiene que revalidar las páginas ya publicadas.

Error 2: códigos de idioma o región inválidos

El formato es idioma o idioma-región, con idioma en ISO 639-1 y región en ISO 3166-1 alpha-2. Suena trivial y aun así estos cuatro se ven a diario:

• es_MX con guion bajo — es un locale de sistema operativo, no un valor de hreflang. Debe ser es-MX.
• spanish, castellano o español — solo valen los códigos, no los nombres.
• MX a secas — no existe hreflang solo de región. El idioma es obligatorio; la región, opcional.
• en-UK — el código de país del Reino Unido es GB. UK no está en la norma.

Un código inválido invalida esa etiqueta concreta, no el grupo entero, pero el efecto práctico es el mismo: esa versión deja de existir para el buscador. Y ojo con la región: es-MX no significa "español para hispanohablantes", significa "español para usuarios en México". Si tu contenido no tiene nada específico de un país, quédate en es a secas y evítate el problema.

Error 3: no autorreferenciarse

Cada página debe incluir una etiqueta que apunte a sí misma. Es contraintuitivo —"ya sé qué idioma soy"— pero es parte de la especificación: sin la autorreferencia, el conjunto queda incompleto y las validaciones fallan. Cuando generas las etiquetas con una plantilla, esto sale gratis; cuando las escribes a mano por página, es lo primero que se olvida.

Error 4: olvidar x-default

x-default declara qué versión mostrar cuando ninguna encaja. Un usuario que busca en alemán, en un sitio con español e inglés, no tiene versión asignada: sin x-default, el buscador decide solo. No es obligatorio y su ausencia no rompe nada, pero es la diferencia entre elegir tú el fallback o dejarlo al azar. Apúntalo a tu versión por defecto o a una página con selector de idioma — nunca a una versión regional específica.

Error 5: hreflang contra canonical

Este es el que más tráfico cuesta. Si la página inglesa lleva canonical hacia la española (algo habitual cuando se copia la plantilla de un idioma a otro), le estás diciendo a Google que la inglesa no debe indexarse. Y una página no indexable no puede ser el destino de un hreflang: la anotación entera se cae.

La regla es corta: cada versión de idioma es canónica de sí misma. El canonical cruzado existe para duplicados reales (una ficha accesible por dos rutas), no para traducciones. Si no tienes claro qué canonical está emitiendo cada página, revísalo junto con el resto de etiquetas del head con el analizador de meta tags.

Error 6: URLs relativas, o no canónicas

El href de un hreflang debe ser una URL absoluta y completa, con protocolo y host: /en/blog/... no vale. Y debe ser exactamente la URL canónica de destino. Los tres deslices típicos son apuntar a http:// cuando el sitio ya redirige a https://, mezclar host con y sin www, y dejar parámetros de campaña pegados en la URL. Cada redirección intermedia es una oportunidad para que la validación falle.

Cómo lo hace Docuboxer

Este sitio sirve el español en la raíz (/blog/...) y el inglés bajo /en, con hreflang recíproco entre ambos y x-default apuntando siempre al español, que es el idioma por defecto. La parte interesante está en el blog: los slugs no coinciden entre idiomas por diseño. Este post vive en /blog/hreflang-errores-comunes y su equivalente inglés en /en/blog/hreflang-mistakes-international-seo, porque cada uno se escribe contra la intención de búsqueda de su mercado, no como traducción literal.

Eso descarta el atajo habitual —asumir el mismo path con prefijo de idioma— así que cada post declara su contraparte explícitamente en un registro central, y las etiquetas se generan desde ahí. El resultado, en esta misma página:

<link rel="alternate" hreflang="es"
      href="https://www.docuboxer.com/blog/hreflang-errores-comunes" />
<link rel="alternate" hreflang="en"
      href="https://www.docuboxer.com/en/blog/hreflang-mistakes-international-seo" />
<link rel="alternate" hreflang="x-default"
      href="https://www.docuboxer.com/blog/hreflang-errores-comunes" />

Con una decisión deliberada: cuando un post todavía no tiene versión en el otro idioma, no emitimos ninguna etiqueta hreflang, solo su canonical. Una anotación que apunta a una traducción inexistente es peor que no tener anotación — es precisamente el error 1 servido en bandeja. Generar las etiquetas desde el mismo registro que alimenta el sitemap XML evita que las dos fuentes se desincronicen, que es como empiezan la mayoría de los problemas de reciprocidad.

Cómo verificarlo sin herramientas de pago

Abre el código fuente de una página, copia todas las URLs de sus etiquetas hreflang y visita cada una comprobando que devuelve el mismo bloque. Es tedioso y por eso se automatiza, pero con dos o tres idiomas es perfectamente viable a mano y suele destapar la mayoría de los fallos. Añade tres comprobaciones más: que cada URL responda 200 sin redirección, que ninguna esté bloqueada por robots.txt —una página bloqueada no puede ser destino de hreflang— y que el lang del <html> coincida con el idioma que declaras.

Y una expectativa honesta para el final: aunque lo hagas todo bien, Google puede seguir mostrando otra versión. Hreflang es una señal fuerte, no una orden. Lo que sí consigues es eliminar los casos en los que la versión equivocada aparece por culpa tuya, que son la inmensa mayoría.

Preguntas frecuentes

Herramientas relacionadas

• Generador de hreflang — Etiquetas recíprocas y x-default para todas tus versiones de idioma.
• Analizador de meta tags — Comprueba canonical, title y descripción de cada versión.
• Generador de sitemap XML — La otra fuente de verdad de tus URLs por idioma.
• Vista previa en Google — Cómo se ve cada versión antes de publicarla.

También te puede interesar: herramientas SEO gratuitas que funcionan sin registro y qué es un slug de URL y cómo elegirlo.